Hi Troy, All, Thanks for this pointer. Yes I agree, there are constructs in here like the subnet which can be leveraged by a L3 (forwarding) component implementation. So just to build on this, and assuming that the IPAM component will be integrated into Quantum (btw, is that already decided?), the L3 forwarding component's realization can make calls to the IPAM component to store/retrieve information pertaining to the subnets, and possibly routes etc. Effectively, this IPAM interface can be used internally by the Quantum service, and/or other privileged entities (say, the nova service).
However, we still need to have the L3 abstractions defined on the tenant/user side. For instance, take the example of the gateway IP address. Per the Melange API, a static route can be created, and requires a gateway IP address. This piece of information is more likely defined by the service provider. However, the tenant still needs to convey that a particular subnet's default route should be to, say, the public network. Hence, the tenant facing API needs to have the constructs to be able to express this. Here is a flow with some pseudo-calls: User:create_route() -> Quantum-L3-API:create_route() -> Quantum-IPAM:store_route() (1) User:create_route() conveys that a particular subnet (provides UUID) should have a default route to the public network. (2) Quantum:L3-API:create_route() realizes the call in step (1) inside the Quantum service, and configures the underlying infrastructure such that VMs instantiated on this subnet will have a default route to the public network. While doing so it determines what the gateway IP address is for that default route. (3) Quantum-IPAM:store_route() results in the gateway IP address determined in step (2) being stored in the IPAM, such that when a VM comes up, this information can be pulled from here. Just wanted to spell this out; it is probably in line with what you are thinking as well? Thanks, ~Sumit. > -----Original Message----- > From: Troy Toman [mailto:troy.to...@rackspace.com] > Sent: Tuesday, April 03, 2012 3:28 PM > To: Sumit Naiksatam (snaiksat) > Cc: Jason Kölker; <netstack@lists.launchpad.net> > Subject: Re: [Netstack] L3 Forwarding > > Sumit, > > You can see the latest Melange documentation here: > > http://melange.readthedocs.org/en/latest/apidoc.html > > There is a section on static routes and a call for creating a tenant > subnet that I think are relevant. It does not fully implement a routing > mechanism. But, may be useful for implementing an L3 service. > > Troy > > On Apr 3, 2012, at 4:41 PM, Sumit Naiksatam (snaiksat) wrote: > > > 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
