draft-ietf-mpls-ldp-igp-sync-04.txt   rfc5443.txt 
Network Working Group M. Jork Network Working Group M. Jork
Internet Draft NextPoint Networks Request for Comments: 5443 GENBAND
Category: Informational Alia Atlas Category: Informational A. Atlas
Expires: June 17, 2009 British Telecom British Telecom
L. Fang L. Fang
Cisco Systems, Inc. Cisco Systems, Inc.
December 17, 2008
LDP IGP Synchronization LDP IGP Synchronization
draft-ietf-mpls-ldp-igp-sync-04.txt
Status of This Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
This memo provides information for the Internet community. It does This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this not specify an Internet standard of any kind. Distribution of this
memo is unlimited. memo is unlimited.
By submitting this Internet-Draft, each author represents that any Copyright Notice
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 18, 2009.
Copyright and License Notice
Copyright (c) 2008 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
LDP IGP Synchronization December 2008
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with and restrictions with respect to this document.
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 Abstract
In certain networks there is a dependency on edge-to-edge Label In certain networks, there is dependency on the edge-to-edge Label
Switched Paths (LSPs) setup by Label Distribution Protocol (LDP), Switched Paths (LSPs) setup by the Label Distribution Protocol (LDP),
e.g., networks that are used for MultiProtocol Label Switching e.g., networks that are used for Multiprotocol Label Switching (MPLS)
(MPLS) Virtual Private Network (VPN) applications. For such Virtual Private Network (VPN) applications. For such applications,
applications it is not possible to rely on Internet Protocol (IP) it is not possible to rely on Internet Protocol (IP) forwarding if
forwarding if the MPLS LSP is not operating appropriately. the MPLS LSP is not operating appropriately. Blackholing of labeled
Blackholing of labeled traffic can occur in situations where the traffic can occur in situations where the Interior Gateway Protocol
Interior Gateway Protocol (IGP) is operational on a link but LDP is (IGP) is operational on a link on which LDP is not. While the link
not operational on that link. While the link could still be used for could still be used for IP forwarding, it is not useful for MPLS
IP forwarding, it is not useful for MPLS forwarding, for example, forwarding, for example, MPLS VPN applications or Border Gateway
MPLS VPN; Border Gateway Protocol (BGP) route free core; or IP Protocol (BGP) route-free cores. This document describes a mechanism
address carried in the packet is out of the RFC 1918 [RFC 1918] to avoid traffic loss due to this condition without introducing any
space. This document describes a mechanism to avoid traffic loss due protocol changes.
to this condition without introducing any protocol changes.
Table of Contents Table of Contents
1. Introduction..................................................3 1. Introduction ....................................................2
2. Proposed Solution.............................................3 1.1. Conventions Used in This Document ..........................3
3. Applicability.................................................5 2. Proposed Solution ...............................................3
4. Interaction with TE Tunnels...................................5 3. Applicability ...................................................4
5. Security Considerations.......................................6 4. Interaction with TE Tunnels .....................................5
6. IANA Considerations...........................................6 5. Security Considerations .........................................5
7. Normative References..........................................6 6. References ......................................................6
8. Informational References......................................6 6.1. Normative References .......................................6
9. Authors' Addresses............................................7 6.2. Informative References .....................................6
10. Acknowledgments..............................................7 7. Acknowledgments .................................................6
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 [RFC
2119].
LDP IGP Synchronization December 2008
1. Introduction 1. Introduction
LDP [RFC 5036] establishes MPLS LSPs along the shortest path to a LDP [RFC 5036] establishes MPLS LSPs along the shortest path to a
destination as determined by IP forwarding. In a common network destination as determined by IP forwarding. In a common network
design, LDP is used to provide label switched paths throughout the design, LDP is used to provide Label Switched Paths throughout the
complete network domain covered by an IGP such as Open Shortest complete network domain covered by an IGP such as Open Shortest Path
Path First (OSPF) [RFC 2328] or Intermediate system to intermediate First (OSPF) [RFC2328] or Intermediate System to Intermediate System
system (IS-IS) [ISO.10589.1992], i.e., all links in the domain have (IS-IS) [ISO.10589.1992]; i.e., all links in the domain have IGP as
IGP as well as LDP adjacencies. well as LDP adjacencies.
A variety of services a network provider may want to deploy over an A variety of services a network provider may want to deploy over an
LDP enabled network depend on the availability of edge to edge LDP-enabled network depend on the availability of edge-to-edge label
label switched paths. In a layer 2 (L2) or layer 3 (L3) VPN switched paths. In a layer 2 (L2) or layer 3 (L3) VPN scenario, for
scenario for example, a given Provider-Edge(PE) router relies on example, a given Provider-Edge (PE) router relies on the availability
the availability of a complete MPLS forwarding path to the other PE of a complete MPLS forwarding path to the other PE routers for the
routers for the VPNs it serves. This means that along the IP VPNs it serves. This means that all the links along the IP shortest
shortest path from one PE router to the other, all the links need path from one PE router to the other need to have operational LDP
to have operational LDP sessions and the necessary label binding sessions, and the necessary label binding must have been exchanged
must have been exchanged over those sessions. If only one link over those sessions. If only one link along the IP shortest path is
along the IP shortest path is not covered by an LDP session, a not covered by an LDP session, a blackhole exists and services
blackhole exists and services depending on MPLS forwarding will depending on MPLS forwarding will fail. This might be a transient or
fail. This might be a transient or a persistent error condition. a persistent error condition. Some of the reasons for this could be:
Some of the reasons for it could be
- A configuration error - A configuration error.
- An implementation bug - An implementation bug.
- The link has just come up and has an IGP adjacency but LDP has - The link has just come up and has an IGP adjacency but LDP has
either not yet established an adjacency or session or either not yet established an adjacency or session, or has not yet
distributed all the label bindings. distributed all the label bindings.
LDP protocol has currently no way to correct the issue, LDP is not The LDP protocol has currently no way to correct the issue. LDP is
a routing protocol; it cannot re-direct traffic to an alternate IGP not a routing protocol; it cannot re-direct traffic to an alternate
path. 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 2. Proposed Solution
The problem described above exists because LDP is tied to IP The problem described above exists because LDP is tied to
forwarding decisions but no coupling between the IGP and LDP IP-forwarding decisions but no coupling between the IGP and LDP
operational state on a given link exists. If IGP is operational on operational state on a given link exists. If IGP is operational on a
a link but LDP is not, a potential network problem exists. So the link but LDP is not, a potential network problem exists. So the
solution described by this document is to discourage a link from solution described by this document is to discourage a link from
being used for IP forwarding as long as LDP is not fully being used for IP forwarding as long as LDP is not fully operational.
operational.
LDP IGP Synchronization December 2008
This has some similarity to the mechanism specified in [RFC 3137] This has some similarity to the mechanism specified in [RFC3137],
which allows an OSPF router to advertise that it should not be used which allows an OSPF router to advertise that it should not be used
as a transit router. One difference is that [RFC 3137] raises the as a transit router. One difference is that [RFC 3137] raises the
link costs on all (stub) router links, while the mechanism link costs on all (stub) router links, while the mechanism described
described in here applies on a per-link basis. here applies on a per-link basis.
In detail: when LDP is not "fully operational" (see below) on a In detail: when LDP is not "fully operational" (see below) on a given
given link, the IGP will advertise the link with maximum cost to link, the IGP will advertise the link with maximum cost to avoid any
avoid any transit traffic over it if possible. In the case of transit traffic over it. In the case of OSPF, this cost is
OSPF, this cost is LSInfinity (16-bit value 0xFFFF) as proposed in LSInfinity (16-bit value 0xFFFF), as proposed in [RFC3137]. In the
[RFC 3137]. In the case of ISIS, the max metric value is 2^24-2 case of ISIS, the maximum metric value is 2^24-2 (0xFFFFFE). Indeed,
(0xFFFFFE). Indeed, if a link is configured with 2^24-1 (the if a link is configured with 2^24-1 (the maximum link metric per
maximum link metric per [RFC 5305]) then this link is not [RFC5305]), then this link is not advertised in the topology. It is
advertised in the topology. It is important to keep the link in the important to keep the link in the topology to allow IP traffic to use
topology to allow for IP traffic to use the link as a last resort the link as a last resort in case of massive failure.
in case of massive failure.
LDP is considered fully operational on a link when an LDP hello LDP is considered fully operational on a link when an LDP hello
adjacency exists on it, a suitable associated LDP session (matching adjacency exists on it, a suitable associated LDP session (matching
the LDP Identifier of the hello adjacency) is established to the the LDP Identifier of the hello adjacency) is established to the peer
peer at the other end of the link and all label bindings have been at the other end of the link, and all label bindings have been
exchanged over the session. At the present time, the latter exchanged over the session. At the present time, the latter
condition cannot generally be verified by a router and some condition cannot generally be verified by a router and some
estimated may have to be used. A simple implementation strategy is estimation may have to be used. A simple implementation strategy is
to use a configurable hold down timer to allow LDP session to use a configurable hold-down timer to allow LDP session
establishment before declaring LDP fully operational. The default establishment before declaring LDP fully operational. The default
timer is not defined in this document due to the concerns of the timer is not defined in this document due to concerns of the large
large variations of the Label Information Base (LIB) table size and variations of the Label Information Base (LIB) table size and
the equipment capabilities. In addition, this is a current work in equipment capabilities. In addition, there is a current work in
progress on LDP End-of-LIB as specified in [LDP End-of-LIB], it progress on LDP End-of-LIB as specified in [End-of-LIB], which
enables the LDP speaker to signal the completion of its initial enables the LDP speaker to signal the completion of its initial
advertisement following session establish. When LDP End-of-LIB is advertisement following session establishment. When LDP End-of-LIB
implemented, the configurable hold down timer is no longer needed. is implemented, the configurable hold-down timer is no longer needed.
The neighbor LDP session is considered fully operational when the The neighbor LDP session is considered fully operational when the
End-of-LIB notification message is received. End-of-LIB notification message is received.
This is typically sufficient to deal with the link when it is being This is typically sufficient to deal with the link when it is being
brought up. LDP protocol extensions to indicate the complete brought up. LDP protocol extensions to indicate the complete
transmission of all currently available label bindings after a transmission of all currently available label bindings after a
session has come up are conceivable but not addressed in this session has come up are conceivable, but not addressed in this
document. document.
The mechanism described in this document does not entail any The mechanism described in this document does not entail any protocol
protocol changes and is a local implementation issue. changes and is a local implementation issue.
The problem space and solution specified in this document have also The problem space and solution specified in this document have also
been discussed in an IEEE Communications Magazine paper [LDP been discussed in an IEEE Communications Magazine paper
Failure Recovery]. [LDP-Fail-Rec].
LDP IGP Synchronization December 2008
3. Applicability 3. Applicability
In general, the proposed procedure is applicable in networks where In general, the proposed procedure is applicable in networks where
the availability of LDP signaled MPLS LSPs and avoidance of the availability of LDP-signaled MPLS LSPs and avoidance of
blackholes for MPLS traffic is more important than always choosing blackholes for MPLS traffic are more important than always choosing
an optimal path for IP forwarded traffic. Note however that non- an optimal path for IP-forwarded traffic. Note however that non-
optimal IP forwarding only occurs for a short time after a link optimal IP forwarding only occurs for a short time after a link comes
comes up or when there is a genuine problem on a link. In the up or when there is a genuine problem on a link. In the latter case,
latter case an implementation should issue network management alerts an implementation should issue network management alerts to report
to report the error condition and enable the operator to address it. the error condition and enable the operator to address it.
Example network scenarios that benefit from the mechanism described Example network scenarios that benefit from the mechanism described
here are MPLS VPNs and BGP-free core network designs where traffic here are MPLS VPNs and BGP-free core network designs where traffic
can only be forwarded through the core when LDP forwarding state is can only be forwarded through the core when LDP forwarding state is
available throughout. available throughout.
The usefulness of this mechanism also depends on the availability The usefulness of this mechanism also depends on the availability of
of alternate paths with sufficient bandwidth in the network should alternate paths with sufficient bandwidth in the network should one
one link be assigned to the maximum cost due to unavailability of link be assigned to the maximum cost due to the unavailability of LDP
LDP service over it. service over it.
On broadcast links with more than one IGP/LDP peer, the cost-out 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 an 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 individual peer. So a policy decision has to be made whether the
unavailability of LDP service to one peer should result in the unavailability of LDP service to one peer should result in the
traffic being diverted away from all the peers on the link. traffic being diverted away from all the peers on the link.
4. Interaction with TE Tunnels 4. Interaction with TE Tunnels
In some networks, LDP is used in conjunction with RSVP-TE which sets In some networks, LDP is used in conjunction with RSVP-TE, which sets
up traffic-engineered tunnels. The path computation for the TE up traffic-engineered tunnels. The path computation for the TE
tunnels is based on the TE link cost which is flooded by the IGP in 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 addition to the regular IP link cost. The mechanism described in
this document should only be applied to the IP link cost to prevent this document should only be applied to the IP link cost to prevent
any unnecessary TE tunnel reroutes. unnecessary TE tunnel reroutes.
In order to establish LDP LSPs across a TE tunnel, a targeted LDP In order to establish LDP LSPs across a TE tunnel, a targeted LDP
session between the tunnel endpoints needs to exist. This presents session between the tunnel endpoints needs to exist. This presents a
a problem very similar to the case of a regular LDP session over a problem very similar to the case of a regular LDP session over a link
link (the case discussed so far): when the TE tunnel is used for IP (the case discussed so far): when the TE tunnel is used for IP
forwarding, the targeted LDP session needs to be operational to forwarding, the targeted LDP session needs to be operational to avoid
avoid LDP connectivity problems. Again, raising the IP cost of the LDP connectivity problems. Again, raising the IP cost of the tunnel
tunnel while there is no operational LDP session will solve the while there is no operational LDP session will solve the problem.
problem. When there is no IGP adjacency over the tunnel and the When there is no IGP adjacency over the tunnel and the tunnel is not
tunnel is not advertised as link into the IGP, this becomes a local advertised as a link into the IGP, this becomes a local issue of the
issue of the tunnel headend router. tunnel headend router.
LDP IGP Synchronization December 2008
5. Security Considerations 5. Security Considerations
A DoS attack that brings down LDP service on a link or prevents it A Denial-of-Service (DoS) attack that brings down LDP service on a
from becoming operational on a link could be one of the link or prevents it from becoming operational on a link could be one
possibilities that causes LDP related traffic blackholing. This possible cause of LDP-related traffic blackholing. This document
document does not address how to prevent LDP session failure. The does not address how to prevent LDP session failure. The mechanism
mechanism described here prevents the use of the link when LDP is described here prevents the use of the link where LDP is not
not operational while IGP is. Assigning the IGP cost to maximum on operational while IGP is. Assigning the IGP cost to maximum on such
the link where LDP is failed and IGP is not should not introduce a link should not introduce new security threats. The operation is
new security threats. The operation is internal in the router to internal to the router to allow LDP and IGP to communicate and react.
allow LDP and IGP to communicate and react. Making many LDP links Making many LDP links unavailable, however, is a security threat that
unavailable, however, is a security threat which can cause traffic can cause dropped traffic due to limited available network capacity.
being dropped due to limited available network capacity. This may This may be triggered by operational error or implementation error.
be triggered by operational error or implementation error. They are These errors are considered general security issues and implementors
considered as general Security issues and should follow the current should follow the current best security practice [MPLS-GMPLS-Sec].
best security practice [MPLS-GMPLS-Security].
6. IANA Considerations
This document has no actions for IANA. 6. References
7. Normative References 6.1. Normative References
[RFC 5036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
and B. Thomas, "LDP Specification", RFC 5036, October 2007. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April [RFC 2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April
1998. 1998.
8. Informational References [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas,
Ed., "LDP Specification", RFC 5036, October 2007.
[RFC 1918] Rekhter, Y., "Address Allocation for Private Internets", 6.2. Informative References
BCP: 5, RFC 1918, February 1996.
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate [End-of-LIB] Asati, R., LDP End-of-LIB, Work in Progress, January
[RFC 3137] Retana, A., Nguyen, L., White, R., Zinin, A., and D. 2009.
McPherson, "OSPF Stub Router Advertisement", RFC 3137, June 2001.
[RFC 5305] Li, T., Smit, H., Intermediate System to Intermediate [ISO.10589.1992] International Organization for Standardization,
System (IS-IS) Extension for Traffic Engineering, October 2008. "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 IGP Synchronization December 2008 [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.
[ISO.10589.1992]International Organization for [MPLS-GMPLS-Sec] Fang. L., Ed., "Security Framework for MPLS and
Standardization,"Intermediate system to intermediate system intra- GMPLS Networks", Work in Progress, November 2008.
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 Failure Recovery] Fang, L., Atlas, A., Chiussi, F., Kompella, [RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A., and D.
K., and Swallow, G., "LDP Failure Detection and Recovery", IEEE McPherson, "OSPF Stub Router Advertisement", RFC
Communications Magazine, Vol.42, No.10, October 2004. 3137, June 2001.
[LDP End-of-LIB] Asati, R., LDP End-of-LIB, draft-ietf-mpls-ldp- [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
end-of-lib-01.txt, work in progress, September 2008. Engineering", RFC 5305, October 2008.
[MPLS-GMPLS-Security] Fang. L., Ed., "Security Framework for MPLS 7. Acknowledgments
and GMPLS Networks", draft-ietf-mpls-mpls-and-gmpls-security-
framework-04.txt, work in progress, November 2008.
9. Authors' Addresses 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 Markus Jork
NextPoint Networks GENBAND
3 Fedral St. 3 Federal St.
Billerica, MA 01821 Billerica, MA 01821
USA USA
Email: mjork@nextpointnetworks.com
EMail: Markus.Jork@genband.com
Alia Atlas Alia Atlas
British Telecom British Telecom
Email: alia.atlas@bt.com
EMail: alia.atlas@bt.com
Luyuan Fang Luyuan Fang
Cisco Systems, Inc. Cisco Systems, Inc.
300 Beaver Brook Road 300 Beaver Brook Road
Boxborough, MA 01719 Boxborough, MA 01719
USA USA
Email: lufang@cisco.com
Phone: 1 (978) 936-1633
10. Acknowledgments EMail: lufang@cisco.com
Phone: 1 (978) 936-1633
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
The authors would like to thank Bruno Decraene for his in depth
discussion and comments; thank Dave Ward for his helpful review and
input; and thank Loa Andersson, Ross Callon, Amanda Baber, Francis
Dupont, Donald Eastlake, Russ Housley, Pasi Eronen, Dan Romascanu,
LDP IGP Synchronization December 2008
Bin Mo, Lan Zheng, Bob Thomas, and Dave Ojemann for their review
and comments.
 End of changes. 54 change blocks. 
210 lines changed or deleted 181 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/