Subject: [nvo3] user community concerned about lack of standards for network virtualization

From: Anoop Ghanwani <[email-masked]>
Date: Thu, 24 Jul 2014 16:57:32 -0700

One of the comments I made at the mic in response to some of the WG
reorganization statements was that the user community is complaining about
lack of standards.

The reference I would like to point folks to is the following whitepaper
from ONUG:
<quote>
Unfortunately, there are too many different tunneling protocols
and no multi-vendor interoperability between virtual overlay
vendors.
...
This ambiguity has caused the vendor community to create a
number of disparate mechanisms for state distribution with
very little or no interoperability such as OVSDB and a unicast
approach to VXLAN tunnel creation while others are offering
new protocols such as OpFlex, GENEVE, NVo3, MPLSoGRE,
etc. ONUG is very concerned about this lack of interoperability
and the implications it will have on next generation designs.
</quote>

You can get the document from here:
http://opennetworkingusergroup.com/onug-white-paper/

Anoop

---

From: Alia Atlas <[email-masked]>
Date: Thu, 24 Jul 2014 21:40:48 -0400

Anoop,

Thanks for the pointer.  I would certainly be delighted if NVO3 can quickly
agree on and solidify a good solution or even, if need be, two (for
experimental).

Alia

On Thu, Jul 24, 2014 at 7:57 PM, Anoop Ghanwani <[email-masked]>
wrote:

> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3
>
>

---

From: Sharon Barkai <[email-masked]>
Date: Fri, 25 Jul 2014 09:08:24 +0000

Anoop, what you describe is very true and is must be a result of perceived standardization vacuum.

NVO3 is in a position to fix this because it is not already "in love" with a specific information distribution mechanics - Rather it can phrase the NVA information that needs to be globally available in a form of Schema,

For example: given that all vendors use overlay tunnels, simply state in a Schema, per given end point identity (IP or MAC), on which tunnel destination IP is it. We can differ for later discussion the push, or on-demand pull mechanics used to distribute this. At least it will be clear first what is it we want to obtain in NVEs from the NVA.

This adds to the mic discussion regarding the various Gateways people rightfully start to specify. Gateways which are special NVEs that lead out of the NVO.

We can state the information Schema needed to support these gateways like their IP, the protocols to the outside they support eg any-cast, bridging, BGP, etc so the other NVEs can use them. Same goes for OEM KPI data stored by the NVA, populated and used by NVEs, orchestration etc.

Once we have defined the above using which ever table language, we can examine Schema comparability between all the solutions out there, in any case Schema keeps evolving, And we also supplement push / pull mechanics for setting / getting that data. At least we will know what it is we want to be known across the overlay, any overlay, using the underlay based NVA control.

Together with encapsulation specs and selection - which can also be available per NVE IP as a Schema, we can achieve vendor interoperability and base for evolution eg NVEs which are Gateways,  NVEs which are SFFs, NVEs which are RTRs etc.

Sorry for the long note - IETF jet lag:)

--szb

On Jul 24, 2014, at 7:57 PM, "Anoop Ghanwani" <[email-masked]<mailto:[email-masked]>> wrote:

One of the comments I made at the mic in response to some of the WG reorganization statements was that the user community is complaining about lack of standards.

The reference I would like to point folks to is the following whitepaper from ONUG:
<quote>

Anoop
_______________________________________________
nvo3 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/nvo3