RE: 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 Propose
Italo, Comments inline. Thanks, John Sent from my iPhone -Original Message- From: erminio.ottone...@libero.it [mailto:erminio.ottone...@libero.it] Sent: Wednesday, July 13, 2011 2:04 PM To: John E Drake; david.i.al...@ericsson.com; rco...@ptinovacao.pt; i...@ietf.org; IETF-Announce Cc: m...@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: jdr...@juniper.net Data: 13-lug-2011 22.46 A: erminio.ottone...@libero.iterminio.ottone...@libero.it, david.i. al...@ericsson.comdavid.i.al...@ericsson.com, rco...@ptinovacao.pt rco...@ptinovacao.pt, i...@ietf.orgi...@ietf.org, IETF- Announceietf- annou...@ietf.org Cc: m...@ietf.orgm...@ietf.org Ogg: RE: [mpls] R: RE: R: Re:LastCall: lt;draft-ietf-mpls-tp- cc-cv-rdi-05. txtgt; (Proactive ConnectivityVerification, Continuity Check and Remote Defectindication for MPLSTransport 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-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of erminio.ottone...@libero.it Sent: Wednesday, July 13, 2011 1:27 PM To: david.i.al...@ericsson.com; rco...@ptinovacao.pt; i...@ietf.org; IETF-Announce Cc: m...@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
RE: 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 Propose
Italo, Comments inline. Thanks, John Sent from my iPhone -Original Message- From: erminio.ottone...@libero.it [mailto:erminio.ottone...@libero.it] Sent: Wednesday, July 13, 2011 2:04 PM To: John E Drake; david.i.al...@ericsson.com; rco...@ptinovacao.pt; ietf@ietf.org; IETF-Announce Cc: m...@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: jdr...@juniper.net Data: 13-lug-2011 22.46 A: erminio.ottone...@libero.iterminio.ottone...@libero.it, david.i. al...@ericsson.comdavid.i.al...@ericsson.com, rco...@ptinovacao.pt rco...@ptinovacao.pt, ietf@ietf.orgietf@ietf.org, IETF- Announceietf- annou...@ietf.org Cc: m...@ietf.orgm...@ietf.org Ogg: RE: [mpls] R: RE: R: Re:LastCall: lt;draft-ietf-mpls-tp- cc-cv-rdi-05. txtgt; (Proactive ConnectivityVerification, Continuity Check and Remote Defectindication for MPLSTransport 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-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of erminio.ottone...@libero.it Sent: Wednesday, July 13, 2011 1:27 PM To: david.i.al...@ericsson.com; rco...@ptinovacao.pt; ietf@ietf.org; IETF-Announce Cc: m...@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
