[openstack-dev] VPNaaS
Qin Li
qili at vmware.com
Fri May 17 02:36:55 UTC 2013
+ 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]
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]
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>:
> Hi Llya
>
> Wow. Sounds Great!
> Thank you for your contribution.
>
> Best
> Nachi
>
>
>
> 2013/5/15 Ilya Shakhat <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>
>>>
>>> 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>:
>>> > Hi Paul
>>> >
>>> > Thanks for your contributions! :)
>>> >
>>> > Nachi
>>> >
>>> > 2013/5/10 Paul Michali <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>:
>>> >>
>>> >> 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>:
>>> >>
>>> >>
>>> >> 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]
>>> >>
>>> >>
>>> >> 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]
>>> >>
>>> >>
>>> >> 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]
>>> >>
>>> >>
>>> >> 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>:
>>> >>
>>> >>
>>> >> 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>:
>>> >>
>>> >>
>>> >> 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>
>>> >>
>>> >>
>>> >> To: "OpenStack Development Mailing List
(openstack-dev at lists.openstack.
>>> >>
>>> >>
>>> >> org)"
>>> >>
>>> >>
>>> >> <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
>>> >>
>>> >>
>>> >> 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
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> _______________________________________________
>>> >>
>>> >> 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
More information about the OpenStack-dev
mailing list