Open Stack

Hi Nachi

I think we have some big fundamental issues here. You may not require an insertion mode for some L2VPN types, depending on the service you want the L2VPN  to offer.  Yi also brings a really good point that I feel we are not reflecting and showing on routing, we should decouple routing completely from the VPN Service. Also you have two Router types, one to advertise the VPN Tunnel End Point Upstream for  reachability and one if "you want dynamic routing" for a tenant network (for example) from one network site to another through the VPN Tunnel.

I feel we are mixing a lot of these fundamental concepts and topics.

Alan

-----Original Message-----
From: Nachi Ueno [mailto:nachi at ntti3.com] 
Sent: April-17-13 7:15 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [Quantum] Quantum VPN: Update from today's discussion

Hi Kaiwei

Thank you for your comment.
It depends on the each VPNService sub class.
Some L2VPNService may have network_id and association with out-of-path insertion mode.
(This part is also not implemented)
For some L3 VPN may support routed insertion mode, and the subclass of VPNService will have router_id (or port_id).

The use of insertion mode is input value checking when we insert it.

Thanks
Nachi



2013/4/17  <fank at vmware.com>:
> Hi Nachi,
>
> I'm not sure how "insertion_mode" could be any useful for plugins if it only indicate the mode as routed/out-of-path/floating insertion.
>
> For example, we need to associated it with a router if it is routed insertion (and we have an extension for associating a service with a router id: https://blueprints.launchpad.net/quantum/+spec/routed-service-insertion).
>
> What we need for out-of-path insertion and floating insertion? A network/subnet id?
>
> -Kaiwei
>
> ----- Original Message -----
> From: "Nachi Ueno" <nachi at ntti3.com>
> To: "OpenStack Development Mailing List" 
> <openstack-dev at lists.openstack.org>
> Sent: Wednesday, April 17, 2013 11:42:38 AM
> Subject: Re: [openstack-dev] [Quantum] Quantum VPN: Update from 
> today's discussion
>
> Hi folks
>
> May be, there are many ways to categorize use cases.
>
> We agreed we will model VPN as a Service instance (VPNService).
> If we define new service, the service can support any kind of VPNs 
> (L2, L3) What's we need to be discussed is attributes of Generalize 
> VPN Service Models if we can have generic vpn service models.
>
> I added vpn map for slide 13 ( This may help this discussion)
> https://docs.google.com/a/ntti3.com/presentation/d/1LdL0Fy9PpEQXB9q_c4
> 7iJ6gyA1oZn7B6MKbzFyk73tI/edit#slide=id.gd23898b7_9310
>
> This is current proposed attributes.
>
> 1. id
> 2. name
> 3. tenant_id
> 4. type (VPN type) ( ssl-vpn | ipsec | bgpmpls ... ) 5. insertion_mode 
> 6. mode = l2 | l3 ?
>
> I believe there is no need to discussion about 1-4.
> 5 is needed to use service insertion.
> ( Prevent routed service insertion of which didn't support it)
>
> 6. Mode
>  I'm not sure how to use this attribute, so I'm very appreciate if 
> someone would add the motivation on the slide
>
> Thanks
> Nachi
>
> 2013/4/17 Yi Yang <yyos1999 at gmail.com>:
>> While quantum VPN can serve as either client or server or both, there 
>> are big difference on requirements -- for example, a SSL VPN server 
>> needs to have an address pool, which is not required for clients.
>>
>> IMO, we need to first differentiate these use cases (server vs. 
>> client) before we decide what state fields should be covered.
>>
>> Yi
>>
>>
>> On 4/17/13 9:58 AM, Sachin Thakkar wrote:
>>
>> I definitely agree with point (1) from Yi below. There are so many 
>> flavors and intricacies to VPNs that it would be to our advantage to 
>> decouple as much as possible.
>>
>> For (2), my understanding is that the quantum VPN could be either. Is 
>> your comment to add this explicit role in addition to the state fields?
>>
>> Sachin
>>
>> ________________________________
>> From: "Yi Yang" <yyos1999 at gmail.com>
>> To: "OpenStack Development Mailing List" 
>> <openstack-dev at lists.openstack.org>
>> Sent: Wednesday, April 17, 2013 12:42:35 AM
>> Subject: Re: [openstack-dev] [Quantum] Quantum VPN: Update from 
>> today's discussion
>>
>> A couple of quick comments:
>>
>> 1. IMHO, we should separate IPSec/SSL VPN use cases from MPLS VPN 
>> cases, as the former adopts a server-client model while the latter doesn't.
>>
>> 2. One thing missed in these use cases, except in use case 3, is the 
>> "role"  -- does the quantum VPN act as a server or a client?
>>
>> Yi
>>
>>
>>
>> On 4/16/13 8:16 PM, Nachi Ueno wrote:
>>> Hi folks
>>>
>>> Thank you for  joining today's discussion.
>>> Based on today's discussion, we updated the slide.
>>>
>>>
>>> https://docs.google.com/presentation/d/1LdL0Fy9PpEQXB9q_c47iJ6gyA1oZ
>>> n7B6MKbzFyk73tI/edit#slide=id.gd23898b7_135
>>>
>>> Changes
>>> -  Simplify use case
>>>     removed any router references because it deals with 
>>> implementation
>>> - Simplify Generic VPNService model
>>>    removed any router references because it deals with service 
>>> insertion
>>> - Update attributes of generic VPN Service
>>>      Layer2 or Layer3 mode etc
>>>
>>> Tommorows' discussion is
>>> 5:20 at OpenStack Networking room
>>>
>>> http://openstacksummitapril2013.sched.org/event/a9264b0dd9470fba9335
>>> acc8a78ff61c#.UW3p1SvC82g
>>>
>>> Thanks!
>>> Nachi
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev