Requirements for Hitless MPLS Path Segment Monitoring

Approval announcement
Draft of message to be sent after approval:

From: The IESG <>
To: IETF-Announce <>
Cc:,,, David Sinicrope <>,,, The IESG <>,
Subject: Document Action: 'Requirements for hitless MPLS path segment monitoring' to Informational RFC (draft-ietf-mpls-tp-temporal-hitless-psm-14.txt)

The IESG has approved the following document:
- 'Requirements for hitless MPLS path segment monitoring'
  (draft-ietf-mpls-tp-temporal-hitless-psm-14.txt) as Informational RFC

This document is the product of the Multiprotocol Label Switching Working

The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard.

A URL of this Internet Draft is:

Technical Summary

One of the most important OAM capabilities for transport network
operation is fault localisation.  An in-service, on-demand segment
monitoring function of a transport path is indispensable,
particularly when the service monitoring function is activated only
between end points.  However, the current segment monitoring approach
defined for MPLS (including the transport profile (MPLS-TP)) in RFC
6371 "Operations, Administration, and Maintenance Framework for MPLS-
Based Transport Networks" has drawbacks.  This document provides an
analysis of the existing MPLS-TP OAM mechanisms for the path segment
monitoring and provides requirements to guide the development of new
OAM tools to support a Hitless Path Segment Monitoring (HPSM).

Working Group Summary

WG progress was smooth with no controversy. 

Document Quality

The document has been well reviewed by members of the WG with interest
in MPLS-TP, and liaisoned with ITU-T SG15, and updated accordingly.
As a requirements document it does not specify any protocol to be implemented,
but rather specifies requirements which will be used to guide future work.

As the document has been a WG document since 2012, without any
solution documents submitted, the responsible AD questioned the interest for
publishing the requirements document as a stand-alone document and
advised to delay until solution work was proposed and possibly combining.
After several months, the WG and WG Chairs requested again to proceed
with publishing as a standalone document.


   Who is the Document Shepherd for this document?  David Sinicrope
   Who is the Responsible Area Director?  Deborah Brungard

RFC Editor Note

Section 4.8:
Anyway maintenance points/s/Though maintenance points

Investigating potential solutions for satisfying proposed HPSM requirements
might lead to propose new functional components that have to be backward
compatible with MPLS architecture.
Investigating potential solutions for satisfying HPSM requirements
may lead to identifying new functional components; these components
need to be backward compatible with MPLS architecture.

Section 4.9:
That because these functions/s/These functions