Subject: [mpls] Protocol Action: 'MPLS Transport Profile lock Instruct and Loopback Functions' to Proposed Standard (draft-ietf-mpls-tp-li-lb-08.txt)

From: The IESG <[email-masked]>
Date: Tue, 25 Oct 2011 15:59:38 -0700

The IESG has approved the following document:
- 'MPLS Transport Profile lock Instruct and Loopback Functions'
  (draft-ietf-mpls-tp-li-lb-08.txt) as a Proposed Standard

This document is the product of the Multiprotocol Label Switching Working
Group.

The IESG contact persons are Adrian Farrel and Stewart Bryant.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-li-lb/

Technical Summary

   Two useful Operations, Administration, and Maintenance (OAM)
   functions in a transport network are "lock" and "loopback". The lock
   function enables an operator to lock a transport path such that it
   does not carry client traffic, but can continue to carry OAM messages
   and may carry test traffic. The loopback function allows an operator
   to set a specific node on the transport path into loopback mode such
   that it returns all received data.

   This document specifies the lock function for MPLS networks and
   describes how the loopback function operates in MPLS networks.

Working Group Summary

  This document is a MPLS working group document, and part of the joint
  IETF - ITU.T MPLS-TP project. It has been reviewed in both organizations
  and there is a solid support for the document.

  The following IPR Declarations may be related to this I-D:
  http://datatracker.ietf.org/ipr/1439/
  The IPD disclosure was noted on the WG mailing list and in the IETF last call.
  No concerns were raised.

Document Quality

  The document is well reviewed in the MPLS and PWE3 working groups,
  the ITU-T and the MPLS-TP project. Several implementations are 
  under way or planned.

  This document updates RFC 6371 section 7.1.1.
  This document contains a "downref" to RFC 6371, the Informational RFC that it updates.
  The downref was declared in the IETF last call.  

Personnel

  Loa Andersson ([email-masked]) is the document shepherd
  Adrian Farrel ([email-masked]) is the Responsible AS

RFC Editor Note

Section 1 bullet 2
s/an bidirectional/a bidirectional/