Hi Uri, I hope all the replies have helped answer your question.
To echo what Paul said, the networking-sfc approach is to separate the API from the backend drivers. The actual data plane forwarder is not part of networking-sfc. We aren't going to maintain the out-of-tree OVS NSH code. When OVS accepts the NSH functionality, our network-sfc OVS driver will be updated to support "push NSH" and "pop NSH" etc. to make use of the NSH encapsulation available in the data plane forwarder. If you know any other open source vSwitch/vRouter that already supports NSH and if someone wants to write a networking-sfc driver for it, that code would be welcomed. Thanks, Cathy -----Original Message----- From: Paul Carver [mailto:pcar...@paulcarver.us] Sent: Saturday, May 14, 2016 7:25 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC On Fri, 13 May 2016 17:13:59 -0700 "Armando M." <arma...@gmail.com> wrote: > On 13 May 2016 at 16:10, Elzur, Uri <uri.el...@intel.com> wrote: > > > Hi Cathy > > > > > > > > Thank you for the quick response. This is the essence of my question > > – does Neutron keep OvS as a gold standard and why > > > > Not at all true. Neutron, the open source implementation, uses a > variety of open components, OVS being one of them. If you know of any > open component that supports NSH readily available today, I'd be happy > to hear about it. I agree with Armando and Cathy. There's nothing "gold standard" about OvS. The networking-sfc approach is to separate the API from the backend drivers and the OvS driver is only one of several. We have a place in the API where we expect to capture the tenant's intent to use NSH. What we don't currently have is a backend, OvS or other, that supports NSH. The actual dataplane forwarder is not part of networking-sfc. We aren't going to maintain the out-of-tree OvS NSH code or depend on it. When OvS accepts the NSH functionality upstream then our network-sfc driver will be able to make use of it. If any other vSwitch/vRouter that already supports NSH and if someone wants to write a networking-sfc driver for, that code would be welcome. We've also started discussing how to implement a capabilities discovery API so that if some backends support a capability (e.g. NSH) and other backends don't support it, we will provide the tenant with an abstract way to query the networking-sfc API in order to determine whether a particular capability can be provided by the current backend. The thing networking-sfc won't take on is ownership of the upstream dataplane forwarder projects. We'll simply provide an abstraction so that a common API can invoke SFC across pre-existing SFC-capable dataplanes. __________________________________________________________________________ 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
