Hi Troy, Thanks for your response. Would you be able to point us to more information on the L3 constructs/abstractions you mention? That way we can unify the ideas and arrive at a richer model. We have looked at the Melange wiki and the pointers therein to the base API which is for storing and retrieving network information. However, this API does not seem to represent a L3 routing/forwarding model which can drive the underlying implementation.
Thanks, ~Sumit. > -----Original Message----- > From: Troy Toman [mailto:troy.to...@rackspace.com] > Sent: Tuesday, April 03, 2012 5:56 AM > To: Sumit Naiksatam (snaiksat) > Cc: Jason Kölker; <netstack@lists.launchpad.net> > Subject: Re: [Netstack] L3 Forwarding > > > On Apr 3, 2012, at 12:24 AM, Sumit Naiksatam (snaiksat) wrote: > > > Hi Jason, > > > > Per the information published, Melange is an IPAM service > (information repository for the network). Isn't that fundamentally > different in function from the notion of L3 > abstractions/constructs/model required to drive routing/forwarding? > Reading the specification document referenced in the wiki will clarify > this. Melange could be an IPAM service for the proposed L3 model (these > are complementary). > > Melange was built as a network information repository that initially > focused on IPAM. One thing it does is manage IPs. But, it does have > some fundamental L3 constructs/abstractions as well. Melange > understands subnets, outside global/inside local relationships and > routes, for instance. So, it provides a foundation for many L3 > services. I look forward to talking about how we can evolve this > thinking at the summit. > > Troy > > > > > Thanks, > > ~Sumit. > > > >> -----Original Message----- > >> From: netstack-bounces+snaiksat=cisco....@lists.launchpad.net > >> [mailto:netstack-bounces+snaiksat=cisco....@lists.launchpad.net] On > >> Behalf Of Jason Kölker > >> Sent: Monday, April 02, 2012 9:16 PM > >> To: netstack@lists.launchpad.net > >> Subject: Re: [Netstack] L3 Forwarding > >> > >> On Mon, 2012-04-02 at 20:59 -0700, Sumit Naiksatam (snaiksat) wrote: > >>> Following is a summary of the additions: > >>> As you might have gleaned, the proposal until this point catered > more > >> to > >>> the tenant/user aspects of the L3 discussion, however it did not > >> address > >>> the service-provider/operator aspects. Some of the feedback we have > >>> received until now also points to the missing SP constructs. > >>> > >>> The current thinking is that this missing SP aspect should be > handled > >> in > >>> a generic way so as to be able to handle different types of L3 > >> entities > >>> like gateways, firewalls, etc. More specifically, in the context of > >> the > >>> current proposal, it amounts to introducing a SP API to manage > >>> "targets". The key attribute when creating a "target" is the IP > >> address > >>> being assigned to this "target". Also note that the definition of > the > >>> "target" is in the context of a tenant (and also one or more > >> routetables > >>> for that tenant). Given this definition, the "target" has the > >> following > >>> attributes: > >>> ID: UUID > >>> Name: Public, Private, VPN, etc. > >>> IP Address > >>> Tenant_ID: The tenant for which this "target" is applicable > >>> Routetable IDs: (Optional parameter) One or more routetable IDs > >>> belonging to this tenant for which this target is valid. This > >> provides > >>> for more granular control of the "target " applicability (from a > >> service > >>> provider perspective, e.g. the "Private" target will map to > different > >>> end points with respect to different routetables for the same > >> tenant). > >>> > >>> To illustrate this better, let's take the example of the SP having > to > >>> configure an internet gateway for a particular tenant. Let's say > >> that > >>> the tenant creates a subnet 10.0.0.0/24, and the SP uses the > >> convention > >>> of assigning the first IP in the subnet as a gateway (i.e. > 10.0.0.1). > >>>> From a logical model perspective, the SP would then create a > >> "target" > >>> with the following attributes: > >>> ID : UUID-XYZ-1 > >>> Name: Public > >>> IP Address: 10.0.0.1 > >>> Tenant_ID: UUID-Tenant-ABC > >>> Routetable IDs: [UUID-Routetable-UVW-1] > >>> > >>> The creation of this logical entity would result in the underlying > SP > >>> implementation mapping it to the requirement for the creation of a > >>> gateway entity such that on the tenant network side it would have > the > >>> 10.0.0.1 IP address, and it would have another interface to the > >> public > >>> network (with some PAT/NAT functionality). > >>> > >>> Subsequently, the tenant creates a route in the routetable > >>> UUID-Routetable-UVW-1, > >>> Source: 10.0.0.0/24, Destination: default, Target: Public > >>> > >>> When a VM is now instantiated with an interface on this subnet, the > >>> default route for the packets going out of this interface will lead > >> them > >>> to the gateway 10.0.0.1. Exactly how the L2/L3 networking is setup > to > >>> handle this connectivity from the VM to the gateway is specific to > >> that > >>> particular deployment. > >>> > >>> In the above case, the gateway could be a firewall, and which in > turn > >>> might be managed as a separate service. In that case, the SP would > >>> correlate the above created logical "target" resource with a > resource > >>> created in that firewall service. > >>> > >>> We are actively trying to make this a better/simpler proposal, and > >> any > >>> feedback/participation is very much welcome. Thanks in advance and > >> stay > >>> tuned for further iterations on this! > >> > >> I'm not saying melange is the right way to manage this, but could > you > >> elaborate the differences between this proposal and allocating an IP > in > >> melange for a device and creating a route entry for it? > >> > >> Happy Hacking! > >> > >> 7-11 > >> > >> > >> > >> -- > >> Mailing list: https://launchpad.net/~netstack > >> Post to : netstack@lists.launchpad.net > >> Unsubscribe : https://launchpad.net/~netstack > >> More help : https://help.launchpad.net/ListHelp > > > > -- > > Mailing list: https://launchpad.net/~netstack > > Post to : netstack@lists.launchpad.net > > Unsubscribe : https://launchpad.net/~netstack > > More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
