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@xxxxxxxx [mailto:mpls-bounces@xxxxxxxx] On Behalf Of > erminio.ottone_69@xxxxxxxxx > Sent: Wednesday, July 13, 2011 1:27 PM > To: david.i.allan@xxxxxxxxxxxx; RCosta@xxxxxxxxxxxxx; ietf@xxxxxxxx; > IETF-Announce > Cc: mpls@xxxxxxxx > 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@xxxxxxxxxxxx > >Data: 6-lug-2011 20.24 > >A: "erminio.ottone_69@xxxxxxxxx"<erminio.ottone_69@xxxxxxxxx>, > "RCosta@xxxxxxxxxxxxx"<RCosta@xxxxxxxxxxxxx>, > "ietf@xxxxxxxx"<ietf@xxxxxxxx>, > "IETF-Announce"<ietf-announce@xxxxxxxx> > >Cc: "mpls@xxxxxxxx"<mpls@xxxxxxxx> > >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@xxxxxxxx > https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf