The Reasons for Selecting a Single Solution for MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM)
draft-sprecher-mpls-tp-oam-considerations-03
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/