Open Stack

On 25 May 2016 at 12:29, Elzur, Uri <uri.elzur at intel.com> wrote:

> Armando
>
>
>
> I’m asking for a clear answer “I think the position here is as follows:
> if a technology is not mainstream, i.e. readily available via distros and
> the various channels, it can only be integrated via an experimental path”
>
>
>
> If we can allow for the EXPERIMENTAL path for NSH, then we can stand up
> the whole stack in EXPERIMENTAL mode and quickly move to mainstream when
> other pieces outside of Neutron fall in place.
>

As I said, you're free to experiment. The general directive is to allow
these experimentations to take place and use them as a feedback tool to
iterate on the abstractions. However the abstraction would only be
considered community accepted if and only if there's enough evidence that
there is established support from a broad variety of plugins (open source
and non).


>
>
> As to OVN – it has to be EXPERIMENTAL too. I guess, if I interpret your
> response correctly, that unlike their future intention for OVN,  OvS is not
> willing to signal interest in integrating NSH
>

We're mixing two things here: OVN is not experimenting with (Neutron) APIs
(as it's adopting those as is), but it's experimenting with
implementations. So I would not conflate OVN and NSH in the same
discussion. I simply brought it up as another example (alongside DPDK) of
how innovation can be fostered in open source communities.


>
> Thx
>
>
>
> Uri (“Oo-Ree”)
>
> C: 949-378-7568
>
>
>
> *From:* Armando M. [mailto:armamig at gmail.com]
> *Sent:* Wednesday, May 25, 2016 9:33 AM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev at lists.openstack.org>
> *Subject:* Re: [openstack-dev] [Neutron] support of NSH in networking-SFC
>
>
>
>
>
>
>
> On 24 May 2016 at 21:53, Elzur, Uri <uri.elzur at intel.com> wrote:
>
> Hi Tim
>
> Sorry for the delay due to travel...
>
> This note is very helpful!
>
> We are in agreement that the team including the individuals cited below
> are supportive. We also agree that SFC belongs in the networking-SFC
> project (with proper API adjustment)
>
> It seems networking-sfc still holds the position that without OvS
> accepting VXLAN-gpe and NSH patches they can't support NSH. I'm trying to
> get a clear read on where is this stated as requirement
>
>
>
> I think the position here is as follows: if a technology is not
> mainstream, i.e. readily available via distros and the various channels, it
> can only be integrated via an experimental path. No-one is preventing
> anyone from posting patches and instructions to compile kernels and kernel
> modules, but ultimately as an OpenStack project that is suppose to produce
> commercial and production grade software, we should be very sensitive in
> investing time and energy in supporting a technology that may or may not
> have a viable path towards inclusion into mainstream (Linux and OVS in this
> instance).
>
>
>
> One another clear example we had in the past was DPDK (that enabled fast
> path processing in Neutron with OVS) and connection tracking (that enabled
> security groups natively build on top of OVS). We, as a project have
> consistently avoided endorsing efforts until they mature and show a clear
> path forward.
>
>
>
>
> Like you, we are closely following the progress of the patches and
> honestly I have hard time seeing OpenStack supporting NSH in production
> even by the end of 2017. I think this amounts to slowing down the market...
>
> I think we need to break the logjam.
>
>
>
> We are not the ones (Neutron) you're supposed to break the logjam with. I
> think the stakeholders here go well beyond the Neutron team alone.
>
>
>
>
> I've reviewed (
> https://review.openstack.org/#/c/312199/12/specs/newton/neutron-stadium.rst,unified)
> and found nowhere a guideline suggesting that before a backend has fully
> implemented and merged upstream a technology (i.e. another project outside
> of OepnStack!), OpenStack Neutron can't make any move. ODL is working >2
> years to support NSH using patches, yet to be accepted into Linux Kernel
> (almost done) and OvS (preliminary) - as you stated. Otherwise we create a
> serialization, that gets worse and worse over time and with additional
> layers.
>
> No one suggests the such code needs to be PRODUCTION, but we need a way to
> roll out EXPERIMENTAL functions and later merge them quickly when all
> layers are ready, this creates a nice parallelism and keeps a decent pace
> of rolling out new features broadly supported elsewhere.
>
>
>
> I agree with this last statement; this is for instance what is happening
> with OVN which, in order to work with Neutron, needs patching and stay
> close to trunk etc. The technology is still maturing and the whole Neutron
> integration is in progress, but at least there's a clear signal that the it
> will eventually become mainstream. If it did not, I would bet that
> priorities would be focused elsewhere.
>
>
>
> You asked in a previous email whether Neutron wanted to kept itself
> hostage of OVS. My answer to you is NO: we have many technology stack
> options we can rely on in order to realize abstractions so long as they are
> open, and have a viable future.
>
>
>
>
> Thx
>
> Uri (“Oo-Ree”)
> C: 949-378-7568
>
> -----Original Message-----
> From: Tim Rozet [mailto:trozet at redhat.com]
> Sent: Friday, May 20, 2016 7:01 PM
> To: OpenStack Development Mailing List (not for usage questions) <
> openstack-dev at lists.openstack.org>; Elzur, Uri <uri.elzur at intel.com>
> Cc: Cathy Zhang <Cathy.H.Zhang at huawei.com>
> Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC
>
> Hi Uri,
> I originally wrote the Tacker->ODL SFC NSH piece and have been working
> with Tacker and networking-sfc team to bring it upstream into OpenStack.
> Cathy, Stephen, Louis and the rest of the networking-sfc team have been
> very receptive to changes specific to NSH around their current API and DB
> model.  The proper place for SFC to live in OpenStack is networking-sfc,
> while Tacker can do its orchestration job by rendering ETSI MANO TOSCA
> input like VNF Descriptors and VNF Forwarding Graph Descriptors.
>
> We currently have a spec in netwoking-odl to migrate my original driver
> for ODL to do IETF NSH.  That driver will be supported in networking-sfc,
> along with some changes to networking-sfc to account for NSH awareness and
> encap type (like VXLAN+GPE or Ethernet).  The OVS work to support NSH is
> coming along and patches are under review.  Yi Yang has built a private OVS
> version with these changes and we can use that for now to test with.
>
> I think it is all coming together and will take a couple more months
> before all of the pieces (Tacker, networking-sfc, networking-odl, ovs) are
> in place.  I don't think networking-sfc is holding up any progress.
>
> Thanks,
>
> Tim Rozet
> Red Hat SDN Team
>
> ----- Original Message -----
> From: "Uri Elzur" <uri.elzur at intel.com>
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>, "Cathy Zhang" <
> Cathy.H.Zhang at huawei.com>
> Sent: Friday, May 20, 2016 8:37:26 PM
> Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC
>
>
>
> 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:armamig at gmail.com]
> Sent: Friday, May 13, 2016 5:14 PM
> To: Cathy Zhang <Cathy.H.Zhang at huawei.com>
> Cc: OpenStack Development Mailing List (not for usage questions) <
> openstack-dev at 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.Zhang at 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.elzur at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160525/4cbf2a09/attachment.html>