On 24 May 2016 at 22:07, Elzur, Uri <uri.el...@intel.com> wrote: > Hi Armando > > > > Pls see below [UE] > > > > Thx > > > > Uri (“Oo-Ree”) > > C: 949-378-7568 > > > > *From:* Armando M. [mailto:arma...@gmail.com] > *Sent:* Friday, May 20, 2016 9:08 PM > *To:* OpenStack Development Mailing List (not for usage questions) < > openstack-dev@lists.openstack.org> > *Subject:* Re: [openstack-dev] [Neutron] support of NSH in networking-SFC > > > > > > > > On 20 May 2016 at 17:37, Elzur, Uri <uri.el...@intel.com> wrote: > > Hi Armando, Cathy, All > > > > First I apologize for the delay, returning from a week long international > trip. (yes, I know, a lousy excuse on many accounts…) > > > > If I’m attempting to summarize all the responses, it seems like > > · A given abstraction in Neutron is allowed (e.g. in support of > SFC), preferably not specific to a given technology e.g. NSH for SFC > > · A stadium project is not held to the same tests (but we do not > have a “formal” model here, today) and therefore can support even a > specific technology e.g. NSH (definitely better with abstractions to meet > Neutron standards for future integration) > > > > A given abstraction is allowed so long as there is enough agreement that > it is indeed technology agnostic. If the abstraction maps neatly to a given > technology, the implementation may exist within the context of Neutron or > elsewhere. > > [UE] I think we have agreement SFC is a needed abstraction > > > > Having said that I'd like to clarify a point: you seem to refer to the > stadium as a golden standard. The stadium is nothing else but a list of > software repositories that the Neutron team develops and maintain. Given > the maturity of a specific repo, it may or may not implement an abstraction > with integration code to non open technologies. This is left at discretion > of the group of folks who are directly in control of the specific repo, > though it has been the general direction to strongly encourage and promote > openness throughout the entire stack that falls under the responsibility of > the Neutron team and thus the stadium. > > > > [UE] carefully read ( > https://review.openstack.org/#/c/312199/12/specs/newton/neutron-stadium.rst,unified) > and hope I understand Stadium. All NSH patches that we’d like to support > are OPEN. I’m still looking for the place where a restriction prevents > networking-SFC form moving forward on NSH before all other external > projects to OpenStack has completed their work. Pls see also reply to Tim > Rozet > > > > However, > > · There still is a chicken and egg phenomenon… how can a > technology become main stream with OPEN SOURCE support if we can’t get an > OpenStack to support the required abstractions *before* the technology > was adopted elsewhere?? > > o Especially as Stadium, can we let Neutron to lead the industry, given > broad enough community interest? > > · BTW, in this particular case, there originally has been a > *direct* ODL access as a NSH solution (i.e. NO OpenStack option), then we > got Tacker (now an Neutron Stadium project, if I get it right) to support > SFC and NSH, but we are still told that networking-sfc (another Neutron > Stadium project ) can’t do the same…. > > I cannot comment for the experience and the conversations you've had so > far as I have no context. All I know is that if you want to experiment with > OpenDaylight and its NSH provider and want to use that as a Neutron backend > you can. However, if that requires new abstractions, these new abstractions > must be agreed by all interested parties, be technology agnostic, and allow > for multiple implementation, an open one included. That's the nature of > OpenStack. > > [UE] thanks for this clarification! I think it means that now that we all > agree SFC abstraction is needed and that NSH is an emerging standard and > networking-sfc team agrees to support NSH – there should be no reason to > wait. As Tim Rozet mentioned an ODL driver with explicit SFC support is > WIP, so sounds like NSH support in it should be a go! >
So long the required support is not specific to NSH and the API is not polluted by implementation details specific to NSH. > · Also regarding the following comment made on another message > in this thread, “As to OvS features, I guess the OvS ml is a better place, > but wonder if the Neutron community wants to hold itself hostage to the > pace of other projects who are reluctant to adopt a feature”, what I mean > is again, that chicken and egg situation as above. Personally, I think > OpenStack 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 e.g. OvS??? > As I said, if the abstraction is leaking implementation details or it is unable to be fulfilled by a pure implementation platform then it should not be endorsed. > > > SOOO, is the bottom line that we agree that supporting NSH explicitly in > networking-sfc can be added now? > > > > I don't know what you mean by supporting NSH explicitly in networking-sfc. > Can you be more specific? Do you intend via OpenDaylight? What would be the > NSH provider? > > [UE] sure. Building NSH specific api and structures inside networking-sfc > project (requires upgrade to its v1 API) and supporting of the ODL driver > with NSH support. ODL can be the provider and can be tested w Neutron+ > Networking-sfc > Do you have a pointer for these iterations on top of the v1 API? > > 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