Hi Dan, All,
I missed this one...I think I responded to another email in which you had similar questions, but I noticed that the netstack mailer was not copied on that (thanks for the feedback!). Some responses/thoughts inline. Discussion to be continued on the white board! J I believe this session is still targeted for 3 PM, Tuesday. Updated proposal here: http://wiki.openstack.org/quantum-l3?action=AttachFile&do=view&target=re vised-quantum-l3-forwarding-model-sumitnaiksatam-2.pdf Thanks, ~Sumit. From: Dan Wendlandt [mailto:d...@nicira.com] Sent: Wednesday, April 11, 2012 2:09 PM To: Sumit Naiksatam (snaiksat) Cc: netstack@lists.launchpad.net; Brad Hall; Carl Perry Subject: Re: L3 Forwarding 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)? <Sumit> Yes, that is thinking. </Sumit> 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? <Sumit> We could take either approach, but it should be possible to update the config as well, right? May be using shorter DHCP leases? </Sumit> 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). <Sumit> I think you will find that this is covered in the cases where a target can be created by pointing it to a resource owned by the tenant (LB in a VM as you state here), or to a resource owned by a 3rd party. </Sumit> 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
