Open Stack

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
>