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]; [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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
