Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)
RFC 8077

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: db3546@att.com, draft-ietf-pals-rfc4447bis.all@ietf.org, "The IESG" <iesg@ietf.org>, pals-chairs@ietf.org, "Stewart Bryant" <stewart.bryant@gmail.com>, pals@ietf.org, stewart.bryant@gmail.com, draft-ietf-pals-rfc4447bis@ietf.org, rfc-editor@rfc-editor.org
Subject: Protocol Action: 'Pseudowire Setup and Maintenance using the Label Distribution Protocol' to Internet Standard (draft-ietf-pals-rfc4447bis-05.txt)

The IESG has approved the following document:
- 'Pseudowire Setup and Maintenance using the Label Distribution
Protocol'
  (draft-ietf-pals-rfc4447bis-05.txt) as Internet Standard

This document is the product of the Pseudowire And LDP-enabled Services
Working Group.

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

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-pals-rfc4447bis/


Technical Summary

Layer 2 services (such as Frame Relay, Asynchronous Transfer Mode,
and Ethernet) can be "emulated" over an MPLS backbone by
encapsulating the Layer 2 Protocol Data Units (PDU) and then
transmitting them over "pseudowires". It is also possible to use
pseudowires to provide low-rate Time Division Multiplexed and
Synchronous Optical NETworking circuit emulation over an MPLS-enabled
network. This document specifies a protocol for establishing and
maintaining the pseudowires, using extensions to the Label
Distribution Protocol (LDP).  Procedures for encapsulating Layer 2
PDUs are specified in a set of companion documents.

This document has been written to address errata in a previous
version of this standard.

Working Group Summary

This was reviewed by the WG. There is nothing contentious.

 Document Quality

This document addresses errata in previous versions of RFC 6723, RFC 4447.
There are many implementations of this protocol. Refer to Section 10 of
document.

Personnel

   Who is the Document Shepherd for this document?  Stewart Bryant
   Who is the Responsible Area Director?  Deborah Brungard

IANA Note

Changes for the IANA section:

OLD:

8. IANA Considerations

   The authors request that IANA remove this section before publication
   and that IANA update any references to [RFC4447] in their registries
   to refer to this document.

NEW:

8. IANA Considerations
       
8.1. LDP TLV TYPE

   This document uses several new LDP TLV types; IANA already maintains
   a registry of name "TLV TYPE NAME SPACE" defined by RFC 5036.  The
   following values are suggested for assignment:

      TLV type  Description
      =====================================
       0x096A   PW Status TLV
       0x096B   PW Interface Parameters TLV
       0x096C   Group ID TLV

8.2. LDP Status Codes

   This document uses several new LDP status codes; IANA already
   maintains a registry of name "STATUS CODE NAME SPACE" defined by RFC
   5036.  The following values are suggested for assignment:

   Range/Value     E     Description                       Reference
   ------------- -----   ----------------------            ---------
   0x00000024      0     Illegal C-Bit                     [RFC4447]
   0x00000025      0     Wrong C-Bit                       [RFC4447]
   0x00000026      0     Incompatible bit-rate             [RFC4447]
   0x00000027      0     CEP-TDM mis-configuration         [RFC4447]
   0x00000028      0     PW Status                         [RFC4447]
   0x00000029      0     Unassigned/Unrecognized TAI       [RFC4447]
   0x0000002A      0     Generic Misconfiguration Error    [RFC4447]
   0x0000002B      0     Label Withdraw PW Status Method   [RFC4447]

8.3. FEC Type Name Space

   This document uses two new FEC element types, 0x80 and 0x81, from the
   registry "FEC Type Name Space" for the Label Distribution Protocol
   (LDP RFC 5036).

NOTE TO IANA:

IANA needs to update any references to [RFC4447] in their registries
to refer to this document. No other action is needed.


RFC Editor Notes:

Figure 2 appears to be missing a couple of forward/backslashes in the
ASCII art drawing. Please add them.

OLD:
  +-------+---------+        ___________        +---------+-------+
           |                /                             |
           +===============/     PSN       ===============+
                                          /
                            _____________/

NEW:
  +-------+---------+        ____________       +---------+-------+
           |                /            \                  |
           +===============/     PSN      \===============+
                           \              /
                            \____________/


At the end of the Abstract:

OLD:
    This document has been written to address errata in a previous
     version of this standard.

NEW:

    This document is a rewrite of RFC 4447 for publication as an
    Internet Standard

In section 9.1:

OLD:
   When an MPLS PSN is used to provide pseudowire service, there is a
   perception that security MUST be at least equal to the currently
   deployed Layer 2 native protocol networks that the MPLS/PW network

NEW:
   When an MPLS PSN is used to provide pseudowire service, there is a
   perception that security must be at least equal to the currently
   deployed Layer 2 native protocol networks that the MPLS/PW network


OLD:
14. Author Information


   Luca Martini
   Cisco Systems, Inc.
   1899 Wynkoop Street
   Suite 600
   Denver, CO, 80202
   e-mail: lmartini@cisco.com

NEW:
14. Author Information


   Luca Martini
   Cisco Systems, Inc.
   1899 Wynkoop Street
   Suite 600
   Denver, CO, 80202
   e-mail: lmartini@monoski.com


Please update all references to RFC4447 in the IANA section to the
correct RFC number for this document.
Note: While this document obsoletes RFC6723 and RFC4447, it does not update RFC6073.