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 <loywo...@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.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 >
__________________________________________________________________________ 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
