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. 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.
-- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
