LDP IGP Sync: LDP IGP Synchronization
How to keep IP traffic off a link where routing works but label switching does not, without changing any protocol.
Jork, M., Atlas, A., and L. Fang, "LDP IGP Synchronization", RFC 5443, DOI 10.17487/RFC5443, March 2009, <https://www.rfc-editor.org/info/rfc5443>.
@misc{rfc5443,
series = {Request for Comments},
number = 5443,
howpublished = {RFC 5443},
publisher = {RFC Editor},
doi = {10.17487/RFC5443},
url = {https://www.rfc-editor.org/info/rfc5443},
author = {M. Jork and A. Atlas and L. Fang},
title = {{LDP IGP Synchronization}},
pagetotal = 7,
year = 2009,
month = mar,
} RFC text
Contents
Network Working Group M. Jork
Request for Comments: 5443 GENBAND
Category: Informational A. Atlas
British Telecom
L. Fang
Cisco Systems, Inc.
March 2009
LDP IGP Synchronization
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Abstract
In certain networks, there is dependency on the edge-to-edge Label
Switched Paths (LSPs) setup by the Label Distribution Protocol (LDP),
e.g., networks that are used for Multiprotocol Label Switching (MPLS)
Virtual Private Network (VPN) applications. For such applications,
it is not possible to rely on Internet Protocol (IP) forwarding if
the MPLS LSP is not operating appropriately. Blackholing of labeled
traffic can occur in situations where the Interior Gateway Protocol
(IGP) is operational on a link on which LDP is not. While the link
could still be used for IP forwarding, it is not useful for MPLS
forwarding, for example, MPLS VPN applications or Border Gateway
Protocol (BGP) route-free cores. This document describes a mechanism
to avoid traffic loss due to this condition 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] establishes MPLS LSPs along the shortest path to a
destination as determined by IP forwarding. In a common network
design, LDP is used to provide Label Switched Paths throughout the
complete network domain covered by an IGP such as Open Shortest Path
First (OSPF) [RFC2328] or Intermediate System to Intermediate System
(IS-IS) [ISO.10589.1992]; i.e., all links in the domain have IGP as
well as LDP adjacencies.
A variety of services a network provider may want to deploy over an
LDP-enabled network depend on the availability of edge-to-edge label
switched paths. In a layer 2 (L2) or layer 3 (L3) VPN scenario, for
example, a given Provider-Edge (PE) router relies on the availability
of a complete MPLS forwarding path to the other PE routers for the
VPNs it serves. This means that all the links along the IP shortest
path from one PE router to the other need to have operational LDP
sessions, and the necessary label binding must have been exchanged
over those sessions. If only one link along the IP shortest path is
not covered by an LDP session, a blackhole exists and services
depending on MPLS forwarding will fail. This might be a transient or
a persistent error condition. Some of the reasons for this could be:
- A configuration error.
- An implementation bug.
- The link has just come up and has an IGP adjacency but LDP has
either not yet established an adjacency or session, or has not yet
distributed all the label bindings.
The LDP protocol has currently no way to correct the issue. LDP is
not a routing protocol; it cannot re-direct traffic to 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
The problem described above exists because LDP is tied to
IP-forwarding decisions but no coupling between the IGP and LDP
operational state on a given link exists. If IGP is operational on a
link but LDP is not, a potential network problem exists. So the
solution described by this document is to discourage a link from
being used for IP forwarding as long as LDP is not fully operational.
This has some similarity to the mechanism specified in [RFC3137],
which allows an OSPF router to advertise that it should not be used
as a transit router. One difference is that [RFC3137] raises the
link costs on all (stub) router links, while the mechanism described
here applies on a per-link basis.
In detail: when LDP is not "fully operational" (see below) on a given
link, the IGP will advertise the link with maximum cost to avoid any
transit traffic over it. In the case of OSPF, this cost is
LSInfinity (16-bit value 0xFFFF), as proposed in [RFC3137]. In the
case of ISIS, the maximum metric value is 2^24-2 (0xFFFFFE). Indeed,
if a link is configured with 2^24-1 (the maximum link metric per
[RFC5305]), then this link is not advertised in the topology. It is
important to keep the link in the topology to allow IP traffic to use
the link as a last resort in case of massive failure.
LDP is considered fully operational on a link when 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 the session. At the present time, the latter
condition cannot generally be verified by a router and some
estimation may have to be used. A simple implementation strategy is
to use a configurable hold-down timer to allow LDP session
establishment before declaring LDP fully operational. The default
timer is not defined in this document due to concerns of the large
variations of the Label Information Base (LIB) table size and
equipment capabilities. In addition, there is a current work in
progress on LDP End-of-LIB as specified in [End-of-LIB], which
enables the LDP speaker to signal the completion of its initial
advertisement following session establishment. When LDP End-of-LIB
is implemented, the configurable hold-down timer is no longer needed.
The neighbor LDP session is considered fully operational when the
End-of-LIB notification message is received.
This is typically sufficient to deal with the link when it is being
brought up. LDP protocol extensions to indicate the complete
transmission of all currently available label bindings after a
session has come up are conceivable, but not addressed in this
document.
The mechanism described in this document does not entail any protocol
changes and is a local implementation issue.
The problem space and solution specified in this document have also
been discussed in an IEEE Communications Magazine paper
[LDP-Fail-Rec].
3. Applicability
In general, the proposed procedure is applicable in networks where
the availability of LDP-signaled MPLS LSPs and avoidance of
blackholes for MPLS traffic are more important than always choosing
an optimal path for IP-forwarded traffic. Note however that non-
optimal IP forwarding only occurs for a short time after a link comes
up or when there is a genuine problem on a link. In the latter case,
an implementation should issue network management alerts to report
the error condition and enable the operator to address it.
Example network scenarios that benefit from the mechanism described
here are MPLS VPNs and BGP-free core network designs where traffic
can only be forwarded through the core when LDP forwarding state is
available throughout.
The usefulness of this mechanism also depends on the availability of
alternate paths with sufficient bandwidth in the network should one
link be assigned to the maximum cost due to the unavailability of LDP
service over it.
On broadcast links with more than one IGP/LDP peer, the cost-out
procedure can only be applied to the link as a whole and not to an
individual peer. So a policy decision has to be made whether the
unavailability of LDP service to one peer should result in the
traffic being diverted away from all the peers on the link.
4. Interaction with TE Tunnels
In some networks, LDP is used in conjunction with RSVP-TE, which sets
up traffic-engineered tunnels. The path computation for the TE
tunnels is based on the TE link cost that is flooded by the IGP in
addition to the regular IP link cost. The mechanism described in
this document should only be applied to the IP link cost to prevent
unnecessary TE tunnel reroutes.
In order to establish LDP LSPs across a TE tunnel, a targeted LDP
session between the tunnel endpoints needs to exist. This presents a
problem very similar to the case of a regular LDP session over a link
(the case discussed so far): 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 is no operational LDP session will solve the problem.
When there is no IGP adjacency over the tunnel and the tunnel is not
advertised as a link into the IGP, this becomes a local issue of the
tunnel headend router.
5. Security Considerations
A Denial-of-Service (DoS) attack that brings down LDP service on a
link or prevents it from becoming operational on a link could be one
possible cause of LDP-related traffic blackholing. This document
does not address how to prevent LDP session failure. The mechanism
described here prevents the use of the link where LDP is not
operational while IGP is. Assigning the IGP cost to maximum on such
a link should not introduce new security threats. The operation is
internal to the router to allow LDP and IGP to communicate and react.
Making many LDP links unavailable, however, is a security threat that
can cause dropped traffic due to limited available network capacity.
This may be triggered by operational error or implementation error.
These errors are considered general security issues and implementors
should follow the current best security practice [MPLS-GMPLS-Sec].
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, Dave Ward for his helpful review and input,
and 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.
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
ISO Plain Language
On this page
§1The Blackhole Problem
LDP (RFC 5036) builds MPLS label switched paths (LSPs) along the shortest path to a destination as computed by IP forwarding. In a common design an IGP such as OSPF (RFC 2328) or IS-IS (ISO 10589) runs on every link, and so does LDP, so the whole domain has matching IGP and LDP adjacencies.
Some services need a complete edge-to-edge MPLS path between provider-edge routers. The RFC names layer 2 and layer 3 VPNs. Every link on the IP shortest path must have an operational LDP session and the needed label bindings must have been exchanged over it. If even one link lacks an LDP session, a blackhole exists and services that depend on MPLS forwarding fail.
The RFC lists three causes: a configuration error, an implementation bug, or a link that has just come up and has an IGP adjacency while LDP has not yet formed a session or distributed all label bindings. LDP cannot repair this, because it is not a routing protocol and cannot send traffic down a different IGP path.
If one road on a delivery route is closed to trucks, the whole delivery fails, even though cars can still drive there. The trucks cannot pick another road on their own, so the network must keep them off that road in the first place.
§2Raising the Link Cost Until LDP Is Ready
The problem exists because LDP follows IP forwarding decisions, but nothing couples a link's IGP state to its LDP state. The fix is to discourage the link from being used for IP forwarding while LDP is not fully operational on it.
The RFC notes a likeness to RFC 3137, which lets an OSPF router advertise that it should not be used for transit. One difference is that RFC 3137 raises costs on all of a stub router's links, while this mechanism works on one link at a time.
In detail, when LDP is not fully operational on a link, the IGP advertises the link at maximum cost. For OSPF that is LSInfinity, the 16-bit value 0xFFFF, as proposed in RFC 3137. For IS-IS the maximum metric value is 2^24-2 (0xFFFFFE). A link configured with 2^24-1, the maximum link metric of RFC 5305, is not advertised in the topology at all, so it cannot serve as a last resort. Keeping the link in the topology lets IP traffic still fall back on it during a massive failure.
LDP is fully operational on a link when an LDP hello adjacency exists, a matching LDP session is established with the peer at the far end, and all label bindings have been exchanged. A router generally cannot confirm the last point, so a simple strategy is a configurable hold-down timer before declaring LDP fully operational. The RFC defines no default, because label information base sizes and equipment capabilities vary widely. When LDP End-of-LIB (work in progress at the time) is implemented, the timer is not needed: receiving the End-of-LIB notification means the session is fully operational.
The mechanism brings no protocol changes and is a local implementation matter.
The router puts a very high toll on the half-ready link so nobody chooses it, but leaves the link open as a last resort. Once the truck lane is ready, the toll goes away. Deciding when it is ready may need a short wait, because the router cannot always tell by itself.
| IGP | Cost while LDP is not ready | Note |
|---|---|---|
| OSPF | LSInfinity, 0xFFFF (16-bit) | As proposed in RFC 3137 |
| IS-IS | 2^24-2 (0xFFFFFE) | 2^24-1 would remove the link from the topology |
§3When to Use It
The procedure suits networks where having working LDP-signaled MPLS LSPs and avoiding blackholes for MPLS traffic matters more than always choosing the best path for IP-forwarded traffic. The examples given are MPLS VPNs and BGP-free core designs, where traffic can pass through the core only when LDP forwarding state exists throughout.
Non-optimal IP forwarding happens only briefly after a link comes up, or while a real problem lasts. In the second case an implementation should raise network management alerts so the operator can fix the cause.
The mechanism also needs alternate paths with enough bandwidth, since the costed-out link carries no transit traffic. On a broadcast link with more than one IGP/LDP peer, the cost-out can apply only to the link as a whole, not to one peer, so a policy decision is needed on whether losing LDP to a single peer should divert traffic from all peers on that link.
This is worth doing when trucks matter more than taking the shortest route for cars, and only when there are other roads with room to spare. On a shared road, you cannot make it expensive for just one trucking company.
§4Interaction with TE Tunnels
Some networks run LDP alongside RSVP-TE, which sets up traffic-engineered tunnels. TE tunnel path computation uses a separate TE link cost that the IGP floods in addition to the regular IP link cost. The RFC says the mechanism should be applied only to the IP link cost, to avoid needless TE tunnel reroutes.
LDP LSPs across a TE tunnel need a targeted LDP session between the tunnel endpoints. This is much like a regular link: when the tunnel is used for IP forwarding, its targeted LDP session must be operational. Raising the tunnel's IP cost while there is no operational session solves it. If there is no IGP adjacency over the tunnel and the tunnel is not advertised into the IGP as a link, this becomes a local matter for the tunnel headend router.
Reserved lanes keep their own price list. Only the normal price list is changed, so the reserved lanes are not rearranged for no reason.
§5Security Considerations
A denial-of-service attack that takes LDP down on a link, or keeps it from becoming operational, could be one cause of LDP-related blackholing. The RFC does not address how to prevent LDP session failure. The mechanism prevents use of a link where LDP is down while the IGP is up, and assigning the maximum IGP cost on such a link is not expected to add new threats, since the operation is internal to the router so LDP and the IGP can communicate.
Making many LDP links unavailable at once is a threat, because dropping that much of the network can lose traffic when capacity is limited. Operational or implementation error may trigger it. The RFC treats these as general security issues and says implementors should follow current best security practice.
Someone could break the truck lanes on purpose. This fix does not stop that, but it does not make things worse either. The bigger risk is many roads losing their truck lanes at once, leaving too little capacity for the remaining traffic.