Open Stack

However after thinking about it more deeply, option A might be suitable if
the vpn-service becomes more generic, and usable by other vpn objects
(ipsec-site-connection, bgpvpn-connection....).
I would become an object that the tenant can update to attach CIDR it wants
to export in its VPN.
To transform the vpn-service object in a generic vpn description, we need
to remove the mandatory ROUTER attribute, so that we can use it for l2vpn
either.

Hope we can discuss that on friday morning

On Wed, May 20, 2015 at 5:12 PM, Paul Michali <pc at michali.net> wrote:

> Hi Mathieu,
>
> In Kilo, VPNaaS APIs were no longer marked as experimental. We need to
> understand the implication of changing the API. I'm not sure how much
> VPNaaS is being used by OpenStack users at this time, either.  I'm hoping
> to seek out answers to this at the summit.
>
> If anyone has suggestions, comments, information on this, please chime in. I'll
> likely make a BP for multiple subnets, when I get back from the summit.
>
> Lastly, I'm planning on trying to get people interested in VPN to meet on
> Friday morning at the summit to discuss all the VPN topics that have been
> coming up.
>
> Regards,
>
> Paul Michali (pc_m)
>
> On Wed, May 20, 2015 at 7:54 AM Mathieu Rohon <mathieu.rohon at gmail.com>
> wrote:
>
>> Hi paul,
>>
>> this is also something that we would like to introduce for BGP/MPLS VPNs
>> [2].
>>
>> We choose to allow tenants to attach existing networks ( it might evolve
>> to subnets) to bgpvpn-connection objects, by updating the bgpvpn-connection
>> object, which is the equivalent of the ipsec-site-connection object.
>>
>> So I think that Option B is suitable here.
>>
>> Concerning backward compatibility, I think VPNaas is still considered as
>> experimental, am I wrong? Do you have to provide backward compatbility in
>> this case?
>>
>> Mathieu
>>
>> [2] https://review.openstack.org/#/c/177740/
>>
>> On Wed, May 13, 2015 at 8:59 PM, Paul Michali <pc at michali.net> wrote:
>>
>>> Hi,
>>>
>>> There has been, over the years, some mention about having VPN IPSec
>>> connections supporting multiple CIDRs for local (left side) private
>>> networks, in addition to the current support for multiple peer CIDRs (right
>>> side).
>>>
>>> I'm raising the question again with these goals:
>>>
>>> 1) Determine if the reference IPSec implementations support this
>>> capability
>>> 2) Determine if there is a community desire to enhance VPN to support
>>> this capability (for all VPN types)
>>> 3) See what would be the best way to handle this (changes to API and
>>> model)
>>> 4) Identify any consequences of making this change.
>>>
>>> Note: My assumption here is something that could be used for any type of
>>> VPN connection - current IPSec, future BGP/MPLS VPN, DM VPN, etc.
>>>
>>> Here is some information that was gathered from people on the VPN team
>>> so far. Please correct any inaccuracies and comment on the items...
>>>
>>> (1) It looks like OpenSwan and Libreswan will support this capability.
>>> StrongSwan will support this with IKEv2. For IKEv1, a Cisco Unity plugin
>>> extensions is needed. I'm not sure what that implies [1].
>>>
>>> (2) Do we, as a community, want to enhance VPNaaS to provide this
>>> capability of N:M subnets for VPN implementations? Putting on my vendor
>>> hat, I can see cases where customers want to be able to only create one
>>> connection and reference multiple subnets on each end. Is there a desire to
>>> do this and bake it into the reference implementation (thus making it
>>> available for other implementations)?
>>>
>>> (3) Currently, the vpn service API includes the router and subnet ID.
>>> The IPSec connection command includes the peer CIDR(s). For reference, here
>>> are two of the APIs:
>>>
>>> usage: neutron vpn-service-create [-h] [-f
>>> {html,json,shell,table,value,yaml}]
>>>                                   [-c COLUMN] [--max-width <integer>]
>>>                                   [--prefix PREFIX]
>>>                                   [--request-format {json,xml}]
>>>                                   [--tenant-id TENANT_ID]
>>> [--admin-state-down]
>>>                                   [--name NAME] [--description
>>> DESCRIPTION]
>>>                                   ROUTER SUBNET
>>>
>>> usage: neutron ipsec-site-connection-create [-h]
>>>                                             [-f
>>> {html,json,shell,table,value,yaml}]
>>>                                             [-c COLUMN]
>>>                                             [--max-width <integer>]
>>>                                             [--prefix PREFIX]
>>>                                             [--request-format {json,xml}]
>>>                                             [--tenant-id TENANT_ID]
>>>                                             [--admin-state-down] [--name
>>> NAME]
>>>                                             [--description DESCRIPTION]
>>>                                             [--mtu MTU]
>>>                                             [--initiator
>>> {bi-directional,response-only}]
>>>                                             [--dpd
>>> action=ACTION,interval=INTERVAL,timeout=TIMEOUT]
>>>                                             --vpnservice-id VPNSERVICE
>>>                                             --ikepolicy-id IKEPOLICY
>>>                                             --ipsecpolicy-id IPSECPOLICY
>>>                                             --peer-address PEER_ADDRESS
>>>                                             --peer-id PEER_ID --peer-cidr
>>>                                             PEER_CIDRS --psk PSK
>>>
>>> I could envision several ways to handle this (feel free to add more).
>>> Here are some thoughts on this...
>>>
>>> A) Allow multiple subnets for the vpn service API. The implication here
>>> is that all types of VPN connections would be able to support multiple
>>> subnets.
>>>
>>> vpn-service-create ... ROUTER LOCAL_CIDRS
>>>
>>> Issue here is that, if a change is desired on a subnet for a specific
>>> connection, the service must be updated.
>>>
>>> Today, I think one has to delete the connections from the service, and
>>> then can update the service. Would need to have ability to update a
>>> service, but still there is concern about the effect on other connections.
>>> It just doesn't seem like the right thing to me.
>>>
>>>
>>> B) Remove the subnet from the vpn service API and add it to the IPSec
>>> connection API, like is done with peer CIDR selection, allowing multiples.
>>> Different VPN types could do the same thing for their connection API.
>>>
>>> ipsec-site-connection ... LOCAL_CIDRS PEER_CIDRS ...
>>>
>>> This seems better, as different types of VPN can decide if they want to
>>> support this capability and implement their connection API accordingly.
>>>
>>> If the handling of this is in a base API, then other VPN types could
>>> possibly reuse? Issue is that this is a non-backward compatible API change.
>>> It does seem like a logical implementation to me though.
>>>
>>> C) Hybrid of A&B, keep the subnet on the vpn service API, and allow the
>>> connection API to (optionally) add additional subnets.
>>>
>>> vpn-service-create ROUTER SUBNET
>>> ipsec-site-connection ... LOCAL_CIDRS PEER_CIDRS ...
>>>
>>> We could require them to repeat the CIDR for the subnet that was
>>> specified in the service API (essentially ignoring that subnet arg, or we
>>> could specify additional CIDRs or subnets in the connection API.
>>>
>>> This seems to be backward compatible, but is awkward. If the user wants
>>> to update a connection, and change the subnet that is mentioned in the vpn
>>> service, we have the same issue as option A (granted, it is not handled
>>> well today either).
>>>
>>> (4) Obviously, if we change the existing API, there there is the
>>> question of how do we handle backward compatibility? By doing this change,
>>> will we be creating other issues?
>>>
>>> I'm not sure why the subnet needed to be specified in the service API,
>>> unless the assumption was that there would only be one subnet for all
>>> connections on the service. Anyone know why? I don't think it is used,
>>> until you make a connection.
>>>
>>> Please express your thoughts!
>>>
>>> Paul Michali (pc_m)
>>>
>>> [1] https://wiki.strongswan.org/projects/strongswan/wiki/ConnSection
>>>
>>>
>>>
>>> __________________________________________________________________________
>>> 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/20150520/68036c3c/attachment.html>