Re: [openstack-dev] [neutron][networking-sfc] API clarification questions
Hi Russell, Please see my replies inline. Thanks, Cathy -Original Message- From: Russell Bryant [mailto:rbry...@redhat.com] Sent: Wednesday, October 28, 2015 4:21 PM To: OpenStack Development Mailing List; Cathy Zhang; Henry Fourie Subject: [neutron][networking-sfc] API clarification questions I read through the proposed SFC API here: http://docs.openstack.org/developer/networking-sfc/api.html I'm looking at implementing what would be required to support this API in OVN. I have a prototype, but I had to make some pretty big assumptions, so I wanted to clarify the intent of the API. First, does it assume that all of the neutron ports in a chain are on the same Neutron network? That keeps things simple. If its intended to allow a chain of ports on different networks, is it just required that you pick ports that all have addresses routable from one port to the next in the chain? Cathy> It can allow a chain of ports on different networks as along it belongs to the same tenant. Yes, it is required that you pick ports that all have addresses routable from one port to the next in the chain. An arbitrary set of ports can't always work, so there has to be some bounds around what set of ports are valid to be in a chain. Second, where is it expected that the match is applied? The API for creating a port chain doesn't associate the chain with a network, but just matching "globally" doesn't make any sense. If all ports are expected to be on the same network, is the match applied for any traffic entering that network from any port? Cathy> As long as the ports are routable, they do not need to associated with the same network. I'm in Tokyo this week, so if the group working on this would like to talk in person, that would be great too. Cathy> Sure. I am going to the "Neutron: Extensibility mechanisms: Plugin and Agent" session. If you also plan to go, we can meet there. Or we can meet at tomorrow afternoon's "Neutron: NFV foundation elements" session (Crown room at 4:30pm). -- Russell Bryant __ 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][networking-sfc] API clarification questions
Hi Giuseppe, Please see inline, Regards, Cathy From: Giuseppe (Pino) de Candia [mailto:gdecan...@midokura.com] Sent: Wednesday, October 28, 2015 5:15 PM To: OpenStack Development Mailing List (not for usage questions) Cc: Cathy Zhang; Henry Fourie; Irena Berezovsky Subject: Re: [openstack-dev] [neutron][networking-sfc] API clarification questions On Wed, Oct 28, 2015 at 4:20 PM, Russell Bryant <rbry...@redhat.com<mailto:rbry...@redhat.com>> wrote: I read through the proposed SFC API here: http://docs.openstack.org/developer/networking-sfc/api.html I'm looking at implementing what would be required to support this API in OVN. I have a prototype, but I had to make some pretty big assumptions, so I wanted to clarify the intent of the API. First, does it assume that all of the neutron ports in a chain are on the same Neutron network? That keeps things simple. If its intended to allow a chain of ports on different networks, is it just required that you pick ports that all have addresses routable from one port to the next in the chain? An arbitrary set of ports can't always work, so there has to be some bounds around what set of ports are valid to be in a chain. Hi Russell, We have similarly been experimenting with a MidoNet implementation of the SFC API. I hope there's no restriction on the location of the Neutron ports in a chain. In terms of addresses, I believe the API is lacking (or we use a chain_parameter?) a way to indicate the service insertion model: - L2 - The service can accept packets sent from any MAC (service NIC in promiscuous mode). The MAC address may be used to identify where the packet came from before it entered the chain. - L3 - The service expects packets to be routed to it. So the destination MAC of the packet must be set to the service's NIC's MAC. Any thoughts on this? Cathy> No restriction as long as the ports are routable. Originally we think we need to specify L2 and L3 service type. But later we found out it is not needed if we program the switch to set the next hop destination to the service function’s MAC. This way no matter whether it is L2 or L3, it always works. Second, where is it expected that the match is applied? The API for creating a port chain doesn't associate the chain with a network, but just matching "globally" doesn't make any sense. If all ports are expected to be on the same network, is the match applied for any traffic entering that network from any port? Here's what we were thinking for MidoNet: use the logical_source_port in the flow classifier: when we render the SFC API in MidoNet's models we will associate the chain with the source port. Cathy> Yes, that is the way to specify the flow classifier. Note that one or more flow classifiers can be associated with the same chain. Our packet pipeline (for packets egressing the VM) is: 1. Port Mirroring 2. Service Chaining 3. Filtering (Port Security, anti-spoofing, Security Groups) Do you think we can standardise on a single order in all implementations? We'd be happy to change the order if it makes sense. I'm in Tokyo this week, so if the group working on this would like to talk in person, that would be great too. I'd love to be included. Great topic, thanks! Cathy> I discussed briefly with Russell in yesterday’s Neutron design session. If needed, we can meet in today’s Neutron NFV session. Thanks, Cathy Pino -- Russell Bryant __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://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][networking-sfc] API clarification questions
Hi Russell, Please see inline. Regards, Cathy -Original Message- From: Russell Bryant [mailto:rbry...@redhat.com] Sent: Wednesday, October 28, 2015 5:27 PM To: Cathy Zhang Cc: OpenStack Development Mailing List; Henry Fourie Subject: Re: [neutron][networking-sfc] API clarification questions > > First, does it assume that all of the neutron ports in a chain are on > the same Neutron network? That keeps things simple. If its intended > to allow a chain of ports on different networks, is it just required > that you pick ports that all have addresses routable from one port to > the next in the chain? > > Cathy> It can allow a chain of ports on different networks as along it > belongs to the same tenant. Yes, it is required that you pick ports > that all have addresses routable from one port to the next in the chain. Thanks. I think it would be good to clarify this in the API doc, so it's clear what makes a valid set of ports in a chain. Cathy> Sure, will do. > An arbitrary set of ports can't always work, so there has to be some > bounds around what set of ports are valid to be in a chain. > > Second, where is it expected that the match is applied? The API for > creating a port chain doesn't associate the chain with a network, but > just matching "globally" doesn't make any sense. If all ports are > expected to be on the same network, is the match applied for any > traffic entering that network from any port? > > Cathy> As long as the ports are routable, they do not need to > Cathy> associated with > the same network. Let me rephrase the question ... where is the flow classifier applied? What traffic exactly? "All traffic on all networks accessible to the tenant who created the port chain" doesn't seem right to me, but the API doesn't seem to specify it. Cathy> What traffic will go through the chain is specified in the flow classifier API. As I presented in the Neutron SFC session of the Summit, there are two ways to specify the type of flows. One is through specification of the source neutron port that a tenant's flow will originate and/or the destination neutron port that a tenant's flow will exit which means all traffic that originates from that port and/or terminates at that port needs to go through the chain. The other is through specification of the n-tuple of a tenant's flow. If it is the first specification, the flow classifier will locate at the host of the neutron port and the flow classifier can either run on the host or the vSwitch or a VM depending on implementation. If it is the second specification, then if the flow's IP or mac is specified, we can locate the host and program the host to do the flow classification, but if there is no information available to locate the host, then all hosts that could originate traffic into the network will be programmed for classification of the flow. So to have better performance, we recommend the first way of specification. Thanks, Cathy -- Russell __ 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][networking-sfc] no IRC project meeting for service function chaining project this week and next week
Some key members of this project are either on business trip or on vacation after the Summit. So we will also cancel our IRC project meeting on 11/5 and resume the meeting on 11/12. Thanks, Cathy From: Cathy Zhang Sent: Wednesday, October 21, 2015 11:06 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Neutron][networking-sfc] no IRC project meeting for service function chaining project this week and next week Hi, Since most of us are very busy with presentation preparation for the Summit, let's cancel this week's project meeting. We will resume the meeting on 11/5. Thanks, Cathy __ 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-dev] [Neutron][networking-sfc] no IRC project meeting for service function chaining project this week and next week
Hi, Since most of us are very busy with presentation preparation for the Summit, let's cancel this week's project meeting. We will resume the meeting on 11/5. Thanks, Cathy __ 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] New cycle started. What are you up to, folks?
Hi Ihar, Thank you for starting this thread. Here is what on top of my mind for Mitaka: I will be busy with work centered around networking-sfc project. Networking-sfc is a sub project of Neutron (part of the Neutron Stadium), which provides a service function chain API and related functionality. It has a service chain plugin similar to the ML2 architecture. On the southbound it could integrate with different SFC drivers such as OVS SFC driver, ONOS SFC driver etc.. It allows different data path encapsulation mechanisms. All the specifications have been reviewed and merged into the networking-sfc repo. In the next cycle, I plan to 1. continue leading the project team to finish the review and update of the code patches 2. Get the last piece of codes (OVS Agent and UT) tested and uploaded for review 3. Add API/Functional/FullStack tests 4. Have the codes pass all the gating testing to ensure no collateral damage 5. Get all the codes fully reviewed, and then merged to be ready for release in Mitaka. 5. We will give a deep dive presentation on the SFC project, future roadmap, and demo the functionality Following are some work items in the future roadmap: 1) integrate with Container to support a mixed chain of Service functions running on VMs or on containers 2) add a registration API to bring the physical service function devices into the chain and support a mixed of service functions running on VMs, or containers, or physical devices 3) Support OpenStack SFC integration with ONOS controller 7. Contribute to the common classifier model (to be used in SFC, QoS, Tap as a Service, FWaaS, Security Group etc) and leverage the flow classifier design and codes developed in networking-sfc. 8. Contribute to port forwarding in neutron which could leverage the work done in networking-sfc. 9. Help with Neutron code review, bug fix, and testing as much as possible. Here are some information links on the networking-sfc project for your reference: http://docs.openstack.org/developer/networking-sfc/ https://github.com/openstack/networking-sfc https://review.openstack.org/#/q/status:open+project:openstack/networking-sfc+branch:master+topic:networking-sfc,n,z https://wiki.openstack.org/wiki/Meetings/ServiceFunctionChainingMeeting Thanks, Cathy -Original Message- From: Ihar Hrachyshka [mailto:ihrac...@redhat.com] Sent: Thursday, October 01, 2015 6:45 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [neutron] New cycle started. What are you up to, folks? Hi all, I talked recently with several contributors about what each of us plans for the next cycle, and found it’s quite useful to share thoughts with others, because you have immediate yay/nay feedback, and maybe find companions for next adventures, and what not. So I’ve decided to ask everyone what you see the team and you personally doing the next cycle, for fun or profit. That’s like a PTL nomination letter, but open to everyone! :) No commitments, no deadlines, just list random ideas you have in mind or in your todo lists, and we’ll all appreciate the huge pile of awesomeness no one will ever have time to implement even if scheduled for Xixao release. To start the fun, I will share my silly ideas in the next email. Ihar __ 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] pypi packages for networking sub-projects
Hi Kyle, Is this only about the sub-projects that are ready for release? I do not see networking-sfc sub-project in the list. Does this mean we have done the pypi registrations for the networking-sfc project correctly or it is not checked because it is not ready for release yet? Thanks, Cathy From: Kyle Mestery [mailto:mest...@mestery.com] Sent: Wednesday, September 30, 2015 11:55 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [neutron] pypi packages for networking sub-projects Folks: In trying to release some networking sub-projects recently, I ran into an issue [1] where I couldn't release some projects due to them not being registered on pypi. I have a patch out [2] which adds pypi publishing jobs, but before that can merge, we need to make sure all projects have pypi registrations in place. The following networking sub-projects do NOT have pypi registrations in place and need them created following the guidelines here [3]: networking-calico networking-infoblox networking-powervm The following pypi registrations did not follow directions to enable openstackci has "Owner" permissions, which allow for the publishing of packages to pypi: networking-ale-omniswitch networking-arista networking-l2gw networking-vsphere Once these are corrected, we can merge [2] which will then allow the neutron-release team the ability to release pypi packages for those packages. Thanks! Kyle [1] http://lists.openstack.org/pipermail/openstack-infra/2015-September/003244.html [2] https://review.openstack.org/#/c/229564/1 [3] http://docs.openstack.org/infra/manual/creators.html#give-openstack-permission-to-publish-releases __ 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] pypi packages for networking sub-projects
Hi Armando and Kyle, Thanks for your reply. Yes, the codes are not ready for release yet. The code size is not small and we are working hard on getting the codes ready as soon as possible. Cathy From: Kyle Mestery [mailto:mest...@mestery.com] Sent: Wednesday, September 30, 2015 6:40 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] pypi packages for networking sub-projects On Wed, Sep 30, 2015 at 8:26 PM, Armando M. <arma...@gmail.com<mailto:arma...@gmail.com>> wrote: On 30 September 2015 at 16:02, Cathy Zhang <cathy.h.zh...@huawei.com<mailto:cathy.h.zh...@huawei.com>> wrote: Hi Kyle, Is this only about the sub-projects that are ready for release? I do not see networking-sfc sub-project in the list. Does this mean we have done the pypi registrations for the networking-sfc project correctly or it is not checked because it is not ready for release yet? Can't speak for Kyle, but with these many meaty patches in flight [1], I think it's fair to assume that although the mechanisms are in place, Kyle is not going to release the project at this time; networking-sfc release is independent, we can publish the project when the time is ripe. Armando is exactly spot on. The release of networking-sfc would appear to be pretty early at this point. Once the patches land and the team has some confidence in the API and it's testing status, we'll look at releasing it. Thanks! Kyle Cheers, Armando [1] https://review.openstack.org/#/q/status:open+project:openstack/networking-sfc,n,z Thanks, Cathy From: Kyle Mestery [mailto:mest...@mestery.com<mailto:mest...@mestery.com>] Sent: Wednesday, September 30, 2015 11:55 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [neutron] pypi packages for networking sub-projects Folks: In trying to release some networking sub-projects recently, I ran into an issue [1] where I couldn't release some projects due to them not being registered on pypi. I have a patch out [2] which adds pypi publishing jobs, but before that can merge, we need to make sure all projects have pypi registrations in place. The following networking sub-projects do NOT have pypi registrations in place and need them created following the guidelines here [3]: networking-calico networking-infoblox networking-powervm The following pypi registrations did not follow directions to enable openstackci has "Owner" permissions, which allow for the publishing of packages to pypi: networking-ale-omniswitch networking-arista networking-l2gw networking-vsphere Once these are corrected, we can merge [2] which will then allow the neutron-release team the ability to release pypi packages for those packages. Thanks! Kyle [1] http://lists.openstack.org/pipermail/openstack-infra/2015-September/003244.html [2] https://review.openstack.org/#/c/229564/1 [3] http://docs.openstack.org/infra/manual/creators.html#give-openstack-permission-to-publish-releases __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://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://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] Service Chain project IRC meeting minutes - 09/17/2015
Hi Everyone, Thanks for joining the service chaining project meeting on 9/17/2015. Here is the link to the meeting logs: http://eavesdrop.openstack.org/meetings/service_chaining/2015/. Due to some connection glitch, the HTML format of the meeting log is not quite complete and you may want to refer to the following full log for complete discussion. http://eavesdrop.openstack.org/meetings/service_chaining/2015/service_chaining.2015-09-17-17.00.log.html I will be on business trip and will not be able to run the next project IRC meeting. Louis Fourie will host the next project meeting. Thanks, Cathy __ 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-dev] No networking-sfc project IRC meeting this Thursday 8/27/2015 due to OpenStack Silicon Valley 2015
Hi everyone, Since some of us will go to the OpenStack Silicon Valley 2015 Event, we have to skip this Thursday's SFC IRC project meeting. We will resume our meeting the following week. Thanks, Cathy __ 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-dev] [neutron] No networking-sfc project IRC meeting this Thursday 8/27/2015 due to OpenStack Silicon Valley 2015
Hi everyone, Since some of us will go to the OpenStack Silicon Valley 2015 Event, we have to skip this Thursday's SFC IRC project meeting. We will resume our meeting the following week. Thanks, Cathy __ 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-dev] [neutron] Service Chain project IRC meeting minutes - 07/30/2015
Hi Everyone, Thanks for joining the service chaining project meeting on 7/30/2015. Here is the link to the meeting logs: http://eavesdrop.openstack.org/meetings/service_chaining/2015/ Thanks, Cathy __ 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] The proposed Neutron API extension for packet forwarding has a lot of duplication to the Neutron SFC API
Hi Anita, Not sure if you read the logs. The concern on https://review.openstack.org/#/c/186663/ and duplication were brought up by Sean. The goal is to have one set of API instead of multiple APIs with minor differences. The consensus is that the SFC API seems more general than the forwarding API, the forwarding API can be covered by the chain API, and the forwarding API is just a chain of 1 (a special case of chain API). Here are some snips of the meeting log related to this discussion. Per my action items of the meeting, I am sending out an email updating everyone about our discussion and consensus. No one can force anyone else to do anything. This community project team have done diligence to reach out to authors of https://review.openstack.org/#/c/186663/ multiple times before about collaboration and convergence of APIs (Please refer to previous meeting logs). --- 17:11:55 pcarver vikram: it's not the same but it has a lot in common. If we're going to have both there will need to be extremely clear documentation to guide operators and tenants on when to use each. 17:12:16 pcarver Especially if the two can interact in unpredictable ways 17:12:19 vikram pcarver: i agree.. 17:12:23 sc68cal I just feel like there are some things that are in common, the idea of redirecting traffic - the mechanics may be different but I don't like this idea of oh it's just a little bit different, therefore a whole new separate API is justified 17:12:52 vikram sc68cal: h 17:13:20 pcarver cathy_: I understand the desire to not have too many dependencies, but it may make sense to have a have one be a degenerate case of the other 17:13:42 pcarver as opposed to two unrelated things that appear similar to the user 17:14:04 LouisF sc68cal: the sfc is more general than the forwarding spec 17:14:30 LouisF its functionality can be covered by the sfc spec 17:14:36 vikram sc68cal, pcarver: I agree, service function chaining can achieve the use case defined in forwarding spec 17:15:06 pcarver LouisF, vikram: I haven't reviewed 186663 before looking at it just now, but is there a reason why it couldn't be implemented as a trivially simple service chain? -- 17:15:31 cathy_ vikram:agree with you. Would you like to talk with Yuji on that ? 17:15:32 vikram pcarver: I believe it can 17:15:36 LouisF pcarver: yes I think that can be done 17:16:03 sc68cal yeah I mean I could be stupid but the forwarding API is basically just a chain of 1 -- 17:16:11 vikram cathy_: We can put our concerns over the etherpad link shared for this spec 17:16:14 sc68cal and BTW - fwaas is going to be a chain of 1 17:16:26 vikram https://etherpad.openstack.org/p/forwarding-rule 17:16:27 sc68cal if we're inserting a firewall between an instance and the rest of the network 17:16:52 sc68cal I had hoped to consume SFC, to look into making fwaas more flexible 17:17:00 vikram sc68cal:+++100 17:17:41 pcarver sc68cal: +1, security functions are a primary example of the reason for SFC, although not all chained functions are firewallish 17:17:55 jwarendt +1 17:18:27 cathy_ So we all agree that the service chain API can cover the functionality needed in https://review.openstack.org/#/c/186663/ 17:18:41 LouisF +1 17:18:58 pcarver I'm also hearing requirements from the NFV side wanting to replicate hub and spoke topologies. I'm viewing that also as a subset of SFC - 17:21:16 cathy_ So how should we make sure there is no duplicate API? Maybe Vikram can communicate this with Yuji? Suggestion? 17:22:13 sc68cal I'd say maybe an e-mail to the ML, with the results of this meeting, and say that we want to try and converge where there is commonality 17:22:19 vikram cathy_: sure.. i have posted a comment on the spec.. will try to catch him tomorrow over IRC as wekk -Original Message- From: Anita Kuno [mailto:ante...@anteaya.info] Sent: Monday, July 27, 2015 2:20 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] The proposed Neutron API extension for packet forwarding has a lot of duplication to the Neutron SFC API On 07/24/2015 06: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 currently implemented. In the IRC meeting, the project team reached consensus that we only need one API and the service chain API can cover the functionality needed by https://review.openstack.org/#/c/186663/. Please refer to the meeting log http://eavesdrop.openstack.org/meetings/service_chaining/2015/service_chaining.2015-07-23-17.02.log.html for more discussion info. Please let us know if you have different opinion. Thanks, Cathy
Re: [openstack-dev] [Neutron][SFC] Wiki update - deleting old SFC API
Hi Paul, -Original Message- From: Paul Carver [mailto:pcar...@paulcarver.us] Sent: Thursday, July 23, 2015 7:46 PM To: openstack-dev@lists.openstack.org Subject: 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 a Gerrit review isn't the most end user friendly way of presenting an API. One option is to link to the GitHub version of the rendered RST file [3] but I'd like to know if there are any other preferred practices. Cathy Agree with you. Let's remove those duplicate sections and add the link to the rendered RST file [3] if there are no other preferred practices. Would you like to take care of this or I can clean this up? Thanks, Cathy [1] https://wiki.openstack.org/wiki/Neutron/APIForServiceChaining [2] https://review.openstack.org/#/c/192933/ [3] https://github.com/openstack/networking-sfc/blob/master/doc/source/api.rst __ 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][SFC] Wiki update - deleting old SFC API
Hi Sean, -Original Message- From: Sean M. Collins [mailto:s...@coreitpro.com] Sent: Friday, July 24, 2015 7:45 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][SFC] Wiki update - deleting old SFC API On Thu, Jul 23, 2015 at 10:45:50PM EDT, Paul Carver wrote: On a general topic of wiki cleanup, what's the preferred mechanism for documenting APIs? I prefer that the APIs be submitted in a spec, so that they are published on http://specs.openstack.org/openstack/neutron-specs/ At least there, changes can be reviewed by others - the problem with the wiki is it can be changed without any review. At least with neutron-specs it's versioned and there is discussion that is captured and preserved. Cathy +1. Cathy Do you know the process of getting the API spec published at http://specs.openstack.org/openstack/neutron-specs/? We can port the merged networking-sfc API spec and the latest patch over. Or we have to wait until we have some working codes for key functionality? I'm +1 on cleaning/deleting stuff from the wiki about the old SFC API Cathy +1 too. -- Sean M. Collins __ 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-dev] The proposed Neutron API extension for packet forwarding has a lot of duplication to the Neutron SFC API
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 currently implemented. In the IRC meeting, the project team reached consensus that we only need one API and the service chain API can cover the functionality needed by https://review.openstack.org/#/c/186663/. Please refer to the meeting log http://eavesdrop.openstack.org/meetings/service_chaining/2015/service_chaining.2015-07-23-17.02.log.html for more discussion info. Please let us know if you have different opinion. Thanks, Cathy __ 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] Service Chain project IRC meeting minutes - 07/16/2015
Hi Wei, Yes, We will have project meeting on IRC every week. I will send out an cancellation notice to the openstack-dev if a meeting will be canceled. You are welcome to join! Cathy From: Vikram Choudhary [mailto:viks...@gmail.com] Sent: Tuesday, July 21, 2015 3:40 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] Service Chain project IRC meeting minutes - 07/16/2015 Hi Wei, It happens every week unless cancelled by the chair. Thanks Vikram On Tue, Jul 21, 2015 at 3:10 PM, Damon Wang damon.dev...@gmail.commailto:damon.dev...@gmail.com wrote: Hi, Does service chaining project meeting will be held this week? I'd like to join :-D Wei Wang 2015-07-17 2:09 GMT+08:00 Cathy Zhang cathy.h.zh...@huawei.commailto:cathy.h.zh...@huawei.com: Hi Everyone, Thanks for joining the service chaining project meeting on 7/16/2015. Here is the link to the meeting logs: http://eavesdrop.openstack.org/meetings/service_chaining/2015/ Thanks, Cathy __ 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] Concern about networking-sfc and community process
Hi Sean, I was on IRC Infra channel yesterday getting guidance about the merge. I have replied to all the other comments on the new version 12 and addressed them in the latest updated version, but I did not spot yours since yours is towards the end of the spec and Louis, not I, replied to your comment. I apologize for this! I am usually careful and addressing all comments posted (even after the PTL approval). Yesterday I was in a little rush and was busy switching between intranet for checking the Jenkin email notification and external Internet for getting on the IRC channel and updating/checking in new versions. After I spotted your latest “-1” yesterday, I had replied that I will upload a follow-up patch to add the API endpoints and URL info in the wiki to this spec. Apologize again for this! Thanks, Cathy From: Kyle Mestery [mailto:mest...@mestery.com] Sent: Friday, July 17, 2015 8:13 AM To: OpenStack Development Mailing List (not for usage questions) Cc: Cathy Zhang Subject: Re: [openstack-dev] [Neutron] Concern about networking-sfc and community process On Thu, Jul 16, 2015 at 8:39 PM, Sean M. Collins s...@coreitpro.commailto:s...@coreitpro.com wrote: Hi Cathy, You recently merged the following patch, by +2'ing and then Workflow+1'ing it, without allowing reviewers the chance to look at the changes between the patchset where there were -1's and the newer patchsets. https://review.openstack.org/#/c/192933/ I do see that you were asking on -infra about the mechanics of how to merge a patch http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2015-07-16.log.html#t2015-07-16T23:54:03 Just because a core member has given it a +2 and the Neutron PTL had +2'd a previous patch, doesn't mean that you should go ahead and unilaterally approve your own patch. That's not a way to build a commmunity project. I agree with Sean here. The patch merged with only a single +2, and if the other comments were not addressed earlier, they need to be addressed with a followup patch (and reply on this email thread with the patch), or we should revert the commit and address them there. Thanks, Kyle -- Sean M. Collins __ 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
[openstack-dev] [neutron] Service Chain project IRC meeting minutes - 07/16/2015
Hi Everyone, Thanks for joining the service chaining project meeting on 7/16/2015. Here is the link to the meeting logs: http://eavesdrop.openstack.org/meetings/service_chaining/2015/ Thanks, Cathy __ 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-dev] [neutron] Service Chain project IRC meeting agenda
Hi everyone, Below are some items we plan to discuss in the next IRC meeting. Please add more topics you would like to discuss if any. Thanks, Cathy * Spec update for addressing new comments, and review * SFC CLI client and Horizon Client dependency on base Neutron CLI and Horizon code * OVS Driver and OVS support for classifier and SFF. If we decide to go for no SFC header with chain ID, then the OVS has to build a forwarding table based on 5-tuple or n-tuple for flow identification. * ? __ 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-dev] [neutron] Service Chain project IRC meeting minutes - 07/09/2015
Hi Everyone, Thanks for joining the service chaining project meeting on 7/9/2015. Here is the link to the meeting logs: http://eavesdrop.openstack.org/meetings/service_chaining/2015/ Thanks, Cathy __ 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-dev] [neutron] Service Chain project IRC meeting minutes - 06/25/2015
Hi Everyone, Thanks for joining the service chaining project meeting on 6/25/2015. Here is the link to the meeting logs: http://eavesdrop.openstack.org/meetings/service_chaining/2015/ Thanks, Cathy __ 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-dev] [neutron] Service Chain project IRC meeting minutes - 06/18/2015
Hi Everyone, Thanks for joining the service chaining project meeting on 6/18/2015. Here is the link to the meeting logs: http://eavesdrop.openstack.org/meetings/service_chaining/2015/ A brief summary on today’s discussion: 1. Update on repository creation Repository has been created on OpenStack. https://review.openstack.org/#/c/192820/ and https://review.openstack.org/#/c/188637/ Neutron team has adopted this project. 2. Finalize the SFC API Continue collecting review comments and finalize it by next Wednesday, and we will start implementing the APIs 3. Project management and core members Cathy will manage the project and is currently running the IRC meetings and technical discussions. Core members: Kyle Mestery, Armando, Cathy Zhang, Louis Fourie, Swami, Vikram, Nicolas, Mohankumar, Ramanjaneya, Brian, s3wong, Yuji 4. Finalize the SFC project scope and functional module breakdown Following is a summary of functional module breakdown and ownership sign-up (adding more people who have signed up as the contributors). We will be happy to see more people involved to get this in the direction that suits everybody and reaching us out publicly is best. * Integration with Neutron/devstack, CLI, Horizon, Heat--Mohankumar and Ramanjaneya * Neutron Service chain API Extension- Cathy，LouisF * Flow Classifier API LouisF，Vikram, Yuji, nbouthors * Service chain Plugin: API handling and Data Base- LouisF, Cathy,Swami, s3wong * Service Chain Driver managerCathy, Brian * OVS Driver LouisF, Brian, s3wong * Flow Classifier on the data Path--- nbouthors_, Yuji * OVS with NSH encapsulation for verification of the OpenStack Service Chain API Plugin functionality---LouisF, Swami, 5. Deep dive into technical questions *Relationship with use case spec https://review.openstack.org/#/c/169201/ Our API spec provides the Neutron level design and code to support the use case documented in the above link * Why do we need to add “encapsulation” context to the service chain API Our API needs to cover both service VMs that do not support new chain header and service VMs that support the new chain header. So the vSwitch needs to be told which encapsulation format to use for communicating with the service function VMs. That is why we need this context parameter in the API which will be passed down to the vSwitch. 6. Tentative time line for development of each module We will get the feedback from each piece owner about their timeline of completion in next IRC meeting __ 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] Change in openstack/neutron-specs[master]: Neutron API for Service Chaining
Hi Nicolas, Thanks for your suggestion. Yes, we can add Application ID to the parameter of the flow classifier/filter. The next updated version will reflect this. Actually in its existing design, the parameter field of the flow classifier can be extended in the future to include more flow descriptors for more granular differentiation of flows. Per earlier suggestion from Isaku etc., we can also add a “context” field to the service chain API. The context field will include information such as “the encapsulation mechanism” used by the service functions in the chain, which can be NSH, VLAN, none etc. so that the Service Function Forwarder (the vSwcitch) knows whether it should act as a SFC proxy or not and if acting as a Proxy, what is the chain correlation mechanism between the Service Function Forwarder and the Service Function. Any comments/questions/suggestions? Thanks, Cathy From: Nicolas BOUTHORS [mailto:nicolas.bouth...@qosmos.com] Sent: Wednesday, June 17, 2015 12:03 AM To: Armando Migliaccio; Henry Fourie Cc: Isaku Yamahata; Gal Sagie; vishwanath jayaraman; Swaminathan Vasudevan; Ila Palanisamy; Adolfo Duarte; Ritesh Anand; Lynn Li; Bob Melander; Berezovsky Irena; Subrahmanyam Ongole; Cathy Zhang; Moshe Levi; Joe D'Andrea; Ryan Tidwell; Vikram Choudhary; Ruijing; Yatin Kumbhare; Miguel Angel Ajo; Numan Siddique; Yuriy Babenko; YujiAzama Subject: RE: Change in openstack/neutron-specs[master]: Neutron API for Service Chaining In IETF SFC draft-penno-sfc-appid-00 proposed a notion of ApplicationId, a generic attribute that can be included in NSH metadata. This reflects also on ODL SFC wich has introduced the Application Id as a parameter that can be used by the Classifier to steer traffic into a chain. I suggest we include this parameter in the Flow Filter resource, so that application aware service chaining can be done. ApplicationId is typically encoded in a 32 bit field. Application Identification Data Format The following table displays the Selector ID default length for the different Classification Engine IDs. Classification Selector ID default Engine ID Name length (in bytes) IANA-L3 1 PANA-L3 1 IANA-L4 2 PANA-L4 2 USER-Defined 3 PANA-L2 5 PANA-L7 3 ETHERTYPE2 LLC 1 PANA-L7-PEN 3 (*) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Class. Eng. ID |zero-valued upper-bits ... Selector ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Nicolas -Original Message- From: Jenkins (Code Review) [mailto:rev...@openstack.org] Sent: mercredi 17 juin 2015 08:46 To: Armando Migliaccio; Louis Fourie Cc: Isaku Yamahata; Gal Sagie; vishwanath jayaraman; Swaminathan Vasudevan; Ila Palanisamy; Adolfo Duarte; Ritesh Anand; Lynn Li; Bob Melander; Berezovsky Irena; Subrahmanyam Ongole; cathy; Moshe Levi; Joe D'Andrea; Ryan Tidwell; vikram.choudhary; Ruijing; Yatin Kumbhare; Miguel Angel Ajo; Numan Siddique; Yuriy Babenko; YujiAzama Subject: Change in openstack/neutron-specs[master]: Neutron API for Service Chaining Jenkins has posted comments on this change. Change subject: Neutron API for Service Chaining .. Patch Set 8: Verified+1 Build succeeded (check pipeline). - gate-neutron-specs-docs http://docs-draft.openstack.org/46/177946/8/check/gate-neutron-specs-docs/6955f62//doc/build/html/http://docs-draft.openstack.org/46/177946/8/check/gate-neutron-specs-docs/6955f62/doc/build/html/ : SUCCESS in 3m 51s - gate-neutron-specs-python27 http://logs.openstack.org/46/177946/8/check/gate-neutron-specs-python27/271ef19/ : SUCCESS in 2m 31s -- To view, visit https://review.openstack.org/177946 To unsubscribe, visit https://review.openstack.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ic0df6070fefd9ead6589fa2da6c49824d7ae3941 Gerrit-PatchSet: 8 Gerrit-Project: openstack/neutron-specs Gerrit-Branch: master Gerrit-Owner: Louis Fourie louis.fou...@huawei.commailto:louis.fou...@huawei.com Gerrit-Reviewer: Adolfo Duarte adolfo.dua...@hp.commailto:adolfo.dua...@hp.com Gerrit-Reviewer: Armando Migliaccio arma...@gmail.commailto:arma...@gmail.com Gerrit-Reviewer: Berezovsky Irena irenab@gmail.commailto:irenab@gmail.com Gerrit-Reviewer: Bob Melander bob.melan...@gmail.commailto:bob.melan...@gmail.com Gerrit-Reviewer: Gal Sagie gal.sa...@huawei.commailto:gal.sa
Re: [openstack-dev] Change in openstack/neutron-specs[master]: Neutron API for Service Chaining
Hi Nicolas, Thanks for your suggestion. Yes, we can add Application ID to the parameter of the flow classifier/filter. The next updated version will reflect this. Actually in its existing design, the parameter field of the flow classifier can be extended in the future to include more flow descriptors for more granular differentiation of flows. Per earlier suggestion from Isaku etc., we can also add a “context” field to the service chain API. The context field will include information such as “the encapsulation mechanism” used by the service functions in the chain, which can be NSH, VLAN, none etc. so that the Service Function Forwarder (the vSwcitch) knows whether it should act as a SFC proxy or not and if acting as a Proxy, what is the chain correlation mechanism between the Service Function Forwarder and the Service Function. Any comments/questions/suggestions? Thanks, Cathy From: Nicolas BOUTHORS [mailto:nicolas.bouth...@qosmos.com] Sent: Wednesday, June 17, 2015 12:03 AM To: Armando Migliaccio; Henry Fourie Cc: Isaku Yamahata; Gal Sagie; vishwanath jayaraman; Swaminathan Vasudevan; Ila Palanisamy; Adolfo Duarte; Ritesh Anand; Lynn Li; Bob Melander; Berezovsky Irena; Subrahmanyam Ongole; Cathy Zhang; Moshe Levi; Joe D'Andrea; Ryan Tidwell; Vikram Choudhary; Ruijing; Yatin Kumbhare; Miguel Angel Ajo; Numan Siddique; Yuriy Babenko; YujiAzama Subject: RE: Change in openstack/neutron-specs[master]: Neutron API for Service Chaining In IETF SFC draft-penno-sfc-appid-00 proposed a notion of ApplicationId, a generic attribute that can be included in NSH metadata. This reflects also on ODL SFC wich has introduced the Application Id as a parameter that can be used by the Classifier to steer traffic into a chain. I suggest we include this parameter in the Flow Filter resource, so that application aware service chaining can be done. ApplicationId is typically encoded in a 32 bit field. Application Identification Data Format The following table displays the Selector ID default length for the different Classification Engine IDs. Classification Selector ID default Engine ID Name length (in bytes) IANA-L3 1 PANA-L3 1 IANA-L4 2 PANA-L4 2 USER-Defined 3 PANA-L2 5 PANA-L7 3 ETHERTYPE2 LLC 1 PANA-L7-PEN 3 (*) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Class. Eng. ID |zero-valued upper-bits ... Selector ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Nicolas -Original Message- From: Jenkins (Code Review) [mailto:rev...@openstack.org] Sent: mercredi 17 juin 2015 08:46 To: Armando Migliaccio; Louis Fourie Cc: Isaku Yamahata; Gal Sagie; vishwanath jayaraman; Swaminathan Vasudevan; Ila Palanisamy; Adolfo Duarte; Ritesh Anand; Lynn Li; Bob Melander; Berezovsky Irena; Subrahmanyam Ongole; cathy; Moshe Levi; Joe D'Andrea; Ryan Tidwell; vikram.choudhary; Ruijing; Yatin Kumbhare; Miguel Angel Ajo; Numan Siddique; Yuriy Babenko; YujiAzama Subject: Change in openstack/neutron-specs[master]: Neutron API for Service Chaining Jenkins has posted comments on this change. Change subject: Neutron API for Service Chaining .. Patch Set 8: Verified+1 Build succeeded (check pipeline). - gate-neutron-specs-docs http://docs-draft.openstack.org/46/177946/8/check/gate-neutron-specs-docs/6955f62//doc/build/html/http://docs-draft.openstack.org/46/177946/8/check/gate-neutron-specs-docs/6955f62/doc/build/html/ : SUCCESS in 3m 51s - gate-neutron-specs-python27 http://logs.openstack.org/46/177946/8/check/gate-neutron-specs-python27/271ef19/ : SUCCESS in 2m 31s -- To view, visit https://review.openstack.org/177946 To unsubscribe, visit https://review.openstack.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ic0df6070fefd9ead6589fa2da6c49824d7ae3941 Gerrit-PatchSet: 8 Gerrit-Project: openstack/neutron-specs Gerrit-Branch: master Gerrit-Owner: Louis Fourie louis.fou...@huawei.commailto:louis.fou...@huawei.com Gerrit-Reviewer: Adolfo Duarte adolfo.dua...@hp.commailto:adolfo.dua...@hp.com Gerrit-Reviewer: Armando Migliaccio arma...@gmail.commailto:arma...@gmail.com Gerrit-Reviewer: Berezovsky Irena irenab@gmail.commailto:irenab@gmail.com Gerrit-Reviewer: Bob Melander bob.melan...@gmail.commailto:bob.melan...@gmail.com Gerrit-Reviewer: Gal Sagie gal.sa...@huawei.commailto:gal.sa
[openstack-dev] [Neutron] service chaining feature development meeting at 10am pacific time June 18
Hello everyone, Our next weekly IRC meeting for the OpenStack service chain feature development is 10am pacific time June 18 (UTC 1700) Following is the meeting info: Weekly on Thursday at 1700 UTChttp://www.timeanddate.com/worldclock/fixedtime.html?hour=18min=00sec=0 in #openstack-meeting-4 You can also find the meeting info at http://eavesdrop.openstack.org/#Neutron_Service_Chaining_meeting Agenda: 1. Update on repository creation 2. Finalize the SFC Feature project scope: functional module breakdown and ownership as well as the types of service functions that will be chained in this feature development. Here is a summary of functional module ownership sign-up based on last IRC meeting and email confirmation. * Integration with Neutron/devstack, CLI, Horizon, Heat--Mohankumar and Ramanjaneya * Neutron Service chain API Extension- Cathy，LouisF * Flow Classifier API LouisF，Vikram, Yuji, nbouthors * Service chain Plugin: API handling and Data Base- LouisF, Cathy，Swami, * Service Chain Driver managerCathy, Brian * OVS Driver LouisF, Brian * Flow Classifier on the data Path--- nbouthors_, Yuji * OVS with NSH encapsulation for verification of the OpenStack Service Chain API Plugin functionality---LouisF, Swami, 3. Service chain API and spec discussion and try to finalize the service chain API design so that we can start implementing it. 4. Deep dive into technical questions 5. Tentative time line for development of each module. Anyone who would like to contribute to this feature development is welcome to join the meeting. Hope the time is good for most people. Thanks, Cathy __ 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-dev] [neutron] Service Chain project IRC meeting minutes - 06/11/2015
Hi Everyone, Thanks for joining the service chaining meeting on 6/11/2015. Here are the links to the meeting logs: http://eavesdrop.openstack.org/meetings/sfc_project/2015/sfc_project.2015-06-11-17.01.html http://eavesdrop.openstack.org/meetings/sfc_project/2015/sfc_project.2015-06-11-17.01.txt http://eavesdrop.openstack.org/meetings/sfc_project/2015/sfc_project.2015-06-11-17.01.log.html Thanks, Cathy __ 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] Regarding Flow classifiers existing proposals
Hi Yuji, This is very similar to the flow classifier which has been proposed in https://review.openstack.org/#/c/177946. Since quite some people have reviewed and given comments on https://review.openstack.org/#/c/177946 and the latest version has incorporated those comments, I would suggest that you incorporate your input to https://review.openstack.org/#/c/177946 and work with LouisF and Vikram on driving and developing a unified flow classifier API and model. Thanks, Cathy -Original Message- From: Yuji Azama [mailto:yuj-az...@rc.jp.nec.com] Sent: Wednesday, June 10, 2015 9:24 PM To: Cathy Zhang; Henry Fourie; mangel...@redhat.com; Vikram Choudhary Cc: arma...@gmail.com; Dongfeng (C); mest...@mestery.com; openstack-dev@lists.openstack.org; Dhruv Dhody; Kalyankumar Asangi Subject: RE: [neutron] Regarding Flow classifiers existing proposals Hello everyone, I want to join to IRC meeting. But I cannot join to the meeting because there is time difference. I tried to write my idea in spec of common classifier resource. ( https://review.openstack.org/#/c/190463 ) Thanks, Yuji -Original Message- From: Cathy Zhang [mailto:cathy.h.zh...@huawei.com] Sent: Saturday, June 06, 2015 3:36 AM To: Henry Fourie; Miguel Angel Ajo; Vikram Choudhary Cc: Azama Yuji(安座間 勇二); arma...@gmail.com; Dongfeng (C); Kyle Mestery; openstack-dev@lists.openstack.org; Dhruv Dhody; Kalyankumar Asangi Subject: RE: [neutron] Regarding Flow classifiers existing proposals Sure. I will add this item to the next IRC meeting agenda. Thanks, Cathy From: Henry Fourie Sent: Friday, June 05, 2015 11:27 AM To: Miguel Angel Ajo; Vikram Choudhary Cc: azama-y...@mxe.nes.nec.co.jp; Cathy Zhang; arma...@gmail.com; Dongfeng (C); Kyle Mestery; openstack-dev@lists.openstack.org; Dhruv Dhody; Kalyankumar Asangi Subject: RE: [neutron] Regarding Flow classifiers existing proposals Miguel, I agree, we can probably use the service-chaining meeting to discuss this. We can have it as an agenda item for the next meeting: http://eavesdrop.openstack.org/#Neutron_Service_Chaining_meeting - Louis From: Miguel Angel Ajo [mailto:mangel...@redhat.com] Sent: Friday, June 05, 2015 1:42 AM To: Vikram Choudhary Cc: azama-y...@mxe.nes.nec.co.jp; Henry Fourie; Cathy Zhang; arma...@gmail.com; Dongfeng (C); Kyle Mestery; openstack-dev@lists.openstack.org; Dhruv Dhody; Kalyankumar Asangi Subject: [neutron] Regarding Flow classifiers existing proposals Added openstack-dev, where I believe this conversation must live. I totally agree on this, thank you for bringing up this conversation. This is not something we want to do for QoS this cycle, but probably next cycle. Anyway, an unified data model and API to create/update classifiers will not only be beneficial from the code duplication point of view, but will also provide a better user experience. I’m all for it. Best regards, Miguel Ángel Ajo On Friday 5 June 2015 at 09:57, Vikram Choudhary wrote: Dear All, There are multiple proposal floating around flow classifier rules for Liberty [1], [2] and [3]. I feel we all should work together and try to address all our use case having a unified framework rather than working separately achieving the same goal. Moreover, I can find the proposal for flow classifier as defined by the existing SFC [2] proposal is too generic and could address all the use cases by minor extension’s. In this regard, I would like all to come forward, exchange their thoughts, work together and make it happen good the first go rather doing the same effort separately and end up in duplicating code effort L. I always feel less code will make our life happy in the long run ;) Please let me know about your views. [1] Add Neutron API extensions for packet forwarding https://review.openstack.org/#/c/186663/ https://review.openstack.org/#/c/186663/ [2] Neutron API for Service Chaining [Flow Filter resource] https://review.openstack.org/#/c/177946/6/specs/liberty/neutron-api-fo r-service-chaining.rst https://review.openstack.org/#/c/177946/6/specs/liberty/neutron-api-f or-service-chaining.rst [3] QoS API Extension [Defines classifier rule in QoSRule. Classifier rule can really grow big in the long run]: https://review.openstack.org/#/c/88599/10/specs/liberty/qos-api-extens ion.rst https://review.openstack.org/#/c/88599/10/specs/liberty/qos-api-exten sion.rst Thanks Vikram __ 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] Service Chain project IRC meeting minutes - 06/04/2015
Hi Armando, Sorry to reply late since I just saw these emails due to improper filter setup in my mailbox. Please see inline. Thanks, Cathy From: Armando M. [mailto:arma...@gmail.com] Sent: Thursday, June 04, 2015 6:06 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] Service Chain project IRC meeting minutes - 06/04/2015 On 4 June 2015 at 14:17, Cathy Zhang cathy.h.zh...@huawei.commailto:cathy.h.zh...@huawei.com wrote: Thanks for joining the service chaining meeting today! Sorry for the time confusion. We will correct the weekly meeting time to 1700UTC (10am pacific time) Thursday #openstack-meeting-4 on the OpenStack meeting page. Cathy, thanks for driving this. I took the liberty to carry out one of the actions identified in the meeting: the creation of repo to help folks collaborate over code/documentation/testing etc [1]. As for the core team definition, we'll start with a single member who can add new folks as more docs/code gets poured in. Cathy Thanks for helping with this. I have asked the infra team to add me to the core team. I will add more folks based on their commitment to this project contribution. One question I had when looking at the minutes, was regarding slides [2]. Not sure if discussing deployment architectures when the API is still baking is premature, but I wonder if you had given some thoughts into having a pure agentless architecture even for the OVS path. Cathy Slide 2 shows the component architecture involved in supporting the port-chain API since many people request more info on what component work are needed for supporting SFC functionality than just an API proposal in https://review.openstack.org/#/c/177946/. As to agentless architecture for OVS path, could you clarify what you mean? Having said that, as soon as the repo is up and running, I'd suggest to move any relevant document (e.g. API proposal, use cases, etc) over to the repo and reboot the review process so that everyone can be on the same page. Cathy Sure, I will do that. Thanks, Cathy Cheers, Armando [1] https://review.openstack.org/#/c/188637/ [2] https://docs.google.com/presentation/d/1SpVyLBCMRFBpMh7BsHmpENbSY6qh1s5NRsAS68ykd_0/edit#slide=id.p Meeting Minutes: http://eavesdrop.openstack.org/meetings/service_chaining/2015/service_chaining.2015-06-04-16.59.html Meeting Minutes (text): http://eavesdrop.openstack.org/meetings/service_chaining/2015/service_chaining.2015-06-04-16.59.txt Meeting Log: http://eavesdrop.openstack.org/meetings/service_chaining/2015/service_chaining.2015-06-04-16.59.log.html The next meeting is scheduled for June 11 (same place and time). Thanks, Cathy __ 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] service chaining feature development meeting at 10am pacific time June 11
Add the following item to the agenda: unified data model for flow classifiers Thanks, Cathy From: Cathy Zhang Sent: Wednesday, June 10, 2015 3:12 PM To: OpenStack Development Mailing List (not for usage questions); Cathy Zhang Subject: [openstack-dev] [Neutron] service chaining feature development meeting at 10am pacific time June 11 Hello everyone, Our next weekly IRC meeting for the OpenStack service chain feature development is 10am pacific time June 11 (UTC 1700, hope I am doing the correct time conversion this time) Following is the meeting info: Weekly on Thursday at 1700 UTChttp://www.timeanddate.com/worldclock/fixedtime.html?hour=18min=00sec=0 in #openstack-meeting-4 You can also find the meeting info at http://eavesdrop.openstack.org/#Neutron_Service_Chaining_meeting Agenda: 1. Update on last meeting's action items 2. Summary on the SFC Feature project scope: functional module breakdown and their architecture relationship as well as their relationship to OpenStack Neutron, the types of service functions that will be chained in this feature development 3. Module development ownership sign-up 4. Deep dive into technical questions on etherpad if there is time. Anyone who would like to contribute to this feature development is welcome to join the meeting. Hope the time is good for most people. Thanks, Cathy __ 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-dev] [Neutron] service chaining feature development meeting at 10am pacific time June 11
Hello everyone, Our next weekly IRC meeting for the OpenStack service chain feature development is 10am pacific time June 11 (UTC 1700, hope I am doing the correct time conversion this time) Following is the meeting info: Weekly on Thursday at 1700 UTChttp://www.timeanddate.com/worldclock/fixedtime.html?hour=18min=00sec=0 in #openstack-meeting-4 You can also find the meeting info at http://eavesdrop.openstack.org/#Neutron_Service_Chaining_meeting Agenda: 1. Update on last meeting's action items 2. Summary on the SFC Feature project scope: functional module breakdown and their architecture relationship as well as their relationship to OpenStack Neutron, the types of service functions that will be chained in this feature development 3. Module development ownership sign-up 4. Deep dive into technical questions on etherpad if there is time. Anyone who would like to contribute to this feature development is welcome to join the meeting. Hope the time is good for most people. Thanks, Cathy __ 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] Service Chain project IRC meeting minutes - 06/04/2015
Hi Paul, Sure. Thanks for the reminder. Cathy -Original Message- From: Paul Carver [mailto:pcar...@paulcarver.us] Sent: Friday, June 05, 2015 4:22 PM To: OpenStack Development Mailing List (not for usage questions) Subject: 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 time confusion. We will correct the weekly meeting time to 1700UTC (10am pacific time) Thursday #openstack-meeting-4 on the OpenStack meeting page. Meeting Minutes: http://eavesdrop.openstack.org/meetings/service_chaining/2015/service_chaining.2015-06-04-16.59.html Meeting Minutes (text): http://eavesdrop.openstack.org/meetings/service_chaining/2015/service_chaining.2015-06-04-16.59.txt Meeting Log: http://eavesdrop.openstack.org/meetings/service_chaining/2015/service_chaining.2015-06-04-16.59.log.html The next meeting is scheduled for June 11 (same place and time). Thanks, Cathy __ 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] service chaining feature development meeting at 10am pacific time June 11
Here is the updated agenda for tomorrow's meeting: 1. Update on last meeting's action items 2. Neutron port chain API for SFC 3. Unified API and data model for flow classifier that can be used for SFC, QoS, Packet forwarding etc. 4. Summary on the SFC Feature project scope: functional module breakdown and their architecture relationship, and Module development ownership sign-up 5. Deep dive into technical questions on etherpad if there is time. Thanks, Cathy From: Cathy Zhang Sent: Wednesday, June 10, 2015 3:23 PM To: Cathy Zhang; OpenStack Development Mailing List (not for usage questions) Subject: RE: [openstack-dev] [Neutron] service chaining feature development meeting at 10am pacific time June 11 Add the following item to the agenda: unified data model for flow classifiers Thanks, Cathy From: Cathy Zhang Sent: Wednesday, June 10, 2015 3:12 PM To: OpenStack Development Mailing List (not for usage questions); Cathy Zhang Subject: [openstack-dev] [Neutron] service chaining feature development meeting at 10am pacific time June 11 Hello everyone, Our next weekly IRC meeting for the OpenStack service chain feature development is 10am pacific time June 11 (UTC 1700, hope I am doing the correct time conversion this time) Following is the meeting info: Weekly on Thursday at 1700 UTChttp://www.timeanddate.com/worldclock/fixedtime.html?hour=18min=00sec=0 in #openstack-meeting-4 You can also find the meeting info at http://eavesdrop.openstack.org/#Neutron_Service_Chaining_meeting Agenda: 6. Update on last meeting's action items 7. Summary on the SFC Feature project scope: functional module breakdown and their architecture relationship as well as their relationship to OpenStack Neutron, the types of service functions that will be chained in this feature development 8. Module development ownership sign-up 9. Deep dive into technical questions on etherpad if there is time. Anyone who would like to contribute to this feature development is welcome to join the meeting. Hope the time is good for most people. Thanks, Cathy __ 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] Regarding Flow classifiers existing proposals
Hi Vikram, Definitely. We should have one unified and generic flow classifier/filter (whatever name we call it) that can be used by all cases. Thank you for driving this! Thanks, Cathy From: Miguel Angel Ajo [mailto:mangel...@redhat.com] Sent: Friday, June 05, 2015 1:42 AM To: Vikram Choudhary Cc: azama-y...@mxe.nes.nec.co.jp; Henry Fourie; Cathy Zhang; arma...@gmail.com; Dongfeng (C); Kyle Mestery; openstack-dev@lists.openstack.org; Dhruv Dhody; Kalyankumar Asangi Subject: [neutron] Regarding Flow classifiers existing proposals Added openstack-dev, where I believe this conversation must live. I totally agree on this, thank you for bringing up this conversation. This is not something we want to do for QoS this cycle, but probably next cycle. Anyway, an unified data model and API to create/update classifiers will not only be beneficial from the code duplication point of view, but will also provide a better user experience. I’m all for it. Best regards, Miguel Ángel Ajo On Friday 5 June 2015 at 09:57, Vikram Choudhary wrote: Dear All, There are multiple proposal floating around flow classifier rules for Liberty [1], [2] and [3]. I feel we all should work together and try to address all our use case having a unified framework rather than working separately achieving the same goal. Moreover, I can find the proposal for flow classifier as defined by the existing SFC [2] proposal is too generic and could address all the use cases by minor extension’s. In this regard, I would like all to come forward, exchange their thoughts, work together and make it happen good the first go rather doing the same effort separately and end up in duplicating code effort ☹. I always feel less code will make our life happy in the long run ;) Please let me know about your views. [1] Add Neutron API extensions for packet forwarding https://review.openstack.org/#/c/186663/ [2] Neutron API for Service Chaining [Flow Filter resource] https://review.openstack.org/#/c/177946/6/specs/liberty/neutron-api-for-service-chaining.rst [3] QoS API Extension [Defines classifier rule in QoSRule. Classifier rule can really grow big in the long run]: https://review.openstack.org/#/c/88599/10/specs/liberty/qos-api-extension.rst Thanks Vikram __ 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] Regarding Flow classifiers existing proposals
Sure. I will add this item to the next IRC meeting agenda. Thanks, Cathy From: Henry Fourie Sent: Friday, June 05, 2015 11:27 AM To: Miguel Angel Ajo; Vikram Choudhary Cc: azama-y...@mxe.nes.nec.co.jp; Cathy Zhang; arma...@gmail.com; Dongfeng (C); Kyle Mestery; openstack-dev@lists.openstack.org; Dhruv Dhody; Kalyankumar Asangi Subject: RE: [neutron] Regarding Flow classifiers existing proposals Miguel, I agree, we can probably use the service-chaining meeting to discuss this. We can have it as an agenda item for the next meeting: http://eavesdrop.openstack.org/#Neutron_Service_Chaining_meeting - Louis From: Miguel Angel Ajo [mailto:mangel...@redhat.com] Sent: Friday, June 05, 2015 1:42 AM To: Vikram Choudhary Cc: azama-y...@mxe.nes.nec.co.jp; Henry Fourie; Cathy Zhang; arma...@gmail.com; Dongfeng (C); Kyle Mestery; openstack-dev@lists.openstack.org; Dhruv Dhody; Kalyankumar Asangi Subject: [neutron] Regarding Flow classifiers existing proposals Added openstack-dev, where I believe this conversation must live. I totally agree on this, thank you for bringing up this conversation. This is not something we want to do for QoS this cycle, but probably next cycle. Anyway, an unified data model and API to create/update classifiers will not only be beneficial from the code duplication point of view, but will also provide a better user experience. I’m all for it. Best regards, Miguel Ángel Ajo On Friday 5 June 2015 at 09:57, Vikram Choudhary wrote: Dear All, There are multiple proposal floating around flow classifier rules for Liberty [1], [2] and [3]. I feel we all should work together and try to address all our use case having a unified framework rather than working separately achieving the same goal. Moreover, I can find the proposal for flow classifier as defined by the existing SFC [2] proposal is too generic and could address all the use cases by minor extension’s. In this regard, I would like all to come forward, exchange their thoughts, work together and make it happen good the first go rather doing the same effort separately and end up in duplicating code effort ☹. I always feel less code will make our life happy in the long run ;) Please let me know about your views. [1] Add Neutron API extensions for packet forwarding https://review.openstack.org/#/c/186663/ [2] Neutron API for Service Chaining [Flow Filter resource] https://review.openstack.org/#/c/177946/6/specs/liberty/neutron-api-for-service-chaining.rst [3] QoS API Extension [Defines classifier rule in QoSRule. Classifier rule can really grow big in the long run]: https://review.openstack.org/#/c/88599/10/specs/liberty/qos-api-extension.rst Thanks Vikram __ 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-dev] [neutron] Service Chain project IRC meeting minutes - 06/04/2015
Thanks for joining the service chaining meeting today! Sorry for the time confusion. We will correct the weekly meeting time to 1700UTC (10am pacific time) Thursday #openstack-meeting-4 on the OpenStack meeting page. Meeting Minutes: http://eavesdrop.openstack.org/meetings/service_chaining/2015/service_chaining.2015-06-04-16.59.html Meeting Minutes (text): http://eavesdrop.openstack.org/meetings/service_chaining/2015/service_chaining.2015-06-04-16.59.txt Meeting Log: http://eavesdrop.openstack.org/meetings/service_chaining/2015/service_chaining.2015-06-04-16.59.log.html The next meeting is scheduled for June 11 (same place and time). Thanks, Cathy __ 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-dev] [Neutron] service chaining feature development meeting at 1800 UTC June 4th
Hello everyone, I have set up the weekly IRC meeting for the OpenStack service chain feature development. Following is the meeting info: Weekly on Thursday at 1800 UTChttp://www.timeanddate.com/worldclock/fixedtime.html?hour=18min=00sec=0 in #openstack-meeting-4 You can also find the meeting info at http://eavesdrop.openstack.org/#Neutron_Service_Chaining_meeting and http://git.openstack.org/cgit/openstack-infra/irc-meetings/tree/meetings] Agenda: 1. Usage scenario 2. Feature scope: functional module breakdown and their architecture relationship as well as their relationship to OpenStack Neutron, the types of service functions that will be chained in this feature development 3. Module ownership sign-up 4. Deep dive into technical questions on etherpad if there is time. Anyone who would like to contribute to this feature development is welcome to join the meeting. Hope the time is good for most people. Thanks, Cathy __ 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-dev] [Neutron] We will have two service chaining feature development design meetings during the Summit
Hi Everyone, I got emails asking for the date of the meeting. Sorry that I forgot to mention the date of the Neutron work session that we can use for Neutron service chain feature discussion. It is at 4:10pm Thursday at room 221 and 9:30am Friday at room 306. Thanks, Cathy From: Cathy Zhang [mailto:cathy.h.zh...@huawei.com] Sent: 19 May 2015 06:37 To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: We will have two service chaining feature development design meetings during the Summit Hi everyone, We will have two service chaining feature design meetings during this Summit. One at 4:10pm during the Neutron Work session at room 221, the other at 9:30am during Neutron Contributors Meetup at room 306. Bring your questions and requirements, poke holes at the API proposal and design, let's have a good deep dive technical discussion. Thanks, Cathy __ 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-dev] [Neutron] service chaining feature development IRC meeting on May 14
Hi everyone, Per request from the community, we will start to host the IRC meetings for this service chain project in addition to the goto audio meetings. The IRC meeting info is as follows. You can also find the meeting info from the link (scroll down to the Neutron Service Chaining Meeting). https://wiki.openstack.org/w/index.php?title=Meetingsdiff=nextoldid=81063#Neutron_Service_Chaining_meeting * Weekly Thursdays at 1800 UTC * IRC channel: #openstack-meeting-4 I have asked Louis Fourie to host this Thursday's meeting. There will be no audio or IRC meeting during the OpenStack Summit week. We will resume the meetings after the Summit. Thanks, Cathy __ 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-dev] [Neutron] service chaining feature development meeting minutes for May 12 2015
Hi, I have added the meeting minutes for May 5 2015 to this feature's meeting link https://wiki.openstack.org/wiki/Meetings/Service_Chaining I have a recording of the service chain feature goto meeting for May 12 2015. The recording is about 50k. Does anyone know an OpenStack link that I can upload this recording to? Thanks, Cathy __ 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] service chaining feature development meeting minutes
Hi Isaku, Sorry that I missed your email. I sent out the meeting info. Hope you received it. I will forward it to you in a separate email. Thanks, Cathy -Original Message- From: Isaku Yamahata [mailto:isaku.yamah...@gmail.com] Sent: Monday, May 11, 2015 10:05 AM To: OpenStack Development Mailing List (not for usage questions) Cc: isaku.yamah...@gmail.com Subject: Re: [openstack-dev] [Neutron] service chaining feature development meeting minutes Hello Cathy. Thank you for arranging the meeting. Will we have goto meeting/irc meeting this week(May 12) on this topic? I haven't seen any announcement yet. thanks in advance Isaku Yamahata On Tue, May 05, 2015 at 08:55:25PM +, Cathy Zhang cathy.h.zh...@huawei.com wrote: Attendees (Sorry we did not catch all the names): Cathy Zhang (Huawei), Louis Fourie, Alex Barclay (HP), Vikram Choudhary, Carlos Goncalves (NTT) m...@cgoncalves.ptmailto:m...@cgoncalves.pt, Adolfo Duarte (HP) adolfo.dua...@hp.commailto:adolfo.dua...@hp.com German Eichberger (HP) german.eichber...@hp.commailto:german.eichber...@hp.com, Swami Vasudevan (HP) swaminathan.vasude...@hp.commailto:swaminathan.vasude...@hp.com, Uri Elzur (Intel) uri.el...@intel.commailto:uri.el...@intel.com Joe D'Andrea (ATT) jdand...@research.att.commailto:jdand...@research.att.com, Isaku Yamahata (Intel) isaku.yamah...@gmail.commailto:isaku.yamah...@gmail.com, Malini Bhandaru malini.k.bhand...@intel.commailto:malini.k.bhand...@intel.com, Michael Johnson (HP) john...@hp.commailto:john...@hp.com, Lynn Li (HP) lynn...@hp.commailto:lynn...@hp.com, Mickey Spiegel (IBM) emspi...@us.ibm.commailto:emspi...@us.ibm.com, Ryan Tidwell (HP) ryan.tidw...@hp.commailto:ryan.tidw...@hp.com Ralf Trezeciak openst...@trezeciak.demailto:openst...@trezeciak.de, David Pinheiro, Hardik Italia Agenda: Cathy presented the service chain architecture and blueprints and Gerrit review for: - Neutron Extensions for Service chaining - Common Neutron SFC Driver API There is a lot of interest on this feature. Questions Uri: Does this BP specify the implementation in the backend data path? Cathy: This could be implemented by various data path chaining schemes: eg. IETF service chain header, VLAN. Uri: What happens if the security group/iptables conflict with SGs for port-chain? Cathy: it is expected that conflicts will be resolved by the upper layer Intent Infra. Vikram: can other datapath transports be used. Cathy: Yes, what is defined in the BP is the NBI for Neutron. Swami: add use case and example. Cathy: will add. There is a SFC use case BP, will contact authors. Carlos: how does this relate to older traffic steering BP. Cathy: we can discuss offline and work together to incorporate the traffic steering BP idea into this BP. Uri: are these two BPs for NBI and SBI for Neutron? Cathy: yes Isaku: does Kyle know about BPs? Cathy: yes Uri: how do these BPs relate to rest of Openstack? Cathy: There will be a presentation on the service chain framework at 2pm May 18 at the Vancouver Summit. It will be presented by Cathy together with Kyle Mestery and Dave Lenrow. Swami: It helps to present a simple service chain use case at meeting next week. Suggest to have IRC meeting too as it provides a record of what is discussed. Cathy: I have already created the IRC meeting for service chain project, will start the IRC meeting too. Malini: we should have a complete spec so redesign is avoided. Swami: We should use Neutron design session at Vancouver to discuss this BP and flesh out details. Action Items 1. We will have two meetings next week: one goto meeting with audio and data sharing, the other IRC meeting with link to google doc for sharing diagrams. Cathy will send out the meeting info to the community 2. Swami will send an email to Kyle Mestery requesting a time slot for service chaining topic in Neutron design session so that we can get all interested parties in one room for a good face-to-face discussion. 3. Cathy will discuss with Carlos offline about incorporating the traffic steering idea into the service chain BPs. 4. Service chaining is a complicated solution involving management plane, control plane, and data plane as well as multiple components. The consensus is to first design/implement the two Neutron related service chain BPs https://review.openstack.org/#/c/177946 and get the feature approved by Neutron Core/Driver team and implemented for the OpenStack L release. If we can not get a slot in the design session, we will meet at the service chain presentation on May 18 and find a room to discuss how to move forward with this feature development in OpenStack. Feel free to chime in if I miss any points. Thanks, Cathy __ OpenStack Development
[openstack-dev] [Neutron] service chaining feature development meeting
Hello everyone, Our next service chain feature development meeting will be 10am~11am May 12th pacific time. Anyone who has interest in this feature development is welcome to join the meeting and contribute together to the service chain feature in OpenStack. OpenStack BP discussion for service chaining Please join the meeting from your computer, tablet or smartphone. https://global.gotomeeting.com/join/199553557, meeting password: 199-553-557 You can also dial in using your phone. United States +1 (224) 501-3212 Access Code: 199-553-557 - Following are the links to the Neutron related service chain specs and the bug IDs. Feel free to sign up and add you comments/input to the BPs. https://review.openstack.org/#/c/177946 https://bugs.launchpad.net/neutron/+bug/1450617 https://bugs.launchpad.net/neutron/+bug/1450625 Thanks, Cathy __ 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-dev] [Neutron] service chaining feature development meeting
Hello everyone, Our next service chain feature development meeting will be 10am~11am May 12th pacific time. Anyone who has interest in this feature development is welcome to join the meeting and contribute together to the service chain feature in OpenStack. OpenStack BP discussion for service chaining Please join the meeting from your computer, tablet or smartphone. https://global.gotomeeting.com/join/199553557, meeting password: 199-553-557 You can also dial in using your phone. United States +1 (224) 501-3212 Access Code: 199-553-557 - Following are the links to the Neutron related service chain specs and the bug IDs. Feel free to sign up and add you comments/input to the BPs. https://review.openstack.org/#/c/177946 https://bugs.launchpad.net/neutron/+bug/1450617 https://bugs.launchpad.net/neutron/+bug/1450625 Thanks, Cathy __ 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-dev] [Neutron] reminder: service chaining feature development meeting at 10am pacific time today May 5th
Hello everyone, Some of you have reached out to me asking questions about when we will start meeting discussion on the service chaining feature BPs in OpenStack. I have set up agoto meeting for an audio meeting discussion so that we can sync up thought and bring everyone on the same page in a more efficient way. The meeting will be 10am~11am May 5th pacific time. Anyone who has interest in this feature development is welcome to join the meeting and contribute together to the service chain feature in OpenStack. Hope the time is good for most people. OpenStack BP discussion for service chaining Please join the meeting from your computer, tablet or smartphone. https://global.gotomeeting.com/join/199553557, meeting password: 199-553-557 You can also dial in using your phone. United States +1 (224) 501-3212 Access Code: 199-553-557 - Following are the links to the Neutron related service chain specs and the bug IDs. Feel free to sign up and add you comments/input to the BPs. https://review.openstack.org/#/c/177946 https://bugs.launchpad.net/neutron/+bug/1450617 https://bugs.launchpad.net/neutron/+bug/1450625 Just FYI. There is an approved service chain project in OPNFV. Here is the link to the project page. It will be good to sync up the service chain work between the two communities. https://wiki.opnfv.org/requirements_projects/openstack_based_vnf_forwarding_graph Thanks, Cathy __ 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-dev] [Neutron] service chaining feature development meeting minutes
Attendees (Sorry we did not catch all the names): Cathy Zhang (Huawei), Louis Fourie, Alex Barclay (HP), Vikram Choudhary, Carlos Goncalves (NTT) m...@cgoncalves.ptmailto:m...@cgoncalves.pt, Adolfo Duarte (HP) adolfo.dua...@hp.commailto:adolfo.dua...@hp.com German Eichberger (HP) german.eichber...@hp.commailto:german.eichber...@hp.com, Swami Vasudevan (HP) swaminathan.vasude...@hp.commailto:swaminathan.vasude...@hp.com, Uri Elzur (Intel) uri.el...@intel.commailto:uri.el...@intel.com Joe D'Andrea (ATT) jdand...@research.att.commailto:jdand...@research.att.com, Isaku Yamahata (Intel) isaku.yamah...@gmail.commailto:isaku.yamah...@gmail.com, Malini Bhandaru malini.k.bhand...@intel.commailto:malini.k.bhand...@intel.com, Michael Johnson (HP) john...@hp.commailto:john...@hp.com, Lynn Li (HP) lynn...@hp.commailto:lynn...@hp.com, Mickey Spiegel (IBM) emspi...@us.ibm.commailto:emspi...@us.ibm.com, Ryan Tidwell (HP) ryan.tidw...@hp.commailto:ryan.tidw...@hp.com Ralf Trezeciak openst...@trezeciak.demailto:openst...@trezeciak.de, David Pinheiro, Hardik Italia Agenda: Cathy presented the service chain architecture and blueprints and Gerrit review for: - Neutron Extensions for Service chaining - Common Neutron SFC Driver API There is a lot of interest on this feature. Questions Uri: Does this BP specify the implementation in the backend data path? Cathy: This could be implemented by various data path chaining schemes: eg. IETF service chain header, VLAN. Uri: What happens if the security group/iptables conflict with SGs for port-chain? Cathy: it is expected that conflicts will be resolved by the upper layer Intent Infra. Vikram: can other datapath transports be used. Cathy: Yes, what is defined in the BP is the NBI for Neutron. Swami: add use case and example. Cathy: will add. There is a SFC use case BP, will contact authors. Carlos: how does this relate to older traffic steering BP. Cathy: we can discuss offline and work together to incorporate the traffic steering BP idea into this BP. Uri: are these two BPs for NBI and SBI for Neutron? Cathy: yes Isaku: does Kyle know about BPs? Cathy: yes Uri: how do these BPs relate to rest of Openstack? Cathy: There will be a presentation on the service chain framework at 2pm May 18 at the Vancouver Summit. It will be presented by Cathy together with Kyle Mestery and Dave Lenrow. Swami: It helps to present a simple service chain use case at meeting next week. Suggest to have IRC meeting too as it provides a record of what is discussed. Cathy: I have already created the IRC meeting for service chain project, will start the IRC meeting too. Malini: we should have a complete spec so redesign is avoided. Swami: We should use Neutron design session at Vancouver to discuss this BP and flesh out details. Action Items 1. We will have two meetings next week: one goto meeting with audio and data sharing, the other IRC meeting with link to google doc for sharing diagrams. Cathy will send out the meeting info to the community 2. Swami will send an email to Kyle Mestery requesting a time slot for service chaining topic in Neutron design session so that we can get all interested parties in one room for a good face-to-face discussion. 3. Cathy will discuss with Carlos offline about incorporating the traffic steering idea into the service chain BPs. 4. Service chaining is a complicated solution involving management plane, control plane, and data plane as well as multiple components. The consensus is to first design/implement the two Neutron related service chain BPs https://review.openstack.org/#/c/177946 and get the feature approved by Neutron Core/Driver team and implemented for the OpenStack L release. If we can not get a slot in the design session, we will meet at the service chain presentation on May 18 and find a room to discuss how to move forward with this feature development in OpenStack. Feel free to chime in if I miss any points. Thanks, Cathy __ 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-dev] [Neutron] service chaining feature development
Hello everyone, Some of you have reached out to me asking questions about when we will start meeting discussion on the service chaining feature BPs in OpenStack. I have set up agoto meeting for an audio meeting discussion so that we can sync up thought and bring everyone on the same page in a more efficient way. The meeting will be 10am~11am May 5th pacific time. Anyone who has interest in this feature development is welcome to join the meeting and contribute together to the service chain feature in OpenStack. Hope the time is good for most people. OpenStack BP discussion for service chaining Please join the meeting from your computer, tablet or smartphone. https://global.gotomeeting.com/join/199553557, meeting password: 199-553-557 You can also dial in using your phone. United States +1 (224) 501-3212 Access Code: 199-553-557 - Following are the links to the Neutron related service chain specs and the bug IDs. Feel free to sign up and add you comments/input to the BPs. https://review.openstack.org/#/c/177946 https://bugs.launchpad.net/neutron/+bug/1450617 https://bugs.launchpad.net/neutron/+bug/1450625 Just FYI. There is an approved service chain project in OPNFV. Here is the link to the project page. It will be good to sync up the service chain work between the two communities. https://wiki.opnfv.org/requirements_projects/openstack_based_vnf_forwarding_graph Thanks, Cathy __ 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-dev] [Neutron] service chaining feature development
Hello everyone, Some of you have reached out to me asking questions about when we will start meeting discussion on the service chaining feature BPs in OpenStack. I have set up agoto meeting for an audio meeting discussion so that we can sync up thought and bring everyone on the same page in a more efficient way. The meeting will be 10am~11am May 5th pacific time. Anyone who has interest in this feature development is welcome to join the meeting and contribute together to the service chain feature in OpenStack. Hope the time is good for most people. OpenStack BP discussion for service chaining Please join the meeting from your computer, tablet or smartphone. https://global.gotomeeting.com/join/199553557, meeting password: 199-553-557 You can also dial in using your phone. United States +1 (224) 501-3212 Access Code: 199-553-557 - Following are the links to the Neutron related service chain specs and the bug IDs. Feel free to sign up and add you comments/input to the BPs. https://review.openstack.org/#/c/177946 https://bugs.launchpad.net/neutron/+bug/1450617 https://bugs.launchpad.net/neutron/+bug/1450625 Just FYI. There is an approved service chain project in OPNFV. Here is the link to the project page. It will be good to sync up the service chain work between the two communities. https://wiki.opnfv.org/requirements_projects/openstack_based_vnf_forwarding_graph Thanks, Cathy __ 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][policy] Bridging the 2-group gap in group policy
Hi all, I support this API proposal. It is simple and conveys clear semantics. Thanks Ryan! Cathy From: Hemanth Ravi [mailto:hemanthrav...@gmail.com] Sent: Wednesday, July 30, 2014 11:13 AM To: OpenStack Development Mailing List (not for usage questions) Cc: Subrahmanyam Ongole Subject: Re: [openstack-dev] [neutron][policy] Bridging the 2-group gap in group policy Hi, Adding this CLI command seems to be a good way to provide support for the second model. This can be submitted as a new review patch to work through the approaches to implement this. I suggest the current CLI patch [1] be reviewed for the existing spec and completed. Ryan, would it possible for you to start a new review submit for the new command(s). Could you also provide any references for profiled API in IETF, CCITT. Thanks, -hemanth [1] https://review.openstack.org/#/c/104013 On Tue, Jul 29, 2014 at 3:16 PM, Ryan Moats rmo...@us.ibm.commailto:rmo...@us.ibm.com wrote: As promised in Monday's Neutron IRC minutes [1], this mail is a trip down memory lane looking at the history of the Neutron GP project.. The original GP google doc [2] included specifying policy via both a produce/consume 1-group approach and as a link between two groups. There was an email thread [3] that discussed the relationship between these models early on, but that discussion petered out and during a later IRC meeting [4] the concept of contracts were added, but without changing the basic use case requirements from the original document. A followup meeting [5] began the discussion of how to express the original model from the contract data model but that discussion doesn't appear to have been completed either. The PoC in Atlanta raised a set of issues [6],[7] around the complexity of the resulting PoC code. The good news is that having looked through the proposed GP code commits (links to which can be found at [8) I believe that folks that want to be able to specify policies via the 2-group approach (and yes, I'm one of them) can have that without changing the model encoded in those commits. Rather, it can be done via the WiP CLI code commit by providing a profiled API - this is a technique used by the IETF, CCITT, etc. to allow a rich API to be consumed in common ways. In this case, what I'm envisioning is something like neutron policy-apply [policy rule] [src group] [destination group] in this case, the CLI would perform the contract creation for the policy rule, and assigning the proper produce/consume edits to the specified source and destination groups. Note: this is in addition to the CLI providing direct access to the underlying data model. I believe that this is the simplest way to bridge the gap and provide support to folks who want to specify policy as something between two groups. Ryan Moats (regXboi) References: [1] http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-07-28-21.02.log.txt [2] https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit#https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit [3] http://lists.openstack.org/pipermail/openstack-dev/2013-December/022150.html [4] http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-02-27-19.00.log.html [5] http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-03-20-19.00.log.html [6] http://lists.openstack.org/pipermail/openstack-dev/2014-May/035661.html [7] http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-05-22-18.01.log.html [8] https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy ___ 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
