A Framework for MPLS in Transport Networks
RFC 5921

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: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    mpls mailing list <mpls@ietf.org>, 
    mpls-tp mailing list <mpls-tp@ietf.org>,
    mpls chair <mpls-chairs@tools.ietf.org>
Subject: Document Action: 'A Framework for MPLS in Transport Networks' to
Informational RFC

The IESG has approved the following document:

- 'A Framework for MPLS in Transport Networks '
   <draft-ietf-mpls-tp-framework-12.txt> as an Informational RFC

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://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-framework-12.txt

Technical Summary

  The document describes an architectural framework to use MPLS 
  for packet-switched transport networks.  It specifies a set of 
  protocol functions that meet the requirements in [RFC5654]. These
  protocol functions constitute a MPLS Transport Profile (MPLS-TP) 
  for point-to-point transport paths.
  
  The remaining MPLS-TP functions, applicable specifically to point-to-
  multipoint transport paths, are outside the scope of this document.

  Optical transport infrastructure, e.g. SONET/SDH and OTN are known to
  provide reliable functionality and operational simplicity. It is the 
  intention that the set of protocol specifications produced by the MPLS-
TP project shall provide the same level of reliability and simplicity

Working Group Summary

  Since the document is an output from the MPLS-TP project it is the 
  joint output of several IETF working groups and Qustion 9, 10, 12 and
  14 of ITU-T SG15. The draft was last called across the MPLS, PWE3, and 
  CCAMP working groups with comments collected on the MPLS-TP mailing 
  list.

Document Quality

  The document is well reviewed in all the groups mentioned above

Personnel

  Loa Andersson (loa@pi.nu) is the Document Shepherd
  Adrian Farrel (adrian.farrel@huawei.com) is the Responsible AD

RFC Editor Note

RFC Editor, please note that this Informational RFC has IETF consensus
through an IETF last call. Please add the appropriate streams 
boilerplate.

--

Section 3.14
OLD
   The Equipment Management Function (EMF) of an MPLS-TP Network Element
   (NE) (i.e.  LSR, LER, PE, S-PE or T-PE) provides the means through
   which a management system manages the NE.  The Management
   Communication Channel (MCC), realised by the G-ACh, provides a
   logical operations channel between NEs for transferring Management
   information.  For the management interface from a management system
   to an MPLS-TP NE, there is no restriction on which management
   protocol is used.  The Network Management System (NMS) is used to
   provision and manage an end-to-end connection across a network where
   some segments are created/managed by, for example, Netconf [RFC4741]
   or SNMP [RFC3411] and other segments by XML or CORBA interfaces.
   Maintenance operations are run on a connection (LSP or PW) in a
   manner that is independent of the provisioning mechanism.  An MPLS-TP
   NE is not required to offer more than one standard management
   interface.  In MPLS-TP, the EMF needs to support statically
   provisioning LSPs for an LSR or LER, and PWs for a PE, as well as any
   associated MEPs and MIPs, as per Section 3.11.
NEW
   The Equipment Management Function (EMF) of an MPLS-TP Network Element
   (NE) (i.e.  LSR, LER, PE, S-PE or T-PE) provides the means through
   which a management system manages the NE.  The Management 
   Communication Channel (MCC), realised by the G-ACh, provides a
   logical operations channel between NEs for transferring Management
   information. The Network Management System (NMS) can be used to
   provision and manage an end-to-end connection across a network.
   Maintenance operations are run on a connection (LSP or PW) in a
   manner that is independent of the provisioning mechanism.  Segments
   may be created or managed by, for example, Netconf [RFC4741], SNMP 
   [RFC3411] or CORBA interfaces, but not all segments need to be 
   created or managed using the same type of interface. Where an MPLS-TP
   NE is managed by an NMS, at least one of these standard management 
   mechanisms is required for interoperability, but this document
   imposes no restriction on which of these standard management 
   protocols is used.  In MPLS-TP, the EMF needs to support statically
   provisioning LSPs for an LSR or LER, and PWs for a PE, as well as any
   associated MEPs and MIPs, as per Section 3.11.

---

Section 14, first paragraph
OLD
   The introduction of MPLS-TP into transport networks means that the
   security considerations applicable to both MPLS and PWE3 apply to
   those transport networks.
NEW
   The introduction of MPLS-TP into transport networks means that the
   security considerations applicable to both MPLS [RFC3031] and PWE3
   [RFC3985] apply to those transport networks.

---