Yes, the effort is on-going for ODL [1] and ONOS [2] [3] has successfully integrated the same..
[1] networking-odl spec https://github.com/openstack/networking-odl/blob/master/doc/source/sfc-driver.rst [2] ONOS Implementation https://github.com/opennetworkinglab/onos/tree/master/apps/vtn/sfcmgr/src/main/java/org/onosproject/sfc [3] networking-onos spec https://github.com/openstack/networking-onos/blob/master/doc/source/devref/sfc_driver.rst On Mon, May 23, 2016 at 11:28 AM, Akihiro Motoki <[email protected]> wrote: > Henry is talking about drivers which CURRENTLY support networking-sfc. > In my understanding, ODL driver for networking-sfc is ongoing. > > 2016-05-23 13:22 GMT+09:00 Elzur, Uri <[email protected]>: > > 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 <[email protected]> > 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:[email protected]] > > 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 <[email protected]> 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:[email protected]] > > Sent: Friday, May 13, 2016 5:14 PM > > To: Cathy Zhang <[email protected]> > > Cc: OpenStack Development Mailing List (not for usage questions) > > <[email protected]> > > Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC > > > > > > > > > > > > > > > > On 13 May 2016 at 16:01, Cathy Zhang <[email protected]> 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:[email protected]] > > 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: > [email protected]?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > [email protected]?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > [email protected]?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
