draft-ietf-mpls-ldp-igp-sync-02.txt | draft-ietf-mpls-ldp-igp-sync-03.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: December 2008 British Telecom | Expires: May 2008 British Telecom | |||
L. Fang | L. Fang | |||
Cisco Systems, Inc. | Cisco Systems, Inc. | |||
June 28, 2008 | November 3, 2008 | |||
LDP IGP Synchronization | LDP IGP Synchronization | |||
draft-ietf-mpls-ldp-igp-sync-02.txt | draft-ietf-mpls-ldp-igp-sync-03.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 page 2, line 4 | skipping to change at page 2, line 4 | |||
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 | |||
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 MPLS | still be used for IP forwarding, it is not useful for MPLS | |||
LDP IGP Synchronization November 2008 | ||||
forwarding, for example, MPLS VPN; BGP route free core; or 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 | |||
5. Security Considerations.......................................5 | 5. Security Considerations.......................................5 | |||
6. IANA Considerations...........................................5 | 6. IANA Considerations...........................................5 | |||
7. Normative References..........................................6 | 7. Normative References..........................................6 | |||
8. Informational References......................................6 | 8. Informational References......................................6 | |||
9. Author's Addresses............................................6 | 9. Author's Addresses............................................6 | |||
10. Acknowledgements............................................8 | 10. Acknowledgements.............................................8 | |||
Conventions used in this document | Conventions used in this document | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in | |||
this document are to be interpreted as described in RFC2119 [RFC | this document are to be interpreted as described in RFC2119 [RFC | |||
2119]. | 2119]. | |||
1. Introduction | 1. Introduction | |||
LDP [RFC5036] 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 | IS-IS [ISO.10589.1992], i.e. all links in the domain MAY have IGP | |||
well as LDP adjacencies. | as 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. | |||
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 | |||
LDP IGP Synchronization November 2008 | ||||
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. | |||
skipping to change at page 3, line 39 | skipping to change at page 3, line 41 | |||
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 | avoid any transit traffic over it if possible. In the case of | |||
OSPF, this cost is LSInfinity (16-bit value 0xFFFF) as proposed in | OSPF, this cost is LSInfinity (16-bit value 0xFFFF) as proposed in | |||
[RFC3137]. In the case of ISIS, the max matrix value is 0xFFFFFE | [RFC3137]. In the case of ISIS, the max metric value is 2^24-2 | |||
per [RFC 3784]. Note that the link is not just simply removed from | (0xFFFFFE). Indeed, if a link is configured with 2^24-1 (the | |||
the topology because LDP depends on the IP reachability to | maximum link metric per [RFC3784]) then this link is not advertised | |||
establish its adjacency and session. Also, if there is no other | in the topology. It is important to keep the link in the topology | |||
link in the network to reach a particular destination, no | to allow for IP traffic to use the link as a last resort in case of | |||
additional harm is done by making this link available for IP | massive failure. | |||
forwarding at maximum cost. | ||||
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. At the present time, the latter | exchanged over the session. At the present time, the latter | |||
LDP IGP Synchronization November 2008 | ||||
condition can not generally be verified by a router and some | condition can not generally be verified by a router and some | |||
estimated may have to be used. A simple implementation strategy is | estimated 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 the concerns of the | |||
large variations of the LIB table size and the equipment | large variations of the LIB table size and the equipment | |||
capabilities. In addition, this is a current work in progress on LDP | capabilities. In addition, this is a current work in progress on LDP | |||
End-of-LIB as specified in [LDP End-of-LIB], it enables the LDP | End-of-LIB as specified in [LDP End-of-LIB], it enables the LDP | |||
speaker to signal the completion of its initial advertisement | speaker to signal the completion of its initial advertisement | |||
following session establish. When LDP End-of-LIB is implemented, the | following session establish. When LDP End-of-LIB is implemented, the | |||
skipping to change at page 5, line 5 | skipping to change at page 5, line 5 | |||
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 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. | |||
LDP IGP Synchronization November 2008 | ||||
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 | |||
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 | |||
skipping to change at page 6, line 4 | 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 | |||
LDP IGP Synchronization November 2008 | ||||
This document has no actions for IANA. | This document has no actions for IANA. | |||
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 | |||
skipping to change at page 6, line 32 | skipping to change at page 6, line 34 | |||
[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- | [LDP End-of-LIB] Asati, R., LDP End-of-LIB, draft-ietf-mpls-ldp- | |||
end-of-lib-01.txt, November 2007. | end-of-lib-01.txt, September 2008. | |||
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 | |||
British Telecom | British Telecom | |||
Email: alia.atlas@bt.com | Email: alia.atlas@bt.com | |||
LDP IGP Synchronization November 2008 | ||||
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 | ||||
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 (2008). | 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 | This document and the information contained herein are provided on | |||
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE | an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE | |||
skipping to change at page 8, line 31 | skipping to change at page 8, line 5 | |||
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. | |||
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 ietf- | this standard. Please address the information to the IETF at ietf- | |||
ipr@ietf.org. | ipr@ietf.org. | |||
LDP IGP Synchronization November 2008 | ||||
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, and thank Bruno Decraene for his in depth discussion, | comments, thank Bruno Decraene for his in depth discussion, | |||
comments and helpful suggestions. | comments and helpful suggestions, and thank Dave Ward for his AD | |||
review comments and suggestions. | ||||
End of changes. 16 change blocks. | ||||
39 lines changed or deleted | 28 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/ |