<div dir="ltr">Yes, the effort is on-going for ODL [1] and ONOS [2] [3] has successfully integrated the same..<div><br></div><div><br></div><div>[1] networking-odl spec</div><div><a href="https://github.com/openstack/networking-odl/blob/master/doc/source/sfc-driver.rst">https://github.com/openstack/networking-odl/blob/master/doc/source/sfc-driver.rst</a><br></div><div>[2] ONOS Implementation<br></div><div><a href="https://github.com/opennetworkinglab/onos/tree/master/apps/vtn/sfcmgr/src/main/java/org/onosproject/sfc">https://github.com/opennetworkinglab/onos/tree/master/apps/vtn/sfcmgr/src/main/java/org/onosproject/sfc</a></div><div>[3] networking-onos spec</div><div><a href="https://github.com/openstack/networking-onos/blob/master/doc/source/devref/sfc_driver.rst">https://github.com/openstack/networking-onos/blob/master/doc/source/devref/sfc_driver.rst</a><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 23, 2016 at 11:28 AM, Akihiro Motoki <span dir="ltr"><<a href="mailto:amotoki@gmail.com" target="_blank">amotoki@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Henry is talking about drivers which CURRENTLY support networking-sfc.<br>
In my understanding, ODL driver for networking-sfc is ongoing.<br>
<div class="HOEnZb"><div class="h5"><br>
2016-05-23 13:22 GMT+09:00 Elzur, Uri <<a href="mailto:uri.elzur@intel.com">uri.elzur@intel.com</a>>:<br>
> ODL has support for sfc w NSH. Why would ONOS count as backend and ODL not?<br>
><br>
> Uri<br>
><br>
> Sent from my iPhone<br>
><br>
> On May 21, 2016, at 11:26 AM, Henry Fourie <<a href="mailto:louis.fourie@huawei.com">louis.fourie@huawei.com</a>> wrote:<br>
><br>
> Doug,<br>
><br>
>    Networking-sfc API currently has two reference SFC implementations that<br>
> are open source:<br>
><br>
> the OVS driver and the ONOS driver. Work is also in progress for an ODL SFC<br>
> driver and an OVN<br>
><br>
> driver.<br>
><br>
> -        Louis<br>
><br>
><br>
><br>
> From: Doug Wiegley [mailto:<a href="mailto:dougwig@parksidesoftware.com">dougwig@parksidesoftware.com</a>]<br>
> Sent: Friday, May 20, 2016 5:48 PM<br>
> To: OpenStack Development Mailing List (not for usage questions)<br>
> Subject: Re: [openstack-dev] [Neutron][TC] support of NSH in networking-SFC<br>
><br>
><br>
><br>
> In a nutshell, you’ve got it, you can’t add an API without a reference<br>
> implementation, including data-plane, which has to be open-source (though<br>
> does not have to itself be openstack.)<br>
><br>
><br>
><br>
> o   Especially as Stadium, can we let Neutron to lead the industry, given<br>
> broad enough community interest?<br>
><br>
><br>
><br>
> You can do anything you want outside the stadium, which is where<br>
> experimental/incubation is meant to happen.  Inside the stadium means,<br>
> “official openstack project”, which means it has an open-source<br>
> implementation.<br>
><br>
><br>
><br>
> If all backends are closed-source, it’s not open as openstack defines it:<br>
> <a href="https://governance.openstack.org/reference/opens.html" rel="noreferrer" target="_blank">https://governance.openstack.org/reference/opens.html</a><br>
><br>
><br>
><br>
> There isn’t any wiggle room there. This isn’t a neutron argument; feel free<br>
> to take it up with the TC.<br>
><br>
><br>
><br>
> Thanks,<br>
><br>
> doug<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> On May 20, 2016, at 6:37 PM, Elzur, Uri <<a href="mailto:uri.elzur@intel.com">uri.elzur@intel.com</a>> wrote:<br>
><br>
><br>
><br>
> Hi Armando, Cathy, All<br>
><br>
><br>
><br>
> First I apologize for the delay, returning from a week long international<br>
> trip. (yes, I know,  a lousy excuse on many accounts…)<br>
><br>
><br>
><br>
> If I’m attempting to summarize all the responses, it seems like<br>
><br>
> ·         A given abstraction in Neutron is allowed (e.g. in support of<br>
> SFC), preferably not specific to a given technology e.g. NSH for SFC<br>
><br>
> ·         A stadium project is not held to the same tests (but we do not<br>
> have a “formal” model here, today) and therefore can support even a specific<br>
> technology e.g. NSH (definitely better with abstractions to meet Neutron<br>
> standards for future integration)<br>
><br>
><br>
><br>
> However,<br>
><br>
> ·         There still is a chicken and egg phenomenon… how can a technology<br>
> become main stream with OPEN SOURCE support  if we can’t get an OpenStack to<br>
> support the required abstractions before the technology was adopted<br>
> elsewhere??<br>
><br>
> o   Especially as Stadium, can we let Neutron to lead the industry, given<br>
> broad enough community interest?<br>
><br>
> ·         BTW,  in this particular case, there originally has been a direct<br>
> ODL access as a NSH solution (i.e. NO OpenStack option), then we got Tacker<br>
> (now an Neutron Stadium project, if I get it right) to support SFC and NSH,<br>
> but we are still told that networking-sfc (another Neutron Stadium project )<br>
> can’t do the same….<br>
><br>
> ·         Also regarding the  following comment made on another message in<br>
> this thread, “As to OvS features, I guess the OvS ml is a better place, but<br>
> wonder if the Neutron community wants to hold itself hostage to the pace of<br>
> other projects who are reluctant to adopt a feature”, what I mean is again,<br>
> that chicken and egg situation as above. Personally, I think OpenStack<br>
> Neutron should allow mechanisms that are of interest / value to the<br>
> networking community at large, to “ experiment with the abstraction” as you<br>
> stated, independent of other organizations/projects…<br>
><br>
><br>
><br>
> SOOO, is the bottom line that we agree that supporting NSH explicitly in<br>
> networking-sfc can be added now?<br>
><br>
><br>
><br>
><br>
><br>
> Thx<br>
><br>
><br>
><br>
> Uri (“Oo-Ree”)<br>
><br>
> C: 949-378-7568<br>
><br>
><br>
><br>
> From: Armando M. [mailto:<a href="mailto:armamig@gmail.com">armamig@gmail.com</a>]<br>
> Sent: Friday, May 13, 2016 5:14 PM<br>
> To: Cathy Zhang <<a href="mailto:Cathy.H.Zhang@huawei.com">Cathy.H.Zhang@huawei.com</a>><br>
> Cc: OpenStack Development Mailing List (not for usage questions)<br>
> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
> Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> On 13 May 2016 at 16:01, Cathy Zhang <<a href="mailto:Cathy.H.Zhang@huawei.com">Cathy.H.Zhang@huawei.com</a>> wrote:<br>
><br>
> Hi Uri,<br>
><br>
><br>
><br>
> Current networking-sfc API allows the user to specify the data path SFC<br>
> encapsulation mechanism and NSH could be one of the encapsulation options.<br>
><br>
> But since OVS release has not supported the NSH yet, we have to wait until<br>
> NSH is added into OVS and then start to support the NSH encapsulation<br>
> mechanism in the data path.<br>
><br>
><br>
><br>
> One can support NSH whichever way they see fit. NSH in OVS is not something<br>
> Neutron can do anything about. Neutron is about defining abstractions that<br>
> can apply to a variety of technologies and experiment with what open source<br>
> component is available on the shelves. Anyone can take the abstraction and<br>
> deliver whatever technology stack they want with it and we'd happily gather<br>
> any feedback to iterate on the abstraction to address more and more use<br>
> case.<br>
><br>
><br>
><br>
><br>
><br>
> AFAIK, it is the position of Neutron to have any OVS related new features<br>
> developed inside the OVS community.<br>
><br>
><br>
><br>
> Thanks,<br>
><br>
> Cathy<br>
><br>
><br>
><br>
> From: Elzur, Uri [mailto:<a href="mailto:uri.elzur@intel.com">uri.elzur@intel.com</a>]<br>
> Sent: Friday, May 13, 2016 3:02 PM<br>
> To: OpenStack Development Mailing List (not for usage questions); Armando M<br>
> Subject: [openstack-dev] [Neutron] support of NSH in networking-SFC<br>
><br>
><br>
><br>
> Hi Armando<br>
><br>
><br>
><br>
> As an industry we are working on SFC for 3 years or so (more?). Still to<br>
> date, we are told we can’t get Neutron or even a Stadium project e.g.<br>
> networking-SFC to support NSH (in IETF LC phase) because OvS has not<br>
> supported NSH. Is this an official position of Neutron that OvS is the gold<br>
> standard to support any new feature?<br>
><br>
><br>
><br>
> We have seen OvS support other overlays that are not ahead of VXLAN-gpe in<br>
> the IETF.<br>
><br>
><br>
><br>
> Thx<br>
><br>
><br>
><br>
> Uri (“Oo-Ree”)<br>
><br>
> C: 949-378-7568<br>
><br>
><br>
><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>