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
