The IESG has approved the following document: - 'The Reasons for Selecting a Single Solution for MPLS-TP OAM' (draft-sprecher-mpls-tp-oam-considerations-03.txt) as Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-sprecher-mpls-tp-oam-considerations/ Technical Summary The MPLS Transport Profile (MPLS-TP) is a profile of the MPLS technology for use in transport network deployments. The work on MPLS-TP has extended the MPLS technology with additional architectural elements and functions that can be used in any MPLS deployment. MPLS-TP is a set of functions and features selected from the extended MPLS toolset and applied in a consistent way to meet the needs and requirements of operators of packet transport networks. During the process of development of the profile, additions to the MPLS toolset have been made to ensure that the tools available met the requirements. These additions were motivated by MPLS-TP, but form part of the wider MPLS toolset such that any of them could be used in any MPLS deployment. One major set of additions provides enhanced support for Operations, Administration, and Maintenance (OAM). This enables fault management and performance monitoring to the level needed in a transport network. Many solutions and protocol extensions have been proposed to address the requirements for MPLS-TP OAM, and this document sets out the reasons for selecting a single, coherent set of solutions for standardization. Working Group Summary This document is an individual submission via AD sponsorship aiming to gain IETF consensus. It is not the product of a working group. The work is a description of why it would be a bad idea to have two solutions for MPLS-TP OAM. MPLS-TP OAM was developed by the IETF in the MPLS and PWE3 working groups, so clearly this document is relevant to those working groups. However, this document does not contain technical details of MPLS-TP OAM, and does not make any comment on the judgement of the working groups in their technical decisions. The document is more of an analysis of wider IETF policy and process. It is the opinion of the document shepherd and sposoring AD that discussion of this document on the working group lists would be a distraction from the techncial protocol work that the working groups need to do. The IETF last call was copied to the MPLS and PWE3 mailing lists. During IETF last call a substantial number of comments were received. These led to some changes in content and a significant restructuring of the document. The changes were reported to the mailing list, and the points that had been raised were answered. Document Quality This is an Informational I-D with nothing to implement. IETF consensus in this document is important in its applicability to the wider IETF community. Personnel Ross Callon (rcallon@juniper.net) is the Document Shepherd. Adrian Farrel (adrian@olddog.co.uk) is the Responsible AD RFC Editor Note -- Section 1.1 para 3 -- s/Transport profile/Transport Profile/ -- Section 1.2 -- OLD The requirements specifications [RFC5654] and [RFC5860] specifications [RFC5654] and [RFC5860] capture the essential issues that must be resolved to allow the same look and feel to be achieved. NEW The requirements specifications [RFC5654] and [RFC5860] capture the essential issues that must be resolved to allow the same look and feel to be achieved. -- Section 3.3 -- OLD As we shall demonstrate, interworking between protocols adds significant complexity, and thus a single default OAM is strongly preferred. NEW As discussed in Section 4, interworking between protocols adds significant complexity, and thus a single default OAM is strongly preferred. -- Section 3.4 -- OLD In an isolated system this may be the case, however when, as is usually case with communications technologies, simplification in one element of the system introduces a (possibly non-linear) increase in complexity elsewhere. NEW In an isolated system this may be the case; however, as is usually case with communications technologies, simplification in one element of the system introduces a (possibly non-linear) increase in complexity elsewhere. OLD the cost of increased complexity at a peer network element we loose out economically NEW the cost of increased complexity at a peer network element we lose out economically -- Section 3.6 -- OLD At the very least, the evaluation of these questions constitute a cost and introduce delay for the operator. NEW At the very least, the evaluation of these questions constitutes a cost and introduces delay for the operator. -- Section 4.3.2.2 -- s/straight-forward/straightforward/ -- Section 5.3 OLD These applications have not been documented in the IETF and most of the support for the idea has come in discussions with a documentationin the ITU-T [TD522]. NEW These applications have not been documented in the IETF and most of the support for the idea has come in a document in the ITU-T [TD522]. -- Section 7 -- This section may be removed before publication. -- Appendix A.3 -- s/viably/viability/ -- Appendix A.5 -- s/straight-forward/straightforward/ -- Appendix B.1 -- s/a E1/an E1/ -- Appendix B.1 -- s/channnel/channel/ -- Appendix B.1 -- Add to end of first paragraph -- The key difference between PDH and SDH is that the S stands for synchronous and the P for plesiochronous. Thus, the difference between the technologies is timing related. -- Appendix B.1 -- New third paragraph -- Until 1988 the standards were unpublished and under development. - The SONET standard ANSI T1.105-1988 was publised in 1988. - The SDH standard ETSI EN 300 417 was first published in 1992. - The compromise SDH/SONET standard ITU-T G.707 was published in 1988 (see below for the nature of this compromise). -- Appendix B.1 -- s/Significant confusion resulted from this situation./Some implementers were confused by this situation./ -- Appendix B.1 -- s/Because the regions or applicability/Because the regions of applicability/ -- Appendix B.1 -- s/SDH has no options for payloads at VC-4/SDH has options for payloads at VC-4/ -- Appendix B.1 -- DELETE text -- This has provided the basis for common solutions for packet based clients (GFP). -- Appendix B.1 -- Anti-penultimate paragraph ending "this was not a practical proposition." -- ADD -- and was the principal reason why the a compromise was agreed. -- Appendix B.1 -- s/A massive/An extensive/
