path: root/doc/rfc/rfc8237.txt

Internet Engineering Task Force (IETF)                        L. Martini
Request for Comments: 8237                                   Monoski LLC
Category: Standards Track                                     G. Swallow
ISSN: 2070-1721                                                     SETC
                                                           E. Bellagamba
                                                                Ericsson
                                                            October 2017


             MPLS Label Switched Path (LSP) Pseudowire (PW)
                Status Refresh Reduction for Static PWs

Abstract

   This document describes a method for generating an aggregated
   pseudowire (PW) status message transmitted for a statically
   configured PW on a Multiprotocol Label Switching (MPLS) Label
   Switched Path (LSP) to indicate the status of one or more PWs carried
   on the LSP.

   The method for transmitting the PW status information is not new;
   however, this protocol extension allows a Service Provider (SP) to
   reliably monitor the individual PW status while not overwhelming the
   network with multiple periodic status messages.  This is achieved by
   sending a single cumulative summary status verification message for
   all the PWs grouped in the same LSP.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc8237.











Martini, et al.              Standards Track                    [Page 1]
^L
RFC 8237          MPLS LSP PW Status Refresh Reduction      October 2017


Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.





































Martini, et al.              Standards Track                    [Page 2]
^L
RFC 8237          MPLS LSP PW Status Refresh Reduction      October 2017


Table of Contents

   1. Introduction ....................................................3
      1.1. Requirements Language ......................................4
      1.2. Terminology ................................................4
      1.3. Notational Conventions .....................................5
   2. PW Status Refresh Reduction Protocol ............................5
      2.1. Protocol States ............................................5
           2.1.1. INACTIVE ............................................5
           2.1.2. STARTUP .............................................6
           2.1.3. ACTIVE ..............................................6
      2.2. Timer Value Change Transition Procedure ....................6
   3. PW Status Refresh Reduction Procedure ...........................7
   4. PW Status Refresh Reduction Message Encoding ....................8
   5. PW Status Refresh Reduction Control Messages ...................11
      5.1. Notification Message ......................................12
      5.2. PW Configuration Message ..................................12
           5.2.1. MPLS-TP Tunnel ID ..................................13
           5.2.2. PW ID Configured List ..............................14
           5.2.3. PW ID Unconfigured List ............................15
   6. PW Provisioning Verification Procedure .........................15
      6.1. PW ID List Advertising and Processing .....................16
   7. Security Considerations ........................................16
   8. IANA Considerations ............................................17
      8.1. PW Status Refresh Reduction Message Types .................17
      8.2. PW Configuration Message Sub-TLVs .........................17
      8.3. PW Status Refresh Reduction Notification Codes ............18
      8.4. PW Status Refresh Reduction Message Flags .................18
      8.5. G-ACh Registry Allocation .................................19
      8.6. Guidance for Designated Experts ...........................19
   9. References .....................................................19
      9.1. Normative References ......................................19
      9.2. Informative References ....................................20
   Authors' Addresses ................................................20

1.  Introduction

   When PWs use a Multiprotocol Label Switching (MPLS) network as the
   Packet Switched Network (PSN), they are set up using static label
   assignment per Section 4 of [RFC8077], and the PW status information
   is propagated using the method described in [RFC6478].  There are two
   basic modes of operation described in [RFC6478], Section 5.3:
   (1) periodic retransmission of non-zero status messages and (2) a
   simple acknowledgment of PW status (Section 5.3.1 of [RFC6478]).  The
   LSP-level protocol described below applies to the case when






Martini, et al.              Standards Track                    [Page 3]
^L
RFC 8237          MPLS LSP PW Status Refresh Reduction      October 2017


   PW status is acknowledged immediately with a requested refresh value
   of zero (no refresh).  In this case, the PW status refresh reduction
   protocol is necessary for several reasons, such as the following:

     i. The PW status refresh reduction protocol greatly increases the
        scalability of the PW status protocol by reducing the amount of
        messages that a Provider Edge (PE) needs to periodically send to
        its neighbors.

    ii. The PW status refresh reduction protocol will detect a remote PE
        restart.

   iii. If the local state is lost for some reason, the PE needs to be
        able to request a status refresh reduction from the remote PE.

    iv. The PW status refresh reduction protocol can optionally detect a
        remote PE provisioning change.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

1.2.  Terminology

   FEC: Forwarding Equivalence Class

   LDP: Label Distribution Protocol

   LSP: Label Switched Path

   MS-PW: Multi-Segment Pseudowire

   PE: Provider Edge

   PW: Pseudowire

   S-PE: Switching Provider Edge Node of MS-PW

   SS-PW: Single-Segment Pseudowire

   T-PE: Terminating Provider Edge Node of MS-PW






Martini, et al.              Standards Track                    [Page 4]
^L
RFC 8237          MPLS LSP PW Status Refresh Reduction      October 2017


1.3.  Notational Conventions

   All multiple-word atomic identifiers use underscores ("_") between
   the words to join the words.  Many of the identifiers are composed of
   a concatenation of other identifiers.  These are expressed using
   double-colon ("::") notation.

   Where the same identifier type is used multiple times in a
   concatenation, they are qualified by a prefix joined to the
   identifier by a dash ("-").  For example, Src-Node_ID is the Node_ID
   of a node referred to as "Src" ("Src" is short for "source").

   The notation does not define an implicit ordering of the information
   elements involved in a concatenated identifier.

2.  PW Status Refresh Reduction Protocol

   The PW status refresh reduction protocol consists of a simple message
   that is sent at the LSP level, using the MPLS Generic Associated
   Channel (G-ACh) [RFC5586].

   For a particular LSP where the PW status refresh reduction protocol
   is enabled, a PE using this protocol MUST send the PW status refresh
   reduction Message as soon as a PW is configured on that LSP.  The
   message is then retransmitted at a locally configured interval
   indicated in the Refresh Timer field.  If no acknowledgment is
   received, the protocol does not reach the ACTIVE state
   (Section 2.1.3), and the PE SHOULD NOT send any PW status messages
   with a Refresh Timer of zero as described in [RFC6478],
   Section 5.3.1.

   It is worth noting that no relationship exists between the locally
   configured timer for the PW status refresh reduction protocol and the
   individual PW status Refresh Timers.

2.1.  Protocol States

   The protocol can be in three possible states: INACTIVE, STARTUP, and
   ACTIVE.

2.1.1.  INACTIVE

   This state is entered when the protocol is turned off.  This state is
   also entered if all PWs on a specific LSP are deprovisioned.







Martini, et al.              Standards Track                    [Page 5]
^L
RFC 8237          MPLS LSP PW Status Refresh Reduction      October 2017


2.1.2.  STARTUP

   In this state, the PE transmits periodic PW status refresh reduction
   Messages with the Ack Session ID (Section 4) set to 0.  The PE
   remains in this state until a PW status refresh message is received
   with the correct local Session ID in the Ack Session ID field.  State
   can transition from the STARTUP state to the ACTIVE or INACTIVE
   state.

2.1.3.  ACTIVE

   This state is entered once the PE receives a PW status refresh
   reduction Message with the correct local Session ID in the Ack
   Session ID field within 3.5 times the Refresh Timer field value of
   the last PW status refresh reduction Message transmitted.  This state
   is immediately exited in the following scenarios:

     i. A valid PW status refresh reduction Message is not received
        within 3.5 times the current Refresh Timer field value (assuming
        that a timer transition procedure is not in progress).
        New state: STARTUP.

    ii. A PW status refresh reduction Message is received with the wrong
        Ack Session ID field value or a zero Ack Session ID field value.
        New state: STARTUP.

   iii. All PWs using the particular LSP are deprovisioned, or the
        protocol is disabled.
        New state: INACTIVE.

2.2.  Timer Value Change Transition Procedure

   If a PE needs to change the value of the Refresh Timer field while
   the PW status refresh reduction protocol is in the ACTIVE state, the
   following procedure must be followed:

     i. A PW status refresh reduction Message is transmitted with the
        new timer value.

    ii. If the new value is greater than the original one, the PE will
        operate according to the new timer value immediately.










Martini, et al.              Standards Track                    [Page 6]
^L
RFC 8237          MPLS LSP PW Status Refresh Reduction      October 2017


   iii. If the new value is smaller than the original one, the PE will
        operate according to the original timer value for a period
        3.5 times the original timer value or until the first valid PW
        status refresh reduction Message is received.

        A PE receiving a PW status refresh reduction Message with a new
        timer value will immediately acknowledge the new value via a PW
        status refresh reduction Message and will start operating
        according to the new timer value.

3.  PW Status Refresh Reduction Procedure

   When the PW status refresh reduction protocol on a particular LSP is
   in the ACTIVE state, the PE can send all PW status messages, for PWs
   on that LSP, with a Refresh Timer value of zero.  This greatly
   decreases the amount of messages that the PE needs to transmit to the
   remote PE because once the PW status message for a particular PW is
   acknowledged, further repetitions of that message are no longer
   necessary.

   To further reduce the amount of possible messages when an LSP starts
   forwarding traffic, care should be taken to permit the PW status
   refresh reduction protocol to reach the ACTIVE state quickly, and
   before the first PW status Refresh Timer expires.  This can be
   achieved by using a PW status refresh reduction Message Refresh Timer
   value that is much smaller than the PW status message Refresh Timer
   value in use (Section 5.3.1 of [RFC6478]).

   If the PW status refresh reduction protocol session is terminated by
   entering the INACTIVE state or the STARTUP state, the PE MUST
   immediately resend all the previously sent PW status messages for
   that particular LSP for which the session was terminated.  In this
   case, the Refresh Timer value MUST NOT be set to 0 and MUST be set
   according to the local policy of the PE router.  Implementations MUST
   take care to avoid flooding the remote PE with a large number of PW
   status messages at once.  If the PW status refresh reduction protocol
   session is terminated for administrative reasons and the local PE can
   still communicate with the remote PE, the local PE SHOULD pace the
   transmission of PW status messages to the remote PE.












Martini, et al.              Standards Track                    [Page 7]
^L
RFC 8237          MPLS LSP PW Status Refresh Reduction      October 2017


4.  PW Status Refresh Reduction Message Encoding

   The packet containing the PW status refresh reduction Message is
   encoded as follows (omitting link-layer information):

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               MPLS LSP (tunnel) Label Stack Entry             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              GAL                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0 0 0 1|Version|   Reserved    | 0x29 PW OAM Message           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Session ID           |         Ack Session ID        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Refresh Timer         |     Total Message Length      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Checksum              |    Message Sequence Number    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Last Received Sequence Number | Message Type  |U|C|   Flags   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                     Control Message Body                      ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This message contains the following fields:

      *  MPLS LSP (tunnel) Label Stack Entry

         The label stack is explained in [RFC3031].

      *  GAL

         The G-ACh Label (GAL) and the next 4 octets (including the PW
         OAM Message field as the Channel Type) are explained in
         Section 2.1 of [RFC5586].

      *  PW OAM Message

         This field indicates the Channel Type in the G-ACh header, as
         described in Section 2.1 of [RFC5586].








Martini, et al.              Standards Track                    [Page 8]
^L
RFC 8237          MPLS LSP PW Status Refresh Reduction      October 2017


      *  Session ID

         A non-zero locally selected session number that is not
         preserved if the local PE restarts.

         In order to get a locally unique Session ID, the recommended
         choice is to perform a CRC-16 ("CRC" stands for "Cyclic
         Redundancy Check"), giving as input the following data:

         |YY|MM|DD|HHMMSSLLL|

         Where:
         YY = the last two decimal digits of the current year
         MM = the two decimal digits of the current month
         DD = the two decimal digits of the current day
         HHMMSSLLL = the decimal digits of the current time,
            expressed in hours (HH), minutes (MM), seconds (SS), and
            milliseconds (LLL)

         If the calculation results in an already-existing Session ID, a
         unique Session ID can be generated by adding 1 to the result
         until the Session ID is unique.  Any other method to generate a
         locally unique Session ID is also acceptable.

      *  Ack Session ID

         The Acknowledgment Session ID received from the remote PE.

      *  Refresh Timer

         A non-zero unsigned 16-bit integer value greater than or equal
         to 10, expressed in milliseconds, that indicates the desired
         refresh interval.  The default value of 30000 is RECOMMENDED.

      *  Total Message Length

         Total length in octets of the Checksum, Message Type, Flags,
         Message Sequence Number, and Control Message Body.  A value of
         zero means that no control message is present and, therefore,
         that no Checksum or subsequent fields are present either.











Martini, et al.              Standards Track                    [Page 9]
^L
RFC 8237          MPLS LSP PW Status Refresh Reduction      October 2017


      *  Checksum

         A 16-bit field containing the one's complement of the one's
         complement sum of the entire message (including the G-ACh
         header), with the Checksum field replaced by zero for the
         purpose of computing the checksum.  An all-zero value means
         that no checksum was transmitted.  Note that when the checksum
         is not computed, the header of the bundle message will not be
         covered by any checksum.

      *  Message Sequence Number

         An unsigned 16-bit integer that is started from 1 when the
         protocol enters the ACTIVE state.  The sequence number wraps
         back to 1 when the maximum value is reached.  The value 0 is
         reserved and MUST NOT be used.

      *  Last Received Message Sequence Number

         The sequence number of the last message received.  If no
         message has yet been received during this session, this field
         is set to 0.

      *  Message Type

         The type of control message that follows.  Control message
         types are allocated in this document and by IANA.

      *  (U) Unknown flag bit

         Upon receipt of an unknown message or TLV, if U is clear (0),
         a notification message with code "Unknown TLV (U-Bit=0)"
         (code 0x4) MUST be sent to the remote PE, and the keepalive
         session MUST be terminated by entering the STARTUP state; if
         U is set (1), the unknown message, or message containing an
         unknown TLV, MUST be acknowledged and silently ignored, and the
         following messages, or TLVs, if any, processed as if the
         unknown message or TLV did not exist.  In this case, the PE MAY
         send back a single notification message per keepalive session
         with code "Unknown TLV (U-Bit=1)".  This last step is OPTIONAL.

      *  (C) Configuration flag bit

         The C-Bit is used to signal the end of PW configuration
         transmission.  If it is set, the sending PE has finished
         sending all of its current configuration information.





Martini, et al.              Standards Track                   [Page 10]
^L
RFC 8237          MPLS LSP PW Status Refresh Reduction      October 2017


      *  Flags

         The remaining 6 bits of PW status refresh reduction Message
         Flags to be allocated by IANA.  These unallocated bits MUST be
         set to 0 on transmission and ignored on reception.

      *  Control Message Body

         The Control Message Body is defined in Section 5 and is
         specific to the type of message.

   It should be noted that the Checksum, Message Sequence Number, Last
   Received Message Sequence Number, Message Type, Flags, and Control
   Message Body are OPTIONAL.  The Total Message Length field is used to
   parse how many optional fields are included.  Hence, all optional
   fields that precede a specific field that needs to be included in a
   specific implementation MUST be included if that optional field is
   also included.

   If any of the above values are outside the specified range, a
   notification message is returned with code "PW configuration not
   supported", and the message is ignored.

5.  PW Status Refresh Reduction Control Messages

   PW status refresh reduction Control Messages consist of the Checksum,
   Message Sequence Number, Last Received Message Sequence Number,
   Message Type, Flags, and Control Message Body.

   When a PW status refresh reduction Control Message needs to be sent,
   the system can attach it to a scheduled PW status refresh reduction
   Message or send one ahead of time.  In any case, PW status refresh
   reduction Control Messages always piggyback on normal messages.

   A PW status refresh reduction Message is also called a PW status
   refresh reduction Control Message if it contains a control message
   construct.

   There can only be one control message construct per PW status refresh
   reduction Message.  If the U-Bit is set and a PE receiving the PW
   status refresh reduction Message does not understand the control
   message, the control message MUST be silently ignored.  However, the
   Message Sequence Number MUST still be acknowledged by sending a Null
   Notification message back with the appropriate value in the Last
   Message Received field.  If a control message is not acknowledged
   after 3.5 times the value of the Refresh Timer, a fatal notification
   -- "Unacknowledged control message" -- MUST be sent, and the PW
   status refresh reduction session MUST be terminated.



Martini, et al.              Standards Track                   [Page 11]
^L
RFC 8237          MPLS LSP PW Status Refresh Reduction      October 2017


   If a PE does not want or need to send a control message, the Checksum
   and all subsequent fields MUST NOT be sent, and the Total Message
   Length field is then set to 0.

5.1.  Notification Message

   The most common use of the notification message is to acknowledge the
   reception of a message by indicating the received Message Sequence
   Number in the Last Received Sequence Number field.  The notification
   message is encoded as follows:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Checksum              |    Message Sequence Number    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Last Received Sequence Number |  Type=0x01    |U|C|   Flags   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Notification Code                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The message type is set to 0x01, and the U-Bit is treated as
   described in Section 4.  The Notification Codes are 32-bit quantities
   assigned by IANA (see the IANA Considerations section).  Notification
   codes are considered either "Error codes" or simple notifications.
   If the Notification Code is an Error code as indicated in the IANA
   allocation registry, the keepalive session MUST be terminated by
   entering the STARTUP state.

   When there is no notification information to be sent, the
   notification code is set to 0 to indicate a "Null Notification".  The
   C-Bit MUST always be set to 0 in this type of message.  The remaining
   6 bits of PW status refresh reduction Message Flags are to be
   allocated by IANA.  These unallocated bits MUST be set to 0 on
   transmission and ignored on reception.

5.2.  PW Configuration Message

   The PW status refresh reduction TLVs are informational TLVs that
   allow the remote PE to verify certain provisioning information.  This
   message contains a series of sub-TLVs, in no particular order, that
   contain PW and LSP configuration information.  The message has no
   preset length limit; however, its total length will be limited by the
   transport network's Maximum Transmission Unit (MTU).  PW status
   refresh reduction Messages MUST NOT be fragmented.  If a sender has
   more configuration information to send than will fit into one PW
   Configuration Message, it may send additional messages carrying
   additional TLVs.



Martini, et al.              Standards Track                   [Page 12]
^L
RFC 8237          MPLS LSP PW Status Refresh Reduction      October 2017


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Checksum              |    Message Sequence Number    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Last Received Sequence Number |  Type=0x02    |U|C|   Flags   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                                                               ~
      |                PW Configuration Message Sub-TLVs              |
      ~                                                               ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The PW Configuration Message type is set to 0x02.  For this message,
   the U-Bit is set to 1, as processing of these messages is OPTIONAL.

   The C-Bit is used to signal the end of PW configuration transmission.
   If it is set, the sending PE has finished sending all of its current
   configuration information.  The PE transmitting the configuration
   MUST set the C-Bit on the last PW Configuration Message when all
   current PW configuration information has been sent.

   PW Configuration Message sub-TLVs have the following generic format:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type        |  Length       |        Value                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                                                               ~
      |                      Value (Continued)                        |
      ~                                                               ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.2.1.  MPLS-TP Tunnel ID

   This TLV contains the MPLS-TP Tunnel ID ("MPLS-TP" stands for "MPLS
   Transport Profile").  When the configuration message is used for a
   particular keepalive session, the MPLS-TP Tunnel ID sub-TLV MUST be
   sent at least once.












Martini, et al.              Standards Track                   [Page 13]
^L
RFC 8237          MPLS LSP PW Status Refresh Reduction      October 2017


   The MPLS-TP Tunnel ID is encoded as follows:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type=0x01   |  Length=20    |      MPLS-TP Tunnel ID        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                                                               ~
      |           MPLS-TP Tunnel ID (Continued) (20 octets)           |
      ~                                                               ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The MPLS point-to-point tunnel ID is defined in [RFC6370].  The
   coding used by the node that is the source of a message is:

      Src-Global_Node_ID::Src-Tunnel_Num::Dst-Global_Node_ID::
      Dst-Tunnel_Num

   Note that a single tunnel ID is enough to identify the tunnel and the
   source end of the message.

5.2.2.  PW ID Configured List

   This OPTIONAL sub-TLV contains a list of the provisioned PWs on
   the LSP.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type=0x02   |    Length     |         PW Path ID            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                      PW Path ID (Continued)                   |
      ~                                                               ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The PW Path ID is a 32-octet PW path identifier [RFC6370].  The
   coding used by the node that is the source of a message is:

      AGI::Src-Global_ID::Src-Node_ID::Src-AC_ID::
      Dst-Global_ID::Dst-Node_ID::Dst-AC_ID

   The number of PW Path IDs in the TLV will be inferred by the length
   of the TLV, up to a maximum of 8.  The procedure for processing this
   TLV will be described in Section 6.





Martini, et al.              Standards Track                   [Page 14]
^L
RFC 8237          MPLS LSP PW Status Refresh Reduction      October 2017


5.2.3.  PW ID Unconfigured List

   This OPTIONAL sub-TLV contains a list of the PWs that have been
   deprovisioned on the LSP.  Note that sending the same PW address in
   both the PW ID Configured List sub-TLV and the PW ID Unconfigured
   List sub-TLV in the same configuration message constitutes a fatal
   session error.  If this error occurs, an error notification message
   is returned with the Error code "PW Configuration TLV conflict", and
   the session is terminated by entering the STARTUP state.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type=0x03   |    Length     |         PW Path ID            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                      PW Path ID (Continued)                   |
      ~                                                               ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The PW Path ID is a 32-octet PW path identifier as defined in
   Section 5.2.2.

   The number of PW Path IDs in the TLV will be inferred by the length
   of the TLV, up to a maximum of 8.

6.  PW Provisioning Verification Procedure

   The advertisement of the PW Configuration Message is OPTIONAL.

   A PE that desires to use the PW Configuration Message to verify the
   configuration of PWs on a particular LSP should advertise its PW
   configuration to the remote PE on LSPs that have active keepalive
   sessions.  When a PE receives PW configuration information using this
   protocol and it does not support processing the information or is not
   willing to process it, it MUST acknowledge all the PW Configuration
   Messages with the notification code "PW configuration not supported".
   In this case, the information in the PW Configuration Message is
   silently ignored.  If a PE receives such a notification, it SHOULD
   stop sending PW Configuration Messages for the duration of the PW
   status refresh reduction keepalive session.









Martini, et al.              Standards Track                   [Page 15]
^L
RFC 8237          MPLS LSP PW Status Refresh Reduction      October 2017


   If PW configuration information is received, it is used to verify the
   accuracy of the local configuration information against the remote
   PE's configuration information.  If a configuration mismatch is
   detected, where a particular PW is configured locally but not on the
   remote PE, the following actions SHOULD be taken:

     i. The local PW MUST be considered in "Not Forwarding" state
        (Section 6.3.2 of [RFC8077]).

    ii. The PW Attachment Circuit status is set to reflect the PW fault.

   iii. An alarm SHOULD be raised to a network management system.

    iv. A notification message with the notification code "PW
        configuration mismatch" MUST be sent to the remote PE.  Only one
        such message is REQUIRED per configuration message even if the
        configuration message is split into multiple configuration
        messages due to individual message-size restrictions on a
        particular link.  Upon receipt of such a message, the receiving
        PE MAY raise an alarm to a network management system.  This
        alarm MAY be cleared when the configuration is updated.

6.1.  PW ID List Advertising and Processing

   When configuration messages are advertised on a particular LSP, the
   PE sending the messages needs to checkpoint the configuration
   information sent by setting the C-Bit when all currently known
   configuration information has been sent.  This process allows the
   receiving PE to immediately proceed to verify all the currently
   configured PWs on that LSP, eliminating the need for a long waiting
   period.

   If a new PW is added to a particular LSP, the PE MUST place the
   configuration verification of this PW on hold for a period of at
   least 30 seconds.  This is necessary to minimize false-positive
   events of misconfiguration due to the ends of the PW being slightly
   out of sync.

7.  Security Considerations

   The security considerations discussed in [RFC6478] are adequate for
   the mechanism described in this document, since the operating
   environment is almost identical to the one where this protocol would
   be deployed.  It should also be noted that since this protocol is
   designed to be deployed between two adjacent PEs connected by a
   physical link, it is not possible to misdirect or inject traffic
   without compromising the PW transport link itself.




Martini, et al.              Standards Track                   [Page 16]
^L
RFC 8237          MPLS LSP PW Status Refresh Reduction      October 2017


8.  IANA Considerations

   The registries in this section have been created or updated as
   appropriate in the "Pseudowire Name Spaces (PWE3)" registry or the
   "Generic Associated Channel (G-ACh) Parameters" registry.  For the
   allocation ranges designated as "vendor-proprietary extensions", the
   respective IANA registry contains the vendor name in brackets at the
   end of the Description field.

8.1.  PW Status Refresh Reduction Message Types

   IANA has set up the "PW Status Refresh Reduction Control Messages"
   registry.  This registry contains 8-bit values.  Type values 1 and 2
   are defined in this document.  Type values 3 through 64 and 128
   through 254 are to be assigned by IANA using the "Expert Review"
   policy defined in [RFC8126].  Type values 65 through 127, 0, and 255
   are to be allocated using the "IETF Review" policy defined in
   [RFC8126].

   The Type values are assigned as follows:

      Type   Message Description
      ----   ------------------------
      0x01   Notification message
      0x02   PW Configuration Message

8.2.  PW Configuration Message Sub-TLVs

   IANA has set up the "PW Status Refresh Reduction Configuration
   Message Sub-TLVs" registry.  This registry contains 8-bit values.
   Type values 1 through 3 are defined in this document.  Type values 4
   through 64 and 128 through 254 are to be assigned by IANA using the
   "Expert Review" policy defined in [RFC8126].  Type values 65 through
   127, 0, and 255 are to be allocated using the "IETF Review" policy
   defined in [RFC8126].

   The Type values are assigned as follows:

      Sub-TLV Type    Description
      ------------    -----------------------
      0x01            MPLS-TP Tunnel ID
      0x02            PW ID Configured List
      0x03            PW ID Unconfigured List








Martini, et al.              Standards Track                   [Page 17]
^L
RFC 8237          MPLS LSP PW Status Refresh Reduction      October 2017


8.3.  PW Status Refresh Reduction Notification Codes

   IANA has set up the "PW Status Refresh Reduction Notification Codes"
   registry.  This registry contains 32-bit values.  Type values 0
   through 7 are defined in this document.  Type values 8 through 65536
   and 134,217,729 through 4,294,967,294 are to be assigned by IANA
   using the "Expert Review" policy defined in [RFC8126].  Type values
   65537 through 134,217,728, 0, and 4,294,967,295 are to be allocated
   using the "IETF Review" policy defined in [RFC8126].

   For each value assigned, IANA should also track whether the value
   constitutes an error as described in Section 5.1.  When values are
   assigned by IETF Review, the settings in the "Error?" column must be
   documented in the RFC that requests the allocation.  For
   "Expert Review" assignments, the settings in the "Error?" column must
   be made clear by the requester at the time of assignment.

   The Type values are assigned as follows:

      Code          Error?    Description
      ----------    ------    ------------------------------
      0x00000000    No        Null Notification
      0x00000001    No        PW configuration mismatch
      0x00000002    Yes       PW Configuration TLV conflict
      0x00000003    No        Unknown TLV (U-Bit=1)
      0x00000004    Yes       Unknown TLV (U-Bit=0)
      0x00000005    No        Unknown Message Type
      0x00000006    No        PW configuration not supported
      0x00000007    Yes       Unacknowledged control message

8.4.  PW Status Refresh Reduction Message Flags

   IANA has set up the "PW Status Refresh Reduction Message Flags"
   registry.  This is an 8-bit registry, with the first two most
   significant bits allocated by this document as follows:

      Bit Position  Name    Description
      ------------  ----    ----------------------
           0        U       Unknown flag bit
           1        C       Configuration flag bit

   The remaining bits are to be allocated using the "IETF Review" policy
   defined in [RFC8126].








Martini, et al.              Standards Track                   [Page 18]
^L
RFC 8237          MPLS LSP PW Status Refresh Reduction      October 2017


8.5.  G-ACh Registry Allocation

   IANA maintains a registry called "MPLS Generalized Associated Channel
   (G-ACh) Types (including Pseudowire Associated Channel Types)".  IANA
   has allocated a new value as follows:

      Value     Description                     Reference
      -----     ---------------------------     ---------
      0x29      PW Status Refresh Reduction     RFC 8237

8.6.  Guidance for Designated Experts

   In all cases of review by the Designated Expert (DE) described here,
   the DE is expected to ascertain the existence of suitable
   documentation (a specification) as described in [RFC8126] and to
   verify that the document is permanently and publicly available.  The
   DE is also expected to check that the clarity of purpose and use of
   the requested code points fit the general architecture and intended
   purpose of the respective message or TLV.  Lastly, the DE should
   check that any assignment does not duplicate or conflict with work
   that is active or already published within the IETF.

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
              Label Switching Architecture", RFC 3031,
              DOI 10.17487/RFC3031, January 2001,
              <https://www.rfc-editor.org/info/rfc3031>.

   [RFC6370]  Bocci, M., Swallow, G., and E. Gray, "MPLS Transport
              Profile (MPLS-TP) Identifiers", RFC 6370,
              DOI 10.17487/RFC6370, September 2011,
              <https://www.rfc-editor.org/info/rfc6370>.

   [RFC6478]  Martini, L., Swallow, G., Heron, G., and M. Bocci,
              "Pseudowire Status for Static Pseudowires", RFC 6478,
              DOI 10.17487/RFC6478, May 2012,
              <https://www.rfc-editor.org/info/rfc6478>.






Martini, et al.              Standards Track                   [Page 19]
^L
RFC 8237          MPLS LSP PW Status Refresh Reduction      October 2017


   [RFC8077]  Martini, L., Ed., and G. Heron, Ed., "Pseudowire Setup and
              Maintenance Using the Label Distribution Protocol (LDP)",
              STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017,
              <https://www.rfc-editor.org/info/rfc8077>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in
              RFC 2119 Key Words", BCP 14, RFC 8174,
              DOI 10.17487/RFC8174, May 2017,
              <https://www.rfc-editor.org/info/rfc8174>.

9.2.  Informative References

   [RFC5586]  Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
              "MPLS Generic Associated Channel", RFC 5586,
              DOI 10.17487/RFC5586, June 2009,
              <https://www.rfc-editor.org/info/rfc5586>.

Authors' Addresses

   Luca Martini
   Monoski LLC

   Email: lmartini@monoski.com


   George Swallow
   Southend Technical Center

   Email: swallow.ietf@gmail.com


   Elisa Bellagamba
   Ericsson EAB
   Torshamnsgatan 48
   16480, Stockholm
   Sweden

   Email: elisa.bellagamba@gmail.com








Martini, et al.              Standards Track                   [Page 20]
^L