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 | |||
[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 281 | 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 340 | 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 367 | 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. 19 change blocks. | ||||
57 lines changed or deleted | 44 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/ |