Application of Ethernet Pseudowires to MPLS Transport Networks
RFC 5994

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>, 
    pwe3 mailing list <pwe3@ietf.org>, 
    pwe3 chair <pwe3-chairs@tools.ietf.org>
Subject: Document Action: 'Application of Ethernet Pseudowires to MPLS Transport Networks' to Informational RFC

The IESG has approved the following document:

- 'Application of Ethernet Pseudowires to MPLS Transport Networks '
   <draft-ietf-pwe3-mpls-transport-04.txt> as an Informational RFC


This document is the product of the Pseudowire Emulation Edge to Edge Working Group. 

The IESG contact persons are Ralph Droms and Jari Arkko.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-mpls-transport-04.txt

Technical Summary

  A requirement has been identified by the operator community for the
  transparent carriage of the MPLS(-TP) network of one party over the
  MPLS(-TP) network of another party.  This document describes a
  method of satisfying this need using the existing PWE3 Ethernet
  pseudowire standard RFC4448.

Working Group Summary

  The draft originated as a response to the work that was then going
  on in the ITU to apply MPLS to transport networks. It reflected a
  desire to illustrate how IETF defined pseudowires could be applied
  to the problem of packet transport. Since that time, the development
  of MPLS-TP has proceeded in the IETF in close cooperation with the
  ITU-T. This draft addresses a sub-set of the MPLS-TP requirements
  using a limited set of existing MPLS and Pseudowire functionality,
  as defined in the IETF, but is not intended as a comprehensive
  standard for MPLS-TP per-se. The draft was widely reviewed by
  participants in the IETF MPLS-TP effort, as well as the MPLS and
  PWE3 WGs.

Document Quality

  There are no concerns about protocol quality. There are understood
  to be implementations of this protocol.

Personnel

   Who is the Document Shepherd for this document?  Who is the 
   Responsible Area Director?  If the document requires IANA
   experts(s), insert 'The IANA Expert(s) for the registries
   in this document are <TO BE ADDED BY THE AD>.'

RFC Editor Note

Please make the following two changes to
draft-ietf-pwe3-mpls-transport-04.txt before publication.
===
Abstract

OLD
  A requirement has been identified by the operator community for the
  transparent carriage of the MPLS(-TP) network of one party over the
  MPLS(-TP) network of another party.  This document describes a method
  of satisfying this need using the existing PWE3 Ethernet pseudowire
  standard RFC4448.
NEW
  Ethernet pseudowires are widely deployed to support packet transport
  of Ethernet services. These services in-turn provide transport
  for a variety of client networks e.g. IP and MPLS. This document uses
  procedures defined in the existing IETF specifications of Ethernet
  pseudowires carried over MPLS networks.

  Many of the requirements for the services provided by the mechanisms
  explained in this document, are also recognized by the MPLS transport
  profile (MPLS-TP) design effort formed jointly by the IETF and ITU-T.
  The solution described here does not address all of the MPLS-TP
  requirements, but it provides a viable form of packet transport
  service using tools that are already available.

  This document also serves as an indication that existing MPLS
  techniques form an appropriate basis for the design of a fully-
  featured packet transport solution addressing all of the requirements
  of MPLS-TP.
===

Section 1

OLD
  The operator community has identified the need for the transparent
  carriage of the MPLS(-TP) network of one party over the MPLS(-TP)
  network of another party [I-D.ietf-mpls-tp-requirements].  This
  document describes one mechanism to satisfy this requirement using
  existing IETF standards such as PWE3 Ethernet pseudowire standard
  [RFC4448] .  The mechanism described here fulfills the MPLS-TP
  requirements for transparent carriage (MPLS-TP requirements 30 & 31)
  of the Ethernet data plane.

  The key purpose of this document is to demonstrate that there is an
  existing IETF mechanism with known implementations that satisfies the
  requirements posed by the operator community.  It is recognised that
  it is possible to design a more efficient method of satisfying the
  requirements, and the IETF anticipates that improved solutions will
  be proposed in the future.
NEW
  Ethernet pseudowires are widely deployed to support packet transport
  of Ethernet services. These services in-turn provide transport
  for a variety of client networks e.g. IP and MPLS. This document uses
  procedures defined in the existing IETF specifications of Ethernet
  pseudowires carried over MPLS networks.

  Many of the requirements for the services provided by the mechanisms
  explained in this document, are also recognized by the MPLS transport
  profile (MPLS-TP) design effort formed jointly by the IETF and ITU-T
  [I-D.ietf-mpls-tp-requirements]. For example, the ability to operate
  solely with netowrk management control, the ability to use
  Operations, Adminstration and Maintenance (OAM) that does not rely on
  IP forwarding, and the ability to provide light-weight proactive
  connection verification (CV) functionality.

  The solution described in this document does not address all of the
  MPLS-TP requirements, but it provides a viable form of packet
  transport service using tools that are already available.

  The key purpose of this document is to demonstrate that there is an
  existing IETF mechanism with known implementations that satisfies the
  requirements posed by the operator community.  It is recognised that
  it is possible to design a more efficient method of satisfying the
  requirements, and the IETF anticipates that improved solutions will
  be proposed in the future as part of the MPLS-TP effort. Indeed, the
  solution described in this document is not intended to detract from
  the MPLS-TP effort. Instead, it provides legitimacy for that work by
  showing that there is a real demand from networks that are already
  deployed, and by indicating that the MPLS-TP solutions work is based
  on sound foundations.
===