RFC 7267

Dynamic Placement of Multi-Segment Pseudowires

📅 published June 2014, from ietf

Dynamic Placement of Multi-Segment Pseudowires 🎀

Okay bestie, the paperwork first 📋✨ This is RFC 7267, and it's from the IETF (Internet Engineering Task Force). It came out in June 2014 🗓️ and it's a Standards Track document, so it's the real deal. L. Martini, Ed. is from Cisco Systems, Inc., M. Bocci, Ed. co-wrote it, and F. Balus, Ed. is from Alcatel-Lucent. It updates RFC 6073 and doesn't obsolete anything. The ISSN is 2070-1721 🔥

Abstract ✨

Okay so, RFC 5254 lays out what service providers need to stretch pseudowires (PWs) across several Packet Switched Network domains, and it's giving big-league ambition 💅 A multi-segment PW is a set of two or more contiguous PW segments that act like one single point-to-point PW. This doc adds extensions to the PW control protocol so those segments can be dynamically placed among a set of Provider Edge (PE) routers. It also updates RFC 6073 by changing the value of the Length field of the PW Switching Point PE Sub-TLV Type 0x06 to 14. Iconic 👑

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 went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 5741 🦋

Info about the current status of this document, any errata, and how to send feedback is at http://www.rfc-editor.org/info/rfc7267.

Copyright Notice ⚖️

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the date this document was published. Please read these carefully, because they describe your rights and restrictions for this document. 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 with no warranty, as described in the Simplified BSD License.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The people controlling the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. Unless you get an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌈

Table of Contents 🗂️

   1. Introduction ....................................................4
      1.1. Scope ......................................................4
      1.2. Specification of Requirements ..............................4
      1.3. Terminology ................................................4
      1.4. Architecture Overview ......................................5
   2. Applicability ...................................................6
      2.1. Changes to Existing PW Signaling ...........................6
   3. PW Layer 2 Addressing ...........................................6
      3.1. Attachment Circuit Addressing ..............................7
      3.2. S-PE Addressing ............................................8
   4. Dynamic Placement of MS-PWs .....................................8
      4.1. Pseudowire Routing Procedures ..............................8
           4.1.1. AII PW Routing Table Lookup Aggregation Rules .......9
           4.1.2. PW Static Route .....................................9
           4.1.3. Dynamic Advertisement with BGP .....................10
      4.2. LDP Signaling .............................................11
           4.2.1. Multiple Alternative Paths in PW Routing ...........13
           4.2.2. Active/Passive T-PE Election Procedure .............14
           4.2.3. Detailed Signaling Procedures ......................15
   5. Procedures for Failure Handling ................................16
      5.1. PSN Failures ..............................................16
      5.2. S-PE Failures .............................................17
      5.3. PW Reachability Changes ...................................17
   6. Operations, Administration, and Maintenance (OAM) ..............18
   7. Security Considerations ........................................18
   8. IANA Considerations ............................................19
      8.1. Correction ................................................19
      8.2. LDP TLV Type Name Space ...................................19
      8.3. LDP Status Codes ..........................................20
      8.4. BGP SAFI ..................................................20
   9. References .....................................................20
      9.1. Normative References ......................................20
      9.2. Informative References ....................................21
   10. Contributors ..................................................22
   11. Acknowledgements ..............................................23

1. Introduction 💖

1.1. Scope 🔭

Okay so, [RFC5254] covers what service providers need to extend the reach of pseudowires across multiple Packet Switched Network (PSN) domains. This is done with a multi-segment pseudowire (MS-PW). An MS-PW is a set of two or more contiguous pseudowire (PW) segments that behave and function as a single point-to-point PW. The architecture is described in [RFC5659] 🧚

The procedures for setting up a PW across a single PSN domain are in [RFC4447], and the procedures for setting up PWs across multiple PSN domains or control plane domains are in [RFC6073].

The point of this document is to extend the pseudowire control protocol [RFC4447] and the [RFC6073] procedures so MS-PWs can be dynamically placed. The procedures follow the guidelines in [RFC5036], and they reuse existing TLVs and the procedures [RFC4447] defines for Single-Segment Pseudowires (SS-PWs). Dynamic placement of point-to-multipoint (P2MP) PWs is for further study and is out of scope here 🙈

1.2. Specification of Requirements 📏

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 💅

1.3. Terminology 📖

[RFC5659] provides the terminology for multi-segment pseudowires.

This document defines these extra terms:

Source Terminating Provider Edge (ST-PE): A Terminating Provider Edge (T-PE) that takes on the active signaling role and starts the signaling for multi-segment PWs.
Target Terminating Provider Edge (TT-PE): A Terminating Provider Edge (T-PE) that takes on the passive signaling role. It waits, then responds to the multi-segment PW signaling message in the reverse direction.
Forward Direction: ST-PE to TT-PE.
Reverse Direction: TT-PE to ST-PE.
Pseudowire Routing (PW routing): The dynamic placement of the segments that make up an MS-PW, plus the automatic selection of Switching PEs (S-PEs). 🦋

1.4. Architecture Overview 🗺️

Here's the reference model, taken from [RFC5659], for supporting PW emulated services with multi-segment PWs:

      Native  |<---------Multi-Segment Pseudowire-------->|  Native
      Service |          PSN                PSN           |  Service
       (AC)   |     |<--Tunnel-->|     |<--Tunnel-->|     |   (AC)
         |    V     V     1      V     V     2      V     V     |
         |    +-----+            +-----+            +-----+     |
   +---+ |    |T-PE1|============|S-PE1|============|T-PE2|     | +---+
   |   |------|...... PW.Seg't 1....X....PW.Seg't 3.......|-------|   |
   |CE1| |    |     |            |     |            |     |     | |CE2|
   |   |------|...... PW.Seg't 2....X....PW.Seg't 4.......|-------|   |
   +---+ |    |     |============|     |============|     |     | +---+
       ^      +-----+            +-----+            +-----+       ^
       |   Provider Edge 1          ^          Provider Edge 2    |
       |                            |                             |
       |                            |                             |
       |                    PW switching point                    |
       |                                                          |
       |<-------------------- Emulated Service ------------------>|

                      Figure 1: MS-PW Reference Model

The PEs that serve CE1 and CE2 are Terminating PE1 (T-PE1) and Terminating PE2 (T-PE2), in that order. A PSN tunnel runs from T-PE1 to Switching PE1 (S-PE1), and a second PSN tunnel runs from S-PE1 to T-PE2. PWs connect the attachment circuits (ACs) on PE1 to the matching ACs on T-PE2 ✨

A PW segment on PSN Tunnel 1 gets connected to a PW segment on PSN Tunnel 2 at S-PE1, which completes the multi-segment PW (MS-PW) between T-PE1 and T-PE2. That makes S-PE1 the PW switching point, and it's called the switching provider edge (S-PE). PW Segment 1 and PW Segment 3 belong to the same MS-PW, while PW Segment 2 and PW Segment 4 belong to a different MS-PW. PW segments of the same MS-PW (for example, PW Segment 1 and PW Segment 3) MUST be the same PW type, and their PSN tunnels can use the same technology or different ones. An S-PE switches an MS-PW from one segment to another based on the PW identifiers (PWid, or Attachment Individual Identifier (AII)). How the PW protocol data units (PDUs) get switched at the S-PE depends on the PSN tunnel technology. For an MPLS PSN going to another MPLS PSN, the PW switching is a standard MPLS label swap operation 🔥

Heads up, although Figure 1 only shows one S-PE, a PW may pass through more than one S-PE along its path. [RFC5659] describes MS-PWs that span more than one PSN, but this document doesn't specify how the Label Distribution Protocol (LDP) is used for PW control [RFC4447] in an inter-AS (Autonomous System) environment 🙈

2. Applicability 🎯

This document covers the case where the PSNs carrying the MS-PW are only MPLS PSNs that use the Generalized Pseudowire Identifier (PWid) Forwarding Equivalence Class (FEC) element, also known as FEC 129.

Interactions with an IP PSN that uses the Layer 2 Tunneling Protocol version 3 (L2TPv3), as described in Section 8 of [RFC6073], are left for further study.

2.1. Changes to Existing PW Signaling 🛠️

The procedures in this document use the existing LDP TLVs and related PW signaling procedures described in [RFC4447] and [RFC6073]. It also defines one optional TLV:

A Bandwidth TLV to address QoS Signaling requirements (see Section 4.2).

This document also updates the value of the Length field of the PW Switching Point PE Sub-TLV Type 0x06 to 14 💜

3. PW Layer 2 Addressing ✨

okay so single-segment pseudowires on an MPLS PSN can totally use attachment circuit identifiers for a PW using FEC 129 🎀 but when an MS-PW is dynamically placed, those identifiers have to be globally unique so reachability and manageability work 🌍 bestie, looking at Figure 1 above, individual globally unique addresses MUST be allocated to all the ACs and S-PEs of an MS-PW 💖

3.1. Attachment Circuit Addressing

the AC addressing is derived from AII Type 2 [RFC5003], and it looks 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  AII Type=02  |    Length     |        Global ID              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       Global ID (continued)   |        Prefix                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       Prefix (continued)      |        AC ID                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      AC ID                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: AII Type 2 TLV Structure

the fields are defined in Section 3.2 of [RFC5003] 📝

AII Type 2 addressing lets you have varying levels of AII summarization, which takes some pressure off PW routing 🧠 it's a great fit for point-to-point provisioning models where auto-discovery of the address at the TT-PE isn't needed, because the address is already known a priori by provisioning 💅

Implementations of the following procedure MUST interpret the AII type to figure out the meaning of the address format of the AII, no matter how many segments the MS-PW has ✨ and all segments of the PW MUST be signaled with the same AII type 🫶

each AC gets its own unique combo of Global ID, Prefix, and AC ID parts of the AII Type 2 💖 generally the same Global ID and Prefix are assigned to all the ACs on the same T-PE, but that's not a strict requirement, okay 🙈 a particular T-PE might have more than one Prefix, and a fully qualified AII with the same Global ID/Prefix but different AC IDs might belong to different T-PEs 🌸

for MS-PWs, the AII MUST be globally unique across all PSNs that are spanned by the MS-PW 👑

the AII for a local attachment circuit of a given T-PE of an MS-PW, and the AII of the matching attachment circuit on the far-end T-PE (with respect to the LDP signaling), are known as the Source Attachment Individual Identifier (SAII) and Target Attachment Individual Identifier (TAII) as per [RFC6074] 🦋

3.2. S-PE Addressing

each S-PE MUST be assigned an address that uniquely identifies it from a pseudowire perspective, so it can populate the PW Switching Point PE (SP-PE) TLV specified in [RFC6073] 🧚 for this, at least one Attachment Identifier (AI) address in a format similar to AII Type 2 [RFC5003], made of only the Global ID and Prefix parts, MUST be assigned to each S-PE 💜

if an S-PE can do dynamic MS-PW signaling but doesn't have an S-PE address assigned, then when it gets a dynamic MS-PW Label Mapping message, the S-PE MUST return a Label Release with the "Resources Unavailable" (0x38) status code 💀 nope nope nope, that's a whole mood 😭

4. Dynamic Placement of MS-PWs 🚀

okay so [RFC6073] describes a procedure for concatenating multiple pseudowires together, but it requires each S-PE to be manually configured with the info for each segment of the MS-PW 🥱 the procedures in the following sections extend [RFC6073] by letting the S-PEs automatically select predefined S-PEs and dynamically set up an MS-PW between two T-PEs. iconic, honestly 👑

4.1. Pseudowire Routing Procedures

the AII Type 2 described above contains a Global ID, Prefix, and AC ID 🧩 the TAII is what S-PEs use to figure out the next SS-PW destination for LDP signaling 💌

once an S-PE gets an MS-PW Label Mapping message with a TAII containing an AII that isn't locally present, the S-PE does a lookup in a PW AII routing table 🔍 if that lookup gives back an IP address for the next-hop PE with reachability info for the AII in question, the S-PE will start the LDP messaging procedure to set up the next PW segment ✨ but if the PW AII routing table lookup doesn't give an IP address for a next-hop PE, the destination AII is unreachable, and the PW setup MUST fail 💔 in that case, the next PW segment counts as unprovisioned, and a Label Release MUST be returned to the T-PE with a status message of "AII Unreachable" 🙅‍♀️

if the TAII of an MS-PW Label Mapping message received by a PE has a Prefix that matches the locally provisioned prefix on that PE, but the AC ID isn't provisioned, then the LDP liberal label retention procedures apply, and the Label Mapping message is retained 🧃

to allow dynamic end-to-end signaling of MS-PWs, information MUST be present in S-PEs to support figuring out the next PW signaling hop 🗺️ that info can be provisioned on each S-PE (equivalent to a static route), or disseminated via regular routing protocols (e.g., BGP) 🛰️

4.1.1. AII PW Routing Table Lookup Aggregation Rules

all PEs capable of dynamic MS-PW path selection MUST build a PW AII routing table to be used for PW next-hop selection 📚

the PW addressing scheme (AII Type 2 as defined in [RFC5003]) consists of a Global ID, a 32-bit Prefix, and a 32-bit Attachment Circuit ID 🎀

an aggregation scheme similar to the one used for classless IPv4 addresses can be employed 🌈 a length mask (8 bits) is specified as a number from 0 to 96 that tells you which Most Significant Bits (MSBs) are relevant in the address field when doing the PW address-matching algorithm 🧮

                 0        31 32    63 64    95 (bits)
                +-----------+--------+--------+
                | Global ID | Prefix | AC ID  |
                +-----------+--------+--------+

Figure 3: PW Addressing Scheme

during the signaling phase, the content of the (fully qualified) TAII Type 2 field from the FEC 129 TLV is compared against routes in the PW routing table 🔎 just like the IPv4 case, the route with the longest match wins, and that decides the next signaling hop and, implicitly, the next PW segment to be signaled 🏆

4.1.2. PW Static Route

for figuring out the next signaling hop for a segment of the pseudowire, PEs MAY be provisioned with fixed-route entries in the PW next-hop routing table 📌 the static PW entries follow all the addressing and aggregation rules from the previous sections 🤓 the most common use of PW static provisioned routes is the "default" route entry, like this:

Global ID = 0 Prefix = 0 AC ID = 0, Prefix Length = 0
Next Signaling Hop = {IP Address of next-hop S-PE or T-PE}

4.1.3. Dynamic Advertisement with BGP

any suitable routing protocol that can carry external routing information MAY be used to propagate MS-PW path information among S-PEs and T-PEs 🛣️ however, T-PEs and S-PEs MAY choose to use the Border Gateway Protocol (BGP) [RFC4271] with the Multiprotocol Extensions defined in [RFC4760] to propagate PW address information throughout the PSN 🦋 PW address info only gets propagated by PEs that can do PW switching, so the multiprotocol BGP neighbor topology MUST coincide with the topology of T-PEs and S-PEs 🫧

this is different from Layer 2 VPN signaling methods that use BGP for auto-discovery [RFC6074] 🙃 with a dynamically placed MS-PW, the source T-PE already knows (by provisioning) the AC ID on the terminating T-PE that signaling should use 💡 so there's no need to advertise a "fully qualified" 96-bit address for each PW attachment circuit 🙌 only the T-PE Global ID, Prefix, and prefix length need to be advertised as part of the well-known BGP procedures; see [RFC4760] 📣

since PW Endpoints are provisioned in the T-PEs, the ST-PE uses this info to get the first S-PE hop (i.e., the first BGP next hop) to where the first PW segment will be established 🚦 any subsequent S-PEs use the same info (i.e., the next BGP next hop(s)) to find the next signaling hop(s) on the path to the TT-PE 🛤️

the PW dynamic path Network Layer Reachability Information (NLRI) is advertised in BGP UPDATE messages using the MP_REACH_NLRI and MP_UNREACH_NLRI attributes [RFC4760] 📬 the {AFI, SAFI} value pair that identifies this NLRI is (AFI=25, SAFI=6) 🔢 a route target MAY also be advertised along with the NLRI 🎯

the Next Hop field of the MP_REACH_NLRI attribute SHALL be interpreted as an IPv4 address whenever the length of the NextHop address is 4 octets, and as an IPv6 address whenever the length of the NextHop address is 16 octets 🌐

the NLRI field in MP_REACH_NLRI and MP_UNREACH_NLRI is a prefix made of an 8-octet Route Distinguisher, the Global ID, the Prefix, and the AC ID, encoded as defined in Section 4 of [RFC4760] 🧁

this NLRI is structured like so:

     Bit
     0     7 8             71 72      103 104  135 136   167
     +------+----------------+-----------+--------+--------+
     |Length|  Route Dist    | Global ID | Prefix | AC ID  |
     +------+----------------+-----------+--------+--------+

Figure 4: NLRI Field Structure

the Length field is the prefix length of the Route Distinguisher + Global ID + Prefix + AC ID in bits 📏 except for the default PW route, which is encoded as a 0-length Prefix, the minimum value of the Length field is 96 bits 💫 lengths of 128 bits to 159 bits are invalid, because the AC ID field can't be aggregated 🚫 and the maximum value of the Length field is 160 bits 🌟 BGP advertisements received with invalid Prefix lengths MUST be rejected as having a bad packet format 🙅‍♀️💅

4.2. LDP Signaling 💖

okay so the LDP signaling procedures are described in [RFC4447] and then expanded in [RFC6073] ✨ good news, no new LDP signaling components are required for setting up a dynamically placed MS-PW 🙌 there are some optional signaling extensions we can look at below though 🎀

one of the requirements that MUST be met to hit the QoS objectives for a PW on a segment is that a PSN tunnel MUST be selected that can support at least the required class of service and that has sufficient bandwidth available 🔥 no cap, this part is non-negotiable.

that tunnel selection is easy when the next hop for a PW segment is explicitly configured at each PE 💅 that PE can be a T-PE or an S-PE in a segmented PW, and you don't need dynamic path selection (as per [RFC6073]). in that case, the bandwidth for the PW can be explicitly configured so the T-PE or S-PE can reserve it on the PSN tunnel 🧚

but when dynamic path selection is used, the next hop is not explicitly configured by the operator at the S-PE 😭 so there needs to be a way to signal the bandwidth for the PW from the T-PE to the S-PEs. this is done with an optional PW Bandwidth TLV 🦋 the PW Bandwidth TLV is laid out 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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |1|0|     PW BW TLV  (0x096E)   |          TLV  Length          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     Forward SENDER_TSPEC                      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     Reverse SENDER_TSPEC                      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 5: PW Bandwidth TLV Structure 🌸

here's what each PW Bandwidth TLV field means, bestie 👑

TLV Length: the length of the value fields in octets. Value = 64.
Forward SENDER_TSPEC = the SENDER_TSPEC for the forward direction of the PW, as defined in Section 3.1 of [RFC2210].
Reverse SENDER_TSPEC = the SENDER_TSPEC for the reverse direction of the PW, as defined in Section 3.1 of [RFC2210].

the full details of what goes inside the SENDER_TSPEC objects are in Section 3.1 of [RFC2210] 🤓 the forward SENDER_TSPEC is for the data path going from ST-PE to TT-PE, and the reverse SENDER_TSPEC is for the data path going from TT-PE to ST-PE 🦋

in the forward direction, once the next-hop selection is done, a T/S-PE SHOULD reference the forward SENDER_TSPEC object to figure out an appropriate PSN tunnel toward the next signaling hop ✨ if that tunnel exists, the MS-PW signaling procedures get invoked with the PW Bandwidth TLV included 💖 when the PE searches for a PSN tunnel, any tunnel pointing to a next hop equivalent to the selected next hop gets included in the search. the LDP address TLV is what decides next-hop equivalence 🧠

when an S/T-PE gets a PW Bandwidth TLV, once the PW next hop is selected, the S/T-PE MUST request the appropriate resources from the PSN 💅 the resources described in the reverse SENDER_TSPEC get allocated from the PSN toward the originator of the message or the previous hop. and when resources are allocated from the PSN for a specific PW, the allocation SHOULD account for the resource usage of that PW 🫶

now for the case where PSN resources toward the previous hop aren't available 😬 the following procedure MUST be followed:

i. The PSN MAY allocate more QoS resources, e.g., bandwidth, to the PSN tunnel.

ii. The S-PE MAY attempt to set up another PSN tunnel to accommodate the new PW QoS requirements.

iii. If the S-PE cannot get enough resources to set up the segment in the MS-PW, a Label Release MUST be returned to the previous hop with a status message of "Bandwidth resources unavailable".

in that last case, the T-PE that receives the status message MUST also withdraw the corresponding PW Label Mapping message for the opposite direction, if it has already been successfully set up 💀

if an ST-PE receives a Label Mapping message, the following procedure MUST be followed:

if the ST-PE has already sent a Label Mapping message for this PW, then the ST-PE MUST check whether this Label Mapping message came from the same LDP peer that the corresponding Label Mapping message for this particular PW was sent to 👀 if it's the same peer, the PW is established 🎉 if it's a different peer, then the ST-PE MUST send a Label Release message with a status code of "PW Loop Detected" to the PE that originated the LDP Label Mapping message. loop detected, not it 🙅‍♀️

if the PE has not yet sent a Label Mapping message for this particular PW, then it MUST send the Label Mapping message to this LDP peer, regardless of what the PW TAII routing lookup result is 🌈

4.2.1. Multiple Alternative Paths in PW Routing

okay, a next-hop selection for a specific PW might match a PW route with multiple next hops attached to it 🛣️ those next hops can be configured explicitly as static routes or learned through BGP routing procedures. implementations at an S-PE or T-PE MAY use selection algorithms, such as CRC32 on the FEC TLV or flow-aware transport of PWs [RFC6391], to load balance PWs across multiple next hops, so that each PW has a single next hop 🧁 the details of those selection algorithms are outside the scope of this document, so we're not going there today 🙈

4.2.2. Active/Passive T-PE Election Procedure

when an MS-PW is signaled, each T-PE might start signaling the MS-PW on its own 😵 which could mean each direction of the PW ends up using a different path, and that is not the vibe 🙅‍♀️ to avoid this, one T-PE MUST initiate PW signaling (so it takes the active role), while the other T-PE waits to receive the LDP Label Mapping message before it sends the LDP Label Mapping message for the reverse direction of the PW (so it takes the passive role). the active T-PE (the ST-PE) and the passive T-PE (the TT-PE) MUST be identified before signaling begins for a given MS-PW. and both T-PEs MUST use the same method for working out which one is active and which one is passive 🤝

a T-PE SHOULD decide whether it takes the active or the passive role using procedures similar to those in [RFC5036], Section 2.5.2, Bullet 2 ✨ the T-PE compares the Source Attachment Individual Identifier (SAII) [RFC6074] with the Target Attachment Individual Identifier (TAII) [RFC6074] as unsigned integers. if the SAII > TAII, the T-PE assumes the active role. otherwise, it assumes the passive role 💜

the following procedure for comparing the SAII and TAII as unsigned integers SHOULD be used:

If the SAII Global ID > TAII Global ID, then the T-PE is active
- else if the SAII Global ID < TAII Global ID, then the T-PE is passive
  - else if the SAII Prefix > TAII Prefix, then the T-PE is active
    - else if the SAII Prefix < TAII Prefix, then the T-PE is passive
      - else if the SAII AC ID > TAII AC ID, then the T-PE is active
        
        else if the SAII AC ID < TAII AC ID, then the T-PE is passive
        
        else there is a configuration error

4.2.3. Detailed Signaling Procedures

okay, when a Label Mapping message comes in, the S-PE MUST inspect the FEC TLV 🔍 if the receiving node has no local AII matching the TAII for that Label Mapping message, then the Label Mapping message SHOULD be forwarded on to another S-PE or T-PE. the S-PE will check whether the FEC is already installed for the forward direction 🧐

If the FEC is already installed and the received Label Mapping was received from the same LDP peer that the forward LDP Label Mapping was sent to, then this Label Mapping represents signaling in the reverse direction for this MS-PW segment.
If the FEC is already installed and the received Label Mapping was received from a different LDP peer than the one the forward LDP Label Mapping was sent to, then the received Label Mapping MUST be released with a status code of "PW Loop Detected". 🔁
If the FEC is not already installed, then this represents signaling in the forward direction.

then the following procedures run, depending on whether the Label Mapping was determined to be for the forward or the reverse direction of the MS-PW 🎀

for the forward direction:

i. Determine the next-hop S-PE or T-PE according to the procedures above. If next-hop reachability is not found in the S-PE's PW AII routing table, then a Label Release MUST be sent with status code "AII Unreachable". If the next-hop S-PE or T-PE is found and is the same LDP peer that sent the Label Mapping message, then a Label Release MUST be returned with status code "PW Loop Detected". If the SAII in the received Label Mapping is local to the S-PE, then a Label Release MUST be returned with status code "PW Loop Detected".

ii. Check to see if a PSN tunnel exists to the next-hop S-PE or T-PE. If no tunnel exists to the next-hop S-PE or T-PE, the S-PE MAY attempt to set up a PSN tunnel.

iii. Check to see if a PSN tunnel exists to the previous hop. If no tunnel exists to the previous-hop S-PE or T-PE, the S-PE MAY attempt to set up a PSN tunnel.

iv. If the S-PE cannot get enough PSN resources to set up the segment to the next-hop or previous-hop S-PE or T-PE, a Label Release MUST be returned to the T-PE with a status message of "Resources Unavailable". 🚫

v. If the Label Mapping message contains a Bandwidth TLV, allocate the required resources on the PSN tunnels in the forward and reverse directions according to the procedures above.

vi. Allocate a new PW label for the forward direction.

vii. Install the FEC for the forward direction.

viii. Send the Label Mapping message with the new forward label and the FEC to the next-hop S-PE/T-PE. 🚀

for the reverse direction:

i. Install the FEC received in the Label Mapping message for the reverse direction.

ii. Determine the next signaling hop by referencing the LDP sessions used to set up the PW in the forward direction.

iii. Allocate a new PW label for the next hop in the reverse direction.

iv. Install the FEC for the next hop in the reverse direction.

v. Send the Label Mapping message with a new label and the FEC to the next-hop S-PE/ST-PE. 💖

5. Procedures for Failure Handling 🦋

5.1. PSN Failures 💅

failures of the PSN tunnel MUST be handled by PSN mechanisms 🛠️ one example of such a PSN mechanism is MPLS fast reroute [RFC4090]. if the PSN can't re-establish the PSN tunnel, then the S-PE SHOULD follow the procedures defined in Section 10 of [RFC6073] 🫶

5.2. S-PE Failures 🚨

okay so for defects inside an S-PE, the procedures in [RFC6073] SHOULD be followed 💅. A T-PE or S-PE can get an unsolicited Label Release message from another S-PE or T-PE carrying failure codes like "Loop Detected", "PW Loop Detected", "Resources Unavailable", "Bad Strict Node Error", or "AII Unreachable". They all basically mean the same thing: a generic PW failure at an S-PE or T-PE 😭.

If a T-PE gets an unsolicited Label Release with one of those failure status codes, it is RECOMMENDED that the T-PE try to re-establish the PW right away 🏃‍♀️. BUT the T-PE MUST throttle its PW setup retries with exponential backoff when setup messages keep getting released over and over, so it doesn't spam the network 🛑. It's also RECOMMENDED that a T-PE that notices this kind of situation tell an operator 🫶.

S-PEs that receive an unsolicited Label Release with a failure status code SHOULD follow this procedure:

i. If the Label Release is received from an S-PE or T-PE in the forward or reverse signaling direction, then the S-PE MUST tear down both segments of the PW. The status code received in the Label Release message SHOULD be propagated when sending the Label Release for the next segment ✨.

5.3. PW Reachability Changes 🦋

in general, an established MS-PW is not affected by next-hop changes in AII reachability information. It's main character energy when it stays stable 👑.

If there is a next-hop change in AII reachability information in the forward direction, the T-PE MAY elect to tear down the MS-PW by sending a Label Withdraw message to the downstream S-PE or T-PE. The teardown MUST also be accompanied by an unsolicited Label Release message, and then the T-PE will try to re-establish the MS-PW 🔁.

If there is a change in the AII reachability information in the forward direction at an S-PE, the S-PE MAY elect to tear down the MS-PW in both directions. A label withdrawal is sent in each direction, followed by an unsolicited Label Release. The unsolicited Label Release messages MUST be accompanied by the status code "AII Unreachable". This procedure is OPTIONAL. Heads up though, this one is likely to be disruptive to the emulated service 🙈. PW Redundancy [RFC6718] MAY be used to keep the connectivity the emulated service relies on when the PSN or an S-PE fails 🌈.

A change in AII reachability information in the reverse direction has no effect on an MS-PW 💅.

6. Operations, Administration, and Maintenance (OAM) 🔧

The OAM procedures defined in [RFC6073] may also be used for dynamically placed MS-PWs 🧚. A PW Switching Point PE TLV [RFC6073] is used to record the switching points that the PW traverses 🍓.

In the case of an MS-PW where the PW Endpoints are identified by using globally unique AII addresses based on FEC 129, there is no pseudowire identifier (PWid) defined on a per-segment basis. Instead, each individual PW segment is identified by the address of the adjacent S-PE(s) together with the SAII and TAII 💜.

In this case, the following TLV type (0x06) MUST be used in place of type 0x01 in the PW Switching Point PE TLV:

   Type      Length    Description
   ----      ------    -----------------------------------
   0x06        14      L2 PW address of PW Switching Point

The above sub-TLV MUST be included in the PW Switching Point PE TLV once per individual PW switching point, following the same rules and procedures as those described in [RFC6073] 🫶. A more detailed description of this sub-TLV is also given in Section 7.4.1 of [RFC6073]. However, the length value MUST be set to 14. ([RFC6073] states that the length value is 12, but that doesn't correctly represent the actual length of the TLV, so we fix it here 🙅‍♀️.)

7. Security Considerations 🔐

This document specifies extensions to the protocols already defined in [RFC4447] and [RFC6073]. The extensions defined here do not affect the security considerations for those protocols. BUT [RFC4447] and [RFC6073] do impose a set of security considerations that apply to the protocol extensions specified in this document, so don't skip them 💀.

Okay, this part is kinda important. The dynamic path selection mechanisms specified in this document let the network automatically pick the S-PEs that forward packets on the MS-PW 🤖. An operator can use tools like the Virtual Circuit Connectivity Verification (VCCV) trace mechanisms specified in [RFC6073] to check the path the MS-PW takes, and then feel confident that the path isn't an extra security risk 🕵️‍♀️.

Note that the PW control protocol may be used to establish and maintain an MS-PW across administrative boundaries 🌍. Section 13 of [RFC6073] covers the security considerations for LDP when it's used this way, including establishing the integrity of LDP control messages and authenticating them. Those considerations apply to the protocol extensions in this document too 🔒.

Also, the protocols for dynamically distributing AII reachability information may have their own security considerations. Those protocol specifications are outside the scope of this document 🧐.

8. IANA Considerations 📋

8.1. Correction

IANA has fixed a minor error in the "Pseudowire Switching Point PE sub-TLV Type" registry 🛠️. The entry 0x06 "L2 PW address of the PW Switching Point" has been corrected to Length 14, and its reference has been changed to [RFC6073] and this document, like so:

   Type  Length  Description                          Reference
   ----  ------  -----------------------------------  ------------------
   0x06    14    L2 PW Address of PW Switching Point  [RFC6073][RFC7267]

8.2. LDP TLV Type Name Space

This document defines one new LDP TLV type ✨. IANA already maintains a registry for LDP TLV types, called the "TLV Type Name Space" registry, within the "Label Distribution Protocol (LDP) Parameters" registry, as defined by [RFC5036]. IANA has assigned the following value 🎀.

     Value    Description     Reference       Notes/Registration Date
     ------   -------------   -------------   -----------------------
     0x096E   Bandwidth TLV   This document

8.3. LDP Status Codes

This document defines three new LDP status codes 🌸. IANA maintains a registry of these codes, called the "Status Code Name Space" registry, in the "Label Distribution Protocol (LDP) Parameters" registry, as defined by [RFC5036]. IANA has assigned the following values 💖.

   Range/Value    E     Description                       Reference
   -----------  -----   -------------------------------   -------------
   0x00000037     0     Bandwidth resources unavailable   This document
   0x00000038     0     Resources Unavailable             This document
   0x00000039     0     AII Unreachable                   This document

8.4. BGP SAFI

IANA has allocated a new BGP SAFI for "Network Layer Reachability Information used for Dynamic Placement of Multi-Segment Pseudowires" in the IANA "SAFI Values" registry [RFC4760], within the "Subsequent Address Family Identifiers (SAFI) Parameters" registry. IANA has assigned the following value 🦋.

   Value   Description                                   Reference
   -----   -------------------------------------------   -------------
   6       Network Layer Reachability Information        This document
           used for Dynamic Placement of Multi-Segment
           Pseudowires

9. References 📚

9.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC5003] Metz, C., Martini, L., Balus, F., and J. Sugimoto, "Attachment Individual Identifier (AII) Types for Aggregation", RFC 5003, September 2007.
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011.

9.2. Informative References

[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[RFC5254] Bitar, N., Ed., Bocci, M., Ed., and L. Martini, Ed., "Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)", RFC 5254, October 2008.
[RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, October 2009.
[RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, January 2011.
[RFC6391] Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V., Regan, J., and S. Amante, "Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network", RFC 6391, November 2011.
[RFC6718] Muley, P., Aissaoui, M., and M. Bocci, "Pseudowire Redundancy", RFC 6718, August 2012.

10. Contributors 🌷

The editors gratefully acknowledge the following people for their contributions to this document. Huge love to all of them 🫶💜:

   Nabil Bitar
   Verizon
   40 Sylvan Road
   Waltham, MA  02145
   US

   EMail: nabil.bitar@verizon.com


   Himanshu Shah
   Ciena Corp.
   35 Nagog Park
   Acton, MA  01720
   US

   EMail: hshah@ciena.com


   Mustapha Aissaoui
   Alcatel-Lucent
   600 March Road
   Kanata
   ON, Canada

   EMail: mustapha.aissaoui@alcatel-lucent.com


   Jason Rusmisel
   Alcatel-Lucent
   600 March Road
   Kanata
   ON, Canada

   EMail: Jason.rusmisel@alcatel-lucent.com


   Andrew G. Malis
   Huawei
   2330 Central Expressway
   Santa Clara, CA  95050
   US

   EMail: agmalis@gmail.com
   Chris Metz
   Cisco Systems, Inc.
   3700 Cisco Way
   San Jose, CA  95134
   US

   EMail: chmetz@cisco.com


   David McDysan
   Verizon
   22001 Loudoun County Pkwy.
   Ashburn, VA  20147
   US

   EMail: dave.mcdysan@verizon.com


   Jeff Sugimoto
   Alcatel-Lucent
   701 E. Middlefield Rd.
   Mountain View, CA  94043
   US

   EMail: jeffery.sugimoto@alcatel-lucent.com


   Mike Loomis
   Alcatel-Lucent
   701 E. Middlefield Rd.
   Mountain View, CA  94043
   US

   EMail: mike.loomis@alcatel-lucent.com

11. Acknowledgements 🌟

The editors also gratefully acknowledge the input of the following people: Paul Doolan, Mike Duckett, Pranjal Dutta, Ping Pan, Prayson Pate, Vasile Radoaca, Yeongil Seo, Yetik Serbest, and Yuichiro Wada 🎀✨

Authors' Addresses 💌✨

okay bestie, here are the three editors who put this whole thing together 🫶 you can reach each of them at the contact details below 🦋

Luca Martini (editor)
Cisco Systems, Inc.
9155 East Nichols Avenue, Suite 400
Englewood, CO  80112
US

EMail: lmartini@cisco.com


Matthew Bocci (editor)
Alcatel-Lucent
Voyager Place
Shoppenhangers Road
Maidenhead
Berks, UK

EMail: matthew.bocci@alcatel-lucent.com


Florin Balus (editor)
Alcatel-Lucent
701 E. Middlefield Rd.
Mountain View, CA  94043
US

EMail: florin@nuagenetworks.net

that's the whole doc, babe 🌈👑 five parts of pure protocol serving looks 💅

📦 where this page comes from

ietf: rfc7267 2014-06
💖 girlified by claude-haiku-5-5 on 2026-10-18: a language model's rewrite of the original, under its terms