Hi Paul, We are all in agreement here.
The best approach is to not get into specific details (I agree that the orginal text was misleading - even if it was not the intent). Hopefully, the newly suggested introduction will be satisfactory to everybody. Marc ________________________________ From: Paul Unbehagen [mailto:[email protected]] Sent: Friday, June 29, 2012 11:18 PM To: AshwoodsmithPeter Cc: Eric Gray; LASSERRE, MARC (MARC); [email protected] Subject: Re: [nvo3] call for adoption: draft-lasserre-nvo3-framework-02 I have personally seen numerous DC's deployed over the last year that have used SPB to create an end to end Ethernet underlay to solve many of the problems that nvo3 is also trying to fix with overlays. VM's are moving across cities transparently to the IP layer above in both single and multi-tenant environments. Obviously some customers may want an overlay for other reasons, but Janos' points are correct. Marc, perhaps if the text on Ethernet capabilities was updated to reflect what is possible today, it will clear up the confusion. -- Paul Unbehagen Sent from my iPad On Jun 29, 2012, at 2:33 PM, AshwoodsmithPeter <[email protected]<mailto:[email protected]>> wrote: Agreed, I think that stating that those limitiations apply to all "Existing virtual network models used for data center networks" is perhaps a bit sweeping and could use a bit of qualification otherwise its untrue. Peter ________________________________ From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Eric Gray Sent: Friday, June 29, 2012 3:43 PM To: Marc Lasserre Cc: [email protected]<mailto:[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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
