Open Stack

On Fri, 13 May 2016 17:13:59 -0700
"Armando M." <armamig at gmail.com> wrote:

> On 13 May 2016 at 16:10, Elzur, Uri <uri.elzur at 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.