From: netstack-bounces+snaiksat=cisco....@lists.launchpad.net [mailto:netstack-bounces+snaiksat=cisco....@lists.launchpad.net] On Behalf Of Dan Wendlandt Sent: Tuesday, April 24, 2012 1:38 PM To: Robert Kukura Cc: netstack@lists.launchpad.net Subject: Re: [Netstack] L3/IPAM summit discussion follow-up... I think we're having a bit of a terminology clash here, at least according to what I intended by the definitions posted on the etherpad: http://etherpad.openstack.org/quantum-folsom . The existing definitions for "IPAM" and "L3 Forwarding" are below. <Sumit> During the summit we called the proposal - "L3 Tenant-facing Abstractions/Model". I don't recall any differences of opinion on this, is everyone comfortable with this? </Sumit> I believe that at the end of Sumit's presentation we decided that his proposal was a higher-level abstraction on top of our existing "IPAM" plan from merging Melange. In particularly, the "route-table" was about what routes that would be injected into the VM such that the VM would have different next hops (route information injected into the VM is within the scope of Melange IPAM). I believe we concluded that these route-tables were NOT about implementing "L3 forwarding" between two different "L2 Quantum Networks". <Sumit> The route-tables (and the entries therein) are proposed as an abstraction for the tenant to request forwarding between subnets (and also to service-gateways, referred to as "targets"). The underlying implementation (realizing the abstraction) could implicitly/explicitly map the subnets to L2 networks and achieve the L3 forwarding as required. I believe this was fairly well understood. In that context, I am having trouble understanding the above explanation.</Sumit> We talked separately about an "L3 forwarding" implementation, that would allow pluggable implementations of a logical L3 forwarding element capable of achieving nova-parity, namely: basic L3 forwarding, SNAT, and DNAT (i.e., what is already implemented in linux_net.py). This L3 forwarding element would be able to route between multiple Quantum L2 networks (one might call it a "router", but apparently that's discouraged :P ). <Sumit> It will be helpful if you can please point us to the session/slides where this "L3 forwarding element" was discussed? </Sumit> I'm REALLY hoping that we're all on the same page here, otherwise, we may need to start back at square one :) Dan - IP Address Management (IPAM): * How virtual servers as allocated IP addresses based on their network connectivity (http://en.wikipedia.org/wiki/IP_address_management) * Often includes other network identifiers that are also configured on a virtual server, including MAC address, subnet mask gateways, routes, DNS servers, etc. * This type of functionality is currently provided by Melange, which will be integrated into Quantum during Folsom. * IPAM is needed even if VMs are only connected to L2 Quantum networks (i.e., it does not required "L3 forwarding" or other logical features described below). * Note: this does NOT specify how these identifiers are "injected" into the server itself (could be via disk injections, DHCP, cloud-init+metadata, statically configured by admin) - L3 Forwarding * Quantum "networks" provide an L2 service model. There are use cases that require connecting virtual servers that are not on the same L2 network + subnets, and are therefore connected only by an element performing L3 forwarding. * Note: this L3 forwarding element is a logical abstraction. We make no statement how how it is implemented (e.g., by a VM appliance, a physical router, or something else). * These L3 forwarding elements would likely expose some kind of a "routing table" to describe the rules used to forward between different L2-subnets. * A common use case is that an L2-network/subnet is a trust domain (private tenant networks, tier of a web application), yet communication is required between trust domains. * We separate out firewall and NAT into a separate discussion, below. * L3 forwarding has a dependency on understanding the IPAM data for a particular subnet that it is connected to (e.g., network address/mask, gateway address) * Note: the primary focus of this is defining L3 forwarding between endpoints WITHIN a Quantum deployment. Connectivity between different Quantum deployments, or to remote datacenters not running Quantum is viewed many as a separate service (e.g., L3VPN-service). On Tue, Apr 24, 2012 at 12:08 PM, Robert Kukura <rkuk...@redhat.com> wrote: On 04/24/2012 10:12 AM, Sumit Naiksatam (snaiksat) wrote: > Hi All, > > Thanks for your feedback on the L3 (forwarding) proposal during the > summit and also prior to that. The action item coming out of the summit > session was to further discuss this with the Melange/IPAM team to > identify points of overlap and/or what are the additional requirements. > Accordingly, after focused discussions with many folks including Troy, > Jason, and Trey from the Melange team, it seems that we are pretty much > on the same page in terms of what the L3 (forwarding) proposal wants to > achieve and how IPAM will support the data-store aspects of this. > > There are constructs like the ip_block in (former) Melange which map to > the Subnet (in the L3 forwarding proposal). There are others like the > route-table and targets which might not have a direct mapping, and which > might need to be realized separately. These in turn might drive further > requirements on the IPAM component, but this will be clearer once we > start implementing the L3 forwarding proposal. Also, realizing the > target abstraction will need plugin-level support which might differ > based on the type of the target being realized and the underlying > network infrastructure. So the plan is to go forward with the > implementation of both IPAM and L3 route-table/target API, with both > going into the trunk branch. The work on L3 will hopefully drive any > further needs on the IPAM component. > > Specifically on the ip_block/subnet construct, the current thought is to > call it a Subnet. Also, this is better modeled as a separate construct, > rather than an attribute in the virtual network resource, since we > should be able to model 1:n and n:1 relationships between L3 and L2 > networks. > > Please let us know if you have any further thoughts on this. If you > missed this session during the summit, the slides are posted here: > http://www.slideshare.net/sumit_naik/summit-prepquantuml3modelsumit9 > > Thanks, > ~Sumit. > This all sounds reasonable to me, as far as it goes. I was at the quantum summit sessions and re-read the slides and proposal, but I'm still not at all clear on how the melange and L3-forwarding functionality will relate to quantum plugins: 1) Is the merge of melange into quantum going to be pluggable, or is the IPAM implementation going to be built directly into quantum-server (or a separate server)? 2) If the IPAM functionality is going to be pluggable, will this be part of the same plugin handling L2, or will it be a separate plugin that can be configured independently of the the L2 plugin? 3) I expect that the L3-forwarding functionality will be pluggable. Will this be handled by the same plugin as L2 and/or IPAM, or as a separate L3 plugin? Thanks, -Bob -- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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
