Sridar R is planning on having a proposal for DM VPN ready (today?) that he wants to propose for Liberty release. We're going to have a VPN meeting next Tuesday (per his request), to discuss this more.
Regards, PCM On Thu, May 7, 2015 at 10:58 AM Mathieu Rohon <mathieu.ro...@gmail.com> wrote: > Hi, > > On Wed, May 6, 2015 at 8:42 AM, Salvatore Orlando <sorla...@nicira.com> > wrote: > >> I think Paul is correctly scoping this discussion in terms of APIs and >> management layer. >> For instance, it is true that dynamic routing support, and BGP support >> might be a prerequisite for BGP VPNs, but it should be possible to have at >> least an idea of how user and admin APIs for this VPN use case should look >> like. >> > > the spec [4] is mainly focusing on API and data model. Of course there > might be some overlap with BGP support and/or dynamic routing support, but > this is more about implementation details to my POV. > We hope we'll see some good progress about the API during reviews and > design summit, since it seem to suit to several players. > > >> In particular the discussion on service chaining is a bit out of scope >> here. I'd just note that [1] seems to have a lot of overlap with >> group-based-policies [2], and that it appears to be a service that consumes >> Neutron rather than an extension to it. >> >> The current VPN service was conceived to be fairly generic. IPSEC VPN is >> the only implemented one, but SSL VPN and BGP VPN were on the map as far as >> I recall. >> Personally having a lot of different VPN APIs is not ideal for users. As >> a user, I probably don't even care about configuring a VPN. What is >> important for me is to get L2 or L3 access to a network in the cloud; >> therefore I would seek for common abstractions that might allow a user for >> configuring a VPN service using the same APIs. Obviously then there will be >> parameters which will be specific for the particular class of VPN being >> created. >> > >> I listened to several contributors in the area in the past, and there are >> plenty of opinions across a spectrum which goes from total abstraction >> (just expose "edges" at the API layer) to what could be tantamount to a >> RESTful configuration of a VPN appliance. I am not in a position such to >> prescribe what direction the community should take; so, for instance, if >> the people working on XXX VPN believe the best way forward for them is to >> start a new project, so be it. >> > > that's what BGP VPN and Edge VPN did by creating their own stackforge > project. But I think the idea was more about sharing the framework upstream > after failing at finding a consensus during design summits, rather than > promoting the fact that this has nothing to do with other VPN stuff in > Neutron. > > >> >> The other approach would obviously to build onto the current APIs. The >> only way the Neutron API layer provides to do that is to extend and >> extension. This sounds terrible, and it is indeed terrible. There is a >> proposal for moving toward versioned APIs [3], but until that proposal is >> approved and implemented extensions are the only thing we have. >> > > Advanced services, such as VPNaaS, are out of the scope of the current > proposal [3]. It might take a while before the VPNaaS team moves to the > micro-versionning framework. > > >> From an API perspective the mechanism would be simpler: >> 1 - declare the extension, and implement get_required_extension to put >> 'vpnaas' as a requirement >> 2 - implement a DB mixin for it providing basic CRUD operations >> 3 - add it to the VPN service plugin and add its alias to >> 'supported_extensions_aliases' (step 2 and 3 can be merged if you wish not >> to have a mixin) >> >> What might be a bit more challenging is defining how this reflects onto >> VPN. Ideally you would have a driver for every VPN type you support, and >> then have a little dispatcher to route the API call to the appropriate >> driver according to the VPN type. >> >> Salvatore >> >> [1] >> https://blueprints.launchpad.net/neutron/+spec/intent-based-service-chaining >> [2] https://wiki.openstack.org/wiki/GroupBasedPolicy >> [3] https://review.openstack.org/#/c/136760 >> > > [4] https://review.openstack.org/#/c/177740/ > > >> On 6 May 2015 at 07:14, Vikram Choudhary <vikram.choudh...@huawei.com> >> wrote: >> >>> Hi Paul, >>> >>> >>> >>> Thanks for starting this mail thread. We are also eyeing for supporting >>> MPBGP in neutron and will like to actively participate in this discussion. >>> >>> Please let me know about the IRC channels which we will be following for >>> this discussion. >>> >>> >>> >>> Currently, I am following below BP’s for this work. >>> >>> https://blueprints.launchpad.net/neutron/+spec/edge-vpn >>> >>> https://blueprints.launchpad.net/neutron/+spec/bgp-dynamic-routing >>> >>> https://blueprints.launchpad.net/neutron/+spec/dynamic-routing-framework >>> >>> >>> https://blueprints.launchpad.net/neutron/+spec/prefix-clashing-issue-with-dynamic-routing-protocol >>> >>> >>> >>> Moreover, a similar kind of work is being headed by Cathy for defining >>> an intent framework which can extended for various use case. Currently it >>> will be leveraged for SFC but I feel the same can be used for providing >>> intend VPN use case. >>> >>> >>> https://blueprints.launchpad.net/neutron/+spec/intent-based-service-chaining >>> >>> >>> >>> Thanks >>> >>> Vikram >>> >>> >>> >>> *From:* Paul Michali [mailto:p...@michali.net] >>> *Sent:* 06 May 2015 01:38 >>> *To:* OpenStack Development Mailing List (not for usage questions) >>> *Subject:* [openstack-dev] [neutron] How should edge services APIs >>> integrate into Neutron? >>> >>> >>> >>> There's been talk in VPN land about new services, like BGP VPN and DM >>> VPN. I suspect there are similar things in other Advanced Services. I >>> talked to Salvatore today, and he suggested starting a ML thread on this... >>> >>> >>> >> > Paul, can you elaborate on any DM VPN proposal, I can't find any > spec/blueprint about it? > > >> Can someone elaborate on how we should integrate these API extensions >>> into Neutron, both today, and in the future, assuming the proposal that >>> Salvatore has is adopted? >>> >>> >>> >>> I could see two cases. The first, and simplest, is when a feature has an >>> entirely new API that doesn't leverage off of an existing API. >>> >>> >>> >>> The other case would be when the feature's API would dovetail into the >>> existing service API. For example, one may use the existing vpn_service API >>> to create the service, but then create BGP VPN or DM VPN connections for >>> that service, instead of the IPSec connections we have today. >>> >>> >>> >>> If there are examples already of how to extend an existing API extension >>> that would help in understanding how to do this. >>> >>> >>> >>> I see that there are RESOURCE_ATTRIBUTE_MAPs with the information on the >>> API, and I see that the plugin has a supported_extension_aliases, but >>> beyond that, I'm not really sure how it all hooks up, and how to extend an >>> existing extension. >>> >>> >>> >>> I'm assuming that the python-neutronclient would also need to be updated. >>> >>> >>> >>> >>> >>> So... the intent here is to start some discussion on how we do this, >>> such that we have some things figured out before the summit and can save >>> some time. >>> >>> >>> >>> Thanks in advance, >>> >>> >>> >>> Paul Michali (pc_m) >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev