Can we refer to the "limitations of a single 12 bit VLAN tag" if we find it necessary to discuss it? That would make clear what limitations we were discussing.
I would be much happier ;-) Dave -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Thomas Narten Sent: Monday, July 09, 2012 10:54 AM To: [email protected] Cc: [email protected] Subject: Re: [nvo3] overlay benefits section: [was: Re: call for adoption: draft-narten-nvo3-overlay-problem-statement-02 / section 3.2] Hi Thomas. > By and large, this idea of a global VNID carried in the dataplane > looks to me as quite orthogonal to the explanation of the benefits of > an overlay solution. OK. > I think the text should go straight to the fact that using an overlay > allows to build a large enough number of virtual network instances > independently of current VLAN size limitation. This is true whether a > globally significant or locally significant id is used, so that aspect > is I think better to kept out of that section. OK. How about: The use of a sufficiently large VNID would eliminate current VLAN size limitations. This VNID can be carried in the data plane along with the packet. Adding an overlay header provides a place to carry this VNID. > > Communication between devices attached to a virtual network > > and devices connected to non-virtualized networks is handled > > architecturally by having specialized gateway devices that > > receive packets from a virtualized network, process them as > > appropriate, and forward them on to non-virtualized networks > > (and vice versa). A simple implementation could do as little > > as forward packets to/from a virtual network, while more > > sophisticated gateways could include full router > > functionality, load balancing or firewall support, etc., or > > have the overlay encapsulation/decapsulation functionality > > implemented with hardware assist for efficiency. > The above does not reflect the fact that external networks can also be > virtualized, and that part of the problem of designing NVO3 is so that > mapping an NVO3 virtual network to an external virtual network can be > efficient, ie. better than a VLAN-based intermediate handoff. Are you talking specifically about the case of having a single device take NVO3 traffic on (say) one interface and send it out on another (different) virtualized network (e.g., a VPN), all in one device? That's (IMO) clearly allowed and expected to be supported. Are you asking that this example be made explicitely in the text? I.e., you don't want to require the use of an L2 hop using VLANs. I agree, but also think that is clearly allowed by the sentence you quote. Thomas _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
