[openstack-dev] VPNaaS

Paul Michali pcm at cisco.com
Wed May 22 13:53:29 UTC 2013


Do we know if openswan supports all the features we require (I'm just starting to look at docs)?  Do we know if there are any bugs/issues that will concern OS use?

Regards,

PCM (Paul Michali)

On May 21, 2013, at 4:40 PM, Nachi Ueno wrote:

> Hi Folks
> 
>> Francois
> Thank you for your investigation!
> 
> I would like to got with openswan because for cmd line config support.
>> Paul, Swami
> Is this OK for you guys?
> 
> Nachi
> 
> 
> 
> 2013/5/21 Eleouet Francois <f.eleouet at gmail.com>:
>> In Openswan, both protocol versions are implemented in the same daemon, by
>> default, both versions are enabled, IKEv2 parameter must be added to conn
>> section to choose between versions:
>> 
>> ikev2=never #will prevent responding to IKEv2
>> ikev2=insist #will force the use of IKEv2
>> 
>> 2013/5/20 Paul Michali <pcm at cisco.com>
>>> 
>>> Very cool information Francois
>>> 
>>> The example you have is with pluto. That's for IKEv1, right?
>>> 
>>> Is there an equivalent for charon (IKEv2)?
>>> 
>>> Regards,
>>> 
>>> 
>>> PCM (Paul Michali)
>>> 
>>> On May 20, 2013, at 7:22 AM, Eleouet Francois wrote:
>>> 
>>> Yes, but It may take some time to land in distros...
>>> 
>>> In the meantime, we could also consider using openswan that hasn't the
>>> same caveats: it can be launched with router-specific conf, pid & control
>>> socket files, as shown in the following sample:
>>> 
>>> ip netns exec moon ipsec pluto --ctlbase /var/lib/quantum/ipsec/moon/pluto
>>> --ipsecdir  /var/lib/quantum/ipsec/moon/ --use-auto --uniqueids
>>> --nat_traversal --secretsfile /var/lib/quantum/ipsec/moon/ipsec.secrets
>>> ip netns exec moon ipsec addconn --ctlbase
>>> /var/lib/quantum/ipsec/moon/pluto.ctl --config
>>> /var/lib/quantum/ipsec/moon/ipsec.conf moon-sun
>>> ip netns exec moon ipsec whack --ctlbase /var/lib/quantum/ipsec/moon/pluto
>>> --listen
>>> 
>>> ip netns exec sun ipsec pluto --ctlbase /var/lib/quantum/ipsec/sun/pluto
>>> --ipsecdir  /var/lib/quantum/ipsec/sun/ --use-auto --uniqueids
>>> --nat_traversal --secretsfile /var/lib/quantum/ipsec/sun/ipsec.secrets
>>> ip netns exec sun ipsec addconn --ctlbase
>>> /var/lib/quantum/ipsec/sun/pluto.ctl --config
>>> /var/lib/quantum/ipsec/sun/ipsec.conf sun-moon
>>> ip netns exec sun ipsec whack --ctlbase /var/lib/quantum/ipsec/sun/pluto
>>> --listen
>>> ip netns exec sun ipsec whack --ctlbase /var/lib/quantum/ipsec/sun/pluto
>>> --name sun-moon --initiate
>>> 
>>> /var/lib/quantum/ipsec/moon/ipsec.conf:
>>> config setup
>>>        nat_traversal=yes
>>>        protostack=auto
>>> 
>>> conn moon-sun
>>>        authby=secret
>>>        left=192.168.1.1
>>>        leftsubnet=10.1.0.0/16
>>>        leftid=@moon.openstack.org
>>>        right=192.168.1.2
>>>        rightsubnet=10.2.0.0/16
>>>        rightid=@sun.openstack.org
>>>        auto=add
>>> 
>>> /var/lib/quantum/ipsec/moon/ipsec.secrets:
>>> @moon.openstack.org %any : PSK "very secret psk"
>>> 
>>> (sun confs are symetrical)
>>> 
>>> 
>>> 2013/5/20 Clark, Robert Graham <robert.clark at hp.com>
>>>> 
>>>> Should be easy enough to change the ugly bit upstream.
>>>> 
>>>> http://wiki.strongswan.org/projects/strongswan/wiki/Contributions
>>>> 
>>>> From: Eleouet Francois <f.eleouet at gmail.com<mailto:f.eleouet at gmail.com>>
>>>> Reply-To: OpenStack List
>>>> <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
>>>> Date: Friday, 17 May 2013 19:44
>>>> To: OpenStack List
>>>> <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
>>>> Subject: Re: [openstack-dev] VPNaaS
>>>> 
>>>> Hi,
>>>> 
>>>> I was curious to know how strongswan was playing with namespaces, so I
>>>> made some test to figure out how it would work in a quantum router.
>>>> 
>>>> Great news is that Strongswann seems to work well when started in a
>>>> namespace: daemons open socket in the netns, and IPsec SAs & SPDs are set up
>>>> in the router netns and non visible in root namespace.
>>>> 
>>>> Bad one is that pid files location are hard coded in strongswan, as a
>>>> result, it's not trivial to start multiple daemons (like charon and pluto)
>>>> in different namespaces, here is the only (ugly) workaround I found so far:
>>>> 
>>>> #set up IPsec connection between two router namespaces on the same host:
>>>> 
>>>> ip netns add moon
>>>> ip netns add sun
>>>> ip link add veth-sun type veth peer name veth-moon
>>>> ip link set veth-sun netns sun
>>>> ip link set veth-moon netns moon
>>>> 
>>>> ip netns exec moon ip addr add 192.168.1.1/24<http://192.168.1.1/24> dev
>>>> veth-moon
>>>> ip netns exec moon ip addr add 10.1.0.1/8<http://10.1.0.1/8> dev
>>>> veth-moon
>>>> ip netns exec moon ip link set veth-moon up
>>>> ip netns exec moon ip link set lo up
>>>> 
>>>> ip netns exec sun ip addr add 192.168.1.2/24<http://192.168.1.2/24> dev
>>>> veth-sun
>>>> ip netns exec sun ip addr add 10.2.0.1/8<http://10.2.0.1/8> dev veth-sun
>>>> ip netns exec sun ip link set veth-sun up
>>>> ip netns exec sun ip link set lo up
>>>> 
>>>> ip netns exec moon ipsec start
>>>> ip netns exec moon ipsec up moon-sun &
>>>> 
>>>> #here comes the uggly part:
>>>> rm /var/run/charon.pid
>>>> rm /var/run/pluto.pid
>>>> rm /var/run/starter.pid
>>>> 
>>>> ip netns exec sun ipsec start
>>>> ip netns exec sun ipsec up sun-moon &
>>>> 
>>>> The correponding ipsec.conf
>>>> 
>>>> config setup
>>>>        charonstart=yes
>>>>        plutostart=yes
>>>> 
>>>> conn %default
>>>>        ikelifetime=60m
>>>>        keylife=20m
>>>>        rekeymargin=3m
>>>>        keyingtries=1
>>>>        authby=secret
>>>>        keyexchange=ikev2
>>>>        mobike=no
>>>> 
>>>> conn moon-sun
>>>>        left=192.168.1.1
>>>>        leftsubnet=10.1.0.0/16<http://10.1.0.0/16>
>>>>        leftid=@moon.strongswan.org<http://moon.strongswan.org/>
>>>>        leftfirewall=yes
>>>>        right=192.168.1.2
>>>>        rightsubnet=10.2.0.0/16<http://10.2.0.0/16>
>>>>        rightid=@sun.strongswan.org<http://sun.strongswan.org/>
>>>>        auto=add
>>>> 
>>>> conn sun-moon
>>>>        left=192.168.1.2
>>>>        leftsubnet=10.2.0.0/16<http://10.2.0.0/16>
>>>>        leftid=@moon.strongswan.org<http://moon.strongswan.org/>
>>>>        leftfirewall=yes
>>>>        right=192.168.1.1
>>>>        rightsubnet=10.1.0.0/16<http://10.1.0.0/16>
>>>>        rightid=@sun.strongswan.org<http://sun.strongswan.org/>
>>>>        auto=add
>>>> 
>>>> Any thoughts on that?
>>>> 
>>>> Francois.
>>>> 
>>>> 
>>>> 2013/5/17 Qin Li <qili at vmware.com<mailto:qili at vmware.com>>
>>>> + one more comment for 3. Local_cidrs
>>>> If there are there subnets got from "subnet_id" and user only wish to
>>>> provide VPN tunnel access to two of them from remote, we need to keep
>>>> local_cidrs.
>>>> 
>>>> Thanks
>>>> Qin
>>>> 
>>>> -----Original Message-----
>>>> From: Qin Li [mailto:qili at vmware.com<mailto:qili at vmware.com>]
>>>> Sent: 2013年5月17日 9:55
>>>> To: OpenStack Development Mailing List
>>>> Subject: RE: [openstack-dev] VPNaaS
>>>> 
>>>> For design on https://wiki.openstack.org/wiki/Quantum/VPNaaS , I'd like
>>>> to
>>>> share some of my comments.
>>>> 
>>>> 1. Table IKEPolicy
>>>> a. encryption_algorithm,  please include more information about algorithm
>>>> such as cipher mode. The value could be 3des-192-cbc, aes-128-cbc,
>>>> aes-192-cbc, aes-256-cbc, aes-128-gcm-a, aes-256-gcm-a, aes-128-ccm etc.
>>>> So as to support more kinds of cipher modes.
>>>> b. phase1_negotiation_mode, suggest to rename it as phrase1_mode or mode,
>>>> phrase 1 already contains the meaning "negotiation".
>>>> c. pfs, since there is no pfs_enable flag, null value of pfs means
>>>> disabled.  What does it mean if user does not specify it in inputs?
>>>> d. A minor adjustment suggestion for encryption_algorithm and
>>>> auth_algorithm, we could combine them into a phrase1 algorithm list named
>>>> phrase1_algs including like 3des-192-cbc-sha1, aes-128-cbc-sha1 etc. So
>>>> as
>>>> to support multiple algorithm proposals in one IKE negotiation. This
>>>> could
>>>> be considered in next release.
>>>> 
>>>> 2. Table IPSecPolicy
>>>> a. encryption_algorithm, the same as IKEPolicy b. transform_protocol,
>>>> encapsulation_mode.  Suggest to remove them to make object and
>>>> configuration simpler. We can focus on ESP and tunnel mode only for
>>>> IPSec.
>>>> This is typical site-to-site mode for Cloud user scenario. AH and
>>>> transform mode are rarely used.  The alternative solution is allowed that
>>>> user can configure IPSecPolicy without specifying them(DB will store them
>>>> as default value).
>>>> c. pfs, the same as IKEPolicy
>>>> d. A minor adjustment suggestion for encryption_algorithm and
>>>> auth_algorithm, we can combine them into a phrase2 algorithm list named
>>>> phrase2_algs like 3des-192-cbc-sha1, aes-128-cbc-sha1. So as to support
>>>> multiple algorithm proposals in one IKE negotiation. This could be
>>>> considered in next release.
>>>> 
>>>> 3. local_cidrs
>>>> If we remove local_cidrs, where can we get local subnets parameter, from
>>>> subnet id?  Does "subnet_id" contain all the private subnets need to be
>>>> protected over VPN tunnel? How to support two local private subnets over
>>>> the same VPN tunnel(connection)?
>>>> 
>>>> Thanks
>>>> Qin
>>>> 
>>>> -----Original Message-----
>>>> From: Nachi Ueno [mailto:nachi at ntti3.com<mailto:nachi at ntti3.com>]
>>>> Sent: 2013年5月17日 7:10
>>>> Cc: OpenStack Development Mailing List
>>>> Subject: Re: [openstack-dev] VPNaaS
>>>> 
>>>> Hi folks
>>>> 
>>>> We have meeting today.
>>>> 
>>>> On IRC #openstack-meetings  (It looks like free)
>>>> 
>>>> Agenda :
>>>> 
>>>> 1.Driver archtecture
>>>> 
>>>> https://docs.google.com/presentation/d/1uoYMl2fAEHTpogAe27xtGpPcbhm7Y3tlHI
>>>> w_G1Dy5aQ/edit
>>>>    [Conclution] keep reviewing
>>>>    Renamed driver name
>>>> 
>>>> 2. Agent archtecutre
>>>> 
>>>> https://docs.google.com/presentation/d/1e85n2IE38XoYwlsqNvqhKFLox6O01SbguZ
>>>> Xq7SnSSGo/edit
>>>> 
>>>> [Conclution]
>>>>    At first, take Option1 (implement it as sub-class of l3-agent)
>>>>    VPN-agent will be subclass of subclass of the l3 agent
>>>> 
>>>> 3.local_subnet vs local_cidr
>>>> 
>>>>    remove local_cidr until BGP is implemented and keep discussion
>>>>    keep peer_cidr
>>>>    keep discussions on mailing list
>>>> 
>>>> 4. Next meeting is not scheudled.
>>>> We are continue discussion on gerrit.
>>>> 
>>>> Munites.
>>>> 
>>>> http://eavesdrop.openstack.org/meetings/openstack_networking__vpn_/2013/op
>>>> enstack_networking__vpn_.2013-05-16-22.03.html
>>>> 
>>>> 2013/5/15 Nachi Ueno <nachi at ntti3.com<mailto:nachi at ntti3.com>>:
>>>>> Hi Llya
>>>>> 
>>>>> Wow. Sounds Great!
>>>>> Thank you for your contribution.
>>>>> 
>>>>> Best
>>>>> Nachi
>>>>> 
>>>>> 
>>>>> 
>>>>> 2013/5/15 Ilya Shakhat
>>>>> <ishakhat at mirantis.com<mailto:ishakhat at mirantis.com>>:
>>>>>> Hi Nachi,
>>>>>> 
>>>>>> Tatyana and me volunteer for work on UI for VPNaaS. The corresponding
>>>>>> bp is https://blueprints.launchpad.net/horizon/+spec/vpnaas-ui. We
>>>>>> will start filling the specification soon.
>>>>>> 
>>>>>> Thanks,
>>>>>> Ilya
>>>>>> 
>>>>>> 
>>>>>> 2013/5/15 Nachi Ueno <nachi at ntti3.com<mailto:nachi at ntti3.com>>
>>>>>>> 
>>>>>>> Hi Folks
>>>>>>> 
>>>>>>> We had VPN meetings yesterday.
>>>>>>> 
>>>>>>> Agenda :
>>>>>>> 1.  local_subnet vs local_cidr  --> Keep discussion 2.  Use cidr
>>>>>>> value or subnet_id?  --> Keep discussion 3.  Task assignment
>>>>>>>  -  move doc to wiki (Swami) Done
>>>>>>> https://wiki.openstack.org/wiki/Quantum/VPNaaS
>>>>>>>  -  Register BP and get approval by Mark (Swami) Done -> H2
>>>>>>>  -  check default value for lifetime value (Swami) Done
>>>>>>>  -  Implement Data Model (Swami will push code to the gerrit) by
>>>>>>> 5/20
>>>>>>>  -  CLI (python-quantum client) work (Swami will push code to the
>>>>>>> gerrit) by 5/20
>>>>>>>  -  Implement Driver (Nachi & PCM ) by 5/31
>>>>>>>     - Investigate strongswan
>>>>>>>     -  rpc (spec needed)
>>>>>>>     - Design driver archtecutre (spec needed)
>>>>>>>     - Write driver code
>>>>>>>  - Instation instructions on Wiki 5/31
>>>>>>>  -  Devstack support (nati) late June?
>>>>>>>  -  Write openstack network api document wiki (Sachin)
>>>>>>>  -  Horizon work (needs contributer)
>>>>>>>  -  Tempest (needs contributer)
>>>>>>> 
>>>>>>> Next meeting is 5/16 Thursday at 3pm (PST) . On IRC
>>>>>>> #openstack-meetings
>>>>>>> 
>>>>>>> Meeting ended Tue May 14 01:00:58 2013 UTC.  Information about
>>>>>>> MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
>>>>>>> Minutes:
>>>>>>> 
>>>>>>> http://eavesdrop.openstack.org/meetings/openstack_networking_vpn/201
>>>>>>> 3/openstack_networking_vpn.2013-05-14-00.06.html
>>>>>>> Minutes (text):
>>>>>>> 
>>>>>>> http://eavesdrop.openstack.org/meetings/openstack_networking_vpn/201
>>>>>>> 3/openstack_networking_vpn.2013-05-14-00.06.txt
>>>>>>> Log:
>>>>>>> 
>>>>>>> http://eavesdrop.openstack.org/meetings/openstack_networking_vpn/201
>>>>>>> 3/openstack_networking_vpn.2013-05-14-00.06.log.htm
>>>>>>> 
>>>>>>> Thanks!
>>>>>>> Nachi Ueno
>>>>>>> 
>>>>>>> 2013/5/10 Nachi Ueno <nachi at ntti3.com<mailto:nachi at ntti3.com>>:
>>>>>>>> Hi Paul
>>>>>>>> 
>>>>>>>> Thanks for your contributions! :)
>>>>>>>> 
>>>>>>>> Nachi
>>>>>>>> 
>>>>>>>> 2013/5/10 Paul Michali <pcm at cisco.com<mailto:pcm at cisco.com>>:
>>>>>>>>> Sure! Glad to work with you Nachi. Anything I can do to help out
>>>>>>>>> on the project!
>>>>>>>>> 
>>>>>>>>> I'll start looking at strongswan and how to configure.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Regards,
>>>>>>>>> 
>>>>>>>>> PCM (Paul Michali)
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On May 10, 2013, at 12:35 PM, Nachi Ueno wrote:
>>>>>>>>> 
>>>>>>>>> Hi Paul
>>>>>>>>> 
>>>>>>>>> Sounds Great.
>>>>>>>>> 
>>>>>>>>> The first driver will be strong-swan based.
>>>>>>>>> http://www.strongswan.org/
>>>>>>>>> 
>>>>>>>>> How about work with me to implement strong-swan vpn driver?
>>>>>>>>> Honestly, i'm new to strong-swan, so I'm very appreciate if you
>>>>>>>>> could try strong-swan on ubuntu and share how to configure it
>>>>>>>>> based on current API model.
>>>>>>>>> 
>>>>>>>>> Thanks
>>>>>>>>> Nachi
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 2013/5/10 Paul Michali <pcm at cisco.com<mailto:pcm at cisco.com>>:
>>>>>>>>> 
>>>>>>>>> Naci, Mark, Swami, Sachin, et al,
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Any suggestions on where/how I can help on this? I'm new to OS
>>>>>>>>> (just working
>>>>>>>>> 
>>>>>>>>> it for a few months), so no specific expertise area, but have
>>>>>>>>> bandwidth to
>>>>>>>>> 
>>>>>>>>> contribute.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Also, any pointers to information that will help me get up to
>>>>>>>>> speed on this
>>>>>>>>> 
>>>>>>>>> would be appreciated (Mark gave me link to Amazon URL for info on
>>>>>>>>> what they
>>>>>>>>> 
>>>>>>>>> provide for VPNaaS). I was going to look at LBaaS code next week
>>>>>>>>> and have
>>>>>>>>> 
>>>>>>>>> been monitoring those discussions, as there seem to be some
>>>>>>>>> parallels there.
>>>>>>>>> 
>>>>>>>>> If there are companion info that you think would help, let me
>>>>>>>>> know.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Regards,
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> PCM (Paul Michali)
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On May 9, 2013, at 9:12 PM, Nachi Ueno wrote:
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Hi Folks
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> We have meeting about VPN today.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> #Conclusions
>>>>>>>>> 
>>>>>>>>> 1. We agreed ipsec api
>>>>>>>>> 
>>>>>>>>> https://blueprints.launchpad.net/quantum/+spec/vpnaas-python-apis
>>>>>>>>> 
>>>>>>>>> 2. Swami will push api CRUD code to review (continue discussion
>>>>>>>>> on
>>>>>>>>> code)
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> https://blueprints.launchpad.net/quantum/+spec/vpnaas-python-apis
>>>>>>>>> 
>>>>>>>>> 3. We agreed first implementation vpn architecture
>>>>>>>>> 
>>>>>>>>> 4. Next meeting is 5/13 PST 5:00 PM on #openstack-meetings
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> #Questions for IPSec API
>>>>>>>>> 
>>>>>>>>> 1 psk_key -> psk (agreed)
>>>>>>>>> 
>>>>>>>>> 2 For ipsecpolicy table, suggest to split lifetime into two parts
>>>>>>>>> 
>>>>>>>>> lifetime_s(per seconds) and lifetime_b(per kilobytes)   ->
>>>>>>>>> updated
>>>>>>>>> 
>>>>>>>>> table (agreed)
>>>>>>>>> 
>>>>>>>>> 3 change back "cidrs" from subnet (or network)  -> check marks's
>>>>>>>>> thought
>>>>>>>>> 
>>>>>>>>> 4 For APIs, can we shorten the naming such as change  -> keep
>>>>>>>>> current
>>>>>>>>> 
>>>>>>>>> longer style for reability
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> #Project Management (Task)
>>>>>>>>> 
>>>>>>>>> -  move doc to wiki (Swami)
>>>>>>>>> 
>>>>>>>>> -  Register BP and get approval by Mark (Swami)
>>>>>>>>> 
>>>>>>>>> -  check default value for lifetime value (Swami)
>>>>>>>>> 
>>>>>>>>> -  Discuss Archtecture
>>>>>>>>> 
>>>>>>>>> -  Implement Data Model (Swami will push code to the gerrit)
>>>>>>>>> 
>>>>>>>>> -  Driver (Nachi?)
>>>>>>>>> 
>>>>>>>>> -  CLI (python-quantum client) work (Swami will push code to the
>>>>>>>>> gerrit)
>>>>>>>>> 
>>>>>>>>> -  Write openstack network api document wiki (Sachin)
>>>>>>>>> 
>>>>>>>>> -  Devstack support
>>>>>>>>> 
>>>>>>>>> -  Horizon work
>>>>>>>>> 
>>>>>>>>> -  Tempest
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> https://docs.google.com/a/ntti3.com/presentation/d/1J7k1eI13-3pQV
>>>>>>>>> wp5XgZDWPfzUvuSqczRdK0lEZKQOKk/edit#slide=id.p
>>>>>>>>> 
>>>>>>>>> Nachi
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 2013/5/7 Qin Li <qili at vmware.com<mailto:qili at vmware.com>>:
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Hi Swami,
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Thanks for your comments. All look good to me except local_cidrs,
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> peer_cidrs. "cidrs" may be clear for value type and validation,
>>>>>>>>> but it is
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> unfamiliar for the existing VPN administrators. I think we might
>>>>>>>>> use
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> subnets or networks to avoid introducing a new concept for users.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Regards
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> QinLi
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> -----Original Message-----
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> From: Vasudevan, Swaminathan (PNB Roseville)
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> [mailto:swaminathan.vasudevan at hp.com<mailto:swaminathan.vasudevan at hp.com>]
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Sent: 2013年5月8日 1:25
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> To: OpenStack Development Mailing List
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Subject: Re: [openstack-dev] VPNaaS
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Hi Qin Li,
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> See my answers inline.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Thanks.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> -----Original Message-----
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> From: Qin Li [mailto:qili at vmware.com<mailto:qili at vmware.com>]
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Sent: Monday, May 06, 2013 8:37 PM
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> To: OpenStack Development Mailing List
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Subject: Re: [openstack-dev] [Quantum] [Networking] VPNaaS
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> I'd like to share some of my comments on data models, tables,
>>>>>>>>> APIs defined
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> in link
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> https://docs.google.com/a/ntti3.com/document/d/1Jphcvnn7PKxqFEFFZ
>>>>>>>>> Q1_PYkEx5
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> J4aO5J5Q74R_PwgV8/edit .
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 1. For VPNServiceConnection table
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> a. suggest to remove psk(Boolean) key defined in
>>>>>>>>> VPNServiceConnection
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> table. There is already key auth_mode defined in ikepolicy table.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> "auth_mode" can be "psk" or "certificate". By default, if not
>>>>>>>>> set, it is
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> psk mode for authentication. Still keeping psk_key inside
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> VPNServiceConnection since psk_key is different per remote peer.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Authentication mode is a part of IKE property.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Swami - Yes we had both the auth_mode and psk_key as part of the
>>>>>>>>> IKEPolicy
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> table.  We moved both the fields to the connection table since,
>>>>>>>>> we just
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> wanted to re-use the IKEPolicy for different connections if only
>>>>>>>>> the PSK
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> key changes or the auth_mode changes. Also in the document we
>>>>>>>>> make
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> necessary changes to the table definition, but I need to make the
>>>>>>>>> change
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> also in the datamodel table.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> b. suggest to change local_cidrs and peer_cidrs to
>>>>>>>>> local_networks(or
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> local_subnets) and peer_networks(per_subnets) in
>>>>>>>>> VPNServiceConnection
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> table.   Cidrs is not a familiar keyword to users in IPSec
>>>> industry.
>>>>>>>>> Some
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> IPSec VPN vendors use subnets, some use networks.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Swami - Yes we had initially defined it as peer_subnets and
>>>>>>>>> local_subnets,
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> but based on yesterday's discussion we moved it to "cidrs", since
>>>>>>>>> it would
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> be clear.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> c. suggest to change psk_key to psk,  psk already means pre-shared
>>>> key.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Swami - Accepted we will change this.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 2. For ipsecpolicy table, suggest to split lifetime into two
>>>>>>>>> parts
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> lifetime_s(per seconds) and lifetime_b(per kilobytes).
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Swami - Yes we can discuss about this in Thursday's meeting.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 3. Can we shorten the naming of keywords? Such as change
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Swami - We can discuss about this in Thursday's meeting. The
>>>>>>>>> reason we
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> don't want to have abbreviated keys is for people to understand
>>>>>>>>> the keys
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> properly.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> In vpnserviceconnections table
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> vpnservice_ipsecpolicy_id  to  ipsecpolicy_id
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> vpnservice_ikepolicy_id    to  ikepolicy_id
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> vpnservice_certificiate_id to  certificate_id
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> In ikepolicys table
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> auth_algorithm           to auth_alg
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> encryption_algorithm     to enc_alg
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> phraseI_negotiation_mode to phraseI_mode
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> In ipsecpolicys table
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> transform_protocol       to protocol
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> auth_algorithm           to auth_alg
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> encryption_algorithm     to enc_alg
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> encapsulation_mode       to mode or encap_mode
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 4. There might be some updates to set proper length for each
>>>>>>>>> value in the
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> tables. Such as change
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> auth_algorithm VARCHAR2(255)       to auth_alg  VARCHAR2(8)   ;
>>>> for
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> example "sha1" etc.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> encryption_algorithm VARCHAR2(255) to enc_alg   VARCHAR2(16)   ;
>>>> for
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> example "aes128-cbc", "aes256-cbc" etc.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> name VARCHAR2(255)                 to name      VARCHAR2(64)
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Swami - Yes we will make the necessary changes in the table.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 5. What do "dh" and "tls" keywords mean in table
>>>> vpnservicecertficates?
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Swami - This was mainly included in the certificate table to
>>>>>>>>> address the
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> "Openvpn" certificate requirements. This will be dropped for now.
>>>>>>>>> Also we
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> are not considering to implement the certificates for this
>>>>>>>>> release. We
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> will clean up the tables.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 6. For APIs, can we shorten the naming such as change
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> /v1.0/vpnservicecertificates/vpnservice_certificate_id  to
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> /v1.0/vpncerts/certificate_id
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> /v1.0/vpnserviceconnections/vpnservice_conn_id          to
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> /v1.0/vpnsrvconns/conn_id
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Swami: We can discuss in Thursday's meeting.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Thanks & Regards
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Qin
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> -----Original Message-----
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> From: Nachi Ueno [mailto:nachi at ntti3.com<mailto:nachi at ntti3.com>]
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Sent: 2013年5月7日 9:07
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> To: OpenStack Development Mailing List
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Subject: Re: [openstack-dev] [Quantum] [Networking] VPNaaS
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Hi folks
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> In today's meeting, we are almost finished to define data models.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> https://docs.google.com/a/ntti3.com/document/d/1Jphcvnn7PKxqFEFFZ
>>>>>>>>> Q1_PYkEx5
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> J4aO5J5Q74R_PwgV8/edit
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> If you have any concerns, please commet it on the doc or question
>>>>>>>>> on the
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> mailing list.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> We will have meeting at
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 5/9 (Thu) 5:00 (PST)
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> In the next meeting, we will discuss more project management
>>>>>>>>> oriented
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> discussion.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Thanks
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Nachi
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 2013/5/6 Nachi Ueno <nachi at ntti3.com<mailto:nachi at ntti3.com>>:
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Hi folks
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Here is note from the meeting at 2nd meeting on VPN # sorry I
>>>>>>>>> thought
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> I have sent it to the mailing list, but it looks not delivery.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 1) FirstStep  SSL-VPN or IPSec?  -> IPSec
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> - all atenndes agrees with IPSec first step
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> - IPSec is widely used so, this is big win to the community
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> - IPSec can support remote user use case
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> - SSL-VPN (CloudPipe) can be supported by OpenVPN VM with
>>>>>>>>> floating ips
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 2) GenricService API -> Agreed
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> -id
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> -name
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> -tenant_id
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> -type (VPN type)
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> type has namespace (should be flat)
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> l2 vpn -> l2.*** (l2.l2tp)
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> l3 vpn -> l3.** (l3.ipsec)
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 3) IPSec API set
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Start discussion for IPSec api on the google doc
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> https://docs.google.com/a/ntti3.com/document/d/1Jphcvnn7PKxqFEFFZ
>>>>>>>>> Q1_PY
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> kEx5J4aO5J5Q74R_PwgV8/edit
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 4) Next meeting time
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> PST Monday 5PM (Sactin at VMWare will reserve conf-call)
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Meeting Agenda and Note
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> https://docs.google.com/presentation/d/1J7k1eI13-3pQVwp5XgZDWPfzU
>>>>>>>>> vuSqc
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> zRdK0lEZKQOKk/edit#slide=id.p
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Thanks!
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 2013/5/1 Sachin Thakkar
>>>>>>>>> <sthakkar at vmware.com<mailto:sthakkar at vmware.com>>:
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Thanks folks for joining today. We've made some good progress on
>>>>>>>>> the
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> IPsec VPN object model. Nachi has sent out the meeting notes to
>>>>>>>>> the
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> alias as well.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> We'll need another follow up to continue the discussion. The
>>>>>>>>> meeting
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> will be at 5pm Pacific time on Monday, May 6.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> The same bridge below will be used.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Thanks,
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Sachin
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> ________________________________
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> From: "Sachin Thakkar"
>>>>>>>>> <sthakkar at vmware.com<mailto:sthakkar at vmware.com>>
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> To: "OpenStack Development Mailing List
>>>> (openstack-dev at lists.openstack<mailto:openstack-dev at lists.openstack>.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> org)"
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Sent: Thursday, April 25, 2013 11:43:30 PM
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Subject: [openstack-dev] [Quantum] [Networking] VPNaaS
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Trying the new Networking tag in the subject :)
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Anyway, we have a kickoff call for VPNaaS scheduled next
>>>>>>>>> Wednesday @
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 5pm Pacific time. We will be discussing over the phone:
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Participant Passcode: 697 737 3510
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Call-in toll-free number (Premiere): 1-866-715-6501 (US)
>>>>>>>>> Additional
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> International Numbers:
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> http://pages.pgi-email.com/page.aspx?qs=5c591a8916642e738e03c2558
>>>>>>>>> 5184
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> f841174bd68edc7b376f211065726f20c4087d2dbd294c95628953b9ebd93c298
>>>>>>>>> f8a5
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 9d287357f683bc937b0420662c826d43f873082e5033f476121c74d72cc5ed151
>>>>>>>>> c4b3
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 0a31fa1b2
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> To all interested, hope to see you there.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Cheers,
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Sachin
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> _______________________________________________
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> OpenStack-dev mailing list
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> OpenStack-dev at lists.openstack.org<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130522/1cbf94c5/attachment-0001.html>


More information about the OpenStack-dev mailing list