Re: [openstack-dev] [neutron][networking-sfc] Proposing Mohan Kumar for networking-sfc core

+1 On 6/13/2016 14:35, Cathy Zhang wrote: Mohan has been working on networking-sfc project for over one year. He is a key contributor to the design/coding/testing of SFC CLI, SFC Horizon, as well as ONOS controller support for SFC functionality. He has been great at helping out with bug

Re: [openstack-dev] [Neutron][vpnaas]Question about MPLS VPN

On 5/26/2016 02:50, zhangyali (D) wrote: I am interested in the VPNaaS project in Neutron. Now I notice that only IPsec tunnel has completed, but other types of VPN, such as, MPLS/BGP, have not completed. I'd like to know how's going about MPLS/BGP vpn? What's the mechanism or extra work need

Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

On 5/25/2016 13:24, Tim Rozet wrote: In my opinion, it is a better approach to break this down into plugin vs driver support. There should be no problem adding support into networking-sfc plugin for NSH today. The OVS driver however, depends on OVS as the dataplane - which I can see a solid

Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

On Fri, 13 May 2016 17:13:59 -0700 "Armando M." wrote: > On 13 May 2016 at 16:10, Elzur, Uri wrote: > > > Hi Cathy > > > > > > > > Thank you for the quick response. This is the essence of my > > question – does Neutron keep OvS as a gold standard and why

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

SFC team and anybody else dealing with flow selection/classification (e.g. QoS), I just wanted to confirm that we're planning to meet in salon C today (Wednesday) to get lunch but then possibly move to a quieter location to discuss the common flow classifier ideas. On 4/21/2016 19:42, Cathy

Re: [openstack-dev] [neutron] [networking-sfc] Network-sfc project f2f2 meet-up place and time

On 4/26/2016 00:35, Akihiro Motoki wrote: Hi Cathy and folks interested in SFC and classifers! Can't we use a different room like Salon D? Salon C is a lunch room and at that time there are no sessions in other rooms. It would be great if we can use Salon D or E (after looking at the first

Re: [openstack-dev] [neutron][networking-sfc] API clarification questions

On 10/28/2015 04:14, Giuseppe (Pino) de Candia wrote: On Wed, Oct 28, 2015 at 4:20 PM, Russell Bryant > wrote: I read through the proposed SFC API here: http://docs.openstack.org/developer/networking-sfc/api.html We have similarly

Re: [openstack-dev] [neutron][sfc] How could an L2 agent extension access agent methods ?

On 11/13/2015 7:03 PM, Henry Fourie wrote: I wonder whether just pushing flows into the existing tables at random points in time can be unstable and break the usual flow assumed by the main agent loop. LF> No not expect any issues. Am I making sense? [1]

Re: [openstack-dev] [neutron][networking-sfc] Deploying current networking-sfc

On 11/16/2015 3:39 PM, Sean M. Collins wrote: Networking-sfc is still just a shell - there is no functional code. To be more clear, most of the code has not yet been merged. Click here for a link to all the pending reviews that contain lots of functional code targetted at merging into the

Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers

On 11/12/2015 3:50 PM, Ihar Hrachyshka wrote: All I am saying is that IF we merge some classifier API into neutron core and start using it for core, non-experimental, features, we cannot later move to some newer version of this API [that you will iterate on] without leaving a huge pile of

Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers

On 11/3/2015 1:03 PM, Sean M. Collins wrote: Anyway, the code is currently up on GitHub - I just threw it on there because I wanted to scratch my hacking itch quickly. https://github.com/sc68cal/neutron-classifier Sean, How much is needed to turn your models into something runnable to the

Re: [openstack-dev] [neutron][sfc] How could an L2 agent extension access agent methods ?

On 11/9/2015 9:59 PM, Vikram Choudhary wrote: Hi Cathy, Could you please check on this. My mother passed away yesterday and I will be on leave for couple of weeks. I'm very sorry to hear that. Please take all the time you need.

Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers

On 11/10/2015 8:30 AM, Sean M. Collins wrote: On Mon, Nov 09, 2015 at 07:58:34AM EST, Jay Pipes wrote: 2) Keep the security-group API as-is to keep outward compatibility with AWS. Create a single, new service-groups and service-group-rules API for L2 to L7 traffic classification using mostly

[openstack-dev] [docs][networking-sfc]

Can someone from the Docs team take a look at why there isn't a docs URL for the networking-sfc repo? Compare [1] vs [2] The first URL appears to be a rendering of the docs/source/index.rst from the Neutron Git repo, but the second one gives a Not Found even though there is a

[openstack-dev] [neutron][sfc] Neutron stadium distribution and/or packaging

Has anyone written anything up about expectations for how Big Tent or Neutron Stadium projects are expected to be installed/distributed/packaged? In particular, I'm wondering how we're supposed to handle changes to Neutron components. For the networking-sfc project we need to make additions

Re: [openstack-dev] [neutron][sfc] Neutron stadium distribution and/or packaging

It's possible that I've misunderstood Big Tent/Stadium, but I thought we were talking about enhancements to Neutron, not separate unrelated projects. We have several efforts focused on adding capabilities to Neutron. This isn't about polluting the Neutron namespace but rather about adding

Re: [openstack-dev] [neutron] till when must code land to make it in liberty

On 7/31/2015 9:47 AM, Kyle Mestery wrote: However, it's reasonable to assume the later you propose your RFE bug, the less of a chance it has of making it. We do enforce the Feature Freeze [2], which is the week of August 31 [3]. Thus, effectively you have 4 weeks to submit patches for new

Re: [openstack-dev] The proposed Neutron API extension for packet forwarding has a lot of duplication to the Neutron SFC API

On 7/27/2015 5:20 PM, Anita Kuno wrote: I think you need to acknowledge in both email topic and in content that Sean tried to draw the fact that you are duplicating this work on July 16th. Collaboration is much more than our meeting decided you shouldn't do your work. Perhaps taking a step back

Re: [openstack-dev] [Neutron][SFC]The proposed Neutron API extension for packet forwarding has a lot of duplication to the Neutron SFC API

On 7/27/2015 4:49 PM, Sean M. Collins wrote: I think when the API is too complex, where python-neutronclient is expected to create a better UX, that means that the API itself may need some further thinking and simplification. I think you are right however, that Get me a network is the first

Re: [openstack-dev] [Neutron][SFC]The proposed Neutron API extension for packet forwarding has a lot of duplication to the Neutron SFC API

On 7/24/2015 6:50 PM, Cathy Zhang wrote: Hi Everyone, In our last networking-sfc project IRC meeting, an issue was brought up that the API proposed in https://review.openstack.org/#/c/186663/ has a lot of duplication to the SFC API https://review.openstack.org/#/c/192933/ that is being

Re: [openstack-dev] [Neutron][L3] Representing a networks connected by routers

On 7/23/2015 2:45 PM, Kevin Benton wrote: We ran in to this long ago. What are some other examples? We've be good about keeping the network L2 only. Segments, VLAN transparency, and other properties of the network are all L2. The example you gave about needing the network to see the grouping

Re: [openstack-dev] [Neutron][SFC] Wiki update - deleting old SFC API

On a general topic of wiki cleanup, what's the preferred mechanism for documenting APIs? Wiki page [1] largely duplicates the content of the spec in [2] I dislike duplication of information because it's likely to get out of sync. I'd rather use hyperlinks whenever possible. However, linking to

[openstack-dev] [Neutron][SFC] Launchpad cleanup

Is it possible to delete dead blueprints or at least change the section at the top to just provide a URL to the blueprint that supersedes it? Blueprint [1] links to a bunch of abandoned reviews and references its parent Blueprint [2] which also links to abandoned work. The current work on

[openstack-dev] [Neutron][SFC] Wiki update - deleting old SFC API

As a courtesy to anyone who may have worked on it, I wanted to notify the list that I'm going to delete [1] from wiki page [2]. I may actually delete [2] completely. I'm going to update the content on [3] to reference the new SFC API spec that has just been merged. Currently [3] links to [2]

[openstack-dev] [Neutron] Flavor framework

What is the status of the flavor framework? Is this the right spec? https://blueprints.launchpad.net/neutron/+spec/neutron-flavor-framework I'm trying to sort through how the ML3 proposal https://review.openstack.org/#/c/105078/ fits in with requirements for high performance (high throughput,

Re: [openstack-dev] [neutron] Service Chain project IRC meeting minutes - 06/04/2015

Cathy, Make sure to take note when Fall rolls around that pacific time is ambiguous. UTC does not observe daylight savings so a meeting at 1700UTC will be 10:00 PDT but 09:00 PST. On 6/4/2015 5:17 PM, Cathy Zhang wrote: Thanks for joining the service chaining meeting today! Sorry for the

Re: [openstack-dev] [Neutron] (RE: Change in openstack/neutron-specs[master]: Introducing Tap-as-a-Service)

On 2/24/2015 6:47 PM, Kevin Benton wrote: More seriously, have you considered starting a tap-as-a-service project on stackforge now that the services split has established a framework for advanced services? Uploading the code you are using to do it is a great way to get people motivated to try