Open Stack

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
>