If they are "ships in the night" it doesn't matter. If they interconnect, you either have to know how to translate between these to sets of capabilities or fail. Using the common subset of the two means turning off some of the features, which avoids translation failures only if it can be negotiated (and both sides agree).
This is a rehash of how internetworking already deals with heterogeneity. Joe > On Oct 7, 2016, at 8:13 AM, Anoop Ghanwani <[email protected]> wrote: > > Joe, > > What happens when we have encap 4 and one DC uses 10 options and the other > one uses on one? > > Anoop > >> On Fri, Oct 7, 2016 at 7:44 AM, Joe Touch <[email protected]> wrote: >> >> >> On 10/6/2016 9:58 AM, Anoop Ghanwani wrote: >> > The obvious way to handle multiple DCs with different encap is to use >> > a gateway. The simplest gateway would terminate one encap domain and >> > start another. OAM, etc. would work within a domain. To work across >> > domains, OAM would have to be run at a higher layer. This is not too >> > much different than, e.g., mapping from 802.1ah/PBB to MPLS. >> > >> > Running multiple encaps within a single DC would be done under >> > supervision of the NVA. The NVA would keep track of which NVEs are >> > capable of a given encap and make sure that a given encap is used only >> > when both the source and destination NVEs can support it. >> > >> > It adds complexity but the problems are not insurmountable. >> >> You are assuming that the semantics of different encapsulations are >> compatible (MTU, fragmentation, signalling, options), and essentially >> describing a translation gateway internetworking model. That model was >> replaced by a layered model using one overarching service (IP) for a >> reason. >> >> Let's please not reinvent the failed percursors to the Internet. >> >> Joe >
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
