Loa, YES, but there are only someone (not organization-that's a individual draft and MEAD team-not ietf mpls group or ietf group, which has been disbanded by themselves one years ago) make decision to done a single solution! B.R. Feng
-----Original Message----- From: Loa Andersson [mailto:l...@pi.nu] Sent: 2011年10月5日 19:53 To: HUANG Feng F Cc: ietf@ietf.org Subject: Re: Last Call: <draft-sprecher-mpls-tp-oam-considerations-01.txt>(The Reasons for Selecting a Single Solution for MPLS-TP OAM) toInformational RFC Feng, there were only one organization invbolved in the decision to develop two OAM solutions! /Loa On 2011-10-05 13:29, HUANG Feng F wrote: > Dear Loa, > Life is not simple, mpls-tp is joint developed by IETF and ITU-T, so it > is complicated, the decision should be done by two orgnizations. > There are many errors about in this draft as many, for example, Rolf, > Huub, Malcolm, Tom Petch and I, point out in emails, it is a bad draft, it > should be stop. > B.R. > Feng > > > -----Original Message----- > From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf > Of Loa Andersson > Sent: 2011年10月5日 18:48 > To: ietf@ietf.org; Rolf Winter > Subject: Re: Last > Call:<draft-sprecher-mpls-tp-oam-considerations-01.txt>(The Reasons > for Selecting a Single Solution for MPLS-TP OAM) toInformational RFC > > Rolf, > > are you saying that if we just liaise RFC1958 to the ITU-T they will stop > developing a competing OAM for MPLS? > > Sometimes the life is simple, though I doubt that it is this simple. > > My 2c's is that this a good draft and should be progressed. > > /Lao > > On 2011-10-04 11:16, Rolf Winter wrote: >> Hi, >> >> I think Brian makes an excellent point here. RFC 1958 already contains >> exactly the same basic message (just with far less (unnecessary) words). I >> don't think we need this document as it doesn't really add anything to what >> RFC 1958 says. I'll provide a more detailed review later. >> >> Best, >> >> Rolf >> >> >> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, >> London W3 6BL | Registered in England 2832014 >> >> >>> -----Original Message----- >>> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf >>> Of Brian E Carpenter >>> Sent: Freitag, 30. September 2011 21:48 >>> To: huubatw...@gmail.com >>> Cc: ietf@ietf.org >>> Subject: Re: Last Call:<draft-sprecher-mpls-tp-oam-considerations- >>> 01.txt> (The Reasons for Selecting a Single Solution for MPLS-TP >>> OAM) to Informational RFC >>> >>> Huub, >>> >>> On 2011-09-30 20:19, Huub van Helvoort wrote: >>>> All, >>>> >>>> Section 1,1 also contains the text: >>>> [RFC5317] includes the analysis that "it is technically >>>> feasible >>> that >>>> the existing MPLS architecture can be extended to meet the >>>> requirements of a Transport profile, and that the architecture >>> allows >>>> for a single OAM technology for LSPs, PWs, and a deeply nested >>>> network." >>>> >>>> This is a quote from slide 113 in the PDF version of RFC5317 and >>> should >>>> be read in realtion to the statement on slide 12 of the same RFC: >>>> >>>> "This presentation is a collection of assumptions, discussion points >>>> and decisions that the combined group has had during the months of >>>> March and April, 2008 >>>> This represents the *agreed upon starting point* for the technical >>>> analysis of the T-MPLS requirements from the ITU-T and the MPLS >>>> architecture to meet those requirements" >>>> >>>> So the quoted text in the draft is one of the assumptions. >>>> >>>> The fact that there are currently *two* OAM mechanisms (and not a >>>> *single*), i.e. one for PW and one for LSP proves that the >>>> assumption was not correct. >>> >>> I'm sorry, I don't understand your logic. You seem to be saying that >>> the fact that two solutions have been designed proves that the >>> assumption that a single solution is possible was false. That >>> doesn't follow at all. The engineering profession has a long history >>> of producing multiple solutions where a single one was possible, and >>> this seems to be just another such case. >>> >>> This isn't news. I quote from RFC 1958 (June 1996): >>> >>> " 3.2 If there are several ways of doing the same thing, choose one. >>> If a previous design, in the Internet context or elsewhere, has >>> successfully solved the same problem, choose the same solution >>> unless >>> there is a good technical reason not to. Duplication of the same >>> protocol functionality should be avoided as far as possible, without >>> of course using this argument to reject improvements." >>> >>> Brian >>> _______________________________________________ >>> Ietf mailing list >>> Ietf@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf > -- Loa Andersson email: loa.anders...@ericsson.com Sr Strategy and Standards Manager l...@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
