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
