< draft-ietf-mpls-ldp-igp-sync-01.txt   draft-ietf-mpls-ldp-igp-sync-02.txt >
Network Working Group M. Jork Network Working Group M. Jork
Internet Draft NextPoint Networks Internet Draft NextPoint Networks
Category: Informational Alia Atlas Category: Informational Alia Atlas
Expires: August 2008 British Telecom Expires: December 2008 British Telecom
L. Fang L. Fang
Cisco Systems, Inc. Cisco Systems, Inc.
February 2008 June 28, 2008
LDP IGP Synchronization LDP IGP Synchronization
draft-ietf-mpls-ldp-igp-sync-01.txt draft-ietf-mpls-ldp-igp-sync-02.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
skipping to change at line 46 skipping to change at page 1, line 47
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
In certain networks there is a dependency on edge-to-edge LSPs setup In certain networks there is a dependency on edge-to-edge LSPs setup
by LDP, e.g. networks that are used for MPLS VPN applications. For by LDP, e.g. networks that are used for MPLS VPN applications. For
such applications it is not possible to rely on IP forwarding if the such applications it is not possible to rely on IP forwarding if the
MPLS LSP is not operating appropriately. Blackholing of labeled MPLS LSP is not operating appropriately. Blackholing of labeled
M. Jork, A. Atlas, and L. Fang
1
LDP IGP Synchronization February 2008
traffic can occur in situations where the IGP is operational on a 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 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 still be used for IP forwarding, it is not useful for MPLS
packets carrying a label stack of more than one label or when the IP forwarding, for example, MPLS VPN; BGP route free core; or IP
address carried in the packet is out of the RFC1918 space. This address carried in the packet is out of the RFC1918 space. This
document describes a mechanism to avoid traffic loss due to this document describes a mechanism to avoid traffic loss due to this
condition without introducing any protocol changes. condition without introducing any protocol changes.
Table of Contents Table of Contents
1. Introduction..................................................2 1. Introduction..................................................2
2. Proposed Solution.............................................3 2. Proposed Solution.............................................3
3. Applicability.................................................4 3. Applicability.................................................4
4. Interaction With TE Tunnels...................................5 4. Interaction With TE Tunnels...................................5
skipping to change at line 93 skipping to change at page 2, line 43
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 IS-IS [ISO.10589.1992], i.e. all links in the domain have 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 switched paths. In a L2 or L3 VPN scenario for example, a label switched paths. In a L2 or L3 VPN scenario for example, a
given PE router relies on the availability of a complete MPLS given PE router relies on the availability of a complete MPLS
forwarding path to the other PE routers for the VPNs it serves. forwarding path to the other PE routers for the VPNs it serves.
M. Jork, Alia Atlas, and L. Fang 2
LDP IGP Synchronization February 2008
This means that along the IP shortest path from one PE router to 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 other, all the links need to have operational LDP sessions and
the necessary label binding must have been exchanged over those the necessary label binding must have been exchanged over those
sessions. If only one link along the IP shortest path is not sessions. If only one link along the IP shortest path is not
covered by an LDP session, a blackhole exists and services covered by an LDP session, a blackhole exists and services
depending on MPLS forwarding will fail. This might be a transient depending on MPLS forwarding will fail. This might be a transient
or a persistent error condition. Some of the reasons for it could or a persistent error condition. Some of the reasons for it could
be 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
distributed all the label bindings. distributed all the label bindings.
The LDP protocol itself has currently no means to indicate to a LDP protocol has currently no way to correct the issue, LDP is not
service depending on it whether there is an uninterrupted label a routing protocol; it can not re-direct traffic to an alternate
switched path available to the desired destination or not. IGP path.
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 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 a 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.
This has some similarity to the mechanism specified in [RFC3137] 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 [RFC3137] raises the as a transit router. One difference is that [RFC3137] raises the
link costs on all (stub) router links, while the mechanism link costs on all (stub) router links, while the mechanism
described in here applies on a per-link basis. described in 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 link, the IGP will advertise the link with maximum cost to given link, the IGP will advertise the link with maximum cost to
avoid any transit traffic over it if possible. In the case of OSPF avoid any transit traffic over it if possible. In the case of
this cost is LSInfinity (16-bit value 0xFFFF) as proposed in OSPF, this cost is LSInfinity (16-bit value 0xFFFF) as proposed in
[RFC3137]. Note that the link is not just simply removed from the [RFC3137]. In the case of ISIS, the max matrix value is 0xFFFFFE
topology because LDP depends on the IP reachability to establish per [RFC 3784]. Note that the link is not just simply removed from
its adjacency and session. Also, if there is no other link in the the topology because LDP depends on the IP reachability to
network to reach a particular destination, no additional harm is establish its adjacency and session. Also, if there is no other
done by making this link available for IP forwarding at maximum link in the network to reach a particular destination, no
cost. 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 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 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. At the present time, the latter
be verified by a router and some heuristics may have to be used. A condition can not generally be verified by a router and some
simple implementation strategy is to wait some time after LDP estimated may have to be used. A simple implementation strategy is
session establishment before declaring LDP fully operational in to use a configurable hold down timer to allow LDP session
order to allow for the exchange of label bindings. This is establishment before declaring LDP fully operational. The default
typically sufficient to deal with the link when it is being brought timer is not defined in this document due to the concerns of the
up. LDP protocol extensions to indicate the complete transmission of large variations of the LIB table size and the equipment
all currently available label bindings after a session has come up capabilities. In addition, this is a current work in progress on LDP
are conceivable but not addressed in this document. End-of-LIB as specified in [LDP End-of-LIB], it enables the LDP
speaker to signal the completion of its initial advertisement
following session establish. 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 The mechanism described in this document does not entail any
protocol changes and is a local implementation issue. However, it protocol changes and is a local implementation issue.
is recommended that both sides of a link implement this mechanism
to be effective and to avoid asymmetric link costs which could
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 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 is 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-
skipping to change at line 195 skipping to change at page 5, line 8
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 alternate paths with sufficient bandwidth in the network should of alternate paths with sufficient bandwidth in the network should
one link be assigned to the maximum cost due to unavailability of one link be assigned to the maximum cost due to unavailability of
LDP service over it. 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
skipping to change at line 240 skipping to change at page 6, line 4
LDP is failed and IGP is not should not introduce new security LDP is failed and IGP is not should not introduce new security
threats. The operation is internal in the router to allow LDP and threats. The operation is internal in the router to allow LDP and
IGP to communicate and react. Making many LDP links unavailable, IGP to communicate and react. Making many LDP links unavailable,
however, is a security threat which can cause traffic being dropped however, is a security threat which can cause traffic being dropped
due to limited available network capacity. This may be trigged by due to limited available network capacity. This may be trigged by
operational error or implementation error. They are considered as operational error or implementation error. They are considered as
general Security issues and should follow the current best security general Security issues and should follow the current best security
practice. practice.
6. IANA Considerations 6. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
M. Jork, Alia Atlas, and L. Fang 5
LDP IGP Synchronization February 2008
7. Normative References 7. Normative References
[RFC5036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., [RFC5036] Andersson, L., Doolan, P., Feldman, N., Fredette, A.,
and B. Thomas, "LDP Specification", RFC 5036, October 2007. 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 8. Informational References
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997 Requirement Levels", BCP 14, RFC 2119, March 1997
[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, June 2001. McPherson, "OSPF Stub Router Advertisement", RFC 3137, June 2001.
[RFC 3784] Smit, H., Li, T., Intermediate System to Intermediate
System (IS-IS) Extension for Traffic Engineering, June 2004.
[ISO.10589.1992]International Organization for [ISO.10589.1992]International Organization for
Standardization,"Intermediate system to intermediate system intra- Standardization,"Intermediate system to intermediate system intra-
domain-routing routine information exchange protocol for use in domain-routing routine information exchange protocol for use in
conjunction with the protocol for providing the connectionless-mode conjunction with the protocol for providing the connectionless-mode
Network Service (ISO 8473)", ISO Standard 10589, 1992. Network Service (ISO 8473)", ISO Standard 10589, 1992.
[LDP-Fail] Fang, L., Atlas, A., Chiussi, F., Kompella, K., and [LDP-Fail] Fang, L., Atlas, A., Chiussi, F., Kompella, K., and
Swallow, G., "LDP Failure Detection and Recovery", IEEE Swallow, G., "LDP Failure Detection and Recovery", IEEE
Communications Magazine, Vol.42, No.10, October 2004. Communications Magazine, Vol.42, No.10, October 2004.
[LDP End-of-LIB] Asati, R., LDP End-of-LIB, draft-asati-mpls-ldp-
end-of-lib-01.txt, November 2007.
9. Author's Addresses 9. Author's Addresses
Markus Jork Markus Jork
NextPoint Networks NextPoint Networks
3 Fedral St. 3 Fedral St.
Billerica, MA 01821 Billerica, MA 01821
USA USA
Email: mjork@nextpointnetworks.com Email: mjork@nextpointnetworks.com
Alia Atlas Alia Atlas
skipping to change at line 283 skipping to change at page 7, line 4
Markus Jork Markus Jork
NextPoint Networks NextPoint Networks
3 Fedral St. 3 Fedral St.
Billerica, MA 01821 Billerica, MA 01821
USA USA
Email: mjork@nextpointnetworks.com Email: mjork@nextpointnetworks.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 Email: lufang@cisco.com
Intellectual Property 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 The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights. it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79. 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
skipping to change at line 342 skipping to change at page 8, line 14
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE. 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 Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that rights might or might not be available; nor does it represent that
M. Jork, Alia Atlas, and L. Fang 7
LDP IGP Synchronization February 2008
it has made any independent effort to identify any such rights. it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79. 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 attempt made to obtain a general license or permission for the use
of 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 specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr. at http://www.ietf.org/ipr.
skipping to change at line 369 skipping to change at page 8, line 37
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 ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
10. Acknowledgements 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 The authors would like to thank Loa Andersson for his review and
comments. comments, and thank Bruno Decraene for his in depth discussion,
comments and helpful suggestions.
M. Jork, Alia Atlas, and L. Fang 8
 End of changes. 22 change blocks. 
60 lines changed or deleted 47 lines changed or added

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