The JWT report is aligned with my statement. 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). 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. 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. >----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
