Lucy, The problem that I have is that you are trying to standardize a solution to the problem that NVO3 is responsible for in a different WG, without their approval. There are already drafts in NVO3 that address the same problem.
We should not bypass NVO3 and do anything we like in MPLS WG to solve the NVO problem. Otherwise how can IETF ensure interoperability when a WG goes and defines and standardizes its own solution. Regarding Technical merits, all these solutions are technically sound, the issue is that we don't want to have a dozen solution to the same problem. Regards, Shahram On Nov 29, 2012, at 12:21 PM, Lucy yong <[email protected]> wrote: > 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 > _______________________________________________ > mpls mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
