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
