RFC 8237

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

📅 published October 2017, from ietf

📬 RFC 8237: MPLS LSP PW Status Refresh Reduction for Static PWs 🎀

Okay bestie, let's get into this one! 💖 This is RFC 8237, and it's a Standards Track document, so it's an official Internet spec. 🌈

The authors are L. Martini (Monoski LLC), G. Swallow (SETC), and E. Bellagamba (Ericsson). The doc is dated October 2017 and it's labelled ISSN 2070-1721. ✨ It doesn't obsolete or update any other RFC, so it's a totally fresh start. 🧚

The whole vibe is that it's about status messages for static pseudowires (PWs) riding on an MPLS Label Switched Path (LSP). 🦋 Instead of every PW shouting its status over and over, the protocol sends one cumulative summary message for all the PWs on the same LSP. Iconic, right? 💅 The Service Provider gets to keep tabs on each PW without flooding the network with periodic messages. 🫶

Let's start with the status and copyright stuff, which is pretty standard but still important. 📜

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 got public review and was approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 7841. 🌸

You can find info about the current status of this doc, any errata, and how to give feedback at https://www.rfc-editor.org/info/rfc8237. 💜

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

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the date of publication. Please read these carefully, because they spell out your rights and restrictions. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License. 🍓

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 🌷

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

1.3. Notational Conventions 🔤

All multiple-word atomic identifiers use underscores ("_") between the words to join them. Lots of identifiers are built by concatenating other identifiers. These get written with double-colon ("::") notation. 🎀

When the same identifier type shows up more than once in a concatenation, it gets qualified by a prefix joined to it with 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 doesn't define any implicit ordering of the information elements in a concatenated identifier. 🌈

Now for the protocol itself, bestie! 🧚‍♀️

2. PW Status Refresh Reduction Protocol 🦋

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

For a particular LSP where this protocol is enabled, a PE using it MUST send the PW status refresh reduction Message as soon as a PW is configured on that LSP. The message then gets retransmitted at a locally configured interval, which is 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's worth noting that there's no relationship between the locally configured timer for this 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. It's also entered if all PWs on a specific LSP are deprovisioned. 🥀

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 stays in this state until a PW status refresh message arrives with the correct local Session ID in the Ack Session ID field. State can transition from STARTUP to ACTIVE or INACTIVE. 👑

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. 🎉 It gets exited immediately in these 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 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.
  • iii. If the new value is smaller than the original one, the PE will operate according to the original timer value for a period of 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. 🦄

Part 1 is done, bestie! 🎀 Part 2 is coming up next with Section 3 and the message encoding, so stay tuned. 💜

3. PW Status Refresh Reduction Procedure ✨

Okay so when the PW status refresh reduction protocol on a particular LSP is in the ACTIVE state, the PE can send all the PW status messages for PWs on that LSP with a Refresh Timer value of zero 💖. This is lowkey iconic because once a PW status message gets acknowledged, repeating it isn't needed anymore, so the PE ends up sending way fewer messages to the remote PE 🦋.

Next, bestie, when an LSP starts forwarding traffic, you wanna get the refresh reduction protocol to the ACTIVE state fast, before the first PW status Refresh Timer runs out ⏰. The way to do that is to use a refresh reduction Message Refresh Timer value that's much smaller than the PW status message Refresh Timer value in use (Section 5.3.1 of [RFC6478]) 🌸.

Now for the sessions that end. 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 that the session was terminated for 😭. In this case the Refresh Timer value MUST NOT be set to 0, and it MUST be set according to the PE router's local policy 📋. Implementations MUST take care to avoid flooding the remote PE with a huge pile of PW status messages all at once 🌊. And if the session is terminated for administrative reasons while the local PE can still talk to the remote PE, the local PE SHOULD pace how fast it sends PW status messages to the remote PE 🫶.

4. PW Status Refresh Reduction Message Encoding 🎀

Here's how the packet that carries the PW status refresh reduction Message is laid out (link-layer info left out):

    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 holds 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].
  • Session ID
    • A non-zero locally selected session number that is not preserved if the local PE restarts.
    • To get a locally unique Session ID, the recommended choice is a CRC-16 ("CRC" stands for "Cyclic Redundancy Check") computed over 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 that calculation lands on a Session ID that already exists, you can add 1 to the result until the Session ID is unique. Any other method of generating a locally unique Session ID is fine too 💅.
  • 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 no control message is present, so no Checksum or later fields are present either 🙈.
  • Checksum
    • A 16-bit field holding 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 while the checksum is computed. An all-zero value means no checksum was sent. Heads up: when the checksum isn't computed, the header of the bundle message isn't covered by any checksum ⚠️.
  • Message Sequence Number
    • An unsigned 16-bit integer that starts at 1 when the protocol enters the ACTIVE state. It wraps back to 1 once it hits the maximum value. 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 been received yet 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
    • When a PE gets an unknown message or TLV and U is clear (0), it MUST send a notification message with code "Unknown TLV (U-Bit=0)" (code 0x4) 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 the message containing an unknown TLV, MUST be acknowledged and silently ignored, and the following messages or TLVs (if any) get processed as if the unknown message or TLV never existed 🦋. In that 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 signals the end of PW configuration transmission. If it's set, the sending PE has finished sending all of its current configuration information ✅.
  • Flags
    • 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.
  • Control Message Body
    • The Control Message Body is defined in Section 5 and is specific to the type of message.

Okay, here's the bit that's easy to mix up 👀. The Checksum, Message Sequence Number, Last Received Message Sequence Number, Message Type, Flags, and Control Message Body are all OPTIONAL. The Total Message Length field is what tells you how many of those optional fields are included. So if a specific implementation needs a given field included, then every optional field that comes before it MUST be included as well 🧚.

If any of the values above fall outside the specified range, a notification message gets sent back with code "PW configuration not supported", and the message is ignored 💀.

5. PW Status Refresh Reduction Control Messages 💜

PW status refresh reduction Control Messages are made up 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 go out, the system can attach it to a scheduled PW status refresh reduction Message, or send it ahead of time. Either way, 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 carries 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 message doesn't understand the control message, that control message MUST be silently ignored. But 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 isn't 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 💥.

If a PE doesn't 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 set to 0 ✨.

5.1. Notification Message

The most common use of the notification message is acknowledging that a message was received, by putting 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 count as either "Error codes" or simple notifications. If the Notification Code is an Error code as listed in the IANA allocation registry, the keepalive session MUST be terminated by entering the STARTUP state 🚨.

When there's no notification info to send, the notification code is set to 0 to mean 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 ✨

Okay so the PW status refresh reduction TLVs are informational TLVs 🔍 that let the remote PE double-check certain provisioning info. This message is basically a bundle of sub-TLVs, in no particular order 🎀, carrying PW and LSP configuration info. There's no preset length limit, but the whole thing is capped by the transport network's Maximum Transmission Unit (MTU) 📏. PW status refresh reduction Messages MUST NOT be fragmented 🙅‍♀️, so no splitting them up. If a sender has more config than fits into one PW Configuration Message, they can send extra messages carrying extra TLVs 💅.

       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, because processing these messages is OPTIONAL 🫶.

The C-Bit is the "we're done" signal 🏁. It marks the end of PW configuration transmission. If it's set, the sending PE has finished sending all of its current configuration info. The PE transmitting the config MUST set the C-Bit on the last PW Configuration Message once all current PW configuration info 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 carries the MPLS-TP Tunnel ID. ("MPLS-TP" stands for "MPLS Transport Profile", bestie 🙈.) When the configuration message is used for a particular keepalive session, the MPLS-TP Tunnel ID sub-TLV MUST be sent at least once 🔁.

The MPLS-TP Tunnel ID is encoded like this:

       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 from the length of the TLV, up to a maximum of 8 🧮. The procedure for processing this TLV will be described in Section 6 👑.

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 from 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 🛑.

If PW configuration information is received, it gets used to verify the accuracy of the local configuration against the remote PE's configuration 🕵️‍♀️. 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 it sent. It does this by setting the C-Bit when all currently known configuration information has been sent 🏁. This lets the receiving PE immediately go ahead and verify all the currently configured PWs on that LSP, so there's no 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 misconfiguration events caused by 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 🛡️. Worth noting 👀: 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 🔒.

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

8.3. PW Status Refresh Reduction Notification Codes ✨

okay so this registry is where all the notification codes live, bestie 🗂️💖 IANA set it up, and it holds 32-bit values. Type values 0 through 7 are defined right here in this document. Values 8 through 65536 and 134,217,729 through 4,294,967,294 get handed out by IANA using the "Expert Review" policy from [RFC8126]. Values 65537 through 134,217,728, plus 0 and 4,294,967,295, are allocated using the "IETF Review" policy from [RFC8126]. 🌸

Not me being extra, but there's a rule for the "Error?" column too 🙈. For each value that gets assigned, IANA should also track whether it counts as an error, as described in Section 5.1. When values come in through IETF Review, the "Error?" settings MUST be documented in the RFC that requests the allocation. For "Expert Review" assignments, the requester MUST make the "Error?" settings clear at the time of assignment. 💅

Here are the Type values, as assigned:

   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 set up the "PW Status Refresh Reduction Message Flags" registry, and it's an 8-bit one 🦋. The first two most significant bits were allocated by this document, and they look like this:

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

The remaining bits get allocated using the "IETF Review" policy from [RFC8126]. 🧚

8.5. G-ACh Registry Allocation 🌈

okay this one's giving "registry crossover episode" 😭. IANA keeps a registry called "MPLS Generalized Associated Channel (G-ACh) Types (including Pseudowire Associated Channel Types)", and IANA has allocated a new value in it, like this:

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

8.6. Guidance for Designated Experts 👑

the Designated Expert (DE) has a whole checklist, and it's honestly so organized 🫶. In every case of review by the DE described here, the DE is expected to confirm that suitable documentation (a specification) exists, 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 fits the general architecture and intended purpose of the respective message or TLV. Lastly, the DE SHOULD check that any assignment doesn't duplicate or conflict with work that is active or already published within the IETF. ✨

9. References 📚

9.1. Normative References 💜

9.2. Informative References 🌸

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

and that's a wrap on RFC 8237, bestie!! 💖🎀 the crew behind it (Martini, Swallow, and Bellagamba) built something genuinely iconic 👑✨

📦 where this page comes from