Italo, Comments inline. Thanks, John Sent from my iPhone > -----Original Message----- > From: erminio.ottone_69@libero.it [mailto:erminio.ottone_69@libero.it] > Sent: Wednesday, July 13, 2011 2:04 PM > To: John E Drake; david.i.allan@ericsson.com; RCosta@ptinovacao.pt; > ietf@ietf.org; IETF-Announce > Cc: mpls@ietf.org > Subject: R: RE: [mpls] R: RE: R: Re: Last Call: <draft-ietf-mpls-tp-cc- > cv-rdi-05.txt> (Proactive Connectivity Verification, Continuity Check > and Remote Defect indication for MPLS Transport Profile) to Proposed > Standard > > The JWT report is aligned with my statement. JD: As SG15 management is fond of pointing out, when it suits them, the JWT operated on a very compressed time scale and didn't fully explore all of the technical issues > > The decision at IETF75 has been taken by the MPLS WG after the JWT and > has > never been endorsed by ITU-T (Huub is NOT ITU-T and, as far as I > understood, he > later removed his name because the other editors of the OAM Analysis > draft were > not considering his input to the document). JD: I'm not sure what your point is > > The BFD-based solution accepted by IETF75 for pro-active CC/CV/RDI was > completely different (and technically much superior) than the one > described by > this draft. JD: Obviously we disagree > > Accepting a solution that meets the requirements does not mean signing > a blank > cheque that whichever changes is done is acceptable regarless whether > it meets > or not the requirements. JD: The requirements as documented in RFCs 5654, 5860, and 5951, or the requirements that seem to change based upon the phases of the moon? > > >----Messaggio originale---- > >Da: jdrake@juniper.net > >Data: 13-lug-2011 22.46 > >A: "erminio.ottone_69@libero.it"<erminio.ottone_69@libero.it>, > "david.i. > allan@ericsson.com"<david.i.allan@ericsson.com>, "RCosta@ptinovacao.pt" > <RCosta@ptinovacao.pt>, "ietf@ietf.org"<ietf@ietf.org>, "IETF- > Announce"<ietf- > announce@ietf.org> > >Cc: "mpls@ietf.org"<mpls@ietf.org> > >Ogg: RE: [mpls] R: RE: R: Re: Last Call: <draft-ietf-mpls-tp- > cc-cv-rdi-05. > txt> (Proactive Connectivity Verification, Continuity > Check and Remote > Defect indication for MPLS Transport Profile) to Proposed > Standard > > > >Italo, > > > >The design team report > (http://www.ietf.org/proceedings/75/slides/mpls- > 17/mpls-17_files/frame.htm), with Huub's name as an author, details a > plan for > MPLS-TP OAM which the MPLS WG has followed to this day. I think the > report is > compelling evidence that the claim that a packet transport network is > an MPLS > application that intrinsically requires a different OAM solution is > simply a > lame ex post facto attempt to justify the ITU's abrogation of the > agreement > with the IETF (TD07 (WP3/SG15) from December 2008 sourced by SG15): > > > >"The ITU-T accepts these recommendations and states that any > extensions to > MPLS technology will be progressed via the IETF standards process using > the > procedures defined in RFC 4929 (Change Process for Multiprotocol Label > Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and > Procedures). > Experts from the ITU-T will assist the IETF in the development of RFCs > that > describe the transport extensions by providing input to and review of > the > drafts as they are progressed via the IETF standards process.. The ITU- > T will > develop new or revised Recommendations that will allow IETF MPLS-TP to > be > integrated into the transport network including integration with the > existing > equipment, and operations infrastructure. These Recommendations will > make > normative references to the base IETF MPLS-TP technology and will be > developed > with input from and review by experts from the IETF to ensure > consistency with > MPLS-TP... > > > >The ITU-T has accepted the proposals from the JWT and we look forward > to > continuing the cooperative development of IETF MPLS to address the > needs of the > transport network. We also believe that this resolution will fulfil the > mutual > goal of improve the functionality of the internet and transport > networks and > guaranteeing complete interoperability and architectural soundness." > > > >Thanks, > > > >John > > > >Sent from my iPhone > > > >> -----Original Message----- > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > >> erminio.ottone_69@libero.it > >> Sent: Wednesday, July 13, 2011 1:27 PM > >> To: david.i.allan@ericsson.com; RCosta@ptinovacao.pt; ietf@ietf.org; > >> IETF-Announce > >> Cc: mpls@ietf.org > >> Subject: [mpls] R: RE: R: Re: Last Call: <draft-ietf-mpls-tp-cc-cv- > rdi- > >> 05.txt> (Proactive Connectivity Verification, Continuity Check and > >> Remote Defect indication for MPLS Transport Profile) to Proposed > >> Standard > >> > >> >However this is a consequence of adapting an existing technology to > a > >> new > >> application. I do not see any way around that. And the entire joint > >> project was > >> based on the premise of engineering re-use not greenfield design. > That > >> is what > >> it said on the tin up front, and IMO why when the IETF started down > >> this path > >> packet transport transitioned from being a minority sport to > >> mainstream, so it > >> is a bit late to cry foul.... > >> > >> This is not what the IETF has committed to deliver to ITU-T and in > fact > >> slide > >> 44 postpones to the OAM design phase "decide whether LSP-Ping or BFD > >> can or > >> should be tweaked or not" and slide 46 reckons "many options > including > >> non IP > >> BFD is an option encapsulation of Y.1731 PDU" > >> > >> It seems to me after having read the draft and followed this very > long > >> thread > >> that tweaking BFD is not the right approach to meet ITU-T > requirements > >> so it > >> would be worth evaluating the other alternative considered viable by > >> the JWT > >> which is encapulating Y.1731 PDUs. > >> > >> >----Messaggio originale---- > >> >Da: david.i.allan@ericsson.com > >> >Data: 6-lug-2011 20.24 > >> >A: "erminio.ottone_69@libero.it"<erminio.ottone_69@libero.it>, > >> "RCosta@ptinovacao.pt"<RCosta@ptinovacao.pt>, > >> "ietf@ietf.org"<ietf@ietf.org>, > >> "IETF-Announce"<ietf-announce@ietf.org> > >> >Cc: "mpls@ietf.org"<mpls@ietf.org> > >> >Ogg: RE: [mpls] R: Re: Last Call: <draft-ietf-mpls-tp-cc-cv- > rdi- > >> 05.txt> > >> (Proactive Connectivity Verification, Continuity Check > and > >> Remote Defect > >> indication for MPLS Transport Profile) to Proposed Standard > >> > > >> >Hi Erminio: > >> > > >> ><snipped> > >> >>Several service providers regarded this draft as not meeting their > >> >>transport networks' needs. > >> > > >> >E> This is a true statement: the solution in this draft is useless > for > >> many > >> MPLS- TP deployments. > >> > > >> >The two statements do not necessarily follow. > >> > > >> >What we established during discussions at the SG15 plenary in > February > >> was > >> that the issue some service providers had was that the IETF BFD > >> solution > >> exceeded their requirements in that there was additional > functionality > >> they did > >> not see a need for, and that they considered any additional > >> functionality > >> parasitic. > >> > > >> >However this is a consequence of adapting an existing technology to > a > >> new > >> application. I do not see any way around that. And the entire joint > >> project was > >> based on the premise of engineering re-use not greenfield design. > That > >> is what > >> it said on the tin up front, and IMO why when the IETF started down > >> this path > >> packet transport transitioned from being a minority sport to > >> mainstream, so it > >> is a bit late to cry foul.... > >> > > >> >My 2 cents > >> >Dave > >> > > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > > > _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
