Open Stack

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_c47iJ6gyA1oZn7B6MKbzFyk73tI/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_c47iJ6gyA1oZn7B6MKbzFyk73tI/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/a9264b0dd9470fba9335acc8a78ff61c#.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