Open Stack

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.rohon at gmail.com>
wrote:

> Hi,
>
> On Wed, May 6, 2015 at 8:42 AM, Salvatore Orlando <sorlando at 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.choudhary at 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:pc at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150507/30e06678/attachment.html>