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 <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> 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> > 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 <tel: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
