I think it is inappropriate to start marketing Brocade's products and comparing their superiority to some other vendor's products. And it would not make sense for me to explain how our products fit into today's and tomorrow's data centers and how they will evolve.
And I agree that the NVE will be located in some instances in network devices. And I have raised the issue in nv03 that the control plane in a software driven data center will be primarily centralized. I was once again, it seems futilely, hoping for activity that is more effective. Regards Somesh > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Xuxiaohu > Sent: Thursday, November 29, 2012 7:16 PM > To: Somesh Gupta; Lucy yong; Shahram Davari; Daniel King > Cc: [email protected]; [email protected]; mpls- > [email protected]; [email protected] > Subject: Re: [nvo3] [mpls] MPLS-RT review of draft-xu-mpls-in-udp-03 > > Somesh, > > > -----邮件原件----- > > 发件人: Somesh Gupta [mailto:[email protected]] > > 发送时间: 2012年11月30日 10:09 > > 收件人: Lucy yong; Shahram Davari; Daniel King > > 抄送: [email protected]; [email protected]; > > [email protected]; [email protected] > > 主题: RE: [mpls] MPLS-RT review of draft-xu-mpls-in-udp-03 > > > > Standardization that ignores how Software Driven Data Centers will be > > provisioned and managed may be just an academic exercise. The > existing > > solution from Nicira, Vmware and Microsoft do point to the general > > direction in which the virtual network solution will move. > > As for where is the right location for NVE(Network Virtualization > Edge), the current NVo3 WG consensus is the NVE can be located either > on network devices or on servers. If you have any different opinion, I > suggest you go to the NVo3 to argue for that. By the way, did you doubt > about the correctness of Brocade's pursuing of TRILL? > > > While some existing networking protocols do provide similar > functionality, > > they assume a different operating environment - distributed > intelligence, > > autonomous systems, inability to manage centrally. > > > > The Software Driven Data Center will be centrally provisioned and > > managed. We can come up with the IETF standards, but unless they > > serve that model in a simple manner, we will be disappointed with > > their adoption by the folks who own the orchestration and management > > software. > > As for this regard, The NVo3 WG consensus is " A control/management > plane entity can be centralized or distributed" (refer to NVo3 > framework draft for more details). If you have any different opinion in > this regard, I suggest you go to the NVo3 to argue for that as well. > > In a word, the above arguments you mentioned is so HUGE that it should > be submitted to the NVo3 WG or even the IETF plenary meeting for > discussion. > > Xiaohu > > > Somesh > > > > > -----Original Message----- > > > From: [email protected] [mailto:[email protected]] On > Behalf Of > > > Lucy yong > > > Sent: Thursday, November 29, 2012 12:21 PM > > > To: Shahram Davari; Daniel King > > > Cc: [email protected]; [email protected]; mpls- > > > [email protected]; [email protected] > > > Subject: Re: [nvo3] [mpls] MPLS-RT review of draft-xu-mpls-in-udp- > 03 > > > > > > Shahram, > > > > > > That is the point. The draft helps to extend VPN solution into DCs > for > > > NVO without implementing MPLS in DC. MPLS VPN solution has been > > > standardized and deployed widely for long time. > > > > > > Regarding your second point, no matter you like or dislike, it > already > > > happens in other WGs. Let's focus on the technical merit here > rather > > > than politics. > > > > > > Lucy > > > > > > > -----Original Message----- > > > > From: [email protected] [mailto:[email protected]] On > Behalf > > > Of > > > > Shahram Davari > > > > Sent: Thursday, November 29, 2012 12:17 PM > > > > To: Lucy yong; Daniel King > > > > Cc: [email protected]; [email protected]; mpls- > > > > [email protected]; [email protected] > > > > Subject: Re: [mpls] MPLS-RT review of draft-xu-mpls-in-udp-03 > > > > > > > > Lucy, > > > > > > > > As far as I know data center operators don't like MPLS and that > is > > > why > > > > the core of Data center is mostly IP (or L2) and not MPLS. As > you > > > > mentioned there is no standard solution, but there are many de- > facto > > > > standards such as NVGRE and VXLAN, which are already in silicon. > > > > > > > > I think you should take this argument to NVo3 WG and get their > > > blessing > > > > for your solution before indirectly submitting yet another > solution > > > to > > > > the same problem to MPLS WG. IETF as a whole should decide on > one > > > > preferred solution. > > > > > > > > > > > > > > > > Thanks > > > > Shahram > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Lucy yong [mailto:[email protected]] > > > > Sent: Thursday, November 29, 2012 8:33 AM > > > > To: Shahram Davari; Daniel King > > > > Cc: [email protected]; [email protected]; mpls- > > > > [email protected] > > > > Subject: RE: [mpls] MPLS-RT review of draft-xu-mpls-in-udp-03 > > > > > > > > Hi Shahram, > > > > > > > > Let me share my opinion on this. Please see inline. > > > > > > > > > -----Original Message----- > > > > > From: [email protected] [mailto:[email protected]] On > > > Behalf > > > > Of > > > > > Shahram Davari > > > > > Sent: Monday, November 26, 2012 11:10 PM > > > > > To: Daniel King > > > > > Cc: [email protected]; [email protected]; mpls- > > > > > [email protected] > > > > > Subject: Re: [mpls] MPLS-RT review of draft-xu-mpls-in-udp-03 > > > > > > > > > > Hi, > > > > > > > > > > In my opinion this is a solution to a problem that has a dozen > > > other > > > > > solutions such as NVGRE, VXLAN, OTP, STT, etc. > > > > [Lucy] is any of them standardized? do we want any BIG company to > > > > implement one solution ahead and then tell the industry to follow > it > > > > without going through a standardization? What is the purpose of > IETF? > > > > > > > > > > > > > > So I wonder why MPLS WG should spend its valuable time working > on > > > yet > > > > > another solution. > > > > [Lucy] IMO: because MPLS and VPN are widely technologies in WAN > > > space. > > > > The VPN technology is very close to network virtualization > overlay > > > > vision in DC except current solution is tied into MPLS > implementation > > > > slightly, which makes overlay network (MPLS client layer) couples > > > with > > > > underlying network (MPLS server layer). DC NVO requires to > decouple > > > > overlay network from underlying network. We want to leverage VPN > > > > technology into DC NVO instead of redesigning a full set of VPN > > > > features for DC NVO. > > > > > > > > In fact, the solution is very simple and requires no change to > the > > > > transit nodes while MPLS client layer can decouple from the MPLS > > > server > > > > layer. I don't think that it will take a lot of WG time to work > out > > > the > > > > solution. If you think that it will, please point out where is > the > > > > complexity in the solution? > > > > > > > > Regards, > > > > Lucy > > > > > > > > > > Regards, > > > > > Shahram > > > > > > > > > > > > > > > On Nov 26, 2012, at 12:48 PM, "Daniel King" > <[email protected]> > > > > wrote: > > > > > > > > > > > Hi All, > > > > > > > > > > > > As requested, I have performed an MPLS-TR review of draft-xu- > > > mpls- > > > > in- > > > > > udp-03: > > > > > > > > > > > > http://tools.ietf.org/html/draft-xu-mpls-in-udp-03 > > > > > > > > > > > > Overall the document is well written and the motivation seems > > > clear. > > > > > The > > > > > > proposed solution is technically sound and given the > application > > > of > > > > > > tunneling of MPLS VPNs across IP PSNs, the mechanism does > look to > > > > > bring > > > > > > operational benefits for specific use cases. Therefore I > believe > > > > the > > > > > > document is ready to be considered for WG adoption. > > > > > > > > > > > > Authors, > > > > > > > > > > > > As I was reviewing the draft I jotted down a number of minor > > > > comments, > > > > > these > > > > > > are outlined below. Feel free to use or discard. > > > > > > > > > > > > 1. Authors. The RFC-Editors are requesting no more than 5 > authors > > > > on > > > > > the > > > > > > front-page. So you may as well address this sooner rather > than > > > > later. > > > > > You > > > > > > can look to split into to - Authors and Contributing Authors > (or > > > > just > > > > > > Contributors) to circumnavigate the author limit. > > > > > > > > > > > > 2. You should move the Abstract above the Status of this Memo > > > > section. > > > > > > > > > > > > 3. Perhaps look to expand Abstract to: > > > > > > > > > > > > Existing technologies to encapsulate MPLS over IP are not > > > adequate > > > > > for > > > > > > efficient transport across IP-enabled Packet Switch Networks > > > (PSNs). > > > > > This > > > > > > document specifies an IP-based encapsulation technology for > load- > > > > > balancing > > > > > > MPLS packets across IP PSNs. This mechanism is referred to as > > > MPLS- > > > > > in-UDP. > > > > > > > > > > > > This document defines the protocol extensions and procedures > for > > > > > MPLS-in-UDP > > > > > > and will facilitate transport of MPLS application traffic, > > > > including > > > > > L2VPNs > > > > > > and L3VPNs, across IP-enabled PSNs. > > > > > > << > > > > > > > > > > > > 4. Introduction is ok, but the wall of text requires > splitting > > > into > > > > > separate > > > > > > paragraphs for readability. You could split the introduction > into > > > > > sections > > > > > > (or just additional paragraphs) to help with navigation, no > major > > > > > changes in > > > > > > text are required: > > > > > > > > > > > > 1. Introduction > > > > > > - Contains application/motivation background text. > > > > > > - Intention of the document. > > > > > > > > > > > > 1.1 Existing Technologies > > > > > > - Describes existing techniques (RFC4023, et al.). > > > > > > > > > > > > 1.2 Requirements and Motivation > > > > > > - What the technology or application gaps between prior work > and > > > > this > > > > > > proposal. > > > > > > - Very important to discuss the motivation given that we > already > > > > have > > > > > a > > > > > > number of alternatives. > > > > > > > > > > > > 5. The document mentions "core" a number of times. Is this > really > > > a > > > > > core > > > > > > application or is the mechanism more likely to be applied in > > > > > environments > > > > > > with equipment that does not support native MPLS forwarding? > This > > > > is > > > > > > something you might want to expand on in Section 6 > > > (Applicability) > > > > > and > > > > > > lessen the "core" applicability in other parts of the > document. > > > > Also, > > > > > how > > > > > > applicable is the document to multicast VPNs, any issues? > > > > > > > > > > > > 6. General comment on acronyms. The document expands ECMP but > > not > > > > GRE > > > > > or > > > > > > SAFI, so maybe check document for consistency. > > > > > > > > > > > > Please do not hesitate to email me if anything is not clear. > > > > > > > > > > > > Br, Dan. > > > > > > > > > > > > -----Original Message----- > > > > > > From: Loa Andersson [mailto:[email protected]] > > > > > > Sent: Tuesday, November 13, 2012 9:16 AM > > > > > > To: Gregory Mirsky; Dan King; Eric Osborne (eosborne); > > > > > > [email protected]; [email protected]; Martin > > > > > Vigoureux; > > > > > > [email protected] > > > > > > Subject: MPLS-RT review of draft-xu-mpls-in-udp-03 > > > > > > > > > > > > Greg, Dan, Eric and Nick, > > > > > > > > > > > > You have been selected as an MPLS Review team reviewers for > > > > > > draft-xu-mpls-in-udp-03. > > > > > > > > > > > > Note to authors: You have been CC'd on this email so that you > can > > > > > know that > > > > > > this review is going on. However, please do not review your > own > > > > > document. > > > > > > > > > > > > Reviews should comment on whether the document is coherent, > is it > > > > > useful > > > > > > (ie, is it likely to be actually useful in operational > networks), > > > > and > > > > > is the > > > > > > document technically sound? We are interested in knowing > whether > > > > the > > > > > > document is ready to be considered for WG adoption (ie, it > > > doesn't > > > > > have to > > > > > > be perfect at this point, but should be a good start). > > > > > > > > > > > > Reviews should be sent to the document authors, WG co-chairs > and > > > > > secretary, > > > > > > and CC'd to the MPLS WG email list. If necessary, comments > may be > > > > > sent > > > > > > privately to only the WG chairs. > > > > > > > > > > > > Are you able to review this draft by November 29, 2012? > > > > > > > > > > > > Thanks, Loa > > > > > > (as MPLS WG chair) > > > > > > > > > > > > /Loa > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > Loa Andersson email: > > > > > [email protected] > > > > > > Sr Strategy and Standards Manager [email protected] > > > > > > Ericsson Inc phone: +46 10 717 52 13 > > > > > > +46 767 72 92 > > 13 > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > mpls mailing list > > > > > > [email protected] > > > > > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > > > > > > > > > _______________________________________________ > > > > > mpls mailing list > > > > > [email protected] > > > > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > > > > > _______________________________________________ > > > > mpls mailing list > > > > [email protected] > > > > https://www.ietf.org/mailman/listinfo/mpls > > > _______________________________________________ > > > 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
