RFC 5443

RFC 5443: LDP IGP Synchronization 🎀

Okay bestie, here's the tea on RFC 5443 💅. It's called LDP IGP Synchronization and it comes from the Network Working Group. The authors are M. Jork (GENBAND), A. Atlas (British Telecom), and L. Fang (Cisco Systems, Inc.). It's an Informational doc from March 2009 🌸. The title block doesn't list anything it obsoletes or updates, so it's a standalone vibe ✨.

Status of This Memo 📜

This memo gives information to the Internet community. It is not a standard of any kind 🫶. Distribution of this memo is unlimited.

Copyright Notice ©️

Copyright (c) 2009 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, as they stood on the publication date of this document (http://trustee.ietf.org/license-info). Please read these carefully, because they explain your rights and restrictions for this document 🧐.

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

Abstract 💭

okay so some networks depend on edge-to-edge Label Switched Paths (LSPs) that are set up by the Label Distribution Protocol (LDP). Think networks used for Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) applications 🌐. For those apps, you can't just fall back on Internet Protocol (IP) forwarding if the MPLS LSP isn't working properly. Labeled traffic can get blackholed when the Interior Gateway Protocol (IGP) is up on a link where LDP isn't. The link could still carry IP traffic, but it's useless for MPLS forwarding, which matters for MPLS VPN apps or Border Gateway Protocol (BGP) route-free cores 💀. This document describes a mechanism that avoids that traffic loss without introducing any protocol changes 🦋.

Table of Contents

   1. Introduction ....................................................2
      1.1. Conventions Used in This Document ..........................3
   2. Proposed Solution ...............................................3
   3. Applicability ...................................................4
   4. Interaction with TE Tunnels .....................................5
   5. Security Considerations .........................................5
   6. References ......................................................6
      6.1. Normative References .......................................6
      6.2. Informative References .....................................6
   7. Acknowledgments .................................................6

1. Introduction ✨

LDP [RFC5036] sets up MPLS LSPs along the shortest path to a destination, as IP forwarding decides it. In a common network design, LDP provides Label Switched Paths across the whole network domain covered by an IGP, like Open Shortest Path First (OSPF) [RFC2328] or Intermediate System to Intermediate System (IS-IS) [ISO.10589.1992]. In other words, every link in the domain has both an IGP adjacency and an LDP adjacency 🍓.

Plenty of services a network provider might want to run on an LDP-enabled network need edge-to-edge label switched paths. Take a layer 2 (L2) or layer 3 (L3) VPN. A given Provider-Edge (PE) router needs a complete MPLS forwarding path to the other PE routers for the VPNs it serves 🔥. That means every link on the IP shortest path from one PE router to another needs a working LDP session, and the right label bindings must have been exchanged over those sessions. If even one link on that path isn't covered by an LDP session, there's a blackhole, and any services that depend on MPLS forwarding will fail 😭. This could be a short-lived glitch or a long-term problem. Some of the reasons could be:

• A configuration error.
• An implementation bug.
• The link has just come up and has an IGP adjacency, but LDP hasn't yet established an adjacency or session, or hasn't yet distributed all the label bindings.

Right now LDP has no way to fix this 🙈. LDP isn't a routing protocol, so it can't redirect traffic onto an alternate IGP path.

1.1. Conventions Used in This Document 📝

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 [RFC2119].

2. Proposed Solution 💡

This problem happens because LDP is tied to IP-forwarding decisions, but nothing couples the IGP and LDP operational state on a given link. If the IGP is up on a link but LDP isn't, you've got a potential network problem 🌸. So the solution in this document is to discourage using a link for IP forwarding for as long as LDP isn't fully operational.

It's kind of similar to the mechanism in [RFC3137], which lets an OSPF router advertise that it shouldn't be used as a transit router. The difference is that [RFC3137] raises the link costs on all (stub) router links, while this mechanism works on a per-link basis 🎯.

Here's the detail: when LDP is not "fully operational" (see below) on a given link, the IGP advertises that link with the maximum cost so no transit traffic goes over it. For OSPF, that cost is LSInfinity (16-bit value 0xFFFF), as proposed in [RFC3137]. For IS-IS, the maximum metric value is 2^24-2 (0xFFFFFE). And if a link is configured with 2^24-1 (the maximum link metric per [RFC5305]), then that link doesn't get advertised in the topology at all. That's a no-no, because it's important to keep the link in the topology so IP traffic can still use it as a last resort during a massive failure 😤.

LDP counts as fully operational on a link when three things are true: an LDP hello adjacency exists on it, a suitable associated LDP session (matching the LDP Identifier of the hello adjacency) is established to the peer at the other end of the link, and all label bindings have been exchanged over that session ✨. Right now, a router generally can't verify that last condition, so some estimation may have to be used 🤔. A simple strategy is a configurable hold-down timer that gives LDP session establishment time to finish before declaring LDP fully operational. This document doesn't define a default for that timer, because the Label Information Base (LIB) table size and equipment capabilities vary a lot 🧠.

There's also ongoing work on LDP End-of-LIB, described in [End-of-LIB]. It lets an LDP speaker signal that it's finished its initial advertisement after a session comes up 🎉. Once LDP End-of-LIB is implemented, the configurable hold-down timer isn't needed anymore. A neighbor LDP session counts as fully operational once the End-of-LIB notification message is received 💖.

Usually that's enough to handle a link when it's coming up. LDP protocol extensions that signal the complete transmission of all currently available label bindings after a session comes up are conceivable, but this document doesn't address them 🦋.

The mechanism in this document doesn't entail any protocol changes. It's purely a local implementation issue 🫶.

The problem space and solution in this document have also been covered in an IEEE Communications Magazine paper [LDP-Fail-Rec] 📰.

3. Applicability 🌈

In general, this procedure fits networks where having LDP-signaled MPLS LSPs and avoiding blackholes for MPLS traffic matters more than always picking the optimal path for IP-forwarded traffic 👑. But heads up: non-optimal IP forwarding only happens for a short time after a link comes up, or when there's a real problem on a link. In that second case, an implementation should issue network management alerts to report the error and let the operator fix it 🚨.

Example scenarios that benefit from this mechanism include MPLS VPNs and BGP-free core network designs, where traffic can only be forwarded through the core when LDP forwarding state is available throughout 🧚.

How useful this mechanism is also depends on having alternate paths with enough bandwidth in the network, in case one link gets assigned the maximum cost because LDP service over it is unavailable 💅.

On broadcast links with more than one IGP/LDP peer, the cost-out procedure can only be applied to the link as a whole, not to an individual peer. So a policy decision has to be made about whether losing LDP service to one peer should divert traffic away from all the peers on the link 🤷‍♀️.

4. Interaction with TE Tunnels 🚇

In some networks, LDP is used together with RSVP-TE, which sets up traffic-engineered tunnels. Path computation for TE tunnels is based on the TE link cost that the IGP floods, in addition to the regular IP link cost. The mechanism in this document should only be applied to the IP link cost, so it doesn't cause unnecessary TE tunnel reroutes 🎀.

To set up LDP LSPs across a TE tunnel, there has to be a targeted LDP session between the tunnel endpoints. This is a lot like the regular-LDP-session-over-a-link case we've been talking about: when the TE tunnel is used for IP forwarding, the targeted LDP session needs to be operational to avoid LDP connectivity problems 😩. Again, raising the IP cost of the tunnel while there's no operational LDP session solves the problem ✨. If there's no IGP adjacency over the tunnel and the tunnel isn't advertised as a link into the IGP, then it's a purely local issue for the tunnel headend router 🥹.

5. Security Considerations 🔐

okay bestie, this part is serious, so let's get it right 💅. A DoS attack that knocks out LDP service on a link, or stops it from ever coming up on a link, could be one way you end up with LDP-related traffic blackholing 😭. This document does not deal with how to stop LDP sessions from failing 🙈.

What the mechanism here does is stop a link from being used when LDP isn't working but IGP is still happily up ✨. Setting the IGP cost to maximum on that kind of link should not bring in any new security threats 🧚. The whole thing happens inside the router, so LDP and IGP can talk to each other and react 🫶.

Now the not-so-cute part 💀. If a bunch of LDP links all go unavailable at once, that IS a security threat, because it can drop traffic when there isn't enough network capacity left 😭. This can be set off by an operational error or an implementation error 🙈. These count as general security issues, so implementors should follow the current best security practice [MPLS-GMPLS-Sec] 🎀 fr fr, no skipping that.

---

6. References 📚

6.1. Normative References 🌸

[RFC2119]        Bradner, S., "Key words for use in RFCs to Indicate
                 Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2328]        Moy, J., "OSPF Version 2", STD 54, RFC 2328, April
                 1998.

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

6.2. Informative References 🦋

[End-of-LIB]     Asati, R., LDP End-of-LIB, Work in Progress, January
                 2009.

[ISO.10589.1992] International Organization for Standardization,
                 "Intermediate system to intermediate system intra-
                 domain-routing routine information exchange protocol
                 for use in conjunction with the protocol for
                 providing the connectionless-mode Network Service
                 (ISO 8473)", ISO Standard 10589, 1992.

[LDP-Fail-Rec]   Fang, L., Atlas, A., Chiussi, F., Kompella, K., and
                 G. Swallow, "LDP Failure Detection and Recovery",
                 IEEE Communications Magazine, Vol.42, No.10, October
                 2004.

[MPLS-GMPLS-Sec] Fang. L., Ed., "Security Framework for MPLS and
                 GMPLS Networks", Work in Progress, November 2008.

[RFC3137]        Retana, A., Nguyen, L., White, R., Zinin, A., and D.
                 McPherson, "OSPF Stub Router Advertisement", RFC
                 3137, June 2001.

[RFC5305]        Li, T. and H. Smit, "IS-IS Extensions for Traffic
                 Engineering", RFC 5305, October 2008.

---

7. Acknowledgments 💜

The authors would like to thank Bruno Decraene for his in-depth discussion and comments 🙌, and Dave Ward for his helpful review and input 💖. Thank you also to Loa Andersson, Ross Callon, Amanda Baber, Francis Dupont, Donald Eastlake, Russ Housley, Pasi Eronen, Dan Romascanu, Bin Mo, Lan Zheng, Bob Thomas, and Dave Ojemann for their reviews and comments ✨. The squad really showed up 👑.

Authors' Addresses 🎀

Markus Jork
GENBAND
3 Federal St.
Billerica, MA 01821
USA

EMail: Markus.Jork@genband.com


Alia Atlas
British Telecom

EMail: alia.atlas@bt.com


Luyuan Fang
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough, MA 01719
USA

EMail: lufang@cisco.com
Phone: 1 (978) 936-1633