Open Stack

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 <amotoki at gmail.com> 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 <uri.elzur at intel.com>:
> > 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 <louis.fourie at huawei.com>
> 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:dougwig at parksidesoftware.com]
> > 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 <uri.elzur at intel.com> 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: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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160523/215478d0/attachment.html>