Feng, I'm not sure how to parse this, but personal attacks on ietf mailing should at least be substantiated with evidence.
Like been said before we discuss thing over and over and come to an working group or IETF consensus call, and then the discussion starts over again. /Loa On 2011-10-05 13:58, HUANG Feng F wrote: > 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
