RFC 5919

RFC 5919: Signaling LDP Label Advertisement Completion 🎀

Okay bestie, let's get into RFC 5919 ✨. The official title is Signaling LDP Label Advertisement Completion. It was written by R. Asati and P. Mohapatra from Cisco Systems, E. Chen from Huawei Technologies, and B. Thomas. It's a Standards Track doc, published in August 2010, with ISSN 2070-1721. 💅

Abstract 🌸

So there are moments after an LDP session is set up where it would be super useful for one LDP speaker to know when its peer has advertised all of its labels 👀. The LDP spec doesn't give you a way to tell your peer "hey, I'm done with my initial label advertisements" 😭. This doc fixes that by defining how an LDP speaker can signal that its initial label advertisements are complete after session establishment. 🦋

Status of This Memo 💜

This is an Internet Standards Track document.

This doc is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, it went through public review, and the Internet Engineering Steering Group (IESG) approved it for publication. If you want more info on Internet Standards, check out Section 2 of RFC 5741 🧚.

For the current status, any errata, and how to give feedback on this doc, head to http://www.rfc-editor.org/info/rfc5919 🔗.

Copyright Notice 🎀

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

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

This doc may include material from IETF Documents or IETF Contributions that were 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. So unless you get an adequate license from those copyright holders, this doc can't be modified outside the IETF Standards Process, and derivative works can't be made outside it either. The one exceptions are formatting it for publication as an RFC or translating it into languages other than English. 🙈

Table of Contents 🍓

   1. Introduction ....................................................3
      1.1. Applicability - Label Advertisement Mode ...................3
   2. Specification Language ..........................................3
   3. Unrecognized Notification Capability ............................4
   4. Signaling Completion of Label Advertisement .....................4
      4.1. Missing Expected End-of-LIB Notifications ..................5
   5. Usage Guidelines ................................................6
   6. Security Considerations .........................................8
   7. IANA Considerations .............................................8
   8. Acknowledgments .................................................8
   9. References ......................................................8
      9.1. Normative References .......................................8
      9.2. Informative References .....................................9

1. Introduction ✨

Okay so there are situations after LDP session establishment where it would be super helpful for an LDP speaker to know when its peer has advertised all the labels from its Label Information Base (LIB) 🫶. For example, if an LDP speaker is using LDP-IGP synchronization procedures [RFC5443], it's really useful to know when its peer has finished advertising its IP label bindings. Same vibe after an LDP session gets re-established with LDP Graceful Restart [RFC3478] in effect: each peer would love to signal the other once it has advertised all its label bindings 💅.

The LDP spec [RFC5036] gives you zero mechanism for an LDP speaker to tell a peer it has finished its initial label advertisements to that peer. Lowkey rude 😭.

So this doc specifies using a Notification message with the End-of-LIB Status Code, so an LDP speaker can signal that it's done advertising labels after session establishment. 🦋

RFC 5036 kind of assumes new Status Codes will show up over time 🔮. But it doesn't spell out what an LDP speaker should do if it doesn't understand the Status Code in a Notification message. To avoid backward compatibility drama, this doc uses the LDP capability mechanism [RFC5561] at session establishment. That's how a speaker tells its peer it can handle a Notification message carrying an unrecognized Status Code 🎀.

1.1. Applicability - Label Advertisement Mode 🌸

The mechanisms in this doc are considered useful for LDP peering that uses the 'Downstream Unsolicited' label advertisement mode [RFC5036]. They're not considered useful for LDP peering in the 'Downstream on Demand' mode, because there the LDP speaker already asks its peer for specific label bindings and knows when it has received them 🙌.

2. Specification Language 💜

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be interpreted as described in [RFC2119] 📖.

3. Unrecognized Notification Capability 🧚

An LDP speaker MAY include a Capability Parameter [RFC5561] in the Initialization message. Doing that tells its peer that it ignores Notification Messages carrying a Status Type-Length-Value (TLV) with a non-fatal Status Code it doesn't recognize 👀.

The Capability Parameter for the Unrecognized Notification capability is a TLV with this format:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |U|F| Unrecognized Noti (0x0603)|            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |S| Reserved    |
   +-+-+-+-+-+-+-+-+

         Figure 1: Unrecognized Notification Capability Format

Here's what each field needs:

• U- and F-bits: MUST be 1 and 0, respectively, as per Section 3 of LDP Capabilities [RFC5561] 🔥.
• Unrecognized Notif: 0x0603 🌈.
• S-bit: MUST be 1 (this means the capability is being advertised) ✨.

When a speaker receives a Notification with an unrecognized Status Code, it MAY generate a console or system log message to help with troubleshooting 🛠️.

4. Signaling Completion of Label Advertisement 👑

An LDP speaker that follows this spec SHOULD signal that it has finished its label advertisements to a peer using a Notification message, as long as that peer advertised the Unrecognized Notification capability during session establishment. The speaker SHOULD send that Notification (one per Forwarding Equivalence Class (FEC) Type) even if it has zero label bindings to advertise to that peer 🦋. Main character energy, no matter how many labels you've got 💖.

Such a Notification message MUST carry:

• A status TLV (with TLV E- and F-bits set to zero) that carries an End-of-LIB Status Code (0x0000002F) 🎀.
• A FEC TLV with the Typed Wildcard FEC Element [RFC5918] that identifies the FEC type whose initial label advertisements are done. In terms of Section 3.5.1 of RFC 5036, this TLV is an "Optional Parameter" of the Notification message 🧚.

An LDP speaker MUST NOT send a Notification carrying a Status TLV with the End-of-LIB Status Code to a peer unless that peer advertised the Unrecognized Notification capability during session establishment. Don't skip this one bestie 🚫.

This applies to any LDP peers found through either basic discovery or extended discovery (per Section 2.4 of [RFC5036]) 🔍.

4.1. Missing Expected End-of-LIB Notifications 🙈

Here's the honest truth: there's no guarantee that an LDP speaker will receive (or send) an End-of-LIB Notification from (or to) a peer, even if the speaker has signaled the Unrecognized Notification capability (Section 3) 😭.

It's expected that an LDP speaker supporting the Unrecognized Notification capability would support sending and receiving an End-of-LIB Notification, but by definition it isn't mandatory 🫠.

And honestly, this isn't a big deal. By definition, the LDP speaker just ignores any Notification with an End-of-LIB status code (or any other status code) that it doesn't recognize or support 💅.

So to deal with End-of-LIB Notifications possibly going missing after LDP session establishment, an LDP speaker MAY time out while waiting for an expected End-of-LIB Notification. An LDP speaker SHOULD start a per-peer internal timer called 'EOL Notification' immediately after LDP session establishment. The default value of 60 seconds is RECOMMENDED, but this timer's value SHOULD be configurable ⏱️.

This timer gets reset by the subsequent label advertisement, and it's stopped by the End-of-LIB Notification message. If there's no label advertisement from the peer, the timer expires, and the LDP speaker behaves as if it had received the End-of-LIB Notification from that peer 🎀.

If the End-of-LIB Notification message shows up after the timer has expired, the message SHOULD be ignored 🙅‍♀️.

5. Usage Guidelines 🌈

The FECs an LDP speaker knows about, and the labels it has bound to those FECs, can change over time 🔄. That makes it tricky to figure out when a speaker has advertised "all" of its label bindings for a given FEC type. Ultimately, that's a judgment call the LDP speaker makes. These guidelines may help 🧠.

An LDP speaker is assumed to "know" a set of FECs 📚. Depending on a few criteria, such as:

• the label distribution control mode in use (Independent or Ordered);
• the set of FECs to which the speaker has bound local labels;
• configuration settings that may constrain which label bindings the speaker may advertise to peers.

The speaker can work out the set of bindings for a given FEC type that it's allowed to advertise to a given peer 🫶.

LDP-IGP Sync, LDP Graceful Restart, and the response to a Wildcard Label Request [RFC5918] are all situations that benefit from an End-of-LIB Notification 🙌. In these situations, once an LDP speaker finishes its label binding advertisements to a peer, sending an End-of-LIB Notification to that peer makes the outcome deterministic 💖. The subsections below walk through each of these situations one by one 👀.

To be continued in Part 2! 🎀✨

5.1. LDP-IGP Sync 🔗

okay so LDP-IGP Synchronization [RFC5443] is the feature that lets directly connected LDP speakers hold off on using the link between them for transit IP traffic forwarding. The hold lasts until the labels needed for IP-over-MPLS forwarding have been distributed and installed. bestie, this is giving patience 🫶

Without an End-of-LIB Notification, the speaker has to rely on some heuristic to figure out when it has received all of its peer's label bindings. 😬 The heuristic could tell LDP to signal the IGP too soon, which means traffic is more likely to get dropped. Or it could signal too late, and then traffic stays on sub-optimal paths longer than it needs to. Neither one is it, ngl.

After session establishment, a directly connected peer that has advertised the Unrecognized Notification capability can get an End-of-LIB Notification from an LDP speaker using LDP-IGP Sync. The speaker sends it once it finishes advertising its IP label bindings to that peer. The speaker can also use an End-of-LIB Notification it receives from a directly connected peer to know when that peer has finished advertising its label bindings for IP prefixes. Once the notification arrives, the speaker should consider LDP fully operational for the link and should signal the IGP to start advertising the link with normal cost. main character energy for that link 💅✨

5.2. LDP Graceful Restart 🔄

LDP Graceful Restart [RFC3478] helps cut down on the loss of MPLS traffic when a router's LDP component restarts. 🌸 It defines procedures for routers that can preserve MPLS forwarding state across the restart. Those routers keep forwarding MPLS traffic using the forwarding state they installed before the restart, for a configured time period.

Without End-of-LIB Notification, here's how it goes. The restarting router and its peers treat the preserved forwarding state as usable but stale. It stays that way until new label advertisements refresh it after new LDP sessions come up, or until the time period runs out. When the time period expires, the router removes whatever stale forwarding state is still left. 🕰️

Getting an End-of-LIB Notification from a peer in an LDP Graceful Restart scenario lets an LDP speaker stop using stale forwarding information learned from that peer. It can also recover the resources it needs without waiting for the time period to expire. 🧹 And if the End-of-LIB Notification never shows up, the time period expiry still works as the fallback. no notes, just vibes 🦋

5.3. Wildcard Label Request 🃏

When an LDP speaker gets a Label Request message from a peer for a Typed Wildcard FEC (for example, a particular FEC Element Type), it figures out which bindings to advertise to that peer for the FEC type in the request. It does this according to any local filtering policy. If the peer advertised the Unrecognized Notification capability at session initialization time, the speaker should send the peer an End-of-LIB Notification for that FEC type once it finishes advertising the permitted bindings. 💌

It's the same deal as the earlier applications. Getting the Notification clears up any uncertainty about when the peer has finished advertising label bindings for the requested Wildcard FEC Element Type. ✅

---

6. Security Considerations 🔐

Okay, security time, and this part is serious, bestie 😤 No security considerations beyond the ones that apply to the base LDP specification [RFC5036] and the ones further described in [RFC5920] apply to signaling the End-of-LIB condition the way this document describes. So the security story here is already covered by those two specs, and this doc doesn't add anything new on top. 🛡️✨

7. IANA Considerations 📋

This document introduces a new LDP Status Code and a new LDP Capability. 🎀

IANA assigned the End-of-LIB status code (0x0000002F) from the Status Code Name Space. [RFC5036] splits that Status Code Name Space into 3 regions: the IETF Consensus region, the First Come First Served region, and the Private Use region. The code point 0x0000002F is in the IETF Consensus range. 🧾

IANA also assigned the Unrecognized Notification capability (0x0603) from the TLV Type name space. [RFC5036] splits the TLV Type name space into 3 regions: the IETF Consensus region, the Vendor Private Use region, and the Experimental Use region. The code point 0x0603 is in the IETF Consensus range. 🥰

8. Acknowledgments 🙏

The authors want to shout out Kamran Raza, who helped formulate this draft. 📣

They also want to thank Ina Minei, Alia Atlas, Yakov Rekhter, Loa Andersson, and Luyuan Fang for their valuable feedback and contributions. You all ate this up 👑🌈

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.

[RFC5036]  Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
           "LDP Specification", RFC 5036, October 2007.

[RFC5561]  Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL.
           Le Roux, "LDP Capabilities", RFC 5561, July 2009.

[RFC5918]  Asati, R., Minei, I., and B. Thomas, "Label Distribution
           Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class
           (FEC)", RFC 5918, August 2010.

9.2. Informative References 🦋

[RFC3478]  Leelanivas, M., Rekhter, Y., and R. Aggarwal, "Graceful
           Restart Mechanism for Label Distribution Protocol", RFC
           3478, February 2003.

[RFC5443]  Jork, M., Atlas, A., and L. Fang, "LDP IGP
           Synchronization", RFC 5443, March 2009.

[RFC5920]  Fang, L., Ed., "Security Framework for MPLS and GMPLS
           Networks", RFC 5920, July 2010.

Authors' Addresses 🧚

Rajiv Asati
Cisco Systems
7025-6 Kit Creek Rd.
Research Triangle Park, NC  27709-4987
EMail: rajiva@cisco.com


Pradosh Mohapatra
Cisco Systems
3750 Cisco Way
San Jose, CA  95134
EMail: pmohapat@cisco.com


Emily Chen
Huawei Technologies
No. 5 Street, Shangdi Information, Haidian
Beijing, China
EMail: chenying220@huawei.com


Bob Thomas
EMail: bobthomas@alum.mit.edu

---

That's the whole RFC, bestie! 🌈💖 Iconic work, you made it through LDP and back. 💅✨