Hi Thomas, 2012-07-05, Thomas Narten: >>> The use of a large (e.g., 24-bit) VNID would allow 16 million >>> distinct virtual networks within a single data center, eliminating >>> current VLAN size limitations. This VNID needs to be carried in the >>> data plane along with the packet. Adding an overlay header provides >>> a place to carry this VNID. >> >> I find the above very misleading, since you can very much achieve the >> same result without having a "large" 24-bit VNID in the dataplane. > > how about s/needs to be carried/can be carried/ > > I expect we agree that a globally significant VNID could be carried > end to end in this manner. And I say "can" not "must", as I agree > there are other possible approaches (i.e., a locally significant > one could be carried as well).
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. 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. >>> External communications (from a VM within a virtual network instance >>> to a machine outside of any virtual network instance, e.g. on the >>> Internet) is handled by having an ingress switch forward traffic to >>> an external router, where an egress switch decapsulates a tunneled >>> packet and delivers it to the router for normal processing. This >>> router is external to the overlay, and behaves much like existing >>> external facing routers in data centers today. > >> If this is all we'll achieve with NVO3, then I certainly wouldn't put it >> in a section called "benefits of overlays", but rather in a section >> called "Drawbacks of NVO3"... > > Well, the context of the text you quote was explaining how things > work. I.e., having an isolated VN unable to talk to the outside world > doesn't seem particularly useful... > > That said, I can move this all into 2.7 " Support Communication > Between Virtual and Traditional Networks" I would agree with this change. >> I think the problem statement should insist on the >> feasibility of efficient interworking with external networks. Being >> limited to an architecture where a box "decapsulates NVO3" to some VLAN >> toward another box which then has to map this VLAN in the proper >> context, will actually be a pain to manage. The provisioning efficiency >> brought by NVO3 is also needed for these interconnects, and the problem >> statement should I think reflect this: the problem statement should >> include the ability to terminate NVO3 directly on a router. > > Re your last point, how about the following text for 2.7: > > <section title="Support Communication Between Virtual and > Traditional Networks"> > <t> > Not all communication will be between devices connected to > virtualized networks. Devices using overlays will continue > to access devices and make use of services on traditional, > non-virtualized networks, whether in the data center, the > public Internet, or at remote/branch campuses. Any virtual > network solution must be capable of interoperating with > existing routers, VPN services, load balancers, intrusion > detection servics, firewalls, etc. > </t> > > <t> > 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. > </t> 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. -Thomas _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
