Re: [openstack-dev] [neutron] Lightning talks during the Design Summit!
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 ijw.ubu...@cack.org.uk 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
Re: [openstack-dev] [neutron] Lightning talks during the Design Summit!
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 mest...@mestery.com wrote: On Mon, Oct 27, 2014 at 8:16 PM, Kyle Mestery mest...@mestery.com wrote: On Thu, Oct 23, 2014 at 3:22 PM, Kyle Mestery mest...@mestery.com 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] [tc][neutron] Proposal to split Neutron into separate repositories
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) p...@cisco.commailto:p...@cisco.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, November 18, 2014 at 4:08 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto: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. arma...@gmail.commailto: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.commailto:p...@cisco.com IRC ……..… pc_m (irc.freenode.comhttp://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 do...@a10networks.commailto: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 m...@mcclain.xyzmailto: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. -
[openstack-dev] [Neutron] Edge-VPN and Edge-Id
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] [Neutron] Edge-VPN and Edge-Id
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 ijw.ubu...@cack.org.ukmailto:ijw.ubu...@cack.org.uk Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Monday, December 1, 2014 at 4:35 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] Edge-VPN and Edge-Id On 1 December 2014 at 09:01, Mathieu Rohon mathieu.ro...@gmail.commailto: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
Re: [openstack-dev] [neutron][vpnaas] Sub-team meetings on Dec 20th and 27th?
Thanks Paul. Happy holidays everyone! On Dec 22, 2014, at 1:06 PM, Paul Michali (pcm) p...@cisco.commailto: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.commailto:p...@cisco.com IRC ... pc_m (irc.freenode.comhttp://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) p...@cisco.commailto: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.commailto:p...@cisco.com IRC ... pc_m (irc.freenode.comhttp://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.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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][vpnaas] VPNaaS Subteam meetings
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 sric...@gmail.commailto: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 p...@michali.netmailto: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: 6032894458tel:6032894458 PCM (Paul Michali) IRC pc_m (irc.freenode.comhttp://irc.freenode.com) Twitter... @pmichali __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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:unsubscribehttp://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][bgpvpn] IRC meetings on BGP VPN interconnection API
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 viks...@gmail.com 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 p...@michali.net 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 thomas.mo...@orange.com 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
