HI Thomas: 2012-07-02, David Allan I: >> >> As the latest edition of 802.1Q (2011) embodies most recent amendments >> .1ad, .1ag., .1ah etc.) , that is not really going to help. And >> referring to an older edition will simply perpetuate the >> problem...folks will not get the subtlety....
>What would you suggest as a reference to designate plain VLAN tagging, which >most people refer to as dot1q ? Unfortunately there is no obvious reference. >> As for the etiquette of crapping on another SDO's older technology... >> I have issue with that as this is really marketing not technology. It >> does not pass the sniff test. >For sure documenting the motivations for NVO3 would require keeping it >factual. It would be hard to do without, for instance, mentioning the 4k >limits of >plain VLAN tagging ; but we can agree this would not equate to >saying that the 802.1Q 2011 is "crap". >Or we could also choose to not document the motivations... I'd prefer the latter. A technology neutral description of the requirements should be sufficient. Cheers Dave > -----Original Message----- From: [email protected] > [mailto:[email protected]] On Behalf Of [email protected] > Sent: Monday, July 02, 2012 6:19 AM To: [email protected] Subject: Re: > [nvo3] call for adoption: draft-lasserre-nvo3-framework-02 / > limitations of "Ethernet" > > Hi all, > > This is good: the right place to explain the motivation for NVO3 > really should be the problem statement draft, since the framework > draft essentially aims at framing the terminology and spelling out the > concepts. > > Now, it can be useful to document the limitations (both the real and > the perceived ones) of Ethernet that contributed to motivate people to > seek an overlay solution. Reflecting this requires looking at what is > most largely deployed ; this is the intent for some people when they > say "Ethernet". For some others "Ethernet" is an 802.1-wildcard, > including more recent, less used improvements. I think that a > reasonable approach would be to avoid "Ethernet" as an ambiguous > label, and word motivation about NVO3 that relate to Ethernet, in > terms of specific pieces of Ethernet, e.g. 802.1q. > > -Thomas > > > LASSERRE, MARC (MARC) a écrit : >> Eric, Thanks. I'm fine with this proposal. I will remove the >> limitiations listed in the introduction. The introduction will be >> revised to be as follows: *Introduction* >> >> This document provides a framework for Data Center Network >> Virtualization over L3 tunnels. This framework is intended to aid in >> standardizing protocols and mechanisms to support large scale network >> virtualization for data centers. >> >> Several IETF drafts relate to the use of overlay networks for data >> centers. >> >> [NVOPS] defines the rationale for using overlay networks in order to >> build large data center networks. The use of virtualization leads to >> a very large number of communication domains and end systems to cope >> with. [OVCPREQ] describes the requirements for a control plane >> protocol required by overlay border nodes to exchange overlay >> mappings. >> >> This document provides reference models and functional components of >> data center overlay networks as well as a discussion of technical >> issues that have to be addressed in the design of standards and >> mechanisms for large scale data centers. >> >> Marc >> >> --------------------------------------------------------------------- >> --- >> >> *From:* Eric Gray [mailto:[email protected]] >> *Sent:* Friday, June 29, 2012 9:43 PM *To:* LASSERRE, MARC (MARC) >> *Cc:* [email protected] *Subject:* Re: [nvo3] call for adoption: >> draft-lasserre-nvo3-framework-02 >> >> Marc, Let's not try to make something hard out of this. Janos >> suggested that certain statements made in your draft are not >> particularly true (or applicable) if existing standard capabilties >> have been deployed. You responded (paraphrasing) that - while this is >> true - there are networks where these capabilities are not part of >> the layer-2 deployment, and there are customers who would prefer a >> layer-3 solution. So far, I have no gripe with this. However, Joel >> points out that the current wording makes it appear that the driving >> justification for doing this work in layr-3 is that existing layer-2 >> standards/solutions won't work. He further points out that this is >> not consistent with your own admission that there are well-known >> layer-2 standards/solutions that address the limitations you list. >> Apparently, it was not your intent to make it sound this way. Without >> going line by line through the introduction, the general changes >> required to bring what you are saying back into alignment with what >> we all apparently agree is the case are relatively obvious and >> simple. 1) The simplest change would be to remove the statements >> about layer-2 limitations as Janos has suggested. I think we all >> understand why perhaps this is not the way you want to go. Fine. 2) >> If you are going to list the limitations that you now list, you need >> to make it clear these are "perceived" limitations based on currently >> deployed layer-2 networking technology, /*in some networks*/. 3) If >> one of the key reasons why we want to define a layer-3 solution is >> that there is a demand from customers for a layer-3 solution, simply >> say /*that*/ rather than giving inaccurate second-hand information >> about "perceived" reasons for this preference based on out-of-date >> layer-2 deployments. Does this help? -- Eric >> >> >> >> _______________________________________________ nvo3 mailing list >> [email protected] https://www.ietf.org/mailman/listinfo/nvo3 > > > ______________________________________________________________________ > ___________________________________________________ > > 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 > _________________________________________________________________________________________________________________________ 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
