<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 25 May 2016 at 10:24, Tim Rozet <span dir="ltr"><<a href="mailto:trozet@redhat.com" target="_blank">trozet@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">In my opinion, it is a better approach to break this down into plugin vs driver support.  There should be no problem adding support into networking-sfc plugin for NSH today.  The OVS driver however, depends on OVS as the dataplane - which I can see a solid argument for only supporting an official version with a non-NSH solution.  The plugin side should have no dependency on OVS.  Therefore if we add NSH SFC support to an ODL driver in networking-odl, and use that as our networking-sfc driver, the argument about OVS goes away (since neutron/networking-sfc is totally unaware of the dataplane at this point). </blockquote><div><br></div><div>I am afraid the argument does not go away is the crux of the matter is exposing implementation aspects over the SFC API where such aspects  can only be realized/understood by a single plugin.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">We would just need to ensure that API calls to networking-sfc specifying NSH port pairs returned error if the enabled driver was OVS (until official OVS with NSH support is released).<br>
<br></blockquote><div><br></div><div>I am not 100% sure what you mean by specifying NSH port pairs over the API but this to me seems to be in violation of the above mentioned abstraction principle we're trying to abide. To date a plugin is allowed to bring its own extensions, however that doesn't mean that those extensions can be universally implemented and as such must be considered plugin specific.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
Thoughts? </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<span class="im"><br>
Tim Rozet<br>
Red Hat SDN Team<br>
<br>
----- Original Message -----<br>
</span><span class="im">From: "Armando M." <<a href="mailto:armamig@gmail.com">armamig@gmail.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
</span><span class="im">Cc: "Tim Rozet" <<a href="mailto:trozet@redhat.com">trozet@redhat.com</a>><br>
Sent: Wednesday, May 25, 2016 12:33:16 PM<br>
Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC<br>
<br>
</span><div class=""><div class="h5">On 24 May 2016 at 21:53, Elzur, Uri <<a href="mailto:uri.elzur@intel.com">uri.elzur@intel.com</a>> wrote:<br>
<br>
> Hi Tim<br>
><br>
> Sorry for the delay due to travel...<br>
><br>
> This note is very helpful!<br>
><br>
> We are in agreement that the team including the individuals cited below<br>
> are supportive. We also agree that SFC belongs in the networking-SFC<br>
> project (with proper API adjustment)<br>
><br>
> It seems networking-sfc still holds the position that without OvS<br>
> accepting VXLAN-gpe and NSH patches they can't support NSH. I'm trying to<br>
> get a clear read on where is this stated as requirement<br>
><br>
<br>
I think the position here is as follows: if a technology is not mainstream,<br>
i.e. readily available via distros and the various channels, it can only be<br>
integrated via an experimental path. No-one is preventing anyone from<br>
posting patches and instructions to compile kernels and kernel modules, but<br>
ultimately as an OpenStack project that is suppose to produce commercial<br>
and production grade software, we should be very sensitive in investing<br>
time and energy in supporting a technology that may or may not have a<br>
viable path towards inclusion into mainstream (Linux and OVS in this<br>
instance).<br>
<br>
One another clear example we had in the past was DPDK (that enabled fast<br>
path processing in Neutron with OVS) and connection tracking (that enabled<br>
security groups natively build on top of OVS). We, as a project have<br>
consistently avoided endorsing efforts until they mature and show a clear<br>
path forward.<br>
<br>
<br>
> Like you, we are closely following the progress of the patches and<br>
> honestly I have hard time seeing OpenStack supporting NSH in production<br>
> even by the end of 2017. I think this amounts to slowing down the market...<br>
><br>
> I think we need to break the logjam.<br>
><br>
<br>
We are not the ones (Neutron) you're supposed to break the logjam with. I<br>
think the stakeholders here go well beyond the Neutron team alone.<br>
<br>
<br>
><br>
> I've reviewed (<br>
> <a href="https://review.openstack.org/#/c/312199/12/specs/newton/neutron-stadium.rst,unified" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/312199/12/specs/newton/neutron-stadium.rst,unified</a>)<br>
> and found nowhere a guideline suggesting that before a backend has fully<br>
> implemented and merged upstream a technology (i.e. another project outside<br>
> of OepnStack!), OpenStack Neutron can't make any move. ODL is working >2<br>
> years to support NSH using patches, yet to be accepted into Linux Kernel<br>
> (almost done) and OvS (preliminary) - as you stated. Otherwise we create a<br>
> serialization, that gets worse and worse over time and with additional<br>
> layers.<br>
><br>
> No one suggests the such code needs to be PRODUCTION, but we need a way to<br>
> roll out EXPERIMENTAL functions and later merge them quickly when all<br>
> layers are ready, this creates a nice parallelism and keeps a decent pace<br>
> of rolling out new features broadly supported elsewhere.<br>
><br>
<br>
I agree with this last statement; this is for instance what is happening<br>
with OVN which, in order to work with Neutron, needs patching and stay<br>
close to trunk etc. The technology is still maturing and the whole Neutron<br>
integration is in progress, but at least there's a clear signal that the it<br>
will eventually become mainstream. If it did not, I would bet that<br>
priorities would be focused elsewhere.<br>
<br>
You asked in a previous email whether Neutron wanted to kept itself hostage<br>
of OVS. My answer to you is NO: we have many technology stack options we<br>
can rely on in order to realize abstractions so long as they are open, and<br>
have a viable future.<br>
<br>
<br>
><br>
> Thx<br>
><br>
> Uri (“Oo-Ree”)<br>
> C: <a href="tel:949-378-7568" value="+19493787568">949-378-7568</a><br>
><br>
> -----Original Message-----<br>
> From: Tim Rozet [mailto:<a href="mailto:trozet@redhat.com">trozet@redhat.com</a>]<br>
> Sent: Friday, May 20, 2016 7:01 PM<br>
> To: OpenStack Development Mailing List (not for usage questions) <<br>
> <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>; Elzur, Uri <<a href="mailto:uri.elzur@intel.com">uri.elzur@intel.com</a>><br>
> Cc: Cathy Zhang <<a href="mailto:Cathy.H.Zhang@huawei.com">Cathy.H.Zhang@huawei.com</a>><br>
> Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC<br>
><br>
> Hi Uri,<br>
> I originally wrote the Tacker->ODL SFC NSH piece and have been working<br>
> with Tacker and networking-sfc team to bring it upstream into OpenStack.<br>
> Cathy, Stephen, Louis and the rest of the networking-sfc team have been<br>
> very receptive to changes specific to NSH around their current API and DB<br>
> model.  The proper place for SFC to live in OpenStack is networking-sfc,<br>
> while Tacker can do its orchestration job by rendering ETSI MANO TOSCA<br>
> input like VNF Descriptors and VNF Forwarding Graph Descriptors.<br>
><br>
> We currently have a spec in netwoking-odl to migrate my original driver<br>
> for ODL to do IETF NSH.  That driver will be supported in networking-sfc,<br>
> along with some changes to networking-sfc to account for NSH awareness and<br>
> encap type (like VXLAN+GPE or Ethernet).  The OVS work to support NSH is<br>
> coming along and patches are under review.  Yi Yang has built a private OVS<br>
> version with these changes and we can use that for now to test with.<br>
><br>
> I think it is all coming together and will take a couple more months<br>
> before all of the pieces (Tacker, networking-sfc, networking-odl, ovs) are<br>
> in place.  I don't think networking-sfc is holding up any progress.<br>
><br>
> Thanks,<br>
><br>
> Tim Rozet<br>
> Red Hat SDN Team<br>
><br>
> ----- Original Message -----<br>
> From: "Uri Elzur" <<a href="mailto:uri.elzur@intel.com">uri.elzur@intel.com</a>><br>
> To: "OpenStack Development Mailing List (not for usage questions)" <<br>
> <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>, "Cathy Zhang" <<br>
> <a href="mailto:Cathy.H.Zhang@huawei.com">Cathy.H.Zhang@huawei.com</a>><br>
> Sent: Friday, May 20, 2016 8:37:26 PM<br>
> Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC<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 SFC),<br>
> 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 have a<br>
> “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 become<br>
> 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 ODL<br>
> 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 this<br>
> 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<br>
> again, that chicken and egg situation as above. Personally, I think<br>
> OpenStack Neutron should allow mechanisms that are of interest / value to<br>
> the networking community at large, to “ experiment with the abstraction” as<br>
> you 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: <a href="tel:949-378-7568" value="+19493787568">949-378-7568</a><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>
><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>
><br>
><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>
><br>
><br>
> One can support NSH whichever way they see fit. NSH in OVS is not<br>
> something Neutron can do anything about. Neutron is about defining<br>
> abstractions that can apply to a variety of technologies and experiment<br>
> with what open source component is available on the shelves. Anyone can<br>
> take the abstraction and deliver whatever technology stack they want with<br>
> it and we'd happily gather any feedback to iterate on the abstraction to<br>
> address more and more use case.<br>
><br>
><br>
><br>
><br>
><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>
><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>
><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: <a href="tel:949-378-7568" value="+19493787568">949-378-7568</a><br>
><br>
><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>
> 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>
</div></div></blockquote></div><br></div></div>