Open Stack

On 24 May 2016 at 22:07, Elzur, Uri <uri.elzur at intel.com> wrote:

> Hi Armando
>
>
>
> Pls see below [UE]
>
>
>
> Thx
>
>
>
> Uri (“Oo-Ree”)
>
> C: 949-378-7568
>
>
>
> *From:* Armando M. [mailto:armamig at gmail.com]
> *Sent:* Friday, May 20, 2016 9:08 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 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.
>
> [UE] I think we have agreement SFC is a needed abstraction
>
>
>
> 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.
>
>
>
> [UE] carefully read (
> https://review.openstack.org/#/c/312199/12/specs/newton/neutron-stadium.rst,unified)
> and hope I understand Stadium. All NSH patches that we’d like to support
> are OPEN. I’m still looking for the place where a restriction prevents
> networking-SFC form moving forward on NSH before all other external
> projects to OpenStack has completed their work. Pls see also reply to Tim
> Rozet
>
>
>
> 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.
>
> [UE] thanks for this clarification! I think it means that now that we all
> agree SFC abstraction is needed and that NSH is an emerging standard and
> networking-sfc team agrees to support NSH – there should be no reason to
> wait. As Tim Rozet mentioned an ODL driver with explicit SFC support is
> WIP, so sounds like NSH  support in it should be a go!
>

So long the required support is not specific to NSH and the API is not
polluted by implementation details specific to NSH.

> ·         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.
>
> [UE] but as stated above and on the ml, in this case where we have
> agreement on the specific SFC abstraction, are we in agreement that we can
> move without being held back by other projects e.g. OvS???
>

As I said, if the abstraction is leaking implementation details or it is
unable to be fulfilled by a pure implementation platform then it should not
be endorsed.

>
>
> 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?
>
> [UE] sure. Building NSH specific api and structures inside networking-sfc
> project (requires upgrade to its v1 API) and supporting of the ODL driver
> with NSH support. ODL can be the provider and can be tested w Neutron+
> Networking-sfc
>

Do you have a pointer for these iterations on top of the v1 API?


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