If we could go with that direction (evolve encap and control plane independently), the WG could narrow down to some specific design. I raised similar question on the list ( http://www.ietf.org/mail-archive/web/nvo3/current/msg00574.html) before, and the tenant identifier design is a key point. In current NVO3 framework draft, section 3.1.3, the tenant identifier could be globally unique (e.g, VLAN) or local vaue (e.g, MPLS). If the tenant identifier is an MPLS label, different control plane interoperation will be much more complex, which will make it hard to evolve encap and control plane independently.
Lizhong > > -----From Martin Casado <[email protected]>, on Thu, 30 Aug > 2012 10:14:34 -0700 ----- > > To: > > Somesh Gupta <[email protected]> > > CC: > > "smith, erik" <[email protected]>, "[email protected]" <[email protected]>, > David LE GOFF <[email protected]>, "Ayandeh, Siamack" <siamack. > [email protected]> > > Subject: > > Re: [nvo3] performance limitations with virtual switch as the nvo3 end point > > Absolutely agree. Encaps will evolve with the problem space, the > ecosysten of end points, and the deployment environments. > Cleanly defining the abstractions between encap and control plane > allow each to evolve independently. > On Aug 30, 2012 9:37 AM, "Somesh Gupta" <[email protected]> wrote: > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
