Hi, Kiran, I would assume that it is possible to support NVO3 deployment and management if each overlay uses only one encapsulation protocol. The issue is deploying a single overlay using multiple protocols - that's where things get difficult, if not impossible. It is more challenging to deal with heterogeneity - the OAM system would need to discover capabilities and deploy overlays only where there was a common subset, or match the capabilities available to the user/operator provided constraints.
That's basically how we addressed this issue in the X-Bone overlay deployment system. It supported different encapsulations (IPv4, IPv6, IPv4 with IPsec, IPv6 with IPsec), but each overlay system deployed used only one encapsulation throughout. Users/operators indicated requirements that mapped directly to encapsulation configurations and we had a secure capability discovery system where "invitations" asked for particular capabilities and only nodes willing to participate responded. I'm not sure how much of this maps to a more modern OAM system, but it seems to me that this is an example that heterogeneous encaps protocols can be supported usefully without too much difficulty, - again, as long as each overlay is homogenous. Joe On 10/7/2016 3:29 PM, Kiran.Makhijani wrote: > > Anoop, Joe > > You are both making interesting points about capability negotiation, > leading to this question for the group –Is it even feasible to proceed > with OAM or control plane activity without assuming (or referring to) > any base encap? > > Thanks > > Kiran > > > > *From:*nvo3 [mailto:[email protected]] *On Behalf Of *Joe Touch > *Sent:* Friday, October 07, 2016 8:37 AM > *To:* Anoop Ghanwani <[email protected]> > *Cc:* Sam Aldrin <[email protected]>; Bocci, Matthew (Nokia - GB) > <[email protected]>; NVO3 <[email protected]>; Lucy yong > <[email protected]>; Alia Atlas <[email protected]> > *Subject:* Re: [nvo3] Discussion on encapsulation formats and next steps > > > > 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] > <mailto:[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] > <mailto:[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
