The Reasons for Selecting a Single Solution for MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM)
RFC 6670

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>
Subject: Document Action: 'The Reasons for Selecting a Single Solution for MPLS-TP OAM' to Informational RFC (draft-sprecher-mpls-tp-oam-considerations-03.txt)

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/