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. > > > > > > > > > > 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-stadi > > um.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 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, 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 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 >
__________________________________________________________________________ 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
