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).
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
