RFC 8338

Signaling Root-Initiated Point-to-Multipoint Pseudowire Using LDP

📅 published March 2018, from ietf

RFC 8338 🎀 Signaling Root-Initiated Point-to-Multipoint Pseudowire Using LDP

okay bestie, here's the title block tea ☕💅 This one comes from the Internet Engineering Task Force (IETF). The editors are S. Boutros, Ed. (VMware) and S. Sivabalan, Ed. (Cisco Systems). It's a Standards Track document, the ISSN is 2070-1721, and it's dated March 2018. It updates RFC 7385 🦋 and there's no Obsoletes line on it, so it doesn't replace anything.

Abstract 🌸

ngl this abstract is giving main character energy ✨ It describes a way to signal Point-to-Multipoint (P2MP) Pseudowire (PW) trees using LDP. This mechanism fits any Layer 2 VPN service that needs P2MP connectivity over an IP or MPLS-enabled PSN. A P2MP PW set up with this mechanism is root initiated 👑 The document also updates RFC 7385 by giving the reserved value 0xFF a new job: it becomes the wildcard transport tunnel type 🌈

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, received public review, and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 7841 🧚

For the current status, any errata, and how to send feedback, head to https://www.rfc-editor.org/info/rfc8338 💜

Copyright (c) 2018 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, because 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 they are provided without warranty as described in the Simplified BSD License 🫶

Table of Contents 🗂️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
  2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
  2.2.  Abbreviations . . . . . . . . . . . . . . . . . . . . . .   4
3.  Signaling P2MP PW . . . . . . . . . . . . . . . . . . . . . .   5
  3.1.  PW Ingress-to-Egress Incompatibility Issues . . . . . . .   6
  3.2.  P2MP PW FEC . . . . . . . . . . . . . . . . . . . . . . .   6
    3.2.1.  P2MP PW Upstream FEC Element  . . . . . . . . . . . .   7
    3.2.2.  P2P PW Downstream FEC Element . . . . . . . . . . . .  11
  3.3.  Typed Wildcard FEC Format for a New FEC . . . . . . . . .  11
  3.4.  Group ID Usage  . . . . . . . . . . . . . . . . . . . . .  12
  3.5.  Generic Label TLV . . . . . . . . . . . . . . . . . . . .  12
4.  LDP Capability Negotiation  . . . . . . . . . . . . . . . . .  12
5.  P2MP PW Status  . . . . . . . . . . . . . . . . . . . . . . .  14
6.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
  7.1.  FEC Type Name Space . . . . . . . . . . . . . . . . . . .  15
  7.2.  LDP TLV Type  . . . . . . . . . . . . . . . . . . . . . .  15
  7.3.  mLDP Opaque Value Element TLV Type  . . . . . . . . . . .  15
  7.4.  Selective Tree Interface Parameter Sub-TLV Type . . . . .  15
  7.5.  Wildcard PMSI Tunnel Type . . . . . . . . . . . . . . . .  15
8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
  8.1.  Normative References  . . . . . . . . . . . . . . . . . .  16
  8.2.  Informative References  . . . . . . . . . . . . . . . . .  17
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  18
Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  18
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  20

1. Introduction ✨

okay so a Point-to-Multipoint (P2MP) Pseudowire (PW) copies the important stuff from a one-way P2MP telecom service, like P2MP ATM over PSN 💅 The big difference from a Point-to-Point (P2P) PW (see [RFC3985]) is that a P2P PW is meant for two-way service, while a P2MP PW is meant for one-way service and, optionally, two-way service too 🦋 The requirements for P2MP PWs live in [RFC7338]. As mentioned there, a P2MP PW can be built as either a Single Segment Pseudowire (P2MP SS-PW) or a Multi-Segment Pseudowire (P2MP MS-PW). P2MP MS-PW is out of scope for this doc, so no spoilers 🙈 Figure 1 shows the reference model for a P2MP PW.

For a P2MP SS-PW, the transport Label Switched Path (LSP) SHOULD be a P2MP MPLS LSP. That means either a P2MP Traffic Engineering (TE) tunnel set up with RSVP-TE [RFC4875], or a P2MP LSP set up with Multipoint LDP (mLDP) [RFC6388]. It runs from the Root PE (Provider Edge) to the Leaf PE(s) of the P2MP SS-PW tree 🌸 In Figure 1, for example, PW1 can ride a P2MP TE tunnel or a mLDP P2MP LSP that starts at PE1 and ends at PE2, PE3, and PE4.

                 |<--------------P2MP PW---------------->|
          Native |                                       |  Native
         Service |     |<--PSN1->|      |<--PSN2->|      |  Service
          (AC)   V     V         V      V         V      V   (AC)
            |    +-----+         +------+         +------+    |
            |    |     |         |   P1 |=========|T-PE2 |AC3 |    +---+
            |    |     |         |   .......PW1.........>|-------->|CE3|
            |    |T-PE1|=========|   .  |=========|      |    |    +---+
            |    |  .......PW1........  |         +------+    |
            |    |  .  |=========|   .  |         +------+    |
            |    |  .  |         |   .  |=========|T-PE3 |AC4 |    +---+
    +---+   |AC1 |  .  |         |   .......PW1.........>|-------->|CE4|
    |CE1|------->|...  |         |      |=========|      |    |    +---+
    +---+   |    |  .  |         +------+         +------+    |
            |    |  .  |         +------+         +------+    |
            |    |  .  |=========|   P2 |=========|T-PE4 |AC5 |    +---+
            |    |  .......PW1..............PW1.........>|-------->|CE5|
            |    |     |=========|      |=========|      |    |    +---+
            |    +-----+         +------+         +------+    |

                             Figure 1: P2MP PW

This doc specifies a way to signal a P2MP PW with LDP. Mechanisms for setting up a P2P SS-PW with LDP are in [RFC8077], and this doc builds on that idea. It defines a new Forwarding Equivalence Class (FEC), TLVs, parameters, and status codes so LDP can signal and maintain P2MP PWs 💖

As [RFC7338] outlines, even though traffic from a Root PE (R-PE) to the Leaf PEs (L-PEs) is P2MP by nature, an L-PE might want to send one-way P2P traffic that goes only to the R-PE. This mechanism covers that case 🧚

The P2MP PW needs an MPLS LSP to carry its traffic, and MPLS packets that carry the PW upstream label get encapsulated using the methods in [RFC5332] 🌈

2. Terminology 📚

Hmm, wait, that heading should be numbered properly. Here it is:

2. Terminology 📚

2.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 🔑✨

2.2. Abbreviations 🔤

AGI:    Attachment Group Identifier

CE:     Customer Edge

FEC:    Forwarding Equivalence Class

L-PE:   Leaf PE (egress PE)

LDP:    Label Distribution Protocol

LSP:    Label Switched Path

mLDP:   Multipoint Label Distribution Protocol (for P2MP/MP2MP LSP)

MS-PW:  Multi-Segment Pseudowire

P2MP:   Point-to-Multipoint

P2P:    Point-to-Point

PE:     Provider Edge

PSN:    Packet Switched Network

PW:     Pseudowire

R-PE:   Root PE (ingress PE, PE initiating P2MP PW setup)

S-PE:   Switching Provider Edge (of MS-PW)

SS-PW:  Single-Segment Pseudowire

TE:     Traffic Engineering

3. Signaling P2MP PW 📡

So PEs need LDP sessions with each other before they can advertise labels and swap PW-related LDP messages 🫶 A PE finds the other PEs it should connect with P2MP PWs either through manual configuration or through autodiscovery [RFC6074].

An R-PE and each L-PE MUST be configured with the same FEC as defined in Section 3.2 🎀

A P2MP PW requires an active P2MP PSN LSP between an R-PE and its L-PE(s). Heads up: how that P2MP PSN LSP gets set up depends on the signaling protocol, RSVP-TE or mLDP 👀

With mLDP, a Leaf PE can choose to join the P2MP LSP at any time. With RSVP-TE, the R-PE sets up the P2MP LSP, usually when the service is first provisioned. Local policy can override any decision to join, add, or prune existing or new L-PEs from the tree, so it's not all automatic 🙃 Either way, PW setup can ignore these differences and just assume the P2MP PSN LSP is there when it's needed ✨

P2MP PW signaling starts at the R-PE. It sends a separate P2MP PW LDP Label Mapping Message to each L-PE in that P2MP PW. This Label Mapping Message contains the following:

  1. A FEC TLV containing a P2MP PW Upstream FEC Element that includes a Transport LSP sub-TLV.
  2. An Interface Parameters TLV, as described in [RFC8077].
  3. A PW Group ID TLV, as described in [RFC8077].
  4. A label TLV for the upstream-assigned label that the R-PE uses for traffic going from the R-PE to the L-PE(s).

The R-PE slaps the upstream-assigned PW label on outbound packets sent over the P2MP PW. Using that label, an L-PE can tell which inbound packets came in over the P2MP PW 💅

The R-PE MAY also send Label Mapping Messages to one or more L-PEs to signal unidirectional P2P PW(s). The L-PE(s) can use those PWs to send traffic back to the R-PE. This optional Label Mapping Message contains the following:

  1. A P2P PW Downstream FEC Element.
  2. A label TLV for the downstream-assigned label that the corresponding L-PE uses to send traffic to the R-PE.

The LDP liberal label retention mode MUST be used. Per the requirements in [RFC5036], the Label Request message MUST also be supported 🌸

The upstream-assigned label gets allocated according to the rules in [RFC5331] 🦋

When an L-PE receives a PW Label Mapping Message, it MUST verify that the associated P2MP PSN LSP is in place. If the associated P2MP PSN LSP is not in place and its type is LDP P2MP LSP, the L-PE MUST attempt to join the P2MP LSP associated with the P2MP PW. If the associated P2MP PSN LSP is not in place and its type is RSVP-TE P2MP LSP, the L-PE SHOULD wait until the P2MP transport LSP is signaled ⏳ If an L-PE fails to join the P2MP PSN LSP, that L-PE MUST not enable the PW and MUST notify the user. In that case, a PW status message with status code of 0x00000008 (Local PSN-facing PW (ingress) Receive Fault) MUST also be sent to the R-PE 🚨

3.1. PW Ingress-to-Egress Incompatibility Issues 🚫💅

Okay, bestie, so picture this: an R-PE signals a PW with a PW Type, Control Word (CW) mode, or interface parameters that a particular L-PE just can't handle 😭. Then the L-PE MUST NOT enable the PW, and it should tell the user about it 🫶. On top of that, a PW status message with status code 0x00000001 (Pseudowire Not Forwarding) MUST also be sent back to the R-PE. Not optional, babe 💀.

BUT, lowkey important plot twist: this doesn't apply if the L-PE was never provisioned with this particular P2MP PW 🙈. In that case, the LDP liberal label retention rules kick in, and nothing happens. Main character energy for the L-PE, no drama 🦋.

3.2. P2MP PW FEC 🎀

Okay so [RFC8077] gives us two FEC element types for signaling P2P PWs: the "PWid FEC Element" and the "Generalized PWid FEC Element" 📝. This document adds two new ones: the "P2MP PW Upstream FEC Element" and the "P2P PW Downstream FEC Element" ✨. The upstream one comes with a mandatory upstream-assigned label, and the downstream one comes with an optional downstream-assigned label. It's giving organized 🌸.

3.2.1. P2MP PW Upstream FEC Element 🌈

The FEC type for the P2MP PW Upstream FEC Element 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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |P2MP PW Up=0x82|C|           PW Type           | PW Info Length|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    AGI Type   | AGI Length    |         AGI Value             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                       AGI Value (contd.)                      ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   AII Type    | SAII Length   |         SAII Value            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                       SAII Value (contd.)                     ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |PMSI Tunnel Typ|PMSI TT Length |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
    +                                                               +
    ~                   Transport LSP ID                            ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                       Optional Parameters                     |
    ~                                                               ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: P2MP PW Upstream FEC Element

Here's the breakdown, bestie 💖:

  • P2MP PW Up: an 8-bit representation for the P2MP PW Upstream FEC type 🔢.
  • C bit: a value of 1 or 0 that tells you whether a control word is present or absent for the P2MP PW 🎯.
  • PW Type: a 15-bit representation of the PW Type, as specified in [RFC8077] 🧩.
  • PW Info Length: the sum of the AGI Length, SAII Length, PMSI Tunnel Type Length, and Optional Parameters fields, in octets. If this value is 0, it references all PWs using the specified group ID 🌍. In that case, there are no other FEC element fields (AGI Type, SAII Value, etc.) present, and no interface parameters TLVs either. Or, if you want better filtering, you can use the typed wildcard FEC described in Section 2.3 to get the same result 🧚.
  • AGI: an Attachment Group Identifier TLV, which uniquely identifies a VPN or Virtual Private LAN Service (VPLS) instance associated with the P2MP PW 🏠. It has the same format as the Generalized PWid FEC Element [RFC8077].
  • SAII Value: a Source Attachment Individual Identifier that identifies the root of the P2MP PW 🌳. The root is represented using the AII Type 2 format specified in [RFC5003]. The SAII can be left out by just setting its length and type to zero 🙃.

The P2MP PW is identified by the Source Attachment Identifier (SAI). If the AGI is non-null, the SAI is the combination of the SAII and the AGI. If the AGI is null, the SAI is just the SAII 🪪.

  • PMSI Tunnel Info: this is the combo of the PMSI Tunnel Type, PMSI Tunnel Type Length (shown in the figure as PMSI TT Length), and Transport LSP ID fields 🎁.

A P2MP PW MUST be associated with a transport LSP, which can be set up using RSVP-TE or mLDP 🚇.

  • PMSI Tunnel Type: defined in [RFC6514] 💜.

When the type is set to mLDP P2MP LSP, the Tunnel Identifier is a P2MP FEC Element as defined in [RFC6388]. The new mLDP Opaque Value Element type for the L2VPN-MCAST application TLV MUST be used. You'll find it in the IANA Considerations section (Section 7) 📋.

  • Transport LSP ID: this is the Tunnel Identifier defined in [RFC6514] 🪄.

An R-PE sends a Label Mapping Message as soon as the transport LSP ID associated with the P2MP PW is known (for example, through configuration), no matter what the operational state of that transport LSP is 📬.

Similarly, an R-PE doesn't withdraw the labels when the corresponding transport LSP goes down. And an L-PE keeps the P2MP PW labels regardless of the operational status of the transport LSP 🫡.

Heads up, though: a given transport LSP can be linked to more than one P2MP PW. When that happens, those P2MP PWs share the same R-PE and L-PE(s). An R-PE may also have lots of P2MP PWs with disjoint L-PE sets 🔀.

For an LDP P2MP LSP, when an L-PE gets the Label Mapping Message, it can start the process of joining the P2MP LSP tree associated with the P2MP PW 🌊.

For an RSVP-TE P2MP LSP, only the R-PE starts signaling the P2MP LSP 👑.

  • Optional Parameters: this field can hold some TLVs that aren't part of the FEC but are still needed for the PW to work 🧃. This mechanism uses two of them: the Interface Parameters TLV and the PW Group ID TLV.

The Interface Parameters TLV and PW Group ID TLV specified in [RFC8077] can also be used alongside the P2MP PW FEC in a label message. For the PW Group ID TLV, the sender and receiver should follow the same rules and procedures specified in [RFC8077]. The Interface Parameters TLV is a different story, though, because of the specifics of P2MP connectivity 🤓. When an R-PE signals the interface parameters, each L-PE should check whether its configured value(s) is less than or equal to the threshold value the R-PE provided (for example, MTU size for Ethernet, or the max number of concatenated ATM cells) 📏. For other interface parameters, like CEP/TDM Payload Bytes, the value MUST exactly match what the R-PE signaled 💯.

A multicast traffic stream associated with a P2MP PW can be selective or inclusive. To support selective streams, this document defines a new optional Selective Tree Interface Parameter sub-TLV. You'll find it in the IANA Considerations section (Section 7), and its format follows [RFC8077]. The sub-TLV's value holds the source and the group for a given multicast tree, as shown in Figure 3 ✨. If a P2MP PW is associated with multiple selective trees, the corresponding Label Mapping Message carries more than one instance of this sub-TLV. And if the sub-TLV isn't there at all, the P2MP PW is associated with all multicast traffic streams originating from the root 🌟.

        +-----------------------------------------+
        |            Sub-TLV Type (1 Octet)       |
        +-----------------------------------------+
        |              Length (1 Octet)           |
        +-----------------------------------------+
        | Multicast Source Length (1 Octet)       |
        +-----------------------------------------+
        | Multicast Source (variable length)      |
        +-----------------------------------------+
        | Multicast Group Length (1 Octet)        |
        +-----------------------------------------+
        | Multicast Group (variable length)       |
        +-----------------------------------------+

Figure 3: Selective Tree Interface Parameter Sub-TLV Value

Note that since the LDP Label Mapping Message is only sent by the R-PE to all the L-PEs, it isn't possible to negotiate any interface parameters 🙅‍♀️.

3.2.2. P2P PW Downstream FEC Element 🦋

The optional P2P PW Downstream FEC Element 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |P2P PWDown=0x84|C|           PW Type           | PW Info Length|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    AGI Type   |     Length    |         AGI Value             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                       AGI Value (contd.)                      ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    AII Type   |     Length    |         SAII Value            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                       SAII Value (contd.)                     ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 4: P2P PW Downstream FEC Element

Good news: the fields in the P2P PW Downstream FEC Element work exactly the same as the ones in the P2MP PW Upstream FEC Element, shown in Figure 2 💜✨

3.3. Typed Wildcard FEC Format for a New FEC 💅

okay so [RFC5918] is the one that defines the general idea of a Typed Wildcard FEC Element, and it says FEC designers have to spell out a Typed Wildcard FEC Element for every newly defined FEC element type 🎀 this doc uses two of them, "P2MP PW Upstream" and "P2P PW Downstream", so yes, we absolutely need their Typed Wildcard format defined. no skipping 🫶

[RFC6667] already defines the Typed Wildcard FEC Element format for the other PW FEC Element types (PWid and Generalized PWid FEC Element) in Section 3, 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Typed Wcard=0x5|Type=PW FEC    |   Len = 3     |R|   PW Type   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    . . .      | PMSI Tun Type |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 5: Typed Wildcard Format for P2MP PW FEC Elements

[RFC6667] says the Type field can be either the "PWid" (0x80) or "Generalized PWid" (0x81) FEC Element type ✨ this document borrows that existing Typed Wildcard format from [RFC6667] (shown in Figure 5), then stretches the Type field so it also covers the P2MP PW Upstream FEC Element and P2P PW Downstream FEC Element types. 👑 it also adds a brand new field called the "PMSI Tunnel Type". PMSI Tunnel Type 0xFF is reserved to mean "wildcard transport tunnel type" 💜 and the PMSI Tunnel Type field only applies to the Typed Wildcard P2MP PW Upstream FEC Element, and it MUST be set to "wildcard" for the "P2P PW Downstream FEC Element" typed wildcard 🌸

3.4. Group ID Usage 🧚

the PW Group ID TLV from [RFC8077] holds a group ID that can indicate an arbitrary group membership of a P2MP PW 🍓 this group ID can be used in LDP "wildcard" status and withdraw label messages, as described in [RFC8077] ✨

3.5. Generic Label TLV 🎀

same as with P2P PW signaling, P2MP PW labels ride inside the Generic Label TLV that sits in the LDP Label Mapping Message 💅 the Generic Label TLV gets formatted and processed by the rules in [RFC8077], no new drama. for a given P2MP PW, the R-PE allocates one upstream-assigned label and advertises it to all L-PEs using the Generic Label TLV in Label Mapping Messages that carry the P2MP PW Upstream FEC Element 🦋

the R-PE can also allocate a unique label for each L-PE it wants to receive P2P traffic from 🫶 that label gets advertised to the L-PE using the Generic Label TLV and the P2P PW Downstream FEC Element in Label Mapping Messages 💖

4. LDP Capability Negotiation ✨

the capability to support P2MP PWs MUST be advertised to all LDP peers 👑 that happens with the methods in [RFC5561] to advertise the LDP P2MP PW Capability TLV. if an LDP peer supports dynamic capability advertisement, it can be done by sending a new Capability message with the S bit set for the P2MP PW Capability TLV 🌈 if the peer doesn't support dynamic capability advertisement, then the P2MP PW Capability TLV MUST be included in the LDP Initialization message during session establishment 😭 and a Label Switched Router (LSR) with P2MP PW capability MUST recognize both the P2MP PW Upstream FEC Element and P2P PW Downstream FEC Element in LDP label messages 💅

in line with the requirements in [RFC5561], this TLV is defined to indicate the P2MP PW capability 🧚

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |U|F| P2MP PW Capability TLV    |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |S| Reserved    |    Reserved   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 6: LDP P2MP PW Capability TLV

  • U bit: the Unknown bit [RFC5036] SHOULD be 1 (ignore if not understood) 🙈
  • F bit: the Forward unknown bit [RFC5036] SHOULD be 0 (don't forward if not understood) 🌸
  • P2MP PW Capability TLV Code Point: the TLV type, which identifies a specific capability. fun fact, the P2MP PW Capability Code Point shows up in the IANA Considerations section (Section 7) 🔥
  • S bit: the State Bit tells you whether the sender is advertising or withdrawing the P2MP PW capability 💜
    • 1 - The TLV is advertising the capability specified by the P2MP PW Capability TLV Code Point.
    • 0 - The TLV is withdrawing the capability specified by the P2MP PW Capability TLV Code Point.
  • Length: MUST be set to 2 (octet) 🎀

5. P2MP PW Status 🦋

okay this part is a big deal ngl 😭 an LSR MUST be capable of handling PW status, because the mechanism needs it 💅 the PW status negotiation procedures in [RFC8077] are not applicable to P2MP PW, and an LSR MUST NOT claim to be P2MP PW capable by sending an LDP P2MP PW Capability TLV if it isn't also capable of handling PW status 🙈

once an L-PE successfully processes a Label Mapping Message for a P2MP PW, it MUST send appropriate PW status according to the procedure specified in [RFC8077] to report the PW status 🫶 if no PW status notification is required, then none is sent. for example, if the P2MP PW is established and operational with a status code of 0x00000000 (Success), a PW status message isn't necessary ✨ a PW status message sent from an L-PE to an R-PE MUST contain the P2P PW Downstream FEC Element to identify the PW 💖

an R-PE also sends PW status to L-PE(s) to reflect its view of a P2MP PW state 🌈 that PW status message contains a P2MP PW Upstream FEC Element to identify the PW 👑

connectivity status of the underlying P2MP LSP that the P2MP PW is associated with can be verified using the LSP ping and traceroute procedures in [RFC6425] 🧚

6. Security Considerations 🔥

okay this is the serious bit, bestie, so listen up 🙈 in general, the security measures in [RFC8077] are adequate for this protocol. HOWEVER 💀 the use of MD5 as the method of securing an LDP control plane is no longer considered adequately secure. implementations should be written so they can migrate to a more secure cryptographic hash function, for when the next LDP authentication method might not be a simple hash-based authentication algorithm 😭 don't sleep on MD5 for LDP. it's not it anymore 💀

7. IANA Considerations 🌸

7.1. FEC Type Name Space 💅

this document uses two FEC element types, 0x82 and 0x84, in the "Forwarding Equivalence Class (FEC) Type Name Space" registry for the Label Distribution Protocol (LDP) [RFC5036]. IANA has added this document as a reference for the following entries 🦋

Value   Hex    Name                            Reference
------  -----  -----------------------------   --------------------
 130    0x82   P2MP PW Upstream FEC Element    [RFC8338] [RFC7358]
 132    0x84   P2P PW Downstream FEC Element   [RFC8338] [RFC7358]

7.2. LDP TLV Type 🎀

this document defines a new LDP TLV type in the "TLV Type Name Space" registry [RFC5036]. IANA has assigned the following value ✨

TLV Type  Description
--------  ----------------------
0x0703    P2MP PW Capability TLV

7.3. mLDP Opaque Value Element TLV Type 🧚

IANA has assigned a new mLDP Opaque Value Element Type in the "LDP MP Opaque Value Element basic type" registry [RFC6388] as follows 💜

TLV Type  Description
-------   ---------------------------
  13      L2VPN-MCAST application TLV

Length:   4

Value:    A 32-bit integer, unique in the context of the
          root, as identified by the root's address.

7.4. Selective Tree Interface Parameter Sub-TLV Type 🍓

IANA has assigned a sub-TLV from the "Pseudowire Interface Parameters Sub-TLV type Registry" [RFC4446] as follows 🌈

TLV Type  Description
--------  ----------------------------------
0x1B      Selective Tree Interface Parameter

7.5. Wildcard PMSI Tunnel Type 👑

IANA has modified an entry in the "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types" registry within the "Border Gateway Protocol (BGP) Parameters" registry [RFC7385]. Value 0xFF, which was previously marked as "Reserved", has been updated as follows 🔥

Value     Meaning                             Reference
-----     ------------------------------      ---------
0xFF      wildcard transport tunnel type      [RFC8338]

8. References 🫶

8.1. Normative References ✨

okay bestie, this is the reading list the spec says you need before you can implement any of this 📚 These are the normative ones, so they're part of the actual rules, not just extra reading 💅

8.2. Informative References 🌸

these ones are the extra-credit reading 🧚 they're not required to build the thing, but they give you the background and context, so read them when you're curious 🤓

Acknowledgments 🫶

the authors wanted to give a big shoutout to Andre Pelletier and Parag Jain for their really helpful suggestions 💖 iconic of them to share the love 🥹

Contributors 💜

these people contributed a lot to the actual content of this document, so they count as coauthors ✨ the whole squad:

  • Luca Martini, Cisco Systems, Inc., Email: lmartini@cisco.com
  • Maciek Konstantynowicz, Cisco Systems, Inc., Email: maciek@cisco.com
  • Gianni Del Vecchio, Swisscom, Email: Gianni.DelVecchio@swisscom.com
  • Thomas D. Nadeau, Brocade, Email: tnadeau@lucidvision.com
  • Frederic Jounay, Orange CH, Email: Frederic.Jounay@salt.ch
  • Philippe Niger, Orange CH, Email: philippe.niger@orange.com
  • Yuji Kamite, NTT Communications Corporation, Email: y.kamite@ntt.com
  • Lizhong Jin, Email: lizho.jin@gmail.com
  • Martin Vigoureux, Nokia, Email: martin.vigoureux@nokia.com
  • Laurent Ciavaglia, Nokia, Email: laurent.ciavaglia@nokia.com
  • Simon Delord, Telstra, Email: simon.delord@gmail.com
  • Kamran Raza, Cisco Systems, Email: skraza@cisco.com

Authors' Addresses 🎀

and the two editors who held the whole thing together 👑

  • Sami Boutros (editor), VMware, Inc., Email: sboutros@vmware.com
  • Siva Sivabalan (editor), Cisco Systems, Inc., Email: msiva@cisco.com
📦 where this page comes from