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