Re: [openstack-dev] [Neutron][bgpvpn] IRC meetings on BGP VPN interconnection API

[Mohammad Hanif]

Hi Thomas,

The time reserved for the weekly IRC is 1600 UTC on Tuesdays 
(http://eavesdrop.openstack.org/#Neutron_VPNaaS_Meeting).  The IRC channel 
might not be available on any other time (1500 UTC is taken by the libvirt team 
meeting).

Thanks,
—Hanif. 



On 5/29/15, 12:57 PM, "Vikram Choudhary"  wrote:

>Hi Thomos/Mathieu,
>
>Thanks for starting this mail thread. Let's discuss over the IRC as
>suggested by Paul.
>
>Thanks
>Vikram
>
>On 5/29/15, Paul Michali  wrote:
>> You can use the VPNaaS IRC channel/time... we don't have much on the agenda
>> right now, other than discussion VPN flavors for Liberty, in which it would
>> be good to discuss BGP VPN and Edge VPN.
>>
>> Regards,
>>
>> Paul Michali (pc_m)
>>
>> On Fri, May 29, 2015 at 11:08 AM  wrote:
>>
>>> Hi everyone,
>>>
>>> As a follow-up to discussions last week on a BGP VPN interconnection API
>>> and the work started with the people already involved, we are going to
>>> hold IRC meetings to discuss how to progress the different pieces of
>>> work, in particular on the API itself [1] and its implementation+drivers
>>> [2].
>>>
>>> The slot we propose is ** Tuesday 15:00 UTC ** with the first meeting
>>> next Tuesday (June 2nd).
>>>
>>> Note that, based on last week feedback, we submitted the existing
>>> stackforge project for inclusion in the Neutron "big tent" earlier this
>>> week [3].
>>>
>>> We will do a proper meeting registration (patch to openstack-infra
>>> irc-meeting) and send meeting info with wiki and meeting room before
>>> next Tuesday.
>>>
>>> Looking forward to discussing with everyone interested!
>>>
>>> -Thomas & Mathieu
>>>
>>> [1] currently being discussed at https://review.openstack.org/#/c/177740
>>> [2] https://github.com/stackforge/networking-bgpvpn
>>> [3] https://review.openstack.org/#/c/186041
>>>
>>>
>>>
>>>
>>> _
>>>
>>> Ce message et ses pieces jointes peuvent contenir des informations
>>> confidentielles ou privilegiees et ne doivent donc
>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
>>> recu ce message par erreur, veuillez le signaler
>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
>>> electroniques etant susceptibles d'alteration,
>>> Orange decline toute responsabilite si ce message a ete altere, deforme
>>> ou
>>> falsifie. Merci.
>>>
>>> This message and its attachments may contain confidential or privileged
>>> information that may be protected by law;
>>> they should not be distributed, used or copied without authorisation.
>>> If you have received this email in error, please notify the sender and
>>> delete this message and its attachments.
>>> As emails may be altered, Orange is not liable for messages that have
>>> been
>>> modified, changed or falsified.
>>> Thank you.
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][vpnaas] VPNaaS Subteam meetings

[Mohammad Hanif]

Hi all,

I would also vote for (C) with 1600 UTC or later.  This  will hopefully 
increase more participation from the Pacific time zone.

Thanks,
—Hanif.

From: Mathieu Rohon
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
Date: Thursday, March 5, 2015 at 1:52 AM
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: Re: [openstack-dev] [neutron][vpnaas] VPNaaS Subteam meetings

Hi,

I'm fine with C) and 1600 UTC would be more adapted for EU time Zone :)

However, I Agree that neutron-vpnaas meetings was mainly focus on maintaining 
the current IPSec implementation, by managing the slip out, adding StrongSwan 
support and adding functional tests.
Maybe we will get a broader audience once we will speak about adding new use 
cases such as edge-vpn.
Edge-vpn use cases overlap with the Telco WG VPN use case [1]. May be those 
edge-vpn discussions should occur during the Telco WG meeting?

[1]https://wiki.openstack.org/wiki/TelcoWorkingGroup/UseCases#VPN_Instantiation

On Thu, Mar 5, 2015 at 3:02 AM, Sridhar Ramaswamy 
mailto:sric...@gmail.com>> wrote:
Hi Paul.

I'd vote for (C) and a slightly later time-slot on Tuesdays - 1630 UTC (or 
later).

The meetings so far was indeed quite useful. I guess the current busy Kilo 
cycle is also contributing to the low turnout. As we pick up things going 
forward this forum will be quite useful to discuss edge-vpn and, perhaps, other 
vpn variants.

- Sridhar

On Tue, Mar 3, 2015 at 3:38 AM, Paul Michali 
mailto:p...@michali.net>> wrote:
Hi all! The email, that I sent on 2/24 didn't make it to the mailing list (no 
wonder I didn't get responses!). I think I had an issue with my email address 
used - sorry for the confusion!

So, I'll hold the meeting today (1500 UTC meeting-4, if it is still available), 
and we can discuss this...


We've been having very low turnout for meetings for the past several weeks, so 
I'd like to ask those in the community interested in VPNaaS, what the 
preference would be regarding meetings...

A) hold at the same day/time, but only on-demand.
B) hold at a different day/time.
C) hold at a different day/time, but only on-demand.
D) hold as a on-demand topic in main Neutron meeting.

Please vote your interest, and provide desired day/time, if you pick B or C. 
The fallback will be (D), if there's not much interest anymore for meeting, or 
we can't seem to come to a consensus (or super-majority :)

Regards,

PCM

Twitter: @pmichali
TEXT: 6032894458
PCM (Paul Michali)

IRC pc_m (irc.freenode.com)
Twitter... @pmichali


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][vpnaas] Sub-team meetings on Dec 20th and 27th?

[Mohammad Hanif]

Thanks Paul.

Happy holidays everyone!

On Dec 22, 2014, at 1:06 PM, Paul Michali (pcm) 
mailto:p...@cisco.com>> wrote:

Will cancel the next two VPNaaS sub-team meetings.  The next meeting will be 
Tuesday, January 6th at 1500 UTC on meeting-4 (<<< Note the channel change).


Enjoy the holiday time!

PCM (Paul Michali)

MAIL . p...@cisco.com
IRC ... pc_m (irc.freenode.com)
TW  @pmichali
GPG Key ... 4525ECC253E31A83
Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83




On Dec 19, 2014, at 2:01 PM, Paul Michali (pcm) 
mailto:p...@cisco.com>> wrote:

Does anyone have agenda items to discuss for the next two meetings during the 
holidays?

If so, please let me know (and add them to the Wiki page), and we'll hold the 
meeting. Otherwise, we can continue on Jan 6th, and any pop-up items can be 
addressed on the mailing list or Neutron IRC.

Please let me know by Monday, if you'd like us to meet.


Regards,

PCM (Paul Michali)

MAIL . p...@cisco.com
IRC ... pc_m (irc.freenode.com)
TW  @pmichali
GPG Key ... 4525ECC253E31A83
Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Edge-VPN and Edge-Id

[Mohammad Hanif]

I hope we all understand how edge VPN works and what interactions are 
introduced as part of this spec.  I see references to neutron-network mapping 
to the tunnel which is not at all case and the edge-VPN spec doesn’t propose 
it.  At a very high level, there are two main concepts:

  1.  Creation of a per tenant VPN “service” on a PE (physical router) which 
has a connectivity to other PEs using some tunnel (not known to tenant or 
tenant-facing).  An attachment circuit for this VPN service is also created 
which carries a “list" of tenant networks (the list is initially empty) .
  2.  Tenant “updates” the list of tenant networks in the attachment circuit 
which essentially allows the VPN “service” to add or remove the network from 
being part of that VPN.

A service plugin implements what is described in (1) and provides an API which 
is called by what is described in (2).  The Neutron driver only “updates” the 
attachment circuit using an API (attachment circuit is also part of the service 
plugin’ data model).   I don’t see where we are introducing large data model 
changes to Neutron?  How else one introduces a network service in OpenStack if 
it is not through a service plugin?  As we can see, tenant needs to communicate 
(explicit or otherwise) to add/remove its networks to/from the VPN.  There has 
to be a channel and the APIs to achieve this.

Thanks,
—Hanif.

From: Ian Wells mailto:ijw.ubu...@cack.org.uk>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Monday, December 1, 2014 at 4:35 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron] Edge-VPN and Edge-Id

On 1 December 2014 at 09:01, Mathieu Rohon 
mailto:mathieu.ro...@gmail.com>> wrote:
This is an alternative that would say : you want an advanced service
for your VM, please stretch your l2 network to this external
component, that is driven by an external controller, and make your
traffic goes to this component to take benefit of this advanced
service. This is a valid alternative of course, but distributing the
service directly to each compute node is much more valuable, ASA it is
doable.

Right, so a lot rides on the interpretation of 'advanced service' here, and 
also 'attachment'.

Firstly, the difference between this and the 'advanced services' (including the 
L3 functionality, though it's not generally considered an 'advanced service') 
is that advanced services that exist today attach via an addressed port.  This 
bridges in.  That's quite a signifcant difference, which is to an extent why 
I've avoided lumping the two together and haven't called this an advanced 
service itself, although it's clearly similar.

Secondly, 'attachment' has historically meant a connection to that port.  But 
in DVRs, it can be a multipoint connection to the network - manifested on 
several hosts - all through the auspices of a single port.  In the edge-id 
proposal you'll note that I've carefully avoided defining what an attachment 
is, largely because I have a natural tendency to want to see the interface at 
the API level before I worry about the backend, I admit.  Your point about 
distributed services is well taken, and I think would be addressed by one of 
these distributed attachment types.

> So the issue I worry about here is that if we start down the path of adding
> the MPLS datamodels to Neutron we have to add Kevin's switch control work.
> And the L2VPN descriptions for GRE, L2TPv3, VxLAN, and EVPN.  And whatever
> else comes along.  And we get back to 'that's a lot of big changes that
> aren't interesting to 90% of Neutron users' - difficult to get in and a lot
> of overhead to maintain for the majority of Neutron developers who don't
> want or need it.

This shouldn't be a lot of big changes, once interfaces between
advanced services and neutron core services will be cleaner.

Well, incorporating a lot of models into Neutron *is*, clearly, quite a bit of 
change, for starters.

The edge-id concept says 'the data models live outside neutron in a separate 
system' and there, yes, absolutely, this proposes a clean model for 
edge/Neutron separation in the way you're alluding to with advanced services.  
I think your primary complaint is that it doesn't define that interface for an 
OVS driver based system.

The edge-vpn concept says 'the data models exists within neutron in an 
integrated fashion' and, if you agree that separation is the way to go, this 
seems to me to be exactly the wrong approach to be using.  It's the way 
advanced services are working - for now - but that's because we believe it 
would be hard to pull them out because the interfaces between service and 
Neutron don't currently exist.  The argument for this seems to be 'we should 
incorporate it so that we can pull it out at the same time as advanced 
services' but it feels like that's making more work 

[openstack-dev] [Neutron] Edge-VPN and Edge-Id

[Mohammad Hanif]

Folks,

Recently, as part of the L2 gateway thread, there was some discussion on 
BGP/MPLS/Edge VPN and how to bridge any overlay networks to the neutron 
network.  Just to update everyone in the community, Ian and I have separately 
submitted specs which make an attempt to address the cloud edge connectivity.  
Below are the links describing it:

Edge-Id: https://review.openstack.org/#/c/136555/
Edge-VPN: https://review.openstack.org/#/c/136929 .  This is a resubmit of 
https://review.openstack.org/#/c/101043/ for the kilo release under the “Edge 
VPN” title.  “Inter-datacenter connectivity orchestration” was just too long 
and just too generic of a title to continue discussing about :-(

I had discussions with some of you (who are active on this mailing lis) on edge 
VPN connectivity during the Paris summit and also went over it during the 
Neutron lightning talks session.  Please take the time to see if you can review 
the above mentioned specs and provide your valuable comments.

For those of you in US, have a happy Thanksgiving holidays!

Thanks,
—Hanif.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into separate repositories

[Mohammad Hanif]

I agree with Paul as advanced services go beyond just L4-L7.  Today, VPNaaS 
deals with L3 connectivity but belongs in advanced services.  Where does 
Edge-VPN work belong?  We need a broader definition for advanced services area.

Thanks,
—Hanif.

From: "Paul Michali (pcm)" mailto:p...@cisco.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, November 18, 2014 at 4:08 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into 
separate repositories

On Nov 18, 2014, at 6:36 PM, Armando M. 
mailto:arma...@gmail.com>> wrote:

Mark, Kyle,

What is the strategy for tracking the progress and all the details about this 
initiative? Blueprint spec, wiki page, or something else?

One thing I personally found useful about the spec approach adopted in [1], was 
that we could quickly and effectively incorporate community feedback; having 
said that I am not sure that the same approach makes sense here, hence the 
question.

Also, what happens for experimental efforts that are neither L2-3 nor L4-7 
(e.g. TaaS or NFV related ones?), but they may still benefit from this 
decomposition (as it promotes better separation of responsibilities)? Where 
would they live? I am not sure we made any particular progress of the incubator 
project idea that was floated a while back.

Would it make sense to define the advanced services repo as being for services 
that are beyond basic connectivity and routing? For example, VPN can be L2 and 
L3. Seems like restricting to L4-L7 may cause some confusion as to what’s in 
and what’s out.


Regards,

PCM (Paul Michali)

MAIL …..…. p...@cisco.com
IRC ……..… pc_m (irc.freenode.com)
TW ………... @pmichali
GPG Key … 4525ECC253E31A83
Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83



Cheers,
Armando

[1] https://review.openstack.org/#/c/134680/

On 18 November 2014 15:32, Doug Wiegley 
mailto:do...@a10networks.com>> wrote:
Hi,

> so the specs repository would continue to be shared during the Kilo cycle.

One of the reasons to split is that these two teams have different priorities 
and velocities.  Wouldn’t that be easier to track/manage as separate launchpad 
projects and specs repos, irrespective of who is approving them?

Thanks,
doug



On Nov 18, 2014, at 10:31 PM, Mark McClain 
mailto:m...@mcclain.xyz>> wrote:

All-

Over the last several months, the members of the Networking Program have been 
discussing ways to improve the management of our program.  When the Quantum 
project was initially launched, we envisioned a combined service that included 
all things network related.  This vision served us well in the early days as 
the team mostly focused on building out layers 2 and 3; however, we’ve run into 
growth challenges as the project started building out layers 4 through 7.  
Initially, we thought that development would float across all layers of the 
networking stack, but the reality is that the development concentrates around 
either layer 2 and 3 or layers 4 through 7.  In the last few cycles, we’ve also 
discovered that these concentrations have different velocities and a single 
core team forces one to match the other to the detriment of the one forced to 
slow down.

Going forward we want to divide the Neutron repository into two separate 
repositories lead by a common Networking PTL.  The current mission of the 
program will remain unchanged [1].  The split would be as follows:

Neutron (Layer 2 and 3)
- Provides REST service and technology agnostic abstractions for layer 2 and 
layer 3 services.

Neutron Advanced Services Library (Layers 4 through 7)
- A python library which is co-released with Neutron
- The advance service library provides controllers that can be configured to 
manage the abstractions for layer 4 through 7 services.

Mechanics of the split:
- Both repositories are members of the same program, so the specs repository 
would continue to be shared during the Kilo cycle.  The PTL and the drivers 
team will retain approval responsibilities they now share.
- The split would occur around Kilo-1 (subject to coordination of the Infra and 
Networking teams). The timing is designed to enable the proposed REST changes 
to land around the time of the December development sprint.
- The core team for each repository will be determined and proposed by Kyle 
Mestery for approval by the current core team.
- The Neutron Server and the Neutron Adv Services Library would be co-gated to 
ensure that incompatibilities are not introduced.
- The Advance Service Library would be an optional dependency of Neutron, so 
integrated cross-project checks would not be required to enable it during 
testing.
- The split should not adversely impact operators and the Networking program 
should maintain standard OpenStack co

Re: [openstack-dev] [neutron] Lightning talks during the Design Summit!

[Mohammad Hanif]

Hi Kyle,

Thanks a lot for organizing this. I heard from Tom Nadeau that you might not be 
coming to Paris. Hope all is well. 

Hanif. 

Sent from my iPhone

> On Oct 31, 2014, at 3:09 PM, Kyle Mestery  wrote:
> 
>> On Mon, Oct 27, 2014 at 8:16 PM, Kyle Mestery  wrote:
>>> On Thu, Oct 23, 2014 at 3:22 PM, Kyle Mestery  wrote:
>>> As discussed during the neutron-drivers meeting this week [1], we've
>>> going to use one of the Neutron 40 minute design summit slots for
>>> lightning talks. The basic idea is we will have 6 lightning talks,
>>> each 5 minutes long. We will force a 5 minute hard limit here. We'll
>>> do the lightning talk round first thing Thursday morning.
>>> 
>>> To submit a lightning talk, please add it to the etherpad linked here
>>> [2]. I'll be collecting ideas until after the Neutron meeting on
>>> Monday, 10-27-2014. At that point, I'll take all the ideas and add
>>> them into a Survey Monkey form and we'll vote for which talks people
>>> want to see. The top 6 talks will get a lightning talk slot.
>>> 
>>> I'm hoping the lightning talks allow people to discuss some ideas
>>> which didn't get summit time, and allow for even new contributors to
>>> discuss their ideas face to face with folks.
>> As discussed in the weekly Neutron meeting, I've setup a Survey Monkey
>> to determine which 6 talks will get a slot for the Neutron Lightning
>> Talk track at the Design Summit. Please go here [1] and vote. I'll
>> collect results until Thursday around 2300UTC or so, and then close
>> the poll and the top 6 choices will get a 5 minute lightning talk.
> Thanks to all who voted for Lightning Talks! I've updated the etherpad
> [100] with the list of talks which got the most votes. I'm also
> copying them here for people who don't like clicking on links:
> 
> MPLS VPN - Orchestrating inter-datacenter connectivity - [Mohammad Hanif]
> IPv6 as an Openstack network infrastructure - ijw (Ian Wells)
> L2GW support - abstraction and reference implementation for extending
> logical networks into physical networks [Maruti Kamat]
> servicevm framework(tacker project) and l3 router poc (yamahata)
> Verifying Neutron at 100-node scale (Rally, iperf) - [Ilya Shakhat]
> Tips on getting reviewers to block your changes - [Kevin Benton]
> 
> I'm excited to see how these work and hope it proves useful for people.
> 
> Safe travels to Paris to all!
> 
> Kyle
> 
> [100] https://etherpad.openstack.org/p/neutron-kilo-lightning-talks
> 
>> Thanks!
>> Kyle
>> 
>> [1] https://www.surveymonkey.com/s/RLTPBY6
>> 
>>> Thanks!
>>> Kyle
>>> 
>>> [1] 
>>> http://eavesdrop.openstack.org/meetings/neutron_drivers/2014/neutron_drivers.2014-10-22-15.02.log.html
>>> [2] https://etherpad.openstack.org/p/neutron-kilo-lightning-talks
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] Lightning talks during the Design Summit!

[Mohammad Hanif]

Hi Ian, all,

I would very much like that. Please let me know what time works for you. I will 
be in Paris all 5 days. 

Thanks,
Hanif. 

Sent from my iPhone

> On Oct 31, 2014, at 9:07 PM, Ian Wells  wrote:
> 
> Maruti's talk is, in fact, so interesting that we should probably get 
> together and talk about this earlier in the week.  I very much want to see 
> virtual-physical programmatic bridging, and I know Kevin Benton is also 
> interested.  Arguably the MPLS VPN stuff also is similar in scope.  Can I 
> propose we have a meeting on cloud edge functionality?
> -- 
> Ian.
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev