Open Stack

On 20 May 2016 at 17:37, 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)
>

A given abstraction is allowed so long as there is enough agreement that it
is indeed technology agnostic. If the abstraction maps neatly to a given
technology, the implementation may exist within the context of Neutron or
elsewhere.

Having said that I'd like to clarify a point: you seem to refer to the
stadium as a golden standard. The stadium is nothing else but a list of
software repositories that the Neutron team develops and maintain. Given
the maturity of a specific repo, it may or may not implement an abstraction
with integration code to non open technologies. This is left at discretion
of the group of folks who are directly in control of the specific repo,
though it has been the general direction to strongly encourage and promote
openness throughout the entire stack that falls under the responsibility of
the Neutron team and thus the stadium.


>
> 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….
>
I cannot comment for the experience and the conversations you've had so far
as I have no context. All I know is that if you want to experiment with
OpenDaylight and its NSH provider and want to use that as a Neutron backend
you can. However, if that requires new abstractions, these new abstractions
must be agreed by all interested parties, be technology agnostic, and allow
for multiple implementation, an open one included. That's the nature of
OpenStack.

> ·         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*…
>
I personally I see no catch-22 if you operate under the premises I stated
above. If Neutron allowed to experiment with *any* mechanism without taking
into consideration the importance of abstractions and community consensus,
we as a community have failed, especially in relation to the aspect of
interoperability.

>
>
> SOOO, is the bottom line that we agree that supporting NSH explicitly in
> networking-sfc can be added now?
>

I don't know what you mean by supporting NSH explicitly in networking-sfc.
Can you be more specific? Do you intend via OpenDaylight? What would be the
NSH provider?


>
>
>
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160520/72f0c76b/attachment.html>