[openstack-dev] VPNaaS
Paul Michali
pcm at cisco.com
Wed May 22 12:18:03 UTC 2013
Sounds good to me. I'll go look at the openswan (only had looked at strongswan initially).
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/75a5c027/attachment-0001.html>
More information about the OpenStack-dev
mailing list