Very much agree with Joel and Rob. A few of us had the same concern for a long time, diff. type of DC focus drives diff. problems statement, diff. req. It does not scale, nor efficient to progress when trying to pack all very diff. approached into the same doc, be it PB statement, framework, requirement... We discussed this concerns off-line with some folks before and after the Taiwan meeting where nvo3 and vpn4dc were first discussed.
Luyuan > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Robert Raszuk > Sent: Monday, July 02, 2012 12:45 PM > To: Joel M. Halpern > Cc: Pedro Roque Marques; [email protected] > Subject: Re: [nvo3] inter-CUG traffic [was Re: call for adoption: > draft-narten-nvo3-overlay-problem-statement-02] > > > To me it seems rather clear that going for _single_ NVO3 solution to > accommodate partial pieces of various (apparently very different) > requirements to only enforce that we all must be on the same single bus > is rather a poor choice. > > Best, > R. > > > There are clear data center architectures, and data center > deployments, > > where optimal inter-subnet routing is important. Equally clearly, > there > > are cases where bouncing everything off the gateway is sufficient. > And > > cases in between. > > > > It seems to me that the framework and problem statement efforts > should > > not mandate that one particular point on that spectrum is a MUST for > all > > NVO3 solutions. > > > > Yours, > > Joel > > > > On 7/2/2012 10:52 AM, Robert Raszuk wrote: > >> Hi Joel, > >> > >>> So I was urging that we not mandate optimal inter-subnet routing as > part > >>> of the NVO3 requirements. > >> > >> If my customers who happen to try my standards based offering to run > >> their 3-tier applications will perform their application level > >> measurements (and trust me - all of them do it these days) and find > that > >> my competition offers more optimal data plane results via non > standard > >> solution - I will likely loose those customers. > >> > >> While in L2 VNs going via some randomly placed gateway may be ok in > L3 > >> services I am afraid the bar is already much higher today. That > actually > >> is one good reason to decouple NVO3 requirements for L2 and L3 VN > >> services and address them separately. > >> > >> Thx, > >> R. > >> _______________________________________________ > >> nvo3 mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/nvo3 > >> > > > > _______________________________________________ > > nvo3 mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/nvo3 > > > > > > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
