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 ; OpenStack Development Mailing List
(not for usage questions) ; b...@ovn.org
Cc: Jesse Gross ; Jiri Benc
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)
; b...@ovn.org; Yang, Yi Y
Cc: Cathy Zhang
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
Re: [openstack-dev] [Neutron] support of NSH in networking-SFC
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)
; b...@ovn.org; Yang, Yi Y
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] support of NSH in networking-SFC
Cathy
So we are ok moving forward on networking-sfc?
What is the next step from your pov?
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:58 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] support of NSH in networking-SFC
Igor and Tim,
+1 on your suggestion.
Thanks,
Cathy
-Original Message-
From: Duarte Cardoso, Igor [mailto:igor.duarte.card...@intel.com]
Sent: Tuesday, May 31, 2016 8:48 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] support of NSH in networking-SFC
Hi Tim,
+1
Focus on the plugin and API while improving the n-sfc<->ODL interaction to
match that.
In parallel, early (non-merged) support in OVS driver itself could be
attempted, based on the unofficial April 2016's NSH patches for OVS [1]. After
official supports gets merged, it would be less troublesome to adapt since the
big hurdles of mapping the abstraction to OVS would have been mostly overcome.
[1]
https://github.com/yyang13/ovs_nsh_patches/tree/98e1d3d6b1ed49d902edaede11820853b0ad5037
Best regards,
Igor.
-Original Message-
From: Tim Rozet [mailto:tro...@redhat.com]
Sent: Tuesday, May 31, 2016 4:21 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC
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"
To: "OpenStack Development Mailing List (not for usage questions)"
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
Re: [openstack-dev] support of NSH in networking-SFC
+1 from me too
How do we close on this thread? Is anyone on the ml, NOT cool with this
approach as outlined by Tim below?
Thx
Uri ("Oo-Ree")
C: 949-378-7568
-Original Message-
From: Duarte Cardoso, Igor [mailto:igor.duarte.card...@intel.com]
Sent: Tuesday, May 31, 2016 8:48 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] support of NSH in networking-SFC
Hi Tim,
+1
Focus on the plugin and API while improving the n-sfc<->ODL interaction to
match that.
In parallel, early (non-merged) support in OVS driver itself could be
attempted, based on the unofficial April 2016's NSH patches for OVS [1]. After
official supports gets merged, it would be less troublesome to adapt since the
big hurdles of mapping the abstraction to OVS would have been mostly overcome.
[1]
https://github.com/yyang13/ovs_nsh_patches/tree/98e1d3d6b1ed49d902edaede11820853b0ad5037
Best regards,
Igor.
-Original Message-
From: Tim Rozet [mailto:tro...@redhat.com]
Sent: Tuesday, May 31, 2016 4:21 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC
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"
To: "OpenStack Development Mailing List (not for usage questions)"
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
Re: [openstack-dev] [Neutron] support of NSH in networking-SFC
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)
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
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
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
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
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
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
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][TC] support of NSH in networking-SFC
ODL has support for sfc w NSH. Why would ONOS count as backend and ODL not? Uri Sent from my iPhone On May 21, 2016, at 11:26 AM, Henry Fourie <louis.fou...@huawei.com<mailto:louis.fou...@huawei.com>> wrote: Doug, Networking-sfc API currently has two reference SFC implementations that are open source: the OVS driver and the ONOS driver. Work is also in progress for an ODL SFC driver and an OVN driver. -Louis From: Doug Wiegley [mailto:doug...@parksidesoftware.com] Sent: Friday, May 20, 2016 5:48 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][TC] support of NSH in networking-SFC In a nutshell, you’ve got it, you can’t add an API without a reference implementation, including data-plane, which has to be open-source (though does not have to itself be openstack.) o Especially as Stadium, can we let Neutron to lead the industry, given broad enough community interest? You can do anything you want outside the stadium, which is where experimental/incubation is meant to happen. Inside the stadium means, “official openstack project”, which means it has an open-source implementation. If all backends are closed-source, it’s not open as openstack defines it: https://governance.openstack.org/reference/opens.html There isn’t any wiggle room there. This isn’t a neutron argument; feel free to take it up with the TC. Thanks, doug On May 20, 2016, at 6:37 PM, Elzur, Uri <uri.el...@intel.com<mailto:uri.el...@intel.com>> wrote: Hi Armando, Cathy, All First I apologize for the delay, returning from a week long international trip. (yes, I know, a lousy excuse on many accounts…) If I’m attempting to summarize all the responses, it seems like • A given abstraction in Neutron is allowed (e.g. in support of SFC), preferably not specific to a given technology e.g. NSH for SFC • A stadium project is not held to the same tests (but we do not have a “formal” model here, today) and therefore can support even a specific technology e.g. NSH (definitely better with abstractions to meet Neutron standards for future integration) However, • There still is a chicken and egg phenomenon… how can a technology become main stream with OPEN SOURCE support if we can’t get an OpenStack to support the required abstractions before the technology was adopted elsewhere?? o Especially as Stadium, can we let Neutron to lead the industry, given broad enough community interest? • BTW, in this particular case, there originally has been a direct ODL access as a NSH solution (i.e. NO OpenStack option), then we got Tacker (now an Neutron Stadium project, if I get it right) to support SFC and NSH, but we are still told that networking-sfc (another Neutron Stadium project ) can’t do the same…. • Also regarding the following comment made on another message in this thread, “As to OvS features, I guess the OvS ml is a better place, but wonder if the Neutron community wants to hold itself hostage to the pace of other projects who are reluctant to adopt a feature”, what I mean is again, that chicken and egg situation as above. Personally, I think OpenStack Neutron should allow mechanisms that are of interest / value to the networking community at large, to “ experiment with the abstraction” as you stated, independent of other organizations/projects… SOOO, is the bottom line that we agree that supporting NSH explicitly in networking-sfc can be added now? Thx Uri (“Oo-Ree”) C: 949-378-7568 From: Armando M. [mailto:arma...@gmail.com] Sent: Friday, May 13, 2016 5:14 PM To: Cathy Zhang <cathy.h.zh...@huawei.com<mailto:cathy.h.zh...@huawei.com>> Cc: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC On 13 May 2016 at 16:01, Cathy Zhang <cathy.h.zh...@huawei.com<mailto:cathy.h.zh...@huawei.com>> wrote: Hi Uri, Current networking-sfc API allows the user to specify the data path SFC encapsulation mechanism and NSH could be one of the encapsulation options. But since OVS release has not supported the NSH yet, we have to wait until NSH is added into OVS and then start to support the NSH encapsulation mechanism in the data path. One can support NSH whichever way they see fit. NSH in OVS is not something Neutron can do anything about. Neutron is about defining abstractions that can apply to a variety of technologies and experiment with what open source component is available on the shelves. Anyone can take the abstraction and deliver whatever technology stack they want with it and we'd happily gather any feedback to iterate on the abstraction to address more and more use case. AFAIK, it is the position of Neutron to have any OVS related new features developed inside the OV
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<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
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
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
[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] [networking-sfc] Network-sfc project f2f2 meet-up place and time
Can you pls add more detailed minutes as to emerging agreements/understandings?
Thx
Uri ("Oo-Ree")
C: 949-378-7568
-Original Message-
From: Akihiro Motoki [mailto:amot...@gmail.com]
Sent: Tuesday, April 26, 2016 11:50 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] [networking-sfc] Network-sfc project
f2f2 meet-up place and time
2016-04-26 12:31 GMT-05:00 Henry Fourie :
> All,
>Please use the networking-sfc etherpad to record discussions at the
> meetups:
>
> https://etherpad.openstack.org/p/networking-sfc-austin-summit-meeting
>
> - Louis
>
> -Original Message-
> From: Paul Carver [mailto:pcar...@paulcarver.us]
> Sent: Tuesday, April 26, 2016 10:20 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [neutron] [networking-sfc] Network-sfc
> project f2f2 meet-up place and time
>
> On 4/26/2016 00:35, Akihiro Motoki wrote:
>> Hi Cathy and folks interested in SFC and classifers!
>>
>> Can't we use a different room like Salon D?
>> Salon C is a lunch room and at that time there are no sessions in other
>> rooms.
>> It would be great if we can use Salon D or E (after looking at the
>> first day's session) I think we can gather more easily and
>> concentrate the discussion if we use some different space.
>> Thought?
>>
>
> Akihiro,
>
> Unless I've misunderstood the emails, the plan for Tuesday is a social lunch
> for the SFC team to get together. The plan for Wednesday is a working lunch
> to discuss flow classifiers in various projects and figure out how to
> converge on a single flow classifier API/model that can be shared by
> everything that needs to specify flows.
>
> If that's correct, then meeting in Salon C for lunch on Tuesday makes sense.
> For Wednesday we probably ought to grab boxed lunches and find a quiet room.
I was confused with networking-sfc f2f meeting and flow classifier one.
My previous mail is a suggestion for wednesday flow classifier meeting.
Thanks for point it out.
Akihiro
>
>
> __
> 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] [Congress] [Delegation] Meeting scheduling
interested Thx Uri (Oo-Ree) C: 949-378-7568 From: Tim Hinrichs [mailto:thinri...@vmware.com] Sent: Monday, March 16, 2015 11:05 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Congress] [Delegation] Meeting scheduling Hi all, The feedback on the POC delegation proposal has been mostly positive. Several people have asked for a meeting to discuss further. Given time zone constraints, it will likely be 8a or 9a Pacific. Let me know in the next 2 days if you want to participate, and we will try to find a day that everyone can attend. https://docs.google.com/document/d/1ksDilJYXV-5AXWON8PLMedDKr9NpS8VbT0jIy_MIEtI/edit Thanks! Tim __ 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 roadmap
Hi Salvatore Would like to discuss with you your views on what services are needed and when and how to architect it etc I’d like to meet in Palo Alto, maybe 11/19? Thx Uri (“Oo-Ree”) C: 949-378-7568 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Nova] [Summit] proposed item for the crossproject and/ or Nova meetings in the Design summit
Today, OpenStack makes placement decision mainly based on Compute demands (Scheduler is part of Nova). It also uses some info provided about platform's Compute capabilities. But for a given application (consists of some VMs, some Network appliances, some storage etc), Nova/Scheduler has no way to figure out relative placement of Network devices (virtual appliances, SFC) and/or Storage devices (which is also network born in many cases) in reference to the Compute elements. This makes it harder to provide SLA, support certain policies (e.g. HA or keeping all of these elements within a physical boundary of your choice, or within a given network physical boundary and guarantee storage proximity, for example. It also makes it harder to optimize resource utilization level, which increases the cost and may cause Openstack to be less competitive on TCO. Another aspect of the issue, is that in order, to lower the cost per unit of compute (or said better per unit of Application), it is essential to pack tighter. This increases infrastructure utilization but also makes interference a more important phenomenon (aka Nosy neighbor). SLA requests, SLA guarantees and placement based on ability to provide desired SLA are required. We'd like to suggest moving a bit faster on making OpenStack a more compelling stack for Compute/Network/Storage, capable of supporting Telco/NFV and other usage models, and creating the foundation for providing very low cost platform, more competitive with large cloud deployment. The concern is that any scheduler change will take long time. Folks closer to the Scheduler work, have already pointed out we first need to stabilize the API between Nova and the Scheduler, before we can talk about a split (e.g. Gantt). So it may take till late in 2016 (best case?), to get this kind of broader Application level functionality in the OpenStack scheduler . We'd like to bring it up in the coming design summit. Where do you think it needs to be discussed: cross project tack? Scheduler discussion? Other? I've just added a proposed item 17.1 to the https://etherpad.openstack.org/p/kilo-crossproject-summit-topics 1. 2. present Application's Network and Storage requirements, coupled with infrastructure capabilities and status (e.g. up/dn, utilization levels) and placement policy (e.g. proximity, HA) to get optimized placement decisions accounting for all application elements (VMs, virt Network appliances, Storage) vs. Compute only Thx Uri (Oo-Ree) C: 949-378-7568 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [gantt] Scheduler group meeting - cancelled this week INTERNAL
Don Will there be a meeting next week? What is the regular time slot for the meeting? I'd like to work w you on a technical slide to use in Paris Do we need to socialize the Gantt topic more? Thx Uri (Oo-Ree) C: 949-378-7568 From: Dugger, Donald D [mailto:donald.d.dug...@intel.com] Sent: Wednesday, October 22, 2014 6:04 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [gantt] Scheduler group meeting - cancelled this week Just a reminder that, as we mentioned last week, no meeting today. -- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale Ph: 303/443-3786 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
