Thanks Andi. Responses inline... > -----Original Message----- > From: andi abes [mailto:andi.a...@gmail.com] > Sent: Wednesday, April 11, 2012 7:22 PM > To: Dan Wendlandt > Cc: Sumit Naiksatam (snaiksat); netstack@lists.launchpad.net > Subject: Re: [Netstack] L3 Forwarding > > A few (short) thoughts and questions: > > * Might be useful to add a use case where a tenant brings their own > network service. As Dan points out, a popular case is a load-balancer > VM. Another interesting set of cases could be encountered in private > cloud environments, where specialized network resources can be > utilized as l3 services (e.g. physical firewalls), as long as quantum > can be made aware of them >
<Sumit> Yes good point. In general, there are probably at least three scenarios which need to be accounted for - * A load balancer like service is provided by the Service Provider. E.g. Amazon provides Elastic Load Balancer service. In this case the service is being provided by the same entity which is also managing the other network infrastructure. * A user wants to deploy his own service. E.g. User has a Load balancer VM and wants to use that to front end his server VMs. * The service is offered by a 3rd party (it's neither the SP nor the user himself). This may not be relevant for all kinds of services, but this does introduce issues of access control. </Sumit> > * There's some interesting verbiage in the Targets section: > " > This operation returns the list of all the targets which are available > to this particular tenant. These will contain a list of system (i.e. > SP-published targets), and there might be > others which are published by other tenants. > " > Is the thought that the API to register and manage these targets is SP > specific? Or would it be included in this API? <Sumit> The thinking on this has evolved from what is mentioned in this email thread. We want to make a distinction between target-types which are abstract, and targets which are realization of those target-types (actual entities). Target-types would be made available by a SP to the tenants (and would be specific to the tenant's context). Tenants would request creation of targets of a particular type. More details in the revised proposal here: http://wiki.openstack.org/quantum-l3?action=AttachFile&do=view&target=revised-quantum-l3-forwarding-model-sumitnaiksatam-2.pdf </Sumit> > > * Authn ... in the face of multi-tenants. I realize that there are > other threads on this, but it ties nicely with the targets discussion > - how do tenants control which other tenants have access to the > services they might be willing to "publish" as targets? <Sumit> Very good point. I was checking the Keystone use cases page, and I think a similar use case has been listed where a one tenant needs to perform some operation on behalf another tenant. So yes, we will need the support from Keystone. </Sumit> > > > > a. > > On Wed, Apr 11, 2012 at 5:09 PM, Dan Wendlandt <d...@nicira.com> wrote: > > > > > > On Mon, Apr 2, 2012 at 8:59 PM, Sumit Naiksatam (snaiksat) > > <snaik...@cisco.com> wrote: > >> > >> Hi All, > >> > >> Per the context setup by Dan in his email on the topic of Quantum L3 > >> Forwarding, here is an addition we are making to the earlier > proposal - > >> API/specification pertaining to creating and managing "targets". I > have > >> updated the API specification with this addition and posted the new > >> version of the document online. As before, you can find it on the > wiki: > >> http://wiki.openstack.org/quantum-l3 (please refer to the pdf > attached > >> therein, version 5). The new additions are in Section 8 (in case you > >> want to go straight to those). > >> > >> 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. > > > > > > I'm still trying to wrap my head around this exactly, so let me ask a > > clarifying question: Is a "Routetable" correspond to both a > forwarding rule > > in the L3-forwarding element, and the description of what routing > should be > > configured within the VM (e.g., default gateway)? > > > > These two things are definitely related, though one thing I'm > struggling > > with is what happens if a user changes a route table after a VM has > been > > booted. Is the assumption that the we can update such config on the > VM? Or > > that the state would be inconsistent? > > > > Also, how to I describe the routing config that should go inside a VM > in a > > scenario where I don't want Quantum to be performing the L3 > forwarding > > (e.g., I have a load-balancer virtual server that is acting as my > gateway). > > > > > > Sorry, I think I need to re-read the proposal again before the > summit, as > > some of it is still fuzzy :) > > > > Dan > > > > > >> > >> > >> 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! > >> > >> ~Sumit. > > > > > > > > > > -- > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Dan Wendlandt > > Nicira, Inc: www.nicira.com > > twitter: danwendlandt > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > > -- > > 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
