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
