Open Stack

Loy, yeah, that is why I was thinking option B, as user has flexibility to
specify what subnet(s) are used for a connection.  Ideally, we want to
consider different VPN connection types.

Regards,
Paul Michali (pc_m)


On Wed, May 20, 2015 at 5:34 PM loy wolfe <loywolfe at gmail.com> wrote:

> Extra subnets is suitable for attribute of IKE connections, but not
> the whole VPN service. Because customer usually want fine-grained
> control of which local subnet could communicate to remote subnets.
>
> On Wed, May 20, 2015 at 11:21 PM, Mathieu Rohon <mathieu.rohon at gmail.com>
> wrote:
> > 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
> >>
> >
> >
> >
> __________________________________________________________________________
> > 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/20150521/4676650a/attachment.html>