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 protected]<mailto:[email protected]>> 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> 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 _______________________________________________ nvo3 mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
