Open Stack

Hi Cathy

Pls note my other response to the list on this subject.
It is not clear to me on what ground is the following conclusion derived. Was asking Armando a clear answer to the topic at hand


Thx

Uri (“Oo-Ree”)
C: 949-378-7568

-----Original Message-----
From: Cathy Zhang [mailto:Cathy.H.Zhang at huawei.com] 
Sent: Monday, May 16, 2016 1:10 PM
To: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

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:pcarver at paulcarver.us]
Sent: Saturday, May 14, 2016 7:25 AM
To: openstack-dev at 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." <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.

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at 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-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev