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