Hi Loa, There actually are some nuggets in the document but you have to look hard for them. E.g. section 4.2 analyzes TDM PWs and states that even within the IETF the exact same situation has arisen before, and three solutions have been specified. However, the IETF made one of them the default solution, so at least there is a baseline type to use and interoperability is guaranteed. If the IETF has gone down that particular path, then I don't see a reason why we cannot do the same thing again (yes, yes I know it is not optimal, I wish life was simple but I was recently convinced of the opposite). The document makes another good point in this regard: the party that is not using the default needs to bear all the cost (operational and such) which is a good point to make. This whole situation right now feels like some sort of attrition warfare and I don't think it is efficient use of our time. 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 13:51 > To: Rolf Winter > 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 > > Rolf, > > I don't remember saying the "sole purpose", the IETF way is to document > requirements, specifications, processes and agreements in RFCs; this is > just another document in this tradition. ANd as such a very good > document. > > /Loa > > On 2011-10-05 13:31, Rolf Winter wrote: > > 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 > > -- > > > 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