> -----Original Message----- > From: netstack-bounces+snaiksat=cisco....@lists.launchpad.net > [mailto:netstack-bounces+snaiksat=cisco....@lists.launchpad.net] On > Behalf Of Robert Kukura > Sent: Tuesday, April 24, 2012 12:09 PM > To: netstack@lists.launchpad.net > Subject: Re: [Netstack] L3/IPAM summit discussion follow-up... > > 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
Hi Bob, Those are good questions, and I am not completely clear on this as well (I don't recall a discussion on this during the summit either). I believe that the team implementing the IPAM functionality has a plan around how to integrate this functionality, possibly as libraries which the Quantum plugins can use? On the implementation of the L3 functionality (with reference to our proposal), our earlier suggestion was that it be implemented as a separate plugin from that of a L2 plugin. It seemed like a more modular approach with the advantage of being able to use different combination of plugins. I do recall reading some concerns in this list around ensuring the compatibility of L3 and L2 plugins. This is a valid concern, however, plugin configuration is a cloud-operator/SP activity, who will probably have good knowledge of the plugin behavior and hence can ensure the configuration of compatible plugins. Of course, if one wants to implement everything in the same plugin, that should still be possible. Thanks, ~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 -- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
