Open Stack

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

> Kyle
>
> Thx for your comment. I think these are orthogonal discussions. The heart
> of this one, for me, and in the Neutron context, is plotting a road forward
> on new technologies INDEPENDENT of external (even if related) open source
> projects. I like Armando's direction.
>
> The best of my understanding (granted, limited) is that the OvS official
> position is not supportive of gpe and NSH as long as the Linux Kernel
> doesn't have them. So we are in a nice little spiral for >2 years, which is
> really long time if we want to have a reasonable pace of new technology
> adoption
>
>
It would be nice to understand what the concerns are and how to resolve
them in order to try and find a path where things can be reconciled later
on. Technology adoption will always be hindered by the potential risk of
dealing with fork down the road.


> The IETF is already last call and open source support ???
>
> Thx
>
> Uri (“Oo-Ree”)
> C: 949-378-7568
>
>
> -----Original Message-----
> From: Kyle Mestery [mailto:mestery at mestery.com]
> Sent: Wednesday, May 25, 2016 1:00 PM
> 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 Wed, May 25, 2016 at 2:29 PM, 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 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
> >
> Would this be a better thing to discuss on the ovs-dev list [1] rather
> than the openstack-dev list? I'm sure the OVS devs would be happy to
> continue a discussion about the possibility of using VXLAN+NSH over GENEVE
> there.
>
> [1] http://mail.openvswitch.org/mailman/listinfo/dev
>
> >
> >
> > 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-stadi
> > um.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
> >
>
> __________________________________________________________________________
> 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/9f99711b/attachment.html>