RFC 8223

Application-Aware Targeted LDP

📅 published August 2017, from ietf

RFC 8223: Application-Aware Targeted LDP 🦋

Okay bestie, this is RFC 8223, titled Application-Aware Targeted LDP ✨ It's from August 2017 and it's an Internet Standards Track document, so it's the real deal 💅 It was published by the Internet Engineering Task Force (IETF) as Request for Comments: 8223, with ISSN 2070-1721.

The authors are S. Esale, R. Torvi, and L. Jalil, plus U. Chunduri and K. Raza. Esale, Torvi, and Jalil are from Juniper Networks, Verizon, and... wait, let me get this right 🙈 Esale and Torvi are at Juniper Networks, Jalil is at Verizon, Chunduri is at Huawei, and Raza is at Cisco Systems, Inc. 🌈

This RFC updates RFC 7473 🔥 It has no "Obsoletes" line, so it doesn't replace anything.

Abstract 🌸

Okay so the newer tLDP apps, like remote Loop-Free Alternates (LFAs) and BGP auto-discovered pseudowires, can automatically set up a tLDP session with any Label Switching Router (LSR) in the network 😭 The starting router knows which apps it's running, so it can control when sessions get started. The responding router? Zero info. It has no way to decide whether to accept.

This doc adds a way to advertise and negotiate the Targeted Application Capability (TAC) during LDP session setup ✨ Once the responder knows about the targeted apps, it can allow a limited number of sessions for certain apps. Each targeted app also gets mapped to LDP Forwarding Equivalence Class (FEC) elements, so only the necessary FEC label bindings get advertised over the session. Iconic behaviour 💖 It also updates RFC 7473 to enable advertising LDP FEC label bindings over the session.

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, and it has been through public review and approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check out Section 2 of RFC 7841.

Want the current status, any errata, or a way to send feedback? Head to https://www.rfc-editor.org/info/rfc8223 🦋

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

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

Table of Contents 📋

   1. Introduction ....................................................3
      1.1. Conventions Used in This Document ..........................4
      1.2. Terminology ................................................4
   2. Targeted Application Capability .................................5
      2.1. Encoding ...................................................5
      2.2. Procedures .................................................5
      2.3. LDP Message Procedures .....................................8
           2.3.1. Initialization Message ..............................8
           2.3.2. Capability Message ..................................8
   3. Targeted Application FEC Advertisement Procedures ...............9
   4. Interaction of Targeted Application Capabilities and State
      Advertisement Control Capabilities .............................10
   5. Use Cases ......................................................12
      5.1. Remote LFA Automatic Targeted Session .....................12
      5.2. FEC 129 Auto-discovery Targeted Session ...................13
      5.3. LDP over RSVP and Remote LFA Targeted Session .............13
      5.4. mLDP Node Protection Targeted Session .....................13
   6. Security Considerations ........................................14
   7. IANA Considerations ............................................14
   8. References .....................................................15
      8.1. Normative References ......................................15
      8.2. Informative References ....................................16
   Acknowledgments ...................................................17
   Contributors ......................................................17
   Authors' Addresses ................................................18

1. Introduction ✨

LDP uses the Extended Discovery mechanism to set up the Targeted LDP (tLDP) adjacency and the session that follows, as described in [RFC5036]. A Label Switching Router (LSR) starts Extended Discovery by sending a tLDP Hello to a specific address. The remote LSR then decides whether to accept or ignore that tLDP Hello, and it bases that decision on local configuration only 🙈

A tLDP application is an app that uses a tLDP session to swap info, such as FEC label bindings ("FEC" stands for "Forwarding Equivalence Class"), with a peer LSR in the network. For an app like FEC 128 pseudowire, the remote LSR is configured with the source LSR address, so it can use that to accept or ignore a given tLDP Hello 💅

Now here's the drama. Apps like remote Loop-Free Alternates (LFAs) and BGP auto-discovered pseudowires automatically start asymmetric Extended Discovery toward any LSR in the network, based on local state only 😭 The remote LSR isn't explicitly configured with the source LSR address. So it either responds to every tLDP Hello or ignores them all.

It gets worse 💀 Since the session starts and gets established after adjacency formation, the responding LSR has no info about the targeted apps. That means it can't pick a session for an app it's configured to support. The initiating LSR might put a limit per app on its locally started automatic tLDP sessions, but the responding LSR has no such info to apply a similar limit to incoming tLDP sessions. Plus, the responding LSR can't tell whether the source LSR is setting up tLDP sessions for configured apps, automatic apps, or both.

This document proposes a fix 🦋 It advertises the Targeted Application Capability (TAC), which is a list of targeted apps, during initialization of a tLDP session. It also defines a way to enable a new app and disable an old one after the session is up. This capability advertisement gives the responding LSR what it needs to control whether it accepts tLDP sessions on a per-app basis. For example, an LSR may accept all BGP auto-discovered tLDP sessions described in [RFC6074], but only accept a limited number of remote LFA tLDP sessions described in [RFC7490] 🎀

Also, the tLDP application gets mapped to LDP FEC element types, so only specific app FECs get advertised. That avoids sending other unnecessary FECs over a tLDP session 🌈

1.1. Conventions Used in This Document 🍓

Here's the deal with the key words. "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are read as BCP 14 [RFC2119] [RFC8174] describes, but only when they appear in all capitals, like they do here 💅

1.2. Terminology 📖

Besides the terminology defined in [RFC7473], this document uses these terms:

      tLDP    : Targeted LDP
      TAC     : Targeted Application Capability
      TAE     : Targeted Application Element
      TA-Id   : Targeted Application Identifier
      SAC     : State Advertisement Control
      LSR     : Label Switching Router
      mLDP    : Multipoint LDP
      PQ node : Remote LFA next hops
      RSVP-TE : RSVP Traffic Engineering
      P2MP    : Point-to-Multipoint
      PW      : Pseudowire
      P2P-PW  : Point-to-Point Pseudowire
      MP2MP   : Multipoint-to-Multipoint
      HSMP LSP: Hub and Spoke Multipoint Label Switched Path
      LSP     : Label Switched Path
      MP2P    : Multipoint-to-Point
      MPT     : Merge Point

2. Targeted Application Capability 🎀

2.1. Encoding 🦋

An LSR MAY advertise that it can negotiate a tLDP application list over a tLDP session. It does this with the capability advertisement defined in [RFC5561], 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |U|F| TLV Code Point            |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |S| Reserved    |                                               |
   +-+-+-+-+-+-+-+-+       Capability Data                         |
   |                                               +-+-+-+-+-+-+-+-+
   |                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Flag "U" MUST be set to 1 so that this capability gets silently ignored if it's unknown 🙈 The TAC's Capability Data field carries the Targeted Application Element (TAE) info, 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           TA-Id               |E|       Reserved              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

TA-Id is a 16-bit Targeted Application Identifier value 💜

E is the E-bit (Enable bit). It tells you whether the sender is advertising or withdrawing the TAE. Here's how the E-bit value works:

   1 - The TAE is advertising the targeted application.
   0 - The TAE is withdrawing the targeted application.

2.2. Procedures ✨

Okay bestie, so at tLDP session setup time 💖, an LSR MAY include a new capability TLV, the TAC TLV, as an optional TLV in the LDP Initialization message. The TAC TLV's Capability data MAY hold zero or more TAEs, and each one is about a unique TA-Id that the LSR supports over the session. If the receiver LSR gets the same TA-Id in more than one TAE, it MUST process the first one and ignore the duplicates. If the receiver LSR gets an unknown TA-Id in a TAE, it MUST silently ignore that TAE and keep going with the rest of the TLV 🫶

If the receiver LSR doesn't get a TAC TLV in the Initialization message, or it doesn't understand the TAC TLV, the TAC negotiation counts as unsuccessful and session establishment just carries on as per [RFC5036] 🙈 But if it gets a valid TAC TLV, an LSR MUST generate its own TAC TLV with TAEs made of unique TA-Ids that it supports over the tLDP session. If there's at least one common TAE between the TAC TLV it received and its own, the session MUST proceed to establishment as per [RFC5036]. If not, an LSR MUST send a 'Session Rejected/Targeted Application Capability Mismatch' Notification message to the peer and close the session 💀 The initiating LSR SHOULD tear down the corresponding tLDP adjacency after sending or receiving that Notification message, to or from the responding LSR respectively.

If both peers support the TAC TLV, an LSR decides whether to establish or close a tLDP session based on the negotiated list of targeted applications 👑 For example, say an initiating LSR advertises A, B, and C as TA-Ids, and the responding LSR advertises C, D, and E as TA-Ids. The negotiated TA-Id for both LSRs is C. Now another one: the initiating LSR advertises A, B, and C, but the responding LSR is a passive LSR that advertises all of the applications (A, B, C, D, and E) as TA-Ids it supports over this session. The negotiated targeted applications for both LSRs are then A, B, and C 🌈 And finally, if the initiating LSR advertises A, B, and C while the responding LSR advertises D and E, the negotiated targeted applications for both LSRs are "none". So if the intersection of the sets of received and sent TA-Ids is null, the LSR sends a 'Session Rejected/Targeted Application Capability Mismatch' Notification message to the peer LSR and closes the session 😭

When the responding LSR, which is playing the active role [RFC5036] in LDP session establishment, receives a 'Session Rejected/Targeted Application Capability Mismatch' Notification message, it MUST set its session setup retry interval to a maximum value, that is, 0xFFFF 🍓 The session MAY stay in a non-existent state. When it detects a change in the initiating LSR's or its own local configuration pertaining to the TAC TLV, it MUST clear the session setup backoff delay associated with the session so it can reattempt session establishment. An LSR detects the configuration change on the other LSR when it receives a tLDP Hello message with a higher configuration sequence number than the earlier tLDP Hello message ✨

When the initiating LSR, which is playing the active role in LDP session establishment, receives a 'Session Rejected/Targeted Application Capability Mismatch' Notification message, it MUST do one of two things: (1) close the session and tear down the corresponding tLDP adjacency, or (2) set its session setup retry interval to a maximum value, that is, 0xFFFF 🎀

If the initiating LSR decides to tear down the associated tLDP adjacency, the session is closed on the initiating LSR and on the responding LSR as well. It MAY also take appropriate actions. For instance, if an automatic session meant to support the remote LFA application gets rejected by the responding LSR, the initiating LSR may tell the IGP to calculate another PQ node [RFC7490] for the route or set of routes 🧚 More specific actions are a local matter and are outside the scope of this document.

If the initiating LSR sets its session setup retry interval to maximum, the session MAY stay in a non-existent state. When this LSR detects a change in the responding LSR's configuration, or in its own configuration pertaining to the TAC TLV, it MUST clear the session setup backoff delay associated with the session so it can reattempt session establishment 🦋

After a tLDP session using the TAC mechanism has been established, the initiating and responding LSRs MUST distribute FEC label bindings for the negotiated applications only. For instance, if the tLDP session is established for a BGP auto-discovered pseudowire, only FEC 129 label bindings MUST be distributed over the session. Similarly, an LSR operating in downstream on-demand mode MUST request FEC label bindings for the negotiated applications only 💅

If the TAC and the Dynamic Capability [RFC5561] are negotiated during session initialization, the TAC MAY be renegotiated after session establishment by sending an updated TAC TLV in the LDP Capability message. The updated TAC TLV carries TA-Ids with an incremental update only. The updated TLV MUST consist of one or more TAEs with the E-bit set to 1 or 0, to advertise or withdraw the new application and the old application respectively. This may lead to advertisements or withdrawals of certain types of FEC label bindings over the session, or to teardown of the tLDP adjacency and, subsequently, the session 🔥

The TAC is advertised on the tLDP session only. If the tLDP session changes to a link session, an LSR SHOULD withdraw it with the S-bit set to 0. Similarly, if the link session changes to tLDP, an LSR SHOULD advertise it via the Capability message. If the capability negotiation fails, this may lead to destruction of the tLDP session 🌸

By default, an LSR SHOULD accept tLDP Hellos so that it can then accept or reject the tLDP session based on the application information 💜

In addition, an LSR SHOULD allow the configuration of any TA-Id so a network operator can use private TA-Ids 🌈

2.3. LDP Message Procedures

2.3.1. Initialization Message

  1. The S-bit of the TAC TLV MUST be set to 1 to advertise the TAC, and it SHOULD be ignored on receipt, as described in [RFC5561] 🎀
  2. The E-bit of the TAE MUST be set to 1 to enable the targeted application, and it SHOULD be ignored on receipt ✨
  3. An LSR MAY add the State Advertisement Control Capability by mapping the TAE to the State Advertisement Control (SAC) elements as defined in Section 4 🦋

2.3.2. Capability Message

After a change to local configuration, the initiating or responding LSR may renegotiate the TAC via the Capability message 💖

  1. The S-bit of the TAC is set to 1 or 0 to advertise or withdraw it.
  2. After the configuration change, if there is no common TAE between its new TAE list and the peer's TAE list, the LSR MUST send a 'Session Rejected/Targeted Application Capability Mismatch' Notification message and close the session 😭
  3. If there is a common TAE, an LSR MAY also update the SAC Capability based on the updated TAC, as described in Section 4, and send the updated TAC and SAC Capability in a Capability message to the peer 🫶
  4. A receiving LSR processes the Capability message with the TAC TLV. If the S-bit is set to 0, the TAC is disabled for the session.
  5. If the S-bit is set to 1, the LSR processes a list of TAEs from the TAC's data, with the E-bit set to 1 or 0, to update the peer's TAE 👑

3. Targeted Application FEC Advertisement Procedures 🧚

The tLDP application MUST be mapped to LDP FEC element types as follows, so that only the necessary LDP FEC label bindings get advertised over the tLDP session. This is the big mapping table, bestie, so screenshot it 📸

  Targeted Application     Description              FEC Mappings
+----------------------+------------------------+------------------+
|LDPv4 Tunneling       | LDP IPv4 over RSVP-TE  | IPv4 prefix      |
|                      | or other MPLS tunnel   |                  |
+----------------------+------------------------+------------------+
|                      |                        |                  |
|LDPv6 Tunneling       | LDP IPv6 over RSVP-TE  | IPv6 prefix      |
|                      | or other MPLS tunnel   |                  |
+----------------------+------------------------+------------------+
|mLDP Tunneling        | mLDP over RSVP-TE or   | P2MP             |
|                      | other MPLS tunnel      | MP2MP-up         |
|                      |                        | MP2MP-down       |
|                      |                        | HSMP-downstream  |
|                      |                        | HSMP-upstream    |
+----------------------+------------------------+------------------+
|                      |                        |                  |
|LDPv4 remote LFA      | LDPv4 over LDPv4 or    | IPv4 prefix      |
|                      | other MPLS tunnel      |                  |
+----------------------+------------------------+------------------+
|LDPv6 remote LFA      | LDPv6 over LDPv6 or    | IPv6 prefix      |
|                      | other MPLS tunnel      |                  |
+----------------------+------------------------+------------------+
|                      |                        |                  |
|LDP FEC 128 PW        | LDP FEC 128 Pseudowire | PWid FEC element |
+----------------------+------------------------+------------------+
|                      |                        |                  |
|LDP FEC 129 PW        | LDP FEC 129 Pseudowire | Generalized PWid |
|                      |                        | FEC element      |
+----------------------+------------------------+------------------+
|                      |                        | FEC types as    |
|LDP Session Protection| LDP session protection | per protected    |
|                      |                        | session          |
+----------------------+------------------------+------------------+
|LDP ICCP              | LDP Inter-Chassis      |                  |
|                      | Communication Protocol | None             |
+----------------------+------------------------+------------------+
|                      |                        |                  |
|LDP P2MP PW           | LDP P2MP Pseudowire    | P2MP PW Upstream |
|                      |                        | FEC element      |
+----------------------+------------------------+------------------+
|                      |                        | P2MP             |
|mLDP Node Protection  | mLDP node protection   | MP2MP-up         |
|                      |                        | MP2MP-down       |
|                      |                        | HSMP-downstream  |
|                      |                        | HSMP-upstream    |
+----------------------+------------------------+------------------+
|                      |                        |                  |
|IPv4 intra-area FECs* | IPv4 intra-area FECs*  | IPv4 prefix      |
+----------------------+------------------------+------------------+
|                      |                        |                  |
|IPv6 intra-area FECs* | IPv6 intra-area FECs*  | IPv6 prefix      |
+----------------------+------------------------+------------------+

* Intra-area FECs: FECs that are on the shortest-path tree and are not leafs of the shortest-path tree 🌳

4. Interaction of Targeted Application Capabilities and State Advertisement Control Capabilities ✨

okay so this part is where TAC and SAC meet, and it gets spicy 🌶️💅 As described in this doc, the set of TAEs that two LDP peers negotiate while advertising the TAC shows that both peers are willing to advertise state info for a set of apps. That set is symmetric between the two peers. Without any extra mechanisms, both peers will advertise state info for the same apps, bestie 🫶

As described in [RFC7473], the SAC TLV lets an LDP speaker say whether it's interested (or not interested 🙅‍♀️) in getting state info from a given peer for a particular app. Two LDP peers can use SAC to make asymmetric advertisements between each other ✨

Here's the tea. The TAC negotiation makes both peers aware of targeted apps, and that awareness lets them advertise only the necessary LDP FEC label bindings for the negotiated apps 💖 With SAC, though, the responding LSR isn't aware of targeted apps at all, so it might not be able to say whether it's interested or not in state info from the peer 😭 So when the responding LSR isn't aware of targeted apps like remote LFAs and BGP auto-discovered pseudowires, the TAC mechanism should be used. When the responding LSR is aware of targeted apps (with the right configuration) like FEC 128 pseudowire, the SAC mechanism should be used. Also, once the TAC mechanism has made the responding LSR aware of targeted apps, the SAC mechanism may be used to say "no thanks" to state info from the peer for a particular negotiated app, which creates asymmetric advertisements 🙈

So, the TAC mechanism lets two LDP peers symmetrically advertise state info for negotiated targeted apps. The SAC mechanism lets both of them asymmetrically turn off receiving state info for some of the apps that were already negotiated. Together, TAC and SAC can both be used to control the FEC label bindings advertised over the tLDP session 🦋 For example, imagine the initiating LSR sets up a tLDP session with the responding LSR using the TAC mechanism, for remote LFA and FEC 129 PW targeted apps. Each LSR then advertises the matching FEC label bindings. Now suppose the initiating LSR isn't the PQ node for the responding LSR's remote LFA IGP calculations. In that case, the responding LSR may use the SAC mechanism to tell the initiating LSR it's not interested in state info for remote LFA tLDP apps 💅

For a given tLDP session, the TAC mechanism can be used without the SAC mechanism, and the SAC mechanism can be used without the TAC mechanism. It's still useful to talk about what happens when both TAC and SAC are used on the same tLDP session 👑 The TAC mechanism MUST take precedence over the SAC mechanism when it comes to enabling the apps whose state info will be advertised. On a tLDP session using the TAC mechanism, the LDP peers MUST NOT advertise state info for an app that wasn't negotiated in the most recent TAE list (a "non-negotiated application"). This still holds even if one peer says it's interested in state info for that non-negotiated app by sending a SAC TLV. Put simply: when TAC is in use, SAC cannot and should not turn on state info advertisements for apps that TAC hasn't enabled 🚫

Flip the script though! The SAC mechanism MUST take precedence over the TAC mechanism when it comes to disabling state info advertisements. If an LDP speaker has announced, using the SAC mechanism, that it's not interested in state info for a given app from a given peer, that peer MUST NOT send state info for that app, even if the two peers negotiated that app via the TAC mechanism 🙅‍♀️✨

For the purposes of matching targeted apps defined in this document with application state as defined in [RFC7473], an LSR MUST use the following mappings 🗺️

LDPv4 Tunneling - IPv4 Prefix-LSPs
LDPv6 Tunneling - IPv6 Prefix-LSPs
LDPv4 Remote LFA - IPv4 Prefix-LSPs
LDPv6 Remote LFA - IPv6 Prefix-LSPs
LDP FEC 128 PW - FEC 128 P2P-PW
LDP FEC 129 PW - FEC 129 P2P-PW

An LSR MUST map the targeted app to the LDP capability as follows 🎀

mLDP Tunneling - P2MP Capability, MP2MP Capability, and HSMP LSP
   Capability TLV

mLDP Node Protection - P2MP Capability, MP2MP Capability, and HSMP
   LSP Capability TLV

5. Use Cases 🎬

5.1. Remote LFA Automatic Targeted Session

okay so the LSR figures out that it needs to form an automatic tLDP session with a remote LSR, based on IGP calculation as described in [RFC7490] or some other mechanism that's outside the scope of this document 🧚 The LSR forms the tLDP adjacency and builds an Initialization message with a TAC TLV containing the TAE for remote LFA during session establishment. The receiver LSR processes the LDP Initialization message and checks whether it's configured to accept a remote LFA tLDP session. If it is, it may also check that setting up this session won't go over the configured limit for remote LFA sessions. If all of these conditions are met, the receiver LSR may reply with an Initialization message carrying the TAC for remote LFA, and then the session may be established ✨

Once the session using the TAC mechanism is up, the sender and receiver LSRs distribute IPv4 or IPv6 FEC label bindings over it. The receiver LSR might decide it doesn't need these FEC label bindings after all 🤷‍♀️ In that case, it may turn off receipt of them by mapping the TAE to the State Advertisement Control Capability, as described in Section 4 💖

5.2. FEC 129 Auto-discovery Targeted Session

BGP auto-discovery may determine whether the LSR needs to start an auto-discovery tLDP session with a border LSR. Lots of LSRs might try to form an auto-discovered tLDP session with the same border LSR, so a service provider may want to limit how many auto-discovered tLDP sessions a border LSR can accept 🚧 As described in Section 2, LDP may convey targeted apps with the TAC TLV to a border LSR. A border LSR may establish or reject the tLDP session based on local administrative policy. Also, once the receiver LSR knows about targeted apps, it can apply an administrative policy for security 🔐 For example, it can use a policy to accept all auto-discovered sessions from a list of source addresses 🌸

Moreover, the sender and receiver LSRs must exchange FEC 129 label bindings only over the tLDP session 🦋

5.3. LDP over RSVP and Remote LFA Targeted Session

An LSR may want to set up a tLDP session with a remote LSR for LDP-over-RSVP tunneling and remote LFA apps. The sender LSR can add both of these apps as a unique TAE in the TAC data of a TAC TLV 🍓 The receiver LSR might have hit its configured limit for accepting remote LFA automatic tLDP sessions, but it may be configured to accept LDP-over-RSVP tunneling. In that case, the tLDP session is formed for both LDP-over-RSVP tunneling and remote LFA apps, since both need the same FECs (IPv4, IPv6, or both) ✨

5.4. mLDP Node Protection Targeted Session

A Merge Point (MPT) LSR may figure out that it needs to form an automatic tLDP session with the upstream point of local repair (PLR) LSR, for MP2P and MP2MP LSP [RFC6388] node protection as described in [RFC7715] 💜 The MPT LSR may add a new tLDP app, mLDP protection, as a unique TAE in the TAC data of a TAC TLV, and send it in the Initialization message to the PLR. If the PLR is configured for mLDP node protection, and setting up this session won't exceed the limit for either mLDP node protection sessions or automatic tLDP sessions, the PLR may decide to accept the session. The PLR may also reply with an Initialization message carrying a TAC TLV that has one of the TAEs as mLDP protection, and then the session moves on to establishment as per [RFC5036] 🎉

6. Security Considerations 🔐💀

The procedures described in this document do not introduce any changes to LDP security considerations as described in [RFC5036]. Ngl, this is the part where we don't make it worse 🙏

As described in [RFC5036], DoS attacks via Extended Hellos, which are required to establish a tLDP session, can be addressed by filtering Extended Hellos using access lists that define the addresses with which Extended Discovery is permitted 🚨 Also, as described in Section 5.2 of this document, an LSR can use a policy to accept all auto-discovered Extended Hellos from the configured source addresses list 🫶

Also, for the two LSRs supporting the TAC, the tLDP session is only established after the TAC has been successfully negotiated. The initiating and receiving LSRs MUST only advertise TA-Ids that they support. In other words, they can only advertise what they're configured for over the tLDP session 💅✨

7. IANA Considerations 📋✨

okay bestie, IANA gets the code point first 💅 The new Capability Parameter TLV gets 0x050F from the "TLV Type Name Space" sub-registry of the "Label Distribution Protocol (LDP) Parameters" registry. It's giving very organized energy 🎀

   Value   Description                      Reference
   ------  -------------------------------  ---------
   0x050F  Targeted Application Capability  RFC 8223

IANA also gave us a new status code from the "Status Code Name Space" sub-registry, in the same LDP Parameters registry. Iconic 👑

   Value        E   Description                           Reference
   ----------  ---  -----------------------------------   ---------
   0x0000004C   1   Session Rejected/Targeted
                       Application Capability Mismatch    RFC 8223

And then there's the new registry called "LDP Targeted Application Identifier", also inside the LDP Parameters registry 🦋 The range is 0x0001-0xFFFE. Values in 0x0001-0x1FFF shall be allocated according to the "IETF Review" procedure [RFC8126], and values in 0x2000-0xF7FF shall be allocated according to the "First Come First Served" procedure [RFC8126]. Those are the rules of the game 🎮 Here are the initial values, bestie:

   Value            Description                      Reference
   ---------------  -------------------------------  ---------
   0x0000           Reserved                         RFC 8223
   0x0001           LDPv4 Tunneling                  RFC 8223
   0x0002           LDPv6 Tunneling                  RFC 8223
   0x0003           mLDP Tunneling                   RFC 8223
   0x0004           LDPv4 Remote LFA                 RFC 8223
   0x0005           LDPv6 Remote LFA                 RFC 8223
   0x0006           LDP FEC 128 PW                   RFC 8223
   0x0007           LDP FEC 129 PW                   RFC 8223
   0x0008           LDP Session Protection           RFC 8223
   0x0009           LDP ICCP                         RFC 8223
   0x000A           LDP P2MP PW                      RFC 8223
   0x000B           mLDP Node Protection             RFC 8223
   0x000C           LDPv4 Intra-area FECs            RFC 8223
   0x000D           LDPv6 Intra-area FECs            RFC 8223
   0x000E-0xF7FF    Unassigned
   0xF800-0xFBFF    Available for Private Use
   0xFC00-0xFFFE    Available for Experimental Use
   0xFFFF           Reserved                         RFC 8223

8. References 📚

8.1. Normative References 💖

These are the must-reads, the ones you lean on 🫶

8.2. Informative References 🌸

These are the extra reading for when you want the full picture 🧚

Acknowledgments 🫶

The authors wanted to thank Nischal Sheth, Hassan Hosseini, Kishore Tiruveedhula, Loa Andersson, Eric Rosen, Yakov Rekhter, Thomas Beckhaus, Tarek Saad, Lizhong Jin, and Bruno Decraene for their detailed reviews 🙌 Thanks also to Manish Gupta and Martin Ehlers for their input to this work and many helpful suggestions 💜

Contributors 💜

These people contributed substantially to the content of this document and should be considered co-authors ✨

   Chris Bowers
   Juniper Networks
   1133 Innovation Way
   Sunnyvale, CA  94089
   United States of America
   Email: cbowers@juniper.net

   Zhenbin Li
   Huawei
   Bldg. No. 156 Beiqing Rd.
   Beijing  100095
   China
   Email: lizhenbin@huawei.com

Authors' Addresses 🦋

   Santosh Esale
   Juniper Networks
   1133 Innovation Way
   Sunnyvale, CA  94089
   United States of America

   Email: sesale@juniper.net


   Raveendra Torvi
   Juniper Networks
   10 Technology Park Drive
   Westford, MA  01886
   United States of America

   Email: rtorvi@juniper.net


   Luay Jalil
   Verizon
   1201 East Arapaho Road
   Richardson, TX  75081
   United States of America

   Email: luay.jalil@verizon.com


   Uma Chunduri
   Huawei
   2330 Central Expressway
   Santa Clara, CA  95050
   United States of America

   Email: uma.chunduri@huawei.com


   Kamran Raza
   Cisco Systems, Inc.
   2000 Innovation Drive
   Ottawa, ON  K2K-3E8
   Canada

   Email: skraza@cisco.com
📦 where this page comes from