draft-ietf-mpls-ldp-igp-sync-00.txt   draft-ietf-mpls-ldp-igp-sync-01.txt 
Network Working Group M. Jork Network Working Group M. Jork
Internet-Draft Reef Point Internet Draft NextPoint Networks
Expires: March 9, 2008 A. Atlas Category: Informational Alia Atlas
Google Expires: August 2008 British Telecom
L. Fang L. Fang
Cisco Systems, Inc. Cisco Systems, Inc.
September 6, 2007
February 2008
LDP IGP Synchronization LDP IGP Synchronization
draft-ietf-mpls-igp-sync-00 draft-ietf-mpls-ldp-igp-sync-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six
and may be updated, replaced, or obsoleted by other documents at any months and may be updated, replaced, or obsoleted by other
time. It is inappropriate to use Internet-Drafts as reference documents at any time. It is inappropriate to use Internet-Drafts
material or to cite them other than as "work in progress." as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 9, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008).
Copyright (C) The IETF Trust (2007).
Abstract Abstract
In networks depending on edge-to-edge establishment of MPLS In certain networks there is a dependency on edge-to-edge LSPs setup
forwarding paths via LDP, blackholing of traffic can occur in by LDP, e.g. networks that are used for MPLS VPN applications. For
situations where the IGP is operational on a link and thus the link such applications it is not possible to rely on IP forwarding if the
is used for IP forwarding but LDP is not operational on that link for MPLS LSP is not operating appropriately. Blackholing of labeled
whatever reason. This document describes a mechanism to avoid
traffic loss due to this condition without introducing any protocol M. Jork, A. Atlas, and L. Fang
changes. 1
LDP IGP Synchronization February 2008
traffic can occur in situations where the IGP is operational on a
link but LDP is not operational on that link. While the link could
still be used for IP forwarding, it is not useful for traffic with
packets carrying a label stack of more than one label or when the IP
address carried in the packet is out of the RFC1918 space. This
document describes a mechanism to avoid traffic loss due to this
condition without introducing any protocol changes.
Table of Contents
1. Introduction..................................................2
2. Proposed Solution.............................................3
3. Applicability.................................................4
4. Interaction With TE Tunnels...................................5
5. Security Considerations.......................................5
6. IANA Considerations...........................................5
7. Normative References..........................................6
8. Informational References......................................6
9. Author's Addresses............................................6
10. Acknowledgements............................................8
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].
1. Introduction 1. Introduction
LDP [RFC3036] establishes MPLS LSPs along the shortest path to a LDP [RFC5036] 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 OSPF [RFC2328] or complete network domain covered by an IGP such as OSPF [RFC2328] or
IS-IS [ISO.10589.1992], i.e. all links in the domain have IGP as well IS-IS [ISO.10589.1992], i.e. all links in the domain have IGP as
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 label LDP enabled network depend on the availability of edge to edge
switched paths. In a L2 or L3 VPN scenario for example, a given PE label switched paths. In a L2 or L3 VPN scenario for example, a
router relies on the availability of a complete MPLS forwarding path given PE router relies on the availability of a complete MPLS
to the other PE routers for the VPNs it serves. This means that forwarding path to the other PE routers for the VPNs it serves.
along the IP shortest path from one PE router to the other, all the
links 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 it could be
o a configuration error, M. Jork, Alia Atlas, and L. Fang 2
LDP IGP Synchronization February 2008
o an implementation bug, This means that along the IP shortest path from one PE router to
the other, all the links 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 it could
be
o the link has just come up and has an IGP adjacency but LDP has - A configuration error
either not yet established an adjacency or session or distributed
all the label bindings. - 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
distributed all the label bindings.
The LDP protocol itself has currently no means to indicate to a The LDP protocol itself has currently no means to indicate to a
service depending on it whether there is an uninterrupted label service depending on it whether there is an uninterrupted label
switched path available to the desired destination or not. switched path available to the desired destination or not.
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 IP
forwarding decisions but no coupling between the IGP and LDP forwarding decisions but no coupling between the IGP and LDP
operational state on a given link exists. If IGP is operational on a operational state on a given link exists. If IGP is operational on
link but LDP is not, a potential network problem exists. So the a link but LDP is not, a potential network problem exists. So the
solution described by this document is to prevent a link from being solution described by this document is to discourage a link from
used for IP forwarding as long as LDP is not fully operational. This being used for IP forwarding as long as LDP is not fully
has some similarity to the mechanism specified in [RFC3137] which operational.
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 in
here applies on a per-link basis.
In detail: when LDP is not "fully operational" (see below) on a given This has some similarity to the mechanism specified in [RFC3137]
link, the IGP will advertise the link with maximum cost to avoid any which allows an OSPF router to advertise that it should not be used
transit traffic over it if possible. In the case of OSPF this cost as a transit router. One difference is that [RFC3137] raises the
is LSInfinity (16-bit value 0xFFFF) as proposed in [RFC3137]. Note link costs on all (stub) router links, while the mechanism
that the link is not just simply removed from the topology because described in here applies on a per-link basis.
LDP depends on the IP reachability to establish its adjacency and
session. Also, if there is no other link in the network to reach a In detail: when LDP is not "fully operational" (see below) on a
particular destination, no additional harm is done by making this given link, the IGP will advertise the link with maximum cost to
link available for IP forwarding at maximum cost. avoid any transit traffic over it if possible. In the case of OSPF
this cost is LSInfinity (16-bit value 0xFFFF) as proposed in
[RFC3137]. Note that the link is not just simply removed from the
topology because LDP depends on the IP reachability to establish
its adjacency and session. Also, if there is no other link in the
network to reach a particular destination, no additional harm is
done by making this link available for IP forwarding at maximum
cost.
M. Jork, Alia Atlas, and L. Fang 3
LDP IGP Synchronization February 2008
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 peer the LDP Identifier of the hello adjacency) is established to the
at the other end of the link and all label bindings have been peer at the other end of the link and all label bindings have been
exchanged over the session. The latter condition can not generally exchanged over the session. The latter condition can not generally
be verified by a router and some heuristics may have to be used. A be verified by a router and some heuristics may have to be used. A
simple implementation strategy is to wait some time after LDP session simple implementation strategy is to wait some time after LDP
establishment before declaring LDP fully operational in order to session establishment before declaring LDP fully operational in
allow for the exchange of label bindings. This is typically order to allow for the exchange of label bindings. This is
sufficient to deal with the link when it is being brought up. LDP typically sufficient to deal with the link when it is being brought
protocol extensions to indicate the complete transmission of all up. LDP protocol extensions to indicate the complete transmission of
currently available label bindings after a session has come up are all currently available label bindings after a session has come up
conceivable but not addressed in this document. are conceivable but not addressed in this document.
The mechanism described in this document does not entail any protocol The mechanism described in this document does not entail any
changes and is a local implementation issue. However, it is protocol changes and is a local implementation issue. However, it
recommended that both sides of a link implement this mechanism to be is recommended that both sides of a link implement this mechanism
effective and to avoid asymmetric link costs which could cause to be effective and to avoid asymmetric link costs which could
problems with IP multicast forwarding. cause problems with IP multicast forwarding.
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-Fail]. been discussed in an IEEE Communications Magazine paper [LDP-Fail].
3. Applicability 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 is 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 Example network scenarios that benefit from the mechanism described
in 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.
In general, the proposed procedure is applicable in networks where The usefulness of this mechanism also depends on the availability
the availability of LDP signaled MPLS LSPs and avoidance of of alternate paths with sufficient bandwidth in the network should
blackholes for MPLS traffic is more important than always choosing an one link be assigned to the maximum cost due to unavailability of
optimal path for IP forwarded traffic. Note however that non-optimal LDP service over it.
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.
The usefulness of this mechanism also depends on the availability of
alternate paths with sufficient bandwidth in the network should one
link get costed out due to unavailability of LDP 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 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
M. Jork, Alia Atlas, and L. Fang 4
LDP IGP Synchronization February 2008
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 which 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. any 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 a session between the tunnel endpoints needs to exist. This presents
problem very similar to the case of a regular LDP session over a link a problem very similar to the case of a regular LDP session over a
(the case discussed so far): when the TE tunnel is used for IP 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 forwarding, the targeted LDP session needs to be operational to
LDP connectivity problems. Again, raising the IP cost of the tunnel avoid LDP connectivity problems. Again, raising the IP cost of the
while there is no operational LDP session will solve the problem. tunnel while there is no operational LDP session will solve the
When there is no IGP adjacency over the tunnel and the tunnel is not problem. When there is no IGP adjacency over the tunnel and the
advertised as link into the IGP, this becomes a local issue of the tunnel is not advertised as link into the IGP, this becomes a local
tunnel headend router. issue of the tunnel headend router.
5. Security Considerations 5. Security Considerations
A DoS attack that brings down LDP service on a link or prevents it A DoS attack brings down LDP service on a link or prevents it from
from becoming operational on a link will now additionally cause non- becoming operational on a link could be one of the possibilities
optimal IP forwarding within the network. However, as discussed that causes LDP related traffic blackholing. This document does not
above this is considered beneficial as it prevents MPLS traffic from address how to prevent LDP session failure. The mechanism described
being dropped. here is to prevent the link to be used when LDP is not operational
while IGP is. Assigning the IGP cost to maximum on the link where
LDP is failed and IGP is not should not introduce new security
threats. The operation is internal in the router to allow LDP and
IGP to communicate and react. Making many LDP links unavailable,
however, is a security threat which can cause traffic being dropped
due to limited available network capacity. This may be trigged by
operational error or implementation error. They are considered as
general Security issues and should follow the current best security
practice.
6. IANA Considerations 6. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
7. References M. Jork, Alia Atlas, and L. Fang 5
LDP IGP Synchronization February 2008
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and 7. Normative References
B. Thomas, "LDP Specification", RFC 3036, January 2001.
[RFC5036] Andersson, L., Doolan, P., Feldman, N., Fredette, A.,
and B. Thomas, "LDP Specification", RFC 5036, October 2007.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
8. Informational References
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
[RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A., and D. [RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A., and D.
McPherson, "OSPF Stub Router Advertisement", RFC 3137, McPherson, "OSPF Stub Router Advertisement", RFC 3137, June 2001.
June 2001.
[ISO.10589.1992] [ISO.10589.1992]International Organization for
International Organization for Standardization, Standardization,"Intermediate system to intermediate system intra-
"Intermediate system to intermediate system intra-domain- domain-routing routine information exchange protocol for use in
routing routine information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode
conjunction with the protocol for providing the Network Service (ISO 8473)", ISO Standard 10589, 1992.
connectionless-mode Network Service (ISO 8473)",
ISO Standard 10589, 1992.
[LDP-Fail] [LDP-Fail] Fang, L., Atlas, A., Chiussi, F., Kompella, K., and
Fang, L., Atlas, A., Chiussi, F., Kompella, K., and G. Swallow, G., "LDP Failure Detection and Recovery", IEEE
Swallow, "LDP Failure Detection and Recovery", IEEE Communications Magazine, Vol.42, No.10, October 2004.
Communications Vol.42 No.10, October 2004.
Authors' Addresses 9. Author's Addresses
Markus Jork Markus Jork
Reef Point Systems NextPoint Networks
8 New England Executive Park 3 Fedral St.
Burlington, MA 01803 Billerica, MA 01821
US USA
Email: mjork@nextpointnetworks.com
Phone: +1 781 359 5071
Email: mjork@reefpoint.com
Alia Atlas Alia Atlas
Google, Inc. British Telecom
One Broadway, 7th Floor Email: alia.atlas@bt.com
Cambridge, MA 02142
US
Email: akatlas@google.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
US USA
Email: lufang@cisco.com Email: lufang@cisco.com
Intellectual Property
M. Jork, Alia Atlas, and L. Fang 6
LDP IGP Synchronization February 2008
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed
pertain to the implementation or use of the technology described in to pertain to the implementation or use of the technology described
this document or the extent to which any license under such rights in this document or the extent to which any license under such
might or might not be available; nor does it represent that it has rights might or might not be available; nor does it represent that
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be M. Jork, Alia Atlas, and L. Fang 7
found in BCP 78 and BCP 79. LDP IGP Synchronization February 2008
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use
such proprietary rights by implementers or users of this of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository
http://www.ietf.org/ipr. at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at ietf-
ietf-ipr@ietf.org. ipr@ietf.org.
Acknowledgment 10. Acknowledgements
Funding for the RFC Editor function is provided by the IETF Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA). Administrative Support Activity (IASA).
The authors would like to thank Loa Andersson for his review and
comments.
M. Jork, Alia Atlas, and L. Fang 8
 End of changes. 43 change blocks. 
154 lines changed or deleted 233 lines changed or added

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