Hi Loa, Let me answer with a counter-question. If the sole purpose of this document is to stop the development of two OAM solutions, do you think this RFC-to-be will achieve that? Seriously? The problem I see here is that we start a habit of writing "politically" motivated documents. We have this issue documented already all over the place in the form of minutes, web sites, press releases etc. I think this is enough and the right place. Let the I* and liaisons figure this out so that we all can go back to protocol design and development. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 > -----Original Message----- > From: Loa Andersson [mailto:loa@xxxxx] > Sent: Mittwoch, 5. Oktober 2011 12:48 > To: ietf@xxxxxxxx; 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) > to Informational 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-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf > Of > >> Brian E Carpenter > >> Sent: Freitag, 30. September 2011 21:48 > >> To: huubatwork@xxxxxxxxx > >> Cc: ietf@xxxxxxxx > >> 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@xxxxxxxx > >> https://www.ietf.org/mailman/listinfo/ietf > > _______________________________________________ > > Ietf mailing list > > Ietf@xxxxxxxx > > https://www.ietf.org/mailman/listinfo/ietf > > -- > > > Loa Andersson email: loa.andersson@xxxxxxxxxxxx > Sr Strategy and Standards Manager loa@xxxxx > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf