Doug, Networking-sfc API currently has two reference SFC implementations that are open source: the OVS driver and the ONOS driver. Work is also in progress for an ODL SFC driver and an OVN driver.
- Louis From: Doug Wiegley [mailto:doug...@parksidesoftware.com] Sent: Friday, May 20, 2016 5:48 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][TC] support of NSH in networking-SFC In a nutshell, you’ve got it, you can’t add an API without a reference implementation, including data-plane, which has to be open-source (though does not have to itself be openstack.) o Especially as Stadium, can we let Neutron to lead the industry, given broad enough community interest? You can do anything you want outside the stadium, which is where experimental/incubation is meant to happen. Inside the stadium means, “official openstack project”, which means it has an open-source implementation. If all backends are closed-source, it’s not open as openstack defines it: https://governance.openstack.org/reference/opens.html There isn’t any wiggle room there. This isn’t a neutron argument; feel free to take it up with the TC. Thanks, doug On May 20, 2016, at 6:37 PM, Elzur, Uri <uri.el...@intel.com<mailto:uri.el...@intel.com>> wrote: Hi Armando, Cathy, All First I apologize for the delay, returning from a week long international trip. (yes, I know, a lousy excuse on many accounts…) If I’m attempting to summarize all the responses, it seems like • A given abstraction in Neutron is allowed (e.g. in support of SFC), preferably not specific to a given technology e.g. NSH for SFC • A stadium project is not held to the same tests (but we do not have a “formal” model here, today) and therefore can support even a specific technology e.g. NSH (definitely better with abstractions to meet Neutron standards for future integration) However, • There still is a chicken and egg phenomenon… how can a technology become main stream with OPEN SOURCE support if we can’t get an OpenStack to support the required abstractions before the technology was adopted elsewhere?? o Especially as Stadium, can we let Neutron to lead the industry, given broad enough community interest? • BTW, in this particular case, there originally has been a direct ODL access as a NSH solution (i.e. NO OpenStack option), then we got Tacker (now an Neutron Stadium project, if I get it right) to support SFC and NSH, but we are still told that networking-sfc (another Neutron Stadium project ) can’t do the same…. • Also regarding the following comment made on another message in this thread, “As to OvS features, I guess the OvS ml is a better place, but wonder if the Neutron community wants to hold itself hostage to the pace of other projects who are reluctant to adopt a feature”, what I mean is again, that chicken and egg situation as above. Personally, I think OpenStack Neutron should allow mechanisms that are of interest / value to the networking community at large, to “ experiment with the abstraction” as you stated, independent of other organizations/projects… SOOO, is the bottom line that we agree that supporting NSH explicitly in networking-sfc can be added now? Thx Uri (“Oo-Ree”) C: 949-378-7568 From: Armando M. [mailto:arma...@gmail.com] Sent: Friday, May 13, 2016 5:14 PM To: Cathy Zhang <cathy.h.zh...@huawei.com<mailto:cathy.h.zh...@huawei.com>> Cc: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC On 13 May 2016 at 16:01, Cathy Zhang <cathy.h.zh...@huawei.com<mailto:cathy.h.zh...@huawei.com>> wrote: Hi Uri, Current networking-sfc API allows the user to specify the data path SFC encapsulation mechanism and NSH could be one of the encapsulation options. But since OVS release has not supported the NSH yet, we have to wait until NSH is added into OVS and then start to support the NSH encapsulation mechanism in the data path. One can support NSH whichever way they see fit. NSH in OVS is not something Neutron can do anything about. Neutron is about defining abstractions that can apply to a variety of technologies and experiment with what open source component is available on the shelves. Anyone can take the abstraction and deliver whatever technology stack they want with it and we'd happily gather any feedback to iterate on the abstraction to address more and more use case. AFAIK, it is the position of Neutron to have any OVS related new features developed inside the OVS community. Thanks, Cathy From: Elzur, Uri [mailto:uri.el...@intel.com<mailto:uri.el...@intel.com>] Sent: Friday, May 13, 2016 3:02 PM To: OpenStack Development Mailing List (not for usage questions); Armando M Subject: [openstack-dev] [Neutron] support of NSH in networking-SFC Hi Armando As an industry we are working on SFC for 3 years or so (more?). Still to date, we are told we can’t get Neutron or even a Stadium project e.g. networking-SFC to support NSH (in IETF LC phase) because OvS has not supported NSH. Is this an official position of Neutron that OvS is the gold standard to support any new feature? We have seen OvS support other overlays that are not ahead of VXLAN-gpe in the IETF. Thx Uri (“Oo-Ree”) C: 949-378-7568<tel:949-378-7568> __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org<mailto: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
