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
* 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? * 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? 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
