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.ro...@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 <p...@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.ro...@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 <p...@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-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 > __________________________________________________________________________ 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
