Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

[Yang, Yi Y]

Replies inline, please check.

-Original Message-
From: Elzur, Uri [mailto:uri.el...@intel.com] 
Sent: Thursday, June 02, 2016 9:19 AM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>; Cathy Zhang <cathy.h.zh...@huawei.com>; 
b...@ovn.org
Cc: Jesse Gross <je...@kernel.org>; Jiri Benc <jb...@redhat.com>
Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

Few comments below

Thx

Uri ("Oo-Ree")
C: 949-378-7568

-Original Message-
From: Yang, Yi Y [mailto:yi.y.y...@intel.com]
Sent: Wednesday, June 1, 2016 5:20 PM
To: Cathy Zhang <cathy.h.zh...@huawei.com>; OpenStack Development Mailing List 
(not for usage questions) <openstack-dev@lists.openstack.org>; b...@ovn.org
Cc: Jesse Gross <je...@kernel.org>; Jiri Benc <jb...@redhat.com>
Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

Also cc to Jiri and Jesse, I think mandatory L3 requirement is not reasonable 
for tunnel port, say VxLAN or VxLAN-gpe, its intention is to L2 over L3, so L2 
header is must-have, but mandatory L3 requirement removed L2.
[UE] pls add more context

[Yi Yang] In current Linux kernel, VxLAN-gpe port is a L3 port, that means one 
packet with L2 will be popped eth header by implicit pop_eth when it is output 
to such port. But I think this is inappropriate, VxLAN-gpe can transfer L2 
packet as VxLAN does, we can't force it to work in L3 mode.

I also think VxLAN + Eth + NSH + Original frame should be an option, at least 
industries have such requirements in practice.

So my point is it will be great if we can support both 
VxLAN-gpe+ETH+NSH+Original L2 and VxLAN+ETH+NSH+Original L2, this will simplify 
our nsh patches upstreaming efforts and speed up merging.
[UE] this " VxLAN+ETH+NSH+Original L2" can be a local packet (i.e. SFF to SF on 
a 'local circuit") IFF OS kernels and SFs will support it, but not sure how it 
can travel on the wire... what is in that added ETH header? 

[Yi Yang] This ETH is from inner L2 (Original L2), but ether_type is 0x894f

[UE] did you mean " VxLAN-gpe+NSH+Original L2" or  " VxLAN-gpe+ETH+NSH+Original 
L2"? The latter is not the packet on the wire

[Yi Yang] Current ovs implementation requires the packet from tunnel port must 
be Ethernet packet, so we have to use VxLAN-gpe+Eth+Nsh+Original packet, I know 
hardware devices only recognize "VxLAN-gpe+NSH+Original L2".


-Original Message-
From: Cathy Zhang [mailto:cathy.h.zh...@huawei.com]
Sent: Thursday, June 02, 2016 2:54 AM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>; b...@ovn.org; Yang, Yi Y 
<yi.y.y...@intel.com>
Cc: Cathy Zhang <cathy.h.zh...@huawei.com>
Subject: RE: [openstack-dev] [Neutron] support of NSH in networking-SFC

Looks like the work of removing the mandatory L3 requirement associated with 
decapsulated VxLAN-gpe packet also involves OVS kernel change, which is 
difficult. Furthermore, even this blocking issue is resolved and eventually OVS 
accepts the VLAN-gpe+NSH encapsulation, there is still another issue. 
Current Neutron only supports VXLAN, not VXLAN-gpe, and adopting VXLAN-gpe 
involves consideration of backward compatibility with existing VXLAN VTEP and 
VXLAN Gateway. 

An alternative and maybe easier/faster path could be to push a patch of " VxLAN 
+ Eth + NSH + Original frame" into OVS kernel. This is also IETF compliant 
encapsulation for SFC and does not have the L3 requirement issue and Neutron 
VXLAN-gpe support issue. 

We can probably take this discussion to the OVS mailing alias. 

Thanks,
Cathy

-Original Message-
From: Ben Pfaff [mailto:b...@ovn.org]
Sent: Tuesday, May 31, 2016 9:48 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

On Wed, Jun 01, 2016 at 12:08:23AM +, Yang, Yi Y wrote:
> Ben, yes, we submitted nsh support patch set last year, but ovs 
> community told me we have to push kernel part into Linux kernel tree, 
> we're struggling to do this, but something blocked us from doing this.

It's quite difficult to get patches for a new protocol into the kernel.
You have my sympathy.

> Recently, ovs did some changes in tunnel protocols which requires the 
> packet decapsulated by a tunnel must be a Ethernet packet, but Linux 
> kernel (net-next) tree accepted VxLAN-gpe patch set from Redhat guy 
> (Jiri Benc) which requires the packet decapsulated by VxLAN-gpe port 
> must be L3 packet but not L2 Ethernet packet, this blocked us from 
> progressing better.
> 
> Simon Horman (Netronome guy) has posted a series of patches to remove 
> the mandatory requirement from ovs in order that the packet from a 
> tunnel can be any packet, but so far we didn't see they are mer

Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

[Elzur, Uri]

Few comments below

Thx

Uri ("Oo-Ree")
C: 949-378-7568

-Original Message-
From: Yang, Yi Y [mailto:yi.y.y...@intel.com] 
Sent: Wednesday, June 1, 2016 5:20 PM
To: Cathy Zhang <cathy.h.zh...@huawei.com>; OpenStack Development Mailing List 
(not for usage questions) <openstack-dev@lists.openstack.org>; b...@ovn.org
Cc: Jesse Gross <je...@kernel.org>; Jiri Benc <jb...@redhat.com>
Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

Also cc to Jiri and Jesse, I think mandatory L3 requirement is not reasonable 
for tunnel port, say VxLAN or VxLAN-gpe, its intention is to L2 over L3, so L2 
header is must-have, but mandatory L3 requirement removed L2.
[UE] pls add more context

I also think VxLAN + Eth + NSH + Original frame should be an option, at least 
industries have such requirements in practice.

So my point is it will be great if we can support both 
VxLAN-gpe+ETH+NSH+Original L2 and VxLAN+ETH+NSH+Original L2, this will simplify 
our nsh patches upstreaming efforts and speed up merging.
[UE] this " VxLAN+ETH+NSH+Original L2" can be a local packet (i.e. SFF to SF on 
a 'local circuit") IFF OS kernels and SFs will support it, but not sure how it 
can travel on the wire... what is in that added ETH header? 
[UE] did you mean " VxLAN-gpe+NSH+Original L2" or  " VxLAN-gpe+ETH+NSH+Original 
L2"? The latter is not the packet on the wire


-Original Message-
From: Cathy Zhang [mailto:cathy.h.zh...@huawei.com]
Sent: Thursday, June 02, 2016 2:54 AM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>; b...@ovn.org; Yang, Yi Y 
<yi.y.y...@intel.com>
Cc: Cathy Zhang <cathy.h.zh...@huawei.com>
Subject: RE: [openstack-dev] [Neutron] support of NSH in networking-SFC

Looks like the work of removing the mandatory L3 requirement associated with 
decapsulated VxLAN-gpe packet also involves OVS kernel change, which is 
difficult. Furthermore, even this blocking issue is resolved and eventually OVS 
accepts the VLAN-gpe+NSH encapsulation, there is still another issue. 
Current Neutron only supports VXLAN, not VXLAN-gpe, and adopting VXLAN-gpe 
involves consideration of backward compatibility with existing VXLAN VTEP and 
VXLAN Gateway. 

An alternative and maybe easier/faster path could be to push a patch of " VxLAN 
+ Eth + NSH + Original frame" into OVS kernel. This is also IETF compliant 
encapsulation for SFC and does not have the L3 requirement issue and Neutron 
VXLAN-gpe support issue. 

We can probably take this discussion to the OVS mailing alias. 

Thanks,
Cathy

-Original Message-
From: Ben Pfaff [mailto:b...@ovn.org]
Sent: Tuesday, May 31, 2016 9:48 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

On Wed, Jun 01, 2016 at 12:08:23AM +, Yang, Yi Y wrote:
> Ben, yes, we submitted nsh support patch set last year, but ovs 
> community told me we have to push kernel part into Linux kernel tree, 
> we're struggling to do this, but something blocked us from doing this.

It's quite difficult to get patches for a new protocol into the kernel.
You have my sympathy.

> Recently, ovs did some changes in tunnel protocols which requires the 
> packet decapsulated by a tunnel must be a Ethernet packet, but Linux 
> kernel (net-next) tree accepted VxLAN-gpe patch set from Redhat guy 
> (Jiri Benc) which requires the packet decapsulated by VxLAN-gpe port 
> must be L3 packet but not L2 Ethernet packet, this blocked us from 
> progressing better.
> 
> Simon Horman (Netronome guy) has posted a series of patches to remove 
> the mandatory requirement from ovs in order that the packet from a 
> tunnel can be any packet, but so far we didn't see they are merged.

These are slowly working their way through OVS review, but these also have a 
prerequisite on kernel patches, so it's not easy to get them in either.

> I heard ovs community looks forward to getting nsh patches merged, it 
> will be great if ovs guys can help progress this.

I do plan to do my part in review (but much of this is kernel review, which I'm 
not really involved in anymore).

__
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 (

Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

[Yang, Yi Y]

Indeed, but I saw an exceptional case, LISP, it is in ovs but not in Linux 
kernel. For our nsh patches, kernel is easier than ovs.

-Original Message-
From: Ben Pfaff [mailto:b...@ovn.org] 
Sent: Thursday, June 02, 2016 7:17 AM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

I'm probably the wrong person to give advice on kernel development, since I 
haven't been involved in it for years.  I just know that it's difficult, and 
not always because of the code.

It's hard to support a protocol in OVS before it's supported in the kernel, 
since userspace without a kernel implementation is not very useful.

On Wed, Jun 01, 2016 at 09:59:12PM +, Elzur, Uri wrote:
> Hi Ben
> 
> Any guidance you can offer will be appreciated. The process has taken long 
> time and precious cycles. How can we get to a coordinated Kernel and OvS 
> approach to avoid the challenges and potentially misaligned advise we got 
> (per Yi Yang's mail)?
> 
> Thx
> 
> Uri ("Oo-Ree")
> C: 949-378-7568
> 
> 
> -Original Message-
> From: Ben Pfaff [mailto:b...@ovn.org]
> Sent: Tuesday, May 31, 2016 9:48 PM
> To: OpenStack Development Mailing List (not for usage questions) 
> <openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [Neutron] support of NSH in 
> networking-SFC
> 
> On Wed, Jun 01, 2016 at 12:08:23AM +, Yang, Yi Y wrote:
> > Ben, yes, we submitted nsh support patch set last year, but ovs 
> > community told me we have to push kernel part into Linux kernel 
> > tree, we're struggling to do this, but something blocked us from doing this.
> 
> It's quite difficult to get patches for a new protocol into the kernel.
> You have my sympathy.
> 
> > Recently, ovs did some changes in tunnel protocols which requires 
> > the packet decapsulated by a tunnel must be a Ethernet packet, but 
> > Linux kernel (net-next) tree accepted VxLAN-gpe patch set from 
> > Redhat guy (Jiri Benc) which requires the packet decapsulated by 
> > VxLAN-gpe port must be L3 packet but not L2 Ethernet packet, this 
> > blocked us from progressing better.
> > 
> > Simon Horman (Netronome guy) has posted a series of patches to 
> > remove the mandatory requirement from ovs in order that the packet 
> > from a tunnel can be any packet, but so far we didn't see they are merged.
> 
> These are slowly working their way through OVS review, but these also have a 
> prerequisite on kernel patches, so it's not easy to get them in either.
> 
> > I heard ovs community looks forward to getting nsh patches merged, 
> > it will be great if ovs guys can help progress this.
> 
> I do plan to do my part in review (but much of this is kernel review, which 
> I'm not really involved in anymore).
> 
> __
>  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

__
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] support of NSH in networking-SFC

[Yang, Yi Y]

Also cc to Jiri and Jesse, I think mandatory L3 requirement is not reasonable 
for tunnel port, say VxLAN or VxLAN-gpe, its intention is to L2 over L3, so L2 
header is must-have, but mandatory L3 requirement removed L2.

I also think VxLAN + Eth + NSH + Original frame should be an option, at least 
industries have such requirements in practice.

So my point is it will be great if we can support both 
VxLAN-gpe+ETH+NSH+Original L2 and VxLAN+ETH+NSH+Original L2, this will simplify 
our nsh patches upstreaming efforts and speed up merging.

-Original Message-
From: Cathy Zhang [mailto:cathy.h.zh...@huawei.com] 
Sent: Thursday, June 02, 2016 2:54 AM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>; b...@ovn.org; Yang, Yi Y 
<yi.y.y...@intel.com>
Cc: Cathy Zhang <cathy.h.zh...@huawei.com>
Subject: RE: [openstack-dev] [Neutron] support of NSH in networking-SFC

Looks like the work of removing the mandatory L3 requirement associated with 
decapsulated VxLAN-gpe packet also involves OVS kernel change, which is 
difficult. Furthermore, even this blocking issue is resolved and eventually OVS 
accepts the VLAN-gpe+NSH encapsulation, there is still another issue. 
Current Neutron only supports VXLAN, not VXLAN-gpe, and adopting VXLAN-gpe 
involves consideration of backward compatibility with existing VXLAN VTEP and 
VXLAN Gateway. 

An alternative and maybe easier/faster path could be to push a patch of " VxLAN 
+ Eth + NSH + Original frame" into OVS kernel. This is also IETF compliant 
encapsulation for SFC and does not have the L3 requirement issue and Neutron 
VXLAN-gpe support issue. 

We can probably take this discussion to the OVS mailing alias. 

Thanks,
Cathy

-Original Message-
From: Ben Pfaff [mailto:b...@ovn.org]
Sent: Tuesday, May 31, 2016 9:48 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

On Wed, Jun 01, 2016 at 12:08:23AM +, Yang, Yi Y wrote:
> Ben, yes, we submitted nsh support patch set last year, but ovs 
> community told me we have to push kernel part into Linux kernel tree, 
> we're struggling to do this, but something blocked us from doing this.

It's quite difficult to get patches for a new protocol into the kernel.
You have my sympathy.

> Recently, ovs did some changes in tunnel protocols which requires the 
> packet decapsulated by a tunnel must be a Ethernet packet, but Linux 
> kernel (net-next) tree accepted VxLAN-gpe patch set from Redhat guy 
> (Jiri Benc) which requires the packet decapsulated by VxLAN-gpe port 
> must be L3 packet but not L2 Ethernet packet, this blocked us from 
> progressing better.
> 
> Simon Horman (Netronome guy) has posted a series of patches to remove 
> the mandatory requirement from ovs in order that the packet from a 
> tunnel can be any packet, but so far we didn't see they are merged.

These are slowly working their way through OVS review, but these also have a 
prerequisite on kernel patches, so it's not easy to get them in either.

> I heard ovs community looks forward to getting nsh patches merged, it 
> will be great if ovs guys can help progress this.

I do plan to do my part in review (but much of this is kernel review, which I'm 
not really involved in anymore).

__
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] support of NSH in networking-SFC

[Ben Pfaff]

I'm probably the wrong person to give advice on kernel development,
since I haven't been involved in it for years.  I just know that it's
difficult, and not always because of the code.

It's hard to support a protocol in OVS before it's supported in the
kernel, since userspace without a kernel implementation is not very
useful.

On Wed, Jun 01, 2016 at 09:59:12PM +, Elzur, Uri wrote:
> Hi Ben
> 
> Any guidance you can offer will be appreciated. The process has taken long 
> time and precious cycles. How can we get to a coordinated Kernel and OvS 
> approach to avoid the challenges and potentially misaligned advise we got 
> (per Yi Yang's mail)?
> 
> Thx
> 
> Uri ("Oo-Ree")
> C: 949-378-7568
> 
> 
> -Original Message-
> From: Ben Pfaff [mailto:b...@ovn.org] 
> Sent: Tuesday, May 31, 2016 9:48 PM
> To: OpenStack Development Mailing List (not for usage questions) 
> <openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC
> 
> On Wed, Jun 01, 2016 at 12:08:23AM +, Yang, Yi Y wrote:
> > Ben, yes, we submitted nsh support patch set last year, but ovs 
> > community told me we have to push kernel part into Linux kernel tree, 
> > we're struggling to do this, but something blocked us from doing this.
> 
> It's quite difficult to get patches for a new protocol into the kernel.
> You have my sympathy.
> 
> > Recently, ovs did some changes in tunnel protocols which requires the 
> > packet decapsulated by a tunnel must be a Ethernet packet, but Linux 
> > kernel (net-next) tree accepted VxLAN-gpe patch set from Redhat guy 
> > (Jiri Benc) which requires the packet decapsulated by VxLAN-gpe port 
> > must be L3 packet but not L2 Ethernet packet, this blocked us from 
> > progressing better.
> > 
> > Simon Horman (Netronome guy) has posted a series of patches to remove 
> > the mandatory requirement from ovs in order that the packet from a 
> > tunnel can be any packet, but so far we didn't see they are merged.
> 
> These are slowly working their way through OVS review, but these also have a 
> prerequisite on kernel patches, so it's not easy to get them in either.
> 
> > I heard ovs community looks forward to getting nsh patches merged, it 
> > will be great if ovs guys can help progress this.
> 
> I do plan to do my part in review (but much of this is kernel review, which 
> I'm not really involved in anymore).
> 
> __
> 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] support of NSH in networking-SFC

[Elzur, Uri]

Pls note that VXLAN-gpe and VXLAN are using different UDP ports. Lots of 
consideration and discussion went into this working on the IETF draft and on 
ODL implementations. So I'm not sure I follow the backwards compatibility 
issues raised below

In any rate, the Ovs-Eth-NSH could be making parallel progress in the OvS 
community to the path outlined by Tim/Igor where networking-sfc using ODL and a 
backend can support full NSH now

Thx

Uri ("Oo-Ree")
C: 949-378-7568


-Original Message-
From: Cathy Zhang [mailto:cathy.h.zh...@huawei.com] 
Sent: Wednesday, June 1, 2016 11:54 AM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>; b...@ovn.org; Yang, Yi Y 
<yi.y.y...@intel.com>
Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

Looks like the work of removing the mandatory L3 requirement associated with 
decapsulated VxLAN-gpe packet also involves OVS kernel change, which is 
difficult. Furthermore, even this blocking issue is resolved and eventually OVS 
accepts the VLAN-gpe+NSH encapsulation, there is still another issue. 
Current Neutron only supports VXLAN, not VXLAN-gpe, and adopting VXLAN-gpe 
involves consideration of backward compatibility with existing VXLAN VTEP and 
VXLAN Gateway. 

An alternative and maybe easier/faster path could be to push a patch of " VxLAN 
+ Eth + NSH + Original frame" into OVS kernel. This is also IETF compliant 
encapsulation for SFC and does not have the L3 requirement issue and Neutron 
VXLAN-gpe support issue. 

We can probably take this discussion to the OVS mailing alias. 

Thanks,
Cathy

-Original Message-
From: Ben Pfaff [mailto:b...@ovn.org]
Sent: Tuesday, May 31, 2016 9:48 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

On Wed, Jun 01, 2016 at 12:08:23AM +, Yang, Yi Y wrote:
> Ben, yes, we submitted nsh support patch set last year, but ovs 
> community told me we have to push kernel part into Linux kernel tree, 
> we're struggling to do this, but something blocked us from doing this.

It's quite difficult to get patches for a new protocol into the kernel.
You have my sympathy.

> Recently, ovs did some changes in tunnel protocols which requires the 
> packet decapsulated by a tunnel must be a Ethernet packet, but Linux 
> kernel (net-next) tree accepted VxLAN-gpe patch set from Redhat guy 
> (Jiri Benc) which requires the packet decapsulated by VxLAN-gpe port 
> must be L3 packet but not L2 Ethernet packet, this blocked us from 
> progressing better.
> 
> Simon Horman (Netronome guy) has posted a series of patches to remove 
> the mandatory requirement from ovs in order that the packet from a 
> tunnel can be any packet, but so far we didn't see they are merged.

These are slowly working their way through OVS review, but these also have a 
prerequisite on kernel patches, so it's not easy to get them in either.

> I heard ovs community looks forward to getting nsh patches merged, it 
> will be great if ovs guys can help progress this.

I do plan to do my part in review (but much of this is kernel review, which I'm 
not really involved in anymore).

__
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] support of NSH in networking-SFC

[Elzur, Uri]

Hi Ben

Any guidance you can offer will be appreciated. The process has taken long time 
and precious cycles. How can we get to a coordinated Kernel and OvS approach to 
avoid the challenges and potentially misaligned advise we got (per Yi Yang's 
mail)?

Thx

Uri ("Oo-Ree")
C: 949-378-7568


-Original Message-
From: Ben Pfaff [mailto:b...@ovn.org] 
Sent: Tuesday, May 31, 2016 9:48 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

On Wed, Jun 01, 2016 at 12:08:23AM +, Yang, Yi Y wrote:
> Ben, yes, we submitted nsh support patch set last year, but ovs 
> community told me we have to push kernel part into Linux kernel tree, 
> we're struggling to do this, but something blocked us from doing this.

It's quite difficult to get patches for a new protocol into the kernel.
You have my sympathy.

> Recently, ovs did some changes in tunnel protocols which requires the 
> packet decapsulated by a tunnel must be a Ethernet packet, but Linux 
> kernel (net-next) tree accepted VxLAN-gpe patch set from Redhat guy 
> (Jiri Benc) which requires the packet decapsulated by VxLAN-gpe port 
> must be L3 packet but not L2 Ethernet packet, this blocked us from 
> progressing better.
> 
> Simon Horman (Netronome guy) has posted a series of patches to remove 
> the mandatory requirement from ovs in order that the packet from a 
> tunnel can be any packet, but so far we didn't see they are merged.

These are slowly working their way through OVS review, but these also have a 
prerequisite on kernel patches, so it's not easy to get them in either.

> I heard ovs community looks forward to getting nsh patches merged, it 
> will be great if ovs guys can help progress this.

I do plan to do my part in review (but much of this is kernel review, which I'm 
not really involved in anymore).

__
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] support of NSH in networking-SFC

[Cathy Zhang]

Looks like the work of removing the mandatory L3 requirement associated with 
decapsulated VxLAN-gpe packet also involves OVS kernel change, which is 
difficult. Furthermore, even this blocking issue is resolved and eventually OVS 
accepts the VLAN-gpe+NSH encapsulation, there is still another issue. 
Current Neutron only supports VXLAN, not VXLAN-gpe, and adopting VXLAN-gpe 
involves consideration of backward compatibility with existing VXLAN VTEP and 
VXLAN Gateway. 

An alternative and maybe easier/faster path could be to push a patch of " VxLAN 
+ Eth + NSH + Original frame" into OVS kernel. This is also IETF compliant 
encapsulation for SFC and does not have the L3 requirement issue and Neutron 
VXLAN-gpe support issue. 

We can probably take this discussion to the OVS mailing alias. 

Thanks,
Cathy

-Original Message-
From: Ben Pfaff [mailto:b...@ovn.org] 
Sent: Tuesday, May 31, 2016 9:48 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

On Wed, Jun 01, 2016 at 12:08:23AM +, Yang, Yi Y wrote:
> Ben, yes, we submitted nsh support patch set last year, but ovs 
> community told me we have to push kernel part into Linux kernel tree, 
> we're struggling to do this, but something blocked us from doing this.

It's quite difficult to get patches for a new protocol into the kernel.
You have my sympathy.

> Recently, ovs did some changes in tunnel protocols which requires the 
> packet decapsulated by a tunnel must be a Ethernet packet, but Linux 
> kernel (net-next) tree accepted VxLAN-gpe patch set from Redhat guy 
> (Jiri Benc) which requires the packet decapsulated by VxLAN-gpe port 
> must be L3 packet but not L2 Ethernet packet, this blocked us from 
> progressing better.
> 
> Simon Horman (Netronome guy) has posted a series of patches to remove 
> the mandatory requirement from ovs in order that the packet from a 
> tunnel can be any packet, but so far we didn't see they are merged.

These are slowly working their way through OVS review, but these also have a 
prerequisite on kernel patches, so it's not easy to get them in either.

> I heard ovs community looks forward to getting nsh patches merged, it 
> will be great if ovs guys can help progress this.

I do plan to do my part in review (but much of this is kernel review, which I'm 
not really involved in anymore).

__
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] support of NSH in networking-SFC

[Ben Pfaff]

On Wed, Jun 01, 2016 at 12:08:23AM +, Yang, Yi Y wrote:
> Ben, yes, we submitted nsh support patch set last year, but ovs
> community told me we have to push kernel part into Linux kernel tree,
> we're struggling to do this, but something blocked us from doing this.

It's quite difficult to get patches for a new protocol into the kernel.
You have my sympathy.

> Recently, ovs did some changes in tunnel protocols which requires the
> packet decapsulated by a tunnel must be a Ethernet packet, but Linux
> kernel (net-next) tree accepted VxLAN-gpe patch set from Redhat guy
> (Jiri Benc) which requires the packet decapsulated by VxLAN-gpe port
> must be L3 packet but not L2 Ethernet packet, this blocked us from
> progressing better.
> 
> Simon Horman (Netronome guy) has posted a series of patches to remove
> the mandatory requirement from ovs in order that the packet from a
> tunnel can be any packet, but so far we didn't see they are merged.

These are slowly working their way through OVS review, but these also
have a prerequisite on kernel patches, so it's not easy to get them in
either.

> I heard ovs community looks forward to getting nsh patches merged, it
> will be great if ovs guys can help progress this.

I do plan to do my part in review (but much of this is kernel review,
which I'm not really involved in anymore).

__
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] support of NSH in networking-SFC

[Yang, Yi Y]

Ben, yes, we submitted nsh support patch set last year, but ovs community told 
me we have to push kernel part into Linux kernel tree, we're struggling to do 
this, but something blocked us from doing this.

Recently, ovs did some changes in tunnel protocols which requires the packet 
decapsulated by a tunnel must be a Ethernet packet, but Linux kernel (net-next) 
tree accepted VxLAN-gpe patch set from Redhat guy (Jiri Benc) which requires 
the packet decapsulated by VxLAN-gpe port must be L3 packet but not L2 Ethernet 
packet, this blocked us from progressing better.

Simon Horman (Netronome guy) has posted a series of patches to remove the 
mandatory requirement from ovs in order that the packet from a tunnel can be 
any packet, but so far we didn't see they are merged.

I heard ovs community looks forward to getting nsh patches merged, it will be 
great if ovs guys can help progress this.

-Original Message-
From: Ben Pfaff [mailto:b...@ovn.org] 
Sent: Tuesday, May 31, 2016 10:38 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

On Mon, May 30, 2016 at 10:12:34PM -0400, Paul Carver wrote:
> I don't know the details of why OvS hasn't added NSH support so I 
> can't judge the validity of the concerns, but one way or another there 
> has to be a production-quality dataplane for networking-sfc to front-end.

It looks like the last time anyone submitted NSH patches to Open vSwitch was 
September 2015.  They got some reviews but no new version has been posted since.

Basically, we can't add NSH support if no one submits patches.

__
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] support of NSH in networking-SFC

[Tim Rozet]

Hey Paul,
ODL uses OVS as its dataplane (but is also not limited to just OVS), and ODL 
already supports IETF SFC today in the ODL SFC project.  My point was Neutron 
is no longer in scope of managing OVS, since it is managed by ODL.  I think 
your comments echo the 2 sides of this discussion - whether or not OVS is in 
scope of a protocol implementation in Neutron networking-sfc.  In my opinon it 
is if you consider OVS driver support, but it is not if you consider a 
different networking-sfc driver.

You can implement IETF NSH in the networking-sfc API/DB Model, without caring 
if it is actually supported in OVS (when using ODL as a driver) because all 
networking-sfc cares about should be if it's driver correctly supports SFC.  To 
that end, if you are using ODL as your SFC driver, then absolutely you should 
verify it is an IETF SFC compliant API/model.  However, outside of that scope, 
it is not networking-sfc's responsibility to care what ODL is using as it's 
dataplane backend or for that matter it's version of OVS.  It is now up to ODL 
to manage that for networking-sfc, and networking-sfc just needs to ensure it 
can talk to ODL.  

I think this is a pragmatic way to go, since networking-sfc doesn't yet support 
an ODL driver and we are in the process of adding one.  We could leave the 
networking-sfc OVS driver alone, add support for NSH to the networking-sfc 
plugin, and then only allow API calls that use NSH to work if ODL networking 
driver is the backend.  That way we allow for some experimental NSH support in 
networking-sfc without officially supporting it in the OVS driver until it is 
officially supported in OVS.

Tim Rozet
Red Hat SDN Team

- Original Message -
From: "Paul Carver" <pcar...@paulcarver.us>
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Sent: Monday, May 30, 2016 10:12:34 PM
Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

On 5/25/2016 13:24, Tim Rozet wrote:
> In my opinion, it is a better approach to break this down into plugin vs 
> driver support.  There should be no problem adding support into 
> networking-sfc plugin for NSH today.  The OVS driver however, depends on OVS 
> as the dataplane - which I can see a solid argument for only supporting an 
> official version with a non-NSH solution.  The plugin side should have no 
> dependency on OVS.  Therefore if we add NSH SFC support to an ODL driver in 
> networking-odl, and use that as our networking-sfc driver, the argument about 
> OVS goes away (since neutron/networking-sfc is totally unaware of the 
> dataplane at this point).  We would just need to ensure that API calls to 
> networking-sfc specifying NSH port pairs returned error if the enabled driver 
> was OVS (until official OVS with NSH support is released).
>

Does ODL have a dataplane? I thought it used OvS. Is the ODL project 
supporting its own fork of OvS that has NSH support or is ODL expecting 
that the user will patch OvS themself?

I don't know the details of why OvS hasn't added NSH support so I can't 
judge the validity of the concerns, but one way or another there has to 
be a production-quality dataplane for networking-sfc to front-end.

If ODL has forked OvS or in some other manner is supporting its own NSH 
capable dataplane then it's reasonable to consider that the ODL driver 
could be the first networking-sfc driver to support NSH. However, we 
still need to make sure that the API is an abstraction, not 
implementation specific.

But if ODL is not supporting its own NSH capable dataplane, instead 
expecting the user to run a patched OvS that doesn't have upstream 
acceptance then I think we would be building a rickety tower by piling 
networking-sfc on top of that unstable base.



__
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] support of NSH in networking-SFC

[Ben Pfaff]

On Mon, May 30, 2016 at 10:12:34PM -0400, Paul Carver wrote:
> I don't know the details of why OvS hasn't added NSH support so I can't
> judge the validity of the concerns, but one way or another there has to be a
> production-quality dataplane for networking-sfc to front-end.

It looks like the last time anyone submitted NSH patches to Open vSwitch
was September 2015.  They got some reviews but no new version has been
posted since.

Basically, we can't add NSH support if no one submits patches.

__
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] support of NSH in networking-SFC

[Duarte Cardoso, Igor]

"But if ODL is not supporting its own NSH capable dataplane, instead expecting 
the user to run a patched OvS that doesn't have upstream acceptance then I 
think we would be building a rickety tower by piling networking-sfc on top of 
that unstable base."

ODL requires a patched OvS too [1].

[1] 
https://wiki.opendaylight.org/view/Service_Function_Chaining:Main#Building_Open_vSwitch_with_VxLAN-GPE_and_NSH_support

Best regards,
Igor.

-Original Message-
From: Paul Carver [mailto:pcar...@paulcarver.us] 
Sent: Tuesday, May 31, 2016 3:13 AM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

On 5/25/2016 13:24, Tim Rozet wrote:
> In my opinion, it is a better approach to break this down into plugin vs 
> driver support.  There should be no problem adding support into 
> networking-sfc plugin for NSH today.  The OVS driver however, depends on OVS 
> as the dataplane - which I can see a solid argument for only supporting an 
> official version with a non-NSH solution.  The plugin side should have no 
> dependency on OVS.  Therefore if we add NSH SFC support to an ODL driver in 
> networking-odl, and use that as our networking-sfc driver, the argument about 
> OVS goes away (since neutron/networking-sfc is totally unaware of the 
> dataplane at this point).  We would just need to ensure that API calls to 
> networking-sfc specifying NSH port pairs returned error if the enabled driver 
> was OVS (until official OVS with NSH support is released).
>

Does ODL have a dataplane? I thought it used OvS. Is the ODL project supporting 
its own fork of OvS that has NSH support or is ODL expecting that the user will 
patch OvS themself?

I don't know the details of why OvS hasn't added NSH support so I can't judge 
the validity of the concerns, but one way or another there has to be a 
production-quality dataplane for networking-sfc to front-end.

If ODL has forked OvS or in some other manner is supporting its own NSH capable 
dataplane then it's reasonable to consider that the ODL driver could be the 
first networking-sfc driver to support NSH. However, we still need to make sure 
that the API is an abstraction, not implementation specific.

But if ODL is not supporting its own NSH capable dataplane, instead expecting 
the user to run a patched OvS that doesn't have upstream acceptance then I 
think we would be building a rickety tower by piling networking-sfc on top of 
that unstable base.



__
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] support of NSH in networking-SFC

[Paul Carver]

On 5/25/2016 13:24, Tim Rozet wrote:

In my opinion, it is a better approach to break this down into plugin vs driver 
support.  There should be no problem adding support into networking-sfc plugin 
for NSH today.  The OVS driver however, depends on OVS as the dataplane - which 
I can see a solid argument for only supporting an official version with a 
non-NSH solution.  The plugin side should have no dependency on OVS.  Therefore 
if we add NSH SFC support to an ODL driver in networking-odl, and use that as 
our networking-sfc driver, the argument about OVS goes away (since 
neutron/networking-sfc is totally unaware of the dataplane at this point).  We 
would just need to ensure that API calls to networking-sfc specifying NSH port 
pairs returned error if the enabled driver was OVS (until official OVS with NSH 
support is released).



Does ODL have a dataplane? I thought it used OvS. Is the ODL project 
supporting its own fork of OvS that has NSH support or is ODL expecting 
that the user will patch OvS themself?


I don't know the details of why OvS hasn't added NSH support so I can't 
judge the validity of the concerns, but one way or another there has to 
be a production-quality dataplane for networking-sfc to front-end.


If ODL has forked OvS or in some other manner is supporting its own NSH 
capable dataplane then it's reasonable to consider that the ODL driver 
could be the first networking-sfc driver to support NSH. However, we 
still need to make sure that the API is an abstraction, not 
implementation specific.


But if ODL is not supporting its own NSH capable dataplane, instead 
expecting the user to run a patched OvS that doesn't have upstream 
acceptance then I think we would be building a rickety tower by piling 
networking-sfc on top of that unstable base.




__
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] support of NSH in networking-SFC

[Duarte Cardoso, Igor]

ubject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

Hi Armando

I hear (hopefully right ☺) that we have an agreement that the SFC abstraction 
we want to follow (and that includes in my mind networking-sfc and OVN – pls 
feel free to correct me if wrong!) is use of NSH approach. This includes 
internal representation of the chain, support of metdata etc. it is not clear 
to me who is interested in supporting the wire protocol too, however given its 
IETF status, not sure why it would be considered “pollution”.

Igor Duarte has a proposal I believe he was working with the networking-sfc 
folks on

Thx

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

From: Armando M. [mailto:arma...@gmail.com]
Sent: Wednesday, May 25, 2016 11:06 AM
To: 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 24 May 2016 at 22:07, Elzur, Uri 
<uri.el...@intel.com<mailto:uri.el...@intel.com>> wrote:
Hi Armando

Pls see below [UE]

Thx

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

From: Armando M. [mailto:arma...@gmail.com<mailto:arma...@gmail.com>]
Sent: Friday, May 20, 2016 9:08 PM
To: 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 20 May 2016 at 17:37, 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)

A given abstraction is allowed so long as there is enough agreement that it is 
indeed technology agnostic. If the abstraction maps neatly to a given 
technology, the implementation may exist within the context of Neutron or 
elsewhere.
[UE] I think we have agreement SFC is a needed abstraction

Having said that I'd like to clarify a point: you seem to refer to the stadium 
as a golden standard. The stadium is nothing else but a list of software 
repositories that the Neutron team develops and maintain. Given the maturity of 
a specific repo, it may or may not implement an abstraction with integration 
code to non open technologies. This is left at discretion of the group of folks 
who are directly in control of the specific repo, though it has been the 
general direction to strongly encourage and promote openness throughout the 
entire stack that falls under the responsibility of the Neutron team and thus 
the stadium.

[UE] carefully read 
(https://review.openstack.org/#/c/312199/12/specs/newton/neutron-stadium.rst,unified)
 and hope I understand Stadium. All NSH patches that we’d like to support are 
OPEN. I’m still looking for the place where a restriction prevents 
networking-SFC form moving forward on NSH before all other external projects to 
OpenStack has completed their work. Pls see also reply to Tim Rozet

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….
I cannot comment for the experience and the conversations you've had so far as 
I have no context. All I know is that if you want to experiment with 
OpenDaylight and its NSH provider and want to use that as a Neutron backend you 
can. However, if that requires new abstractions, these new abstractions must be 
agreed by all interested parties, be technology agnostic, and allow for 
multiple implementation, an open one included. That's the nature of OpenStack.
[UE] thanks for this clarification! I think it means that now that we all agree 
SFC abstraction is needed and that NSH is an emerging standard and 
networking-sfc team agrees to support NSH – there should be no reason to wait. 
As Tim Rozet mentioned an ODL driver with explicit SFC suppo

Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

[Elzur, Uri]

Hi
The OVN point is not about its interaction w Neutron API it is about the 
criteria to use about plugin support for a new code on Neutron. OvS is planning 
to move to OVN but is still building the code AND it is the SINGLE plugin to 
support OVN.
Similarly ODL already has code for NSH so using that very same criteria it 
should be allowed to support NSH (with appropriate abstractions into a generic 
SFC API)

Thx

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

From: Armando M. [mailto:arma...@gmail.com]
Sent: Wednesday, May 25, 2016 1:50 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC



On 25 May 2016 at 12:29, Elzur, Uri 
<uri.el...@intel.com<mailto:uri.el...@intel.com>> wrote:
Armando

I’m asking for a clear answer “I think the position here is as follows: if a 
technology is not mainstream, i.e. readily available via distros and the 
various channels, it can only be integrated via an experimental path”

If we can allow for the EXPERIMENTAL path for NSH, then we can stand up the 
whole stack in EXPERIMENTAL mode and quickly move to mainstream when other 
pieces outside of Neutron fall in place.

As I said, you're free to experiment. The general directive is to allow these 
experimentations to take place and use them as a feedback tool to iterate on 
the abstractions. However the abstraction would only be considered community 
accepted if and only if there's enough evidence that there is established 
support from a broad variety of plugins (open source and non).


As to OVN – it has to be EXPERIMENTAL too. I guess, if I interpret your 
response correctly, that unlike their future intention for OVN,  OvS is not 
willing to signal interest in integrating NSH

We're mixing two things here: OVN is not experimenting with (Neutron) APIs (as 
it's adopting those as is), but it's experimenting with implementations. So I 
would not conflate OVN and NSH in the same discussion. I simply brought it up 
as another example (alongside DPDK) of how innovation can be fostered in open 
source communities.


Thx

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

From: Armando M. [mailto:arma...@gmail.com<mailto:arma...@gmail.com>]
Sent: Wednesday, May 25, 2016 9:33 AM
To: 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 24 May 2016 at 21:53, Elzur, Uri 
<uri.el...@intel.com<mailto:uri.el...@intel.com>> wrote:
Hi Tim

Sorry for the delay due to travel...

This note is very helpful!

We are in agreement that the team including the individuals cited below are 
supportive. We also agree that SFC belongs in the networking-SFC project (with 
proper API adjustment)

It seems networking-sfc still holds the position that without OvS accepting 
VXLAN-gpe and NSH patches they can't support NSH. I'm trying to get a clear 
read on where is this stated as requirement

I think the position here is as follows: if a technology is not mainstream, 
i.e. readily available via distros and the various channels, it can only be 
integrated via an experimental path. No-one is preventing anyone from posting 
patches and instructions to compile kernels and kernel modules, but ultimately 
as an OpenStack project that is suppose to produce commercial and production 
grade software, we should be very sensitive in investing time and energy in 
supporting a technology that may or may not have a viable path towards 
inclusion into mainstream (Linux and OVS in this instance).

One another clear example we had in the past was DPDK (that enabled fast path 
processing in Neutron with OVS) and connection tracking (that enabled security 
groups natively build on top of OVS). We, as a project have consistently 
avoided endorsing efforts until they mature and show a clear path forward.


Like you, we are closely following the progress of the patches and honestly I 
have hard time seeing OpenStack supporting NSH in production even by the end of 
2017. I think this amounts to slowing down the market...

I think we need to break the logjam.

We are not the ones (Neutron) you're supposed to break the logjam with. I think 
the stakeholders here go well beyond the Neutron team alone.


I've reviewed 
(https://review.openstack.org/#/c/312199/12/specs/newton/neutron-stadium.rst,unified)
 and found nowhere a guideline suggesting that before a backend has fully 
implemented and merged upstream a technology (i.e. another project outside of 
OepnStack!), OpenStack Neutron can't make any move. ODL is working >2 years to 
support NSH using patches, yet to be accepted into Linux Kernel (almost done) 
and OvS (preliminary) - as you stated. Otherwise we create a serialization, 
that gets worse and worse over time and with additional layers.

No one suggests the 

Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

[Kyle Mestery]

On Wed, May 25, 2016 at 3:55 PM, Armando M. <arma...@gmail.com> wrote:
>
>
> On 25 May 2016 at 13:31, Elzur, Uri <uri.el...@intel.com> wrote:
>>
>> Kyle
>>
>> Thx for your comment. I think these are orthogonal discussions. The heart
>> of this one, for me, and in the Neutron context, is plotting a road forward
>> on new technologies INDEPENDENT of external (even if related) open source
>> projects. I like Armando's direction.
>>
>> The best of my understanding (granted, limited) is that the OvS official
>> position is not supportive of gpe and NSH as long as the Linux Kernel
>> doesn't have them. So we are in a nice little spiral for >2 years, which is
>> really long time if we want to have a reasonable pace of new technology
>> adoption
>>
>
> It would be nice to understand what the concerns are and how to resolve them
> in order to try and find a path where things can be reconciled later on.
> Technology adoption will always be hindered by the potential risk of dealing
> with fork down the road.
>
Fundamentally, I think we just need to draw a hard line in the sand
that we won't be testing things in the gate which carry patches for
downstream components. Once these things land in the kernel and OVS,
they can easily be supported upstream. We've done this for OVS
features for years. Uri is bringing an argument to the wrong place,
IMHO.

>>
>> The IETF is already last call and open source support ???
>>
>> Thx
>>
>> Uri (“Oo-Ree”)
>> C: 949-378-7568
>>
>>
>> -Original Message-
>> From: Kyle Mestery [mailto:mest...@mestery.com]
>> Sent: Wednesday, May 25, 2016 1:00 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> <openstack-dev@lists.openstack.org>
>> Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC
>>
>> On Wed, May 25, 2016 at 2:29 PM, Elzur, Uri <uri.el...@intel.com> wrote:
>> > Armando
>> >
>> >
>> >
>> > I’m asking for a clear answer “I think the position here is as
>> > follows: if a technology is not mainstream, i.e. readily available via
>> > distros and the various channels, it can only be integrated via an
>> > experimental path”
>> >
>> >
>> >
>> > If we can allow for the EXPERIMENTAL path for NSH, then we can stand
>> > up the whole stack in EXPERIMENTAL mode and quickly move to mainstream
>> > when other pieces outside of Neutron fall in place.
>> >
>> >
>> >
>> > As to OVN – it has to be EXPERIMENTAL too. I guess, if I interpret
>> > your response correctly, that unlike their future intention for OVN,
>> > OvS is not willing to signal interest in integrating NSH
>> >
>> Would this be a better thing to discuss on the ovs-dev list [1] rather
>> than the openstack-dev list? I'm sure the OVS devs would be happy to
>> continue a discussion about the possibility of using VXLAN+NSH over GENEVE
>> there.
>>
>> [1] http://mail.openvswitch.org/mailman/listinfo/dev
>>
>> >
>> >
>> > Thx
>> >
>> >
>> >
>> > Uri (“Oo-Ree”)
>> >
>> > C: 949-378-7568
>> >
>> >
>> >
>> > From: Armando M. [mailto:arma...@gmail.com]
>> > Sent: Wednesday, May 25, 2016 9:33 AM
>> > To: OpenStack Development Mailing List (not for usage questions)
>> > <openstack-dev@lists.openstack.org>
>> >
>> > Subject: Re: [openstack-dev] [Neutron] support of NSH in
>> > networking-SFC
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > On 24 May 2016 at 21:53, Elzur, Uri <uri.el...@intel.com> wrote:
>> >
>> > Hi Tim
>> >
>> > Sorry for the delay due to travel...
>> >
>> > This note is very helpful!
>> >
>> > We are in agreement that the team including the individuals cited
>> > below are supportive. We also agree that SFC belongs in the
>> > networking-SFC project (with proper API adjustment)
>> >
>> > It seems networking-sfc still holds the position that without OvS
>> > accepting VXLAN-gpe and NSH patches they can't support NSH. I'm trying
>> > to get a clear read on where is this stated as requirement
>> >
>> >
>> >
>> > I think the position here is as follows: if a technology is not
>> > mainstream, i.e. readily available via distros and the various
>> > channels, it can only be integrated via an experimen

Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

[Armando M.]

On 25 May 2016 at 13:31, Elzur, Uri <uri.el...@intel.com> wrote:

> Kyle
>
> Thx for your comment. I think these are orthogonal discussions. The heart
> of this one, for me, and in the Neutron context, is plotting a road forward
> on new technologies INDEPENDENT of external (even if related) open source
> projects. I like Armando's direction.
>
> The best of my understanding (granted, limited) is that the OvS official
> position is not supportive of gpe and NSH as long as the Linux Kernel
> doesn't have them. So we are in a nice little spiral for >2 years, which is
> really long time if we want to have a reasonable pace of new technology
> adoption
>
>
It would be nice to understand what the concerns are and how to resolve
them in order to try and find a path where things can be reconciled later
on. Technology adoption will always be hindered by the potential risk of
dealing with fork down the road.


> The IETF is already last call and open source support ???
>
> Thx
>
> Uri (“Oo-Ree”)
> C: 949-378-7568
>
>
> -Original Message-
> From: Kyle Mestery [mailto:mest...@mestery.com]
> Sent: Wednesday, May 25, 2016 1:00 PM
> To: OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC
>
> On Wed, May 25, 2016 at 2:29 PM, Elzur, Uri <uri.el...@intel.com> wrote:
> > Armando
> >
> >
> >
> > I’m asking for a clear answer “I think the position here is as
> > follows: if a technology is not mainstream, i.e. readily available via
> > distros and the various channels, it can only be integrated via an
> experimental path”
> >
> >
> >
> > If we can allow for the EXPERIMENTAL path for NSH, then we can stand
> > up the whole stack in EXPERIMENTAL mode and quickly move to mainstream
> > when other pieces outside of Neutron fall in place.
> >
> >
> >
> > As to OVN – it has to be EXPERIMENTAL too. I guess, if I interpret
> > your response correctly, that unlike their future intention for OVN,
> > OvS is not willing to signal interest in integrating NSH
> >
> Would this be a better thing to discuss on the ovs-dev list [1] rather
> than the openstack-dev list? I'm sure the OVS devs would be happy to
> continue a discussion about the possibility of using VXLAN+NSH over GENEVE
> there.
>
> [1] http://mail.openvswitch.org/mailman/listinfo/dev
>
> >
> >
> > Thx
> >
> >
> >
> > Uri (“Oo-Ree”)
> >
> > C: 949-378-7568
> >
> >
> >
> > From: Armando M. [mailto:arma...@gmail.com]
> > Sent: Wednesday, May 25, 2016 9:33 AM
> > To: OpenStack Development Mailing List (not for usage questions)
> > <openstack-dev@lists.openstack.org>
> >
> > Subject: Re: [openstack-dev] [Neutron] support of NSH in
> > networking-SFC
> >
> >
> >
> >
> >
> >
> >
> > On 24 May 2016 at 21:53, Elzur, Uri <uri.el...@intel.com> wrote:
> >
> > Hi Tim
> >
> > Sorry for the delay due to travel...
> >
> > This note is very helpful!
> >
> > We are in agreement that the team including the individuals cited
> > below are supportive. We also agree that SFC belongs in the
> > networking-SFC project (with proper API adjustment)
> >
> > It seems networking-sfc still holds the position that without OvS
> > accepting VXLAN-gpe and NSH patches they can't support NSH. I'm trying
> > to get a clear read on where is this stated as requirement
> >
> >
> >
> > I think the position here is as follows: if a technology is not
> > mainstream, i.e. readily available via distros and the various
> > channels, it can only be integrated via an experimental path. No-one
> > is preventing anyone from posting patches and instructions to compile
> > kernels and kernel modules, but ultimately as an OpenStack project
> > that is suppose to produce commercial and production grade software,
> > we should be very sensitive in investing time and energy in supporting
> > a technology that may or may not have a viable path towards inclusion
> into mainstream (Linux and OVS in this instance).
> >
> >
> >
> > One another clear example we had in the past was DPDK (that enabled
> > fast path processing in Neutron with OVS) and connection tracking
> > (that enabled security groups natively build on top of OVS). We, as a
> > project have consistently avoided endorsing efforts until they mature
> > and show a clear path forward.
> >
> >
> >
> >

Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

[Armando M.]

On 25 May 2016 at 12:29, Elzur, Uri <uri.el...@intel.com> wrote:

> Armando
>
>
>
> I’m asking for a clear answer “I think the position here is as follows:
> if a technology is not mainstream, i.e. readily available via distros and
> the various channels, it can only be integrated via an experimental path”
>
>
>
> If we can allow for the EXPERIMENTAL path for NSH, then we can stand up
> the whole stack in EXPERIMENTAL mode and quickly move to mainstream when
> other pieces outside of Neutron fall in place.
>

As I said, you're free to experiment. The general directive is to allow
these experimentations to take place and use them as a feedback tool to
iterate on the abstractions. However the abstraction would only be
considered community accepted if and only if there's enough evidence that
there is established support from a broad variety of plugins (open source
and non).


>
>
> As to OVN – it has to be EXPERIMENTAL too. I guess, if I interpret your
> response correctly, that unlike their future intention for OVN,  OvS is not
> willing to signal interest in integrating NSH
>

We're mixing two things here: OVN is not experimenting with (Neutron) APIs
(as it's adopting those as is), but it's experimenting with
implementations. So I would not conflate OVN and NSH in the same
discussion. I simply brought it up as another example (alongside DPDK) of
how innovation can be fostered in open source communities.


>
> Thx
>
>
>
> Uri (“Oo-Ree”)
>
> C: 949-378-7568
>
>
>
> *From:* Armando M. [mailto:arma...@gmail.com]
> *Sent:* Wednesday, May 25, 2016 9:33 AM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [Neutron] support of NSH in networking-SFC
>
>
>
>
>
>
>
> On 24 May 2016 at 21:53, Elzur, Uri <uri.el...@intel.com> wrote:
>
> Hi Tim
>
> Sorry for the delay due to travel...
>
> This note is very helpful!
>
> We are in agreement that the team including the individuals cited below
> are supportive. We also agree that SFC belongs in the networking-SFC
> project (with proper API adjustment)
>
> It seems networking-sfc still holds the position that without OvS
> accepting VXLAN-gpe and NSH patches they can't support NSH. I'm trying to
> get a clear read on where is this stated as requirement
>
>
>
> I think the position here is as follows: if a technology is not
> mainstream, i.e. readily available via distros and the various channels, it
> can only be integrated via an experimental path. No-one is preventing
> anyone from posting patches and instructions to compile kernels and kernel
> modules, but ultimately as an OpenStack project that is suppose to produce
> commercial and production grade software, we should be very sensitive in
> investing time and energy in supporting a technology that may or may not
> have a viable path towards inclusion into mainstream (Linux and OVS in this
> instance).
>
>
>
> One another clear example we had in the past was DPDK (that enabled fast
> path processing in Neutron with OVS) and connection tracking (that enabled
> security groups natively build on top of OVS). We, as a project have
> consistently avoided endorsing efforts until they mature and show a clear
> path forward.
>
>
>
>
> Like you, we are closely following the progress of the patches and
> honestly I have hard time seeing OpenStack supporting NSH in production
> even by the end of 2017. I think this amounts to slowing down the market...
>
> I think we need to break the logjam.
>
>
>
> We are not the ones (Neutron) you're supposed to break the logjam with. I
> think the stakeholders here go well beyond the Neutron team alone.
>
>
>
>
> I've reviewed (
> https://review.openstack.org/#/c/312199/12/specs/newton/neutron-stadium.rst,unified)
> and found nowhere a guideline suggesting that before a backend has fully
> implemented and merged upstream a technology (i.e. another project outside
> of OepnStack!), OpenStack Neutron can't make any move. ODL is working >2
> years to support NSH using patches, yet to be accepted into Linux Kernel
> (almost done) and OvS (preliminary) - as you stated. Otherwise we create a
> serialization, that gets worse and worse over time and with additional
> layers.
>
> No one suggests the such code needs to be PRODUCTION, but we need a way to
> roll out EXPERIMENTAL functions and later merge them quickly when all
> layers are ready, this creates a nice parallelism and keeps a decent pace
> of rolling out new features broadly supported elsewhere.
>
>
>
> I agree with this last statement; this is for instance what is happening
> with OVN which,

Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

[Armando M.]

On 25 May 2016 at 10:24, Tim Rozet <tro...@redhat.com> wrote:

> In my opinion, it is a better approach to break this down into plugin vs
> driver support.  There should be no problem adding support into
> networking-sfc plugin for NSH today.  The OVS driver however, depends on
> OVS as the dataplane - which I can see a solid argument for only supporting
> an official version with a non-NSH solution.  The plugin side should have
> no dependency on OVS.  Therefore if we add NSH SFC support to an ODL driver
> in networking-odl, and use that as our networking-sfc driver, the argument
> about OVS goes away (since neutron/networking-sfc is totally unaware of the
> dataplane at this point).


I am afraid the argument does not go away is the crux of the matter is
exposing implementation aspects over the SFC API where such aspects  can
only be realized/understood by a single plugin.


> We would just need to ensure that API calls to networking-sfc specifying
> NSH port pairs returned error if the enabled driver was OVS (until official
> OVS with NSH support is released).
>
>
I am not 100% sure what you mean by specifying NSH port pairs over the API
but this to me seems to be in violation of the above mentioned abstraction
principle we're trying to abide. To date a plugin is allowed to bring its
own extensions, however that doesn't mean that those extensions can be
universally implemented and as such must be considered plugin specific.

Thoughts?


> Tim Rozet
> Red Hat SDN Team
>
> - Original Message -
> From: "Armando M." <arma...@gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Cc: "Tim Rozet" <tro...@redhat.com>
> Sent: Wednesday, May 25, 2016 12:33:16 PM
> Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC
>
> On 24 May 2016 at 21:53, Elzur, Uri <uri.el...@intel.com> wrote:
>
> > Hi Tim
> >
> > Sorry for the delay due to travel...
> >
> > This note is very helpful!
> >
> > We are in agreement that the team including the individuals cited below
> > are supportive. We also agree that SFC belongs in the networking-SFC
> > project (with proper API adjustment)
> >
> > It seems networking-sfc still holds the position that without OvS
> > accepting VXLAN-gpe and NSH patches they can't support NSH. I'm trying to
> > get a clear read on where is this stated as requirement
> >
>
> I think the position here is as follows: if a technology is not mainstream,
> i.e. readily available via distros and the various channels, it can only be
> integrated via an experimental path. No-one is preventing anyone from
> posting patches and instructions to compile kernels and kernel modules, but
> ultimately as an OpenStack project that is suppose to produce commercial
> and production grade software, we should be very sensitive in investing
> time and energy in supporting a technology that may or may not have a
> viable path towards inclusion into mainstream (Linux and OVS in this
> instance).
>
> One another clear example we had in the past was DPDK (that enabled fast
> path processing in Neutron with OVS) and connection tracking (that enabled
> security groups natively build on top of OVS). We, as a project have
> consistently avoided endorsing efforts until they mature and show a clear
> path forward.
>
>
> > Like you, we are closely following the progress of the patches and
> > honestly I have hard time seeing OpenStack supporting NSH in production
> > even by the end of 2017. I think this amounts to slowing down the
> market...
> >
> > I think we need to break the logjam.
> >
>
> We are not the ones (Neutron) you're supposed to break the logjam with. I
> think the stakeholders here go well beyond the Neutron team alone.
>
>
> >
> > I've reviewed (
> >
> https://review.openstack.org/#/c/312199/12/specs/newton/neutron-stadium.rst,unified
> )
> > and found nowhere a guideline suggesting that before a backend has fully
> > implemented and merged upstream a technology (i.e. another project
> outside
> > of OepnStack!), OpenStack Neutron can't make any move. ODL is working >2
> > years to support NSH using patches, yet to be accepted into Linux Kernel
> > (almost done) and OvS (preliminary) - as you stated. Otherwise we create
> a
> > serialization, that gets worse and worse over time and with additional
> > layers.
> >
> > No one suggests the such code needs to be PRODUCTION, but we need a way
> to
> > roll out EXPERIMENTAL functions and later merge them quickly when all
> > layers are ready, this creates a 

Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

[Kyle Mestery]

On Wed, May 25, 2016 at 2:29 PM, Elzur, Uri <uri.el...@intel.com> wrote:
> Armando
>
>
>
> I’m asking for a clear answer “I think the position here is as follows: if a
> technology is not mainstream, i.e. readily available via distros and the
> various channels, it can only be integrated via an experimental path”
>
>
>
> If we can allow for the EXPERIMENTAL path for NSH, then we can stand up the
> whole stack in EXPERIMENTAL mode and quickly move to mainstream when other
> pieces outside of Neutron fall in place.
>
>
>
> As to OVN – it has to be EXPERIMENTAL too. I guess, if I interpret your
> response correctly, that unlike their future intention for OVN,  OvS is not
> willing to signal interest in integrating NSH
>
Would this be a better thing to discuss on the ovs-dev list [1] rather
than the openstack-dev list? I'm sure the OVS devs would be happy to
continue a discussion about the possibility of using VXLAN+NSH over
GENEVE there.

[1] http://mail.openvswitch.org/mailman/listinfo/dev

>
>
> Thx
>
>
>
> Uri (“Oo-Ree”)
>
> C: 949-378-7568
>
>
>
> From: Armando M. [mailto:arma...@gmail.com]
> Sent: Wednesday, May 25, 2016 9:33 AM
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev@lists.openstack.org>
>
> Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC
>
>
>
>
>
>
>
> On 24 May 2016 at 21:53, Elzur, Uri <uri.el...@intel.com> wrote:
>
> Hi Tim
>
> Sorry for the delay due to travel...
>
> This note is very helpful!
>
> We are in agreement that the team including the individuals cited below are
> supportive. We also agree that SFC belongs in the networking-SFC project
> (with proper API adjustment)
>
> It seems networking-sfc still holds the position that without OvS accepting
> VXLAN-gpe and NSH patches they can't support NSH. I'm trying to get a clear
> read on where is this stated as requirement
>
>
>
> I think the position here is as follows: if a technology is not mainstream,
> i.e. readily available via distros and the various channels, it can only be
> integrated via an experimental path. No-one is preventing anyone from
> posting patches and instructions to compile kernels and kernel modules, but
> ultimately as an OpenStack project that is suppose to produce commercial and
> production grade software, we should be very sensitive in investing time and
> energy in supporting a technology that may or may not have a viable path
> towards inclusion into mainstream (Linux and OVS in this instance).
>
>
>
> One another clear example we had in the past was DPDK (that enabled fast
> path processing in Neutron with OVS) and connection tracking (that enabled
> security groups natively build on top of OVS). We, as a project have
> consistently avoided endorsing efforts until they mature and show a clear
> path forward.
>
>
>
>
> Like you, we are closely following the progress of the patches and honestly
> I have hard time seeing OpenStack supporting NSH in production even by the
> end of 2017. I think this amounts to slowing down the market...
>
> I think we need to break the logjam.
>
>
>
> We are not the ones (Neutron) you're supposed to break the logjam with. I
> think the stakeholders here go well beyond the Neutron team alone.
>
>
>
>
> I've reviewed
> (https://review.openstack.org/#/c/312199/12/specs/newton/neutron-stadium.rst,unified)
> and found nowhere a guideline suggesting that before a backend has fully
> implemented and merged upstream a technology (i.e. another project outside
> of OepnStack!), OpenStack Neutron can't make any move. ODL is working >2
> years to support NSH using patches, yet to be accepted into Linux Kernel
> (almost done) and OvS (preliminary) - as you stated. Otherwise we create a
> serialization, that gets worse and worse over time and with additional
> layers.
>
> No one suggests the such code needs to be PRODUCTION, but we need a way to
> roll out EXPERIMENTAL functions and later merge them quickly when all layers
> are ready, this creates a nice parallelism and keeps a decent pace of
> rolling out new features broadly supported elsewhere.
>
>
>
> I agree with this last statement; this is for instance what is happening
> with OVN which, in order to work with Neutron, needs patching and stay close
> to trunk etc. The technology is still maturing and the whole Neutron
> integration is in progress, but at least there's a clear signal that the it
> will eventually become mainstream. If it did not, I would bet that
> priorities would be focused elsewhere.
>
>
>
> You asked in a previous email whether Neutron wanted to kept it

Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

[Elzur, Uri]

Hi Armando

I hear (hopefully right ☺) that we have an agreement that the SFC abstraction 
we want to follow (and that includes in my mind networking-sfc and OVN – pls 
feel free to correct me if wrong!) is use of NSH approach. This includes 
internal representation of the chain, support of metdata etc. it is not clear 
to me who is interested in supporting the wire protocol too, however given its 
IETF status, not sure why it would be considered “pollution”.

Igor Duarte has a proposal I believe he was working with the networking-sfc 
folks on

Thx

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

From: Armando M. [mailto:arma...@gmail.com]
Sent: Wednesday, May 25, 2016 11:06 AM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC



On 24 May 2016 at 22:07, Elzur, Uri 
<uri.el...@intel.com<mailto:uri.el...@intel.com>> wrote:
Hi Armando

Pls see below [UE]

Thx

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

From: Armando M. [mailto:arma...@gmail.com<mailto:arma...@gmail.com>]
Sent: Friday, May 20, 2016 9:08 PM
To: 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 20 May 2016 at 17:37, 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)

A given abstraction is allowed so long as there is enough agreement that it is 
indeed technology agnostic. If the abstraction maps neatly to a given 
technology, the implementation may exist within the context of Neutron or 
elsewhere.
[UE] I think we have agreement SFC is a needed abstraction

Having said that I'd like to clarify a point: you seem to refer to the stadium 
as a golden standard. The stadium is nothing else but a list of software 
repositories that the Neutron team develops and maintain. Given the maturity of 
a specific repo, it may or may not implement an abstraction with integration 
code to non open technologies. This is left at discretion of the group of folks 
who are directly in control of the specific repo, though it has been the 
general direction to strongly encourage and promote openness throughout the 
entire stack that falls under the responsibility of the Neutron team and thus 
the stadium.

[UE] carefully read 
(https://review.openstack.org/#/c/312199/12/specs/newton/neutron-stadium.rst,unified)
 and hope I understand Stadium. All NSH patches that we’d like to support are 
OPEN. I’m still looking for the place where a restriction prevents 
networking-SFC form moving forward on NSH before all other external projects to 
OpenStack has completed their work. Pls see also reply to Tim Rozet

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….
I cannot comment for the experience and the conversations you've had so far as 
I have no context. All I know is that if you want to experiment with 
OpenDaylight and its NSH provider and want to use that as a Neutron backend you 
can. However, if that requires new abstractions, these new abstractions must be 
agreed by all interested parties, be technology agnostic, and allow for 
multiple implementation, an open one included. That's the nature of OpenStack.
[UE] thanks for this clarification! I think it means that now that we all agree 
SFC abstraction is needed and that NSH is an emerging standard and 
networking-sfc team agrees to support NSH – there should be no reason to wait. 
As Tim Rozet mentioned an ODL driver with explicit SFC support is WIP, so 
sounds like NSH  support in it should be a go!

So long the required support is not specific to NS

Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

[Elzur, Uri]

Tim

+1 for me (guess not surprising...)

Thx

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


-Original Message-
From: Tim Rozet [mailto:tro...@redhat.com] 
Sent: Wednesday, May 25, 2016 10:24 AM
To: Armando M. <arma...@gmail.com>; Elzur, Uri <uri.el...@intel.com>
Cc: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

In my opinion, it is a better approach to break this down into plugin vs driver 
support.  There should be no problem adding support into networking-sfc plugin 
for NSH today.  The OVS driver however, depends on OVS as the dataplane - which 
I can see a solid argument for only supporting an official version with a 
non-NSH solution.  The plugin side should have no dependency on OVS.  Therefore 
if we add NSH SFC support to an ODL driver in networking-odl, and use that as 
our networking-sfc driver, the argument about OVS goes away (since 
neutron/networking-sfc is totally unaware of the dataplane at this point).  We 
would just need to ensure that API calls to networking-sfc specifying NSH port 
pairs returned error if the enabled driver was OVS (until official OVS with NSH 
support is released).

Thoughts?

Tim Rozet
Red Hat SDN Team

- Original Message -
From: "Armando M." <arma...@gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Cc: "Tim Rozet" <tro...@redhat.com>
Sent: Wednesday, May 25, 2016 12:33:16 PM
Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

On 24 May 2016 at 21:53, Elzur, Uri <uri.el...@intel.com> wrote:

> Hi Tim
>
> Sorry for the delay due to travel...
>
> This note is very helpful!
>
> We are in agreement that the team including the individuals cited 
> below are supportive. We also agree that SFC belongs in the 
> networking-SFC project (with proper API adjustment)
>
> It seems networking-sfc still holds the position that without OvS 
> accepting VXLAN-gpe and NSH patches they can't support NSH. I'm trying 
> to get a clear read on where is this stated as requirement
>

I think the position here is as follows: if a technology is not mainstream, 
i.e. readily available via distros and the various channels, it can only be 
integrated via an experimental path. No-one is preventing anyone from posting 
patches and instructions to compile kernels and kernel modules, but ultimately 
as an OpenStack project that is suppose to produce commercial and production 
grade software, we should be very sensitive in investing time and energy in 
supporting a technology that may or may not have a viable path towards 
inclusion into mainstream (Linux and OVS in this instance).

One another clear example we had in the past was DPDK (that enabled fast path 
processing in Neutron with OVS) and connection tracking (that enabled security 
groups natively build on top of OVS). We, as a project have consistently 
avoided endorsing efforts until they mature and show a clear path forward.


> Like you, we are closely following the progress of the patches and 
> honestly I have hard time seeing OpenStack supporting NSH in 
> production even by the end of 2017. I think this amounts to slowing down the 
> market...
>
> I think we need to break the logjam.
>

We are not the ones (Neutron) you're supposed to break the logjam with. I think 
the stakeholders here go well beyond the Neutron team alone.


>
> I've reviewed (
> https://review.openstack.org/#/c/312199/12/specs/newton/neutron-stadiu
> m.rst,unified) and found nowhere a guideline suggesting that before a 
> backend has fully implemented and merged upstream a technology (i.e. 
> another project outside of OepnStack!), OpenStack Neutron can't make 
> any move. ODL is working >2 years to support NSH using patches, yet to 
> be accepted into Linux Kernel (almost done) and OvS (preliminary) - as 
> you stated. Otherwise we create a serialization, that gets worse and 
> worse over time and with additional layers.
>
> No one suggests the such code needs to be PRODUCTION, but we need a 
> way to roll out EXPERIMENTAL functions and later merge them quickly 
> when all layers are ready, this creates a nice parallelism and keeps a 
> decent pace of rolling out new features broadly supported elsewhere.
>

I agree with this last statement; this is for instance what is happening with 
OVN which, in order to work with Neutron, needs patching and stay close to 
trunk etc. The technology is still maturing and the whole Neutron integration 
is in progress, but at least there's a clear signal that the it will eventually 
become mainstream. If it did not, I would bet that priorities would be focused 
elsewhere.

You asked in a previous email whether Neutron wanted to kept 

Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

[Elzur, Uri]

Armando

I’m asking for a clear answer “I think the position here is as follows: if a 
technology is not mainstream, i.e. readily available via distros and the 
various channels, it can only be integrated via an experimental path”

If we can allow for the EXPERIMENTAL path for NSH, then we can stand up the 
whole stack in EXPERIMENTAL mode and quickly move to mainstream when other 
pieces outside of Neutron fall in place.

As to OVN – it has to be EXPERIMENTAL too. I guess, if I interpret your 
response correctly, that unlike their future intention for OVN,  OvS is not 
willing to signal interest in integrating NSH

Thx

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

From: Armando M. [mailto:arma...@gmail.com]
Sent: Wednesday, May 25, 2016 9:33 AM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC



On 24 May 2016 at 21:53, Elzur, Uri 
<uri.el...@intel.com<mailto:uri.el...@intel.com>> wrote:
Hi Tim

Sorry for the delay due to travel...

This note is very helpful!

We are in agreement that the team including the individuals cited below are 
supportive. We also agree that SFC belongs in the networking-SFC project (with 
proper API adjustment)

It seems networking-sfc still holds the position that without OvS accepting 
VXLAN-gpe and NSH patches they can't support NSH. I'm trying to get a clear 
read on where is this stated as requirement

I think the position here is as follows: if a technology is not mainstream, 
i.e. readily available via distros and the various channels, it can only be 
integrated via an experimental path. No-one is preventing anyone from posting 
patches and instructions to compile kernels and kernel modules, but ultimately 
as an OpenStack project that is suppose to produce commercial and production 
grade software, we should be very sensitive in investing time and energy in 
supporting a technology that may or may not have a viable path towards 
inclusion into mainstream (Linux and OVS in this instance).

One another clear example we had in the past was DPDK (that enabled fast path 
processing in Neutron with OVS) and connection tracking (that enabled security 
groups natively build on top of OVS). We, as a project have consistently 
avoided endorsing efforts until they mature and show a clear path forward.


Like you, we are closely following the progress of the patches and honestly I 
have hard time seeing OpenStack supporting NSH in production even by the end of 
2017. I think this amounts to slowing down the market...

I think we need to break the logjam.

We are not the ones (Neutron) you're supposed to break the logjam with. I think 
the stakeholders here go well beyond the Neutron team alone.


I've reviewed 
(https://review.openstack.org/#/c/312199/12/specs/newton/neutron-stadium.rst,unified)
 and found nowhere a guideline suggesting that before a backend has fully 
implemented and merged upstream a technology (i.e. another project outside of 
OepnStack!), OpenStack Neutron can't make any move. ODL is working >2 years to 
support NSH using patches, yet to be accepted into Linux Kernel (almost done) 
and OvS (preliminary) - as you stated. Otherwise we create a serialization, 
that gets worse and worse over time and with additional layers.

No one suggests the such code needs to be PRODUCTION, but we need a way to roll 
out EXPERIMENTAL functions and later merge them quickly when all layers are 
ready, this creates a nice parallelism and keeps a decent pace of rolling out 
new features broadly supported elsewhere.

I agree with this last statement; this is for instance what is happening with 
OVN which, in order to work with Neutron, needs patching and stay close to 
trunk etc. The technology is still maturing and the whole Neutron integration 
is in progress, but at least there's a clear signal that the it will eventually 
become mainstream. If it did not, I would bet that priorities would be focused 
elsewhere.

You asked in a previous email whether Neutron wanted to kept itself hostage of 
OVS. My answer to you is NO: we have many technology stack options we can rely 
on in order to realize abstractions so long as they are open, and have a viable 
future.


Thx

Uri (“Oo-Ree”)
C: 949-378-7568
-Original Message-
From: Tim Rozet [mailto:tro...@redhat.com<mailto:tro...@redhat.com>]
Sent: Friday, May 20, 2016 7:01 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>; 
Elzur, Uri <uri.el...@intel.com<mailto:uri.el...@intel.com>>
Cc: Cathy Zhang <cathy.h.zh...@huawei.com<mailto:cathy.h.zh...@huawei.com>>
Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

Hi Uri,
I originally wrote the Tacker->ODL SFC NSH piece and have been working with 
Tacker and networking-sfc team to brin

Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

[Armando M.]

On 24 May 2016 at 22:07, Elzur, Uri <uri.el...@intel.com> wrote:

> Hi Armando
>
>
>
> Pls see below [UE]
>
>
>
> Thx
>
>
>
> Uri (“Oo-Ree”)
>
> C: 949-378-7568
>
>
>
> *From:* Armando M. [mailto:arma...@gmail.com]
> *Sent:* Friday, May 20, 2016 9:08 PM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [Neutron] support of NSH in networking-SFC
>
>
>
>
>
>
>
> On 20 May 2016 at 17:37, Elzur, Uri <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)
>
>
>
> A given abstraction is allowed so long as there is enough agreement that
> it is indeed technology agnostic. If the abstraction maps neatly to a given
> technology, the implementation may exist within the context of Neutron or
> elsewhere.
>
> [UE] I think we have agreement SFC is a needed abstraction
>
>
>
> Having said that I'd like to clarify a point: you seem to refer to the
> stadium as a golden standard. The stadium is nothing else but a list of
> software repositories that the Neutron team develops and maintain. Given
> the maturity of a specific repo, it may or may not implement an abstraction
> with integration code to non open technologies. This is left at discretion
> of the group of folks who are directly in control of the specific repo,
> though it has been the general direction to strongly encourage and promote
> openness throughout the entire stack that falls under the responsibility of
> the Neutron team and thus the stadium.
>
>
>
> [UE] carefully read (
> https://review.openstack.org/#/c/312199/12/specs/newton/neutron-stadium.rst,unified)
> and hope I understand Stadium. All NSH patches that we’d like to support
> are OPEN. I’m still looking for the place where a restriction prevents
> networking-SFC form moving forward on NSH before all other external
> projects to OpenStack has completed their work. Pls see also reply to Tim
> Rozet
>
>
>
> 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….
>
> I cannot comment for the experience and the conversations you've had so
> far as I have no context. All I know is that if you want to experiment with
> OpenDaylight and its NSH provider and want to use that as a Neutron backend
> you can. However, if that requires new abstractions, these new abstractions
> must be agreed by all interested parties, be technology agnostic, and allow
> for multiple implementation, an open one included. That's the nature of
> OpenStack.
>
> [UE] thanks for this clarification! I think it means that now that we all
> agree SFC abstraction is needed and that NSH is an emerging standard and
> networking-sfc team agrees to support NSH – there should be no reason to
> wait. As Tim Rozet mentioned an ODL driver with explicit SFC support is
> WIP, so sounds like NSH  support in it should be a go!
>

So long the required support is not specific to NSH and the API is not
polluted by implementation details specific to NSH.

> · 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 N

Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

[Tim Rozet]

In my opinion, it is a better approach to break this down into plugin vs driver 
support.  There should be no problem adding support into networking-sfc plugin 
for NSH today.  The OVS driver however, depends on OVS as the dataplane - which 
I can see a solid argument for only supporting an official version with a 
non-NSH solution.  The plugin side should have no dependency on OVS.  Therefore 
if we add NSH SFC support to an ODL driver in networking-odl, and use that as 
our networking-sfc driver, the argument about OVS goes away (since 
neutron/networking-sfc is totally unaware of the dataplane at this point).  We 
would just need to ensure that API calls to networking-sfc specifying NSH port 
pairs returned error if the enabled driver was OVS (until official OVS with NSH 
support is released).

Thoughts?

Tim Rozet
Red Hat SDN Team

- Original Message -
From: "Armando M." <arma...@gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Cc: "Tim Rozet" <tro...@redhat.com>
Sent: Wednesday, May 25, 2016 12:33:16 PM
Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

On 24 May 2016 at 21:53, Elzur, Uri <uri.el...@intel.com> wrote:

> Hi Tim
>
> Sorry for the delay due to travel...
>
> This note is very helpful!
>
> We are in agreement that the team including the individuals cited below
> are supportive. We also agree that SFC belongs in the networking-SFC
> project (with proper API adjustment)
>
> It seems networking-sfc still holds the position that without OvS
> accepting VXLAN-gpe and NSH patches they can't support NSH. I'm trying to
> get a clear read on where is this stated as requirement
>

I think the position here is as follows: if a technology is not mainstream,
i.e. readily available via distros and the various channels, it can only be
integrated via an experimental path. No-one is preventing anyone from
posting patches and instructions to compile kernels and kernel modules, but
ultimately as an OpenStack project that is suppose to produce commercial
and production grade software, we should be very sensitive in investing
time and energy in supporting a technology that may or may not have a
viable path towards inclusion into mainstream (Linux and OVS in this
instance).

One another clear example we had in the past was DPDK (that enabled fast
path processing in Neutron with OVS) and connection tracking (that enabled
security groups natively build on top of OVS). We, as a project have
consistently avoided endorsing efforts until they mature and show a clear
path forward.


> Like you, we are closely following the progress of the patches and
> honestly I have hard time seeing OpenStack supporting NSH in production
> even by the end of 2017. I think this amounts to slowing down the market...
>
> I think we need to break the logjam.
>

We are not the ones (Neutron) you're supposed to break the logjam with. I
think the stakeholders here go well beyond the Neutron team alone.


>
> I've reviewed (
> https://review.openstack.org/#/c/312199/12/specs/newton/neutron-stadium.rst,unified)
> and found nowhere a guideline suggesting that before a backend has fully
> implemented and merged upstream a technology (i.e. another project outside
> of OepnStack!), OpenStack Neutron can't make any move. ODL is working >2
> years to support NSH using patches, yet to be accepted into Linux Kernel
> (almost done) and OvS (preliminary) - as you stated. Otherwise we create a
> serialization, that gets worse and worse over time and with additional
> layers.
>
> No one suggests the such code needs to be PRODUCTION, but we need a way to
> roll out EXPERIMENTAL functions and later merge them quickly when all
> layers are ready, this creates a nice parallelism and keeps a decent pace
> of rolling out new features broadly supported elsewhere.
>

I agree with this last statement; this is for instance what is happening
with OVN which, in order to work with Neutron, needs patching and stay
close to trunk etc. The technology is still maturing and the whole Neutron
integration is in progress, but at least there's a clear signal that the it
will eventually become mainstream. If it did not, I would bet that
priorities would be focused elsewhere.

You asked in a previous email whether Neutron wanted to kept itself hostage
of OVS. My answer to you is NO: we have many technology stack options we
can rely on in order to realize abstractions so long as they are open, and
have a viable future.


>
> Thx
>
> Uri (“Oo-Ree”)
> C: 949-378-7568
>
> -Original Message-
> From: Tim Rozet [mailto:tro...@redhat.com]
> Sent: Friday, May 20, 2016 7:01 PM
> To: OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>; 

Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

[Armando M.]

On 24 May 2016 at 21:53, Elzur, Uri <uri.el...@intel.com> wrote:

> Hi Tim
>
> Sorry for the delay due to travel...
>
> This note is very helpful!
>
> We are in agreement that the team including the individuals cited below
> are supportive. We also agree that SFC belongs in the networking-SFC
> project (with proper API adjustment)
>
> It seems networking-sfc still holds the position that without OvS
> accepting VXLAN-gpe and NSH patches they can't support NSH. I'm trying to
> get a clear read on where is this stated as requirement
>

I think the position here is as follows: if a technology is not mainstream,
i.e. readily available via distros and the various channels, it can only be
integrated via an experimental path. No-one is preventing anyone from
posting patches and instructions to compile kernels and kernel modules, but
ultimately as an OpenStack project that is suppose to produce commercial
and production grade software, we should be very sensitive in investing
time and energy in supporting a technology that may or may not have a
viable path towards inclusion into mainstream (Linux and OVS in this
instance).

One another clear example we had in the past was DPDK (that enabled fast
path processing in Neutron with OVS) and connection tracking (that enabled
security groups natively build on top of OVS). We, as a project have
consistently avoided endorsing efforts until they mature and show a clear
path forward.


> Like you, we are closely following the progress of the patches and
> honestly I have hard time seeing OpenStack supporting NSH in production
> even by the end of 2017. I think this amounts to slowing down the market...
>
> I think we need to break the logjam.
>

We are not the ones (Neutron) you're supposed to break the logjam with. I
think the stakeholders here go well beyond the Neutron team alone.


>
> I've reviewed (
> https://review.openstack.org/#/c/312199/12/specs/newton/neutron-stadium.rst,unified)
> and found nowhere a guideline suggesting that before a backend has fully
> implemented and merged upstream a technology (i.e. another project outside
> of OepnStack!), OpenStack Neutron can't make any move. ODL is working >2
> years to support NSH using patches, yet to be accepted into Linux Kernel
> (almost done) and OvS (preliminary) - as you stated. Otherwise we create a
> serialization, that gets worse and worse over time and with additional
> layers.
>
> No one suggests the such code needs to be PRODUCTION, but we need a way to
> roll out EXPERIMENTAL functions and later merge them quickly when all
> layers are ready, this creates a nice parallelism and keeps a decent pace
> of rolling out new features broadly supported elsewhere.
>

I agree with this last statement; this is for instance what is happening
with OVN which, in order to work with Neutron, needs patching and stay
close to trunk etc. The technology is still maturing and the whole Neutron
integration is in progress, but at least there's a clear signal that the it
will eventually become mainstream. If it did not, I would bet that
priorities would be focused elsewhere.

You asked in a previous email whether Neutron wanted to kept itself hostage
of OVS. My answer to you is NO: we have many technology stack options we
can rely on in order to realize abstractions so long as they are open, and
have a viable future.


>
> Thx
>
> Uri (“Oo-Ree”)
> C: 949-378-7568
>
> -Original Message-
> From: Tim Rozet [mailto:tro...@redhat.com]
> Sent: Friday, May 20, 2016 7:01 PM
> To: OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>; Elzur, Uri <uri.el...@intel.com>
> Cc: Cathy Zhang <cathy.h.zh...@huawei.com>
> Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC
>
> Hi Uri,
> I originally wrote the Tacker->ODL SFC NSH piece and have been working
> with Tacker and networking-sfc team to bring it upstream into OpenStack.
> Cathy, Stephen, Louis and the rest of the networking-sfc team have been
> very receptive to changes specific to NSH around their current API and DB
> model.  The proper place for SFC to live in OpenStack is networking-sfc,
> while Tacker can do its orchestration job by rendering ETSI MANO TOSCA
> input like VNF Descriptors and VNF Forwarding Graph Descriptors.
>
> We currently have a spec in netwoking-odl to migrate my original driver
> for ODL to do IETF NSH.  That driver will be supported in networking-sfc,
> along with some changes to networking-sfc to account for NSH awareness and
> encap type (like VXLAN+GPE or Ethernet).  The OVS work to support NSH is
> coming along and patches are under review.  Yi Yang has built a private OVS
> version with these changes and we can use that for now to test with.
>
> I think it

Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

[Elzur, Uri]

Hi Armando

Pls see below [UE]

Thx

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

From: Armando M. [mailto:arma...@gmail.com]
Sent: Friday, May 20, 2016 9:08 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC



On 20 May 2016 at 17:37, 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)

A given abstraction is allowed so long as there is enough agreement that it is 
indeed technology agnostic. If the abstraction maps neatly to a given 
technology, the implementation may exist within the context of Neutron or 
elsewhere.
[UE] I think we have agreement SFC is a needed abstraction

Having said that I'd like to clarify a point: you seem to refer to the stadium 
as a golden standard. The stadium is nothing else but a list of software 
repositories that the Neutron team develops and maintain. Given the maturity of 
a specific repo, it may or may not implement an abstraction with integration 
code to non open technologies. This is left at discretion of the group of folks 
who are directly in control of the specific repo, though it has been the 
general direction to strongly encourage and promote openness throughout the 
entire stack that falls under the responsibility of the Neutron team and thus 
the stadium.

[UE] carefully read 
(https://review.openstack.org/#/c/312199/12/specs/newton/neutron-stadium.rst,unified)
 and hope I understand Stadium. All NSH patches that we’d like to support are 
OPEN. I’m still looking for the place where a restriction prevents 
networking-SFC form moving forward on NSH before all other external projects to 
OpenStack has completed their work. Pls see also reply to Tim Rozet

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….
I cannot comment for the experience and the conversations you've had so far as 
I have no context. All I know is that if you want to experiment with 
OpenDaylight and its NSH provider and want to use that as a Neutron backend you 
can. However, if that requires new abstractions, these new abstractions must be 
agreed by all interested parties, be technology agnostic, and allow for 
multiple implementation, an open one included. That's the nature of OpenStack.
[UE] thanks for this clarification! I think it means that now that we all agree 
SFC abstraction is needed and that NSH is an emerging standard and 
networking-sfc team agrees to support NSH – there should be no reason to wait. 
As Tim Rozet mentioned an ODL driver with explicit SFC support is WIP, so 
sounds like NSH  support in it should be a go!

• 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…
I personally I see no catch-22 if you operate under the premises I stated 
above. If Neutron allowed to experiment with *any* mechanism without taking 
into consideration the importance of abstractions and community consensus, we 
as a community have failed, especially in relation to the aspect of 
interoperability.
[UE] but as stated above and on the ml, in this case where we have agreement on 
the specific SFC abstraction, are we in agreement that we can move without 
being held back by other projects

Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

[Elzur, Uri]

Hi Tim

Sorry for the delay due to travel...

This note is very helpful! 

We are in agreement that the team including the individuals cited below are 
supportive. We also agree that SFC belongs in the networking-SFC project (with 
proper API adjustment)

It seems networking-sfc still holds the position that without OvS accepting 
VXLAN-gpe and NSH patches they can't support NSH. I'm trying to get a clear 
read on where is this stated as requirement

Like you, we are closely following the progress of the patches and honestly I 
have hard time seeing OpenStack supporting NSH in production even by the end of 
2017. I think this amounts to slowing down the market...

I think we need to break the logjam. 

I've reviewed 
(https://review.openstack.org/#/c/312199/12/specs/newton/neutron-stadium.rst,unified)
 and found nowhere a guideline suggesting that before a backend has fully 
implemented and merged upstream a technology (i.e. another project outside of 
OepnStack!), OpenStack Neutron can't make any move. ODL is working >2 years to 
support NSH using patches, yet to be accepted into Linux Kernel (almost done) 
and OvS (preliminary) - as you stated. Otherwise we create a serialization, 
that gets worse and worse over time and with additional layers. 

No one suggests the such code needs to be PRODUCTION, but we need a way to roll 
out EXPERIMENTAL functions and later merge them quickly when all layers are 
ready, this creates a nice parallelism and keeps a decent pace of rolling out 
new features broadly supported elsewhere.

Thx

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

-Original Message-
From: Tim Rozet [mailto:tro...@redhat.com] 
Sent: Friday, May 20, 2016 7:01 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>; Elzur, Uri <uri.el...@intel.com>
Cc: Cathy Zhang <cathy.h.zh...@huawei.com>
Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

Hi Uri,
I originally wrote the Tacker->ODL SFC NSH piece and have been working with 
Tacker and networking-sfc team to bring it upstream into OpenStack.  Cathy, 
Stephen, Louis and the rest of the networking-sfc team have been very receptive 
to changes specific to NSH around their current API and DB model.  The proper 
place for SFC to live in OpenStack is networking-sfc, while Tacker can do its 
orchestration job by rendering ETSI MANO TOSCA input like VNF Descriptors and 
VNF Forwarding Graph Descriptors.

We currently have a spec in netwoking-odl to migrate my original driver for ODL 
to do IETF NSH.  That driver will be supported in networking-sfc, along with 
some changes to networking-sfc to account for NSH awareness and encap type 
(like VXLAN+GPE or Ethernet).  The OVS work to support NSH is coming along and 
patches are under review.  Yi Yang has built a private OVS version with these 
changes and we can use that for now to test with.

I think it is all coming together and will take a couple more months before all 
of the pieces (Tacker, networking-sfc, networking-odl, ovs) are in place.  I 
don't think networking-sfc is holding up any progress.

Thanks,

Tim Rozet
Red Hat SDN Team

- Original Message -
From: "Uri Elzur" <uri.el...@intel.com>
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>, "Cathy Zhang" <cathy.h.zh...@huawei.com>
Sent: Friday, May 20, 2016 8:37:26 PM
Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC



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 

Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

[Armando M.]

On 20 May 2016 at 17:37, Elzur, Uri <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)
>

A given abstraction is allowed so long as there is enough agreement that it
is indeed technology agnostic. If the abstraction maps neatly to a given
technology, the implementation may exist within the context of Neutron or
elsewhere.

Having said that I'd like to clarify a point: you seem to refer to the
stadium as a golden standard. The stadium is nothing else but a list of
software repositories that the Neutron team develops and maintain. Given
the maturity of a specific repo, it may or may not implement an abstraction
with integration code to non open technologies. This is left at discretion
of the group of folks who are directly in control of the specific repo,
though it has been the general direction to strongly encourage and promote
openness throughout the entire stack that falls under the responsibility of
the Neutron team and thus the stadium.


>
> 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….
>
I cannot comment for the experience and the conversations you've had so far
as I have no context. All I know is that if you want to experiment with
OpenDaylight and its NSH provider and want to use that as a Neutron backend
you can. However, if that requires new abstractions, these new abstractions
must be agreed by all interested parties, be technology agnostic, and allow
for multiple implementation, an open one included. That's the nature of
OpenStack.

> · 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*…
>
I personally I see no catch-22 if you operate under the premises I stated
above. If Neutron allowed to experiment with *any* mechanism without taking
into consideration the importance of abstractions and community consensus,
we as a community have failed, especially in relation to the aspect of
interoperability.

>
>
> SOOO, is the bottom line that we agree that supporting NSH explicitly in
> networking-sfc can be added now?
>

I don't know what you mean by supporting NSH explicitly in networking-sfc.
Can you be more specific? Do you intend via OpenDaylight? What would be the
NSH provider?


>
>
>
>
> 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>
> *Cc:* OpenStack Development Mailing List (not for usage questions) <
> 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> 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 

Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

[Tim Rozet]

Hi Uri,
I originally wrote the Tacker->ODL SFC NSH piece and have been working with 
Tacker and networking-sfc team to bring it upstream into OpenStack.  Cathy, 
Stephen, Louis and the rest of the networking-sfc team have been very receptive 
to changes specific to NSH around their current API and DB model.  The proper 
place for SFC to live in OpenStack is networking-sfc, while Tacker can do its 
orchestration job by rendering ETSI MANO TOSCA input like VNF Descriptors and 
VNF Forwarding Graph Descriptors.

We currently have a spec in netwoking-odl to migrate my original driver for ODL 
to do IETF NSH.  That driver will be supported in networking-sfc, along with 
some changes to networking-sfc to account for NSH awareness and encap type 
(like VXLAN+GPE or Ethernet).  The OVS work to support NSH is coming along and 
patches are under review.  Yi Yang has built a private OVS version with these 
changes and we can use that for now to test with.

I think it is all coming together and will take a couple more months before all 
of the pieces (Tacker, networking-sfc, networking-odl, ovs) are in place.  I 
don't think networking-sfc is holding up any progress.

Thanks,

Tim Rozet
Red Hat SDN Team

- Original Message -
From: "Uri Elzur" <uri.el...@intel.com>
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>, "Cathy Zhang" <cathy.h.zh...@huawei.com>
Sent: Friday, May 20, 2016 8:37:26 PM
Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC



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> 
Cc: OpenStack Development Mailing List (not for usage questions) 
<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 > 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, U

Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

[Elzur, Uri]

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>
Cc: OpenStack Development Mailing List (not for usage questions) 
<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


__
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] support of NSH in networking-SFC

[Elzur, Uri]

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.zh...@huawei.com] 
Sent: Monday, May 16, 2016 1:10 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@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: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
__
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] support of NSH in networking-SFC

[Cathy Zhang]

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

Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

[Paul Carver]

On Fri, 13 May 2016 17:13:59 -0700
"Armando M."  wrote:

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

Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

[Armando M.]

On 13 May 2016 at 16:01, Cathy Zhang <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]
> *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
>
>
>
__
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] support of NSH in networking-SFC

[Armando M.]

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.


> And if so does that apply to stadium projects
>

We have actually been trying to better define what stadium means as it may
lead to misconceptions. But in general no it doesn't.


> 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
>
>
>
> At these point, standard organizations are almost done and open source
> can’t adopt a feature with high demand….
>

Not sure I understand this last point, if you can rephrase I'd be happy to
address any other concern you may have.


>
>

>
> Thx
>
>
>
> Uri (“Oo-Ree”)
>
> C: 949-378-7568
>
>
>
> *From:* Cathy Zhang [mailto:cathy.h.zh...@huawei.com]
> *Sent:* Friday, May 13, 2016 4:02 PM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>; Armando M <arma...@gmail.com>
> *Subject:* Re: [openstack-dev] [Neutron] support of NSH in networking-SFC
>
>
>
> 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.
>
>
>
> 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 <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
>
>
>
__
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] support of NSH in networking-SFC

[Armando M.]

On 13 May 2016 at 15:02, Elzur, Uri  wrote:

> 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.
>

Not sure how you got this information but this is not accurate.


> Is this an official position of Neutron that OvS is the gold standard to
> support any new feature?
>

The position Neutron has typically taken over the years is that as
community we work within the constraints and the dynamics of the various
open source projects and solutions that are required for building
networking abstractions, taking especially into consideration when and if
certain technologies are mainstream.

To your specific reference to NSH and SFC, we strive to define abstractions
that are not particularly tied to a specific technology choice; that's step
1 in providing technology agnostic networking solutions; step 2 is to
experiment with the above mentioned abstractions by building open source
solutions that are readily available. When there's a lag, we wait (look at
how long it took us to have either DPDK of OVS connection tracking enabled
in Neutron for instance).

Having said that, that does not stop anyone to use and provide feedback to
those abstractions agreed at community level and build on top of the most
disparate stacks that are out there.

So what exactly is that is concerning you? I am confused.


>
>
> 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
>
>
>
__
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] support of NSH in networking-SFC

[Elzur, Uri]

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
And if so does that apply to stadium projects
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

At these point, standard organizations are almost done and open source can’t 
adopt a feature with high demand….

Thx

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

From: Cathy Zhang [mailto:cathy.h.zh...@huawei.com]
Sent: Friday, May 13, 2016 4:02 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>; Armando M <arma...@gmail.com>
Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

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.

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]
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

__
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] support of NSH in networking-SFC

[Cathy Zhang]

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.

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]
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

__
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] support of NSH in networking-SFC

[Elzur, Uri]

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

__
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