Network Working Group M. Jork
Internet-Draft Quarry
Expires: August 22, 2005 A. Atlas
Avici
L. Fang
AT&T
February 18, 2005
LDP IGP Synchronization
draft-jork-ldp-igp-sync-01
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any 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 become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 22, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
In networks depending on edge-to-edge establishment of MPLS
forwarding paths via LDP, blackholing of traffic can occur in
situations where the IGP is operational on a link and thus the link
Jork, et al. Expires August 22, 2005 [Page 1]
Internet-Draft LDP IGP Synchronization February 2005
is used for IP forwarding but LDP is not operational on that link for
whatever reason. This document describes a mechanism to avoid
traffic loss due to this condition without introducing any protocol
changes.
Jork, et al. Expires August 22, 2005 [Page 2]
Internet-Draft LDP IGP Synchronization February 2005
1. Introduction
LDP [RFC3036] establishes MPLS LSPs along the shortest path to a
destination as determined by IP forwarding. In a common network
design, LDP is used to provide label switched paths throughout the
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 as LDP adjacencies.
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
switched paths. In a L2 or L3 VPN scenario for example, a given PE
router relies on the availability of a complete MPLS 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 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,
o an implementation bug,
o 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
service depending on it whether there is an uninterrupted label
switched path available to the desired destination or not.
Jork, et al. Expires August 22, 2005 [Page 3]
Internet-Draft LDP IGP Synchronization February 2005
2. Proposed Solution
The problem described above exists because LDP is tied to IP
forwarding decisions but no coupling between the IGP and LDP
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
solution described by this document is to prevent a link from being
used for IP forwarding as long as LDP is not fully operational. This
has some similarity to the mechanism specified in [RFC3137] which
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
link, the IGP will advertise the link with maximum cost to 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.
LDP is considered fully operational on a link when an LDP hello
adjacency exists on it, a suitable associated LDP session (matching
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
exchanged over the session. The latter condition can not generally
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
establishment before declaring LDP fully operational in order to
allow for the exchange of label bindings. 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 protocol
changes and is a local implementation issue. However, it 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
been discussed in an IEEE Communications Magazine paper [LDP-Fail].
Jork, et al. Expires August 22, 2005 [Page 4]
Internet-Draft LDP IGP Synchronization February 2005
3. Applicability
Example network scenarios that benefit from the mechanism described
in here are MPLS VPNs and BGP-free core network designs where traffic
can only be forwarded through the core when LDP forwarding state is
available throughout.
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.
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
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
unavailability of LDP service to one peer should result in the
traffic being diverted away from all the peers on the link.
Jork, et al. Expires August 22, 2005 [Page 5]
Internet-Draft LDP IGP Synchronization February 2005
4. Interaction With TE Tunnels
In some networks, LDP is used in conjunction with RSVP-TE which sets
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
addition to the regular IP link cost. The mechanism described in
this document should only be applied to the IP link cost to prevent
any unnecessary TE tunnel reroutes.
In order to establish LDP LSPs across a TE tunnel, a targeted LDP
session between the tunnel endpoints needs to exist. This presents a
problem very similar to the case of a regular LDP session over a 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
LDP connectivity problems. Again, raising the IP cost of the tunnel
while there is no operational LDP session will solve the problem.
When there is no IGP adjacency over the tunnel and the tunnel is not
advertised as link into the IGP, this becomes a local issue of the
tunnel headend router.
Jork, et al. Expires August 22, 2005 [Page 6]
Internet-Draft LDP IGP Synchronization February 2005
5. Security Considerations
A DoS attack that brings down LDP service on a link or prevents it
from becoming operational on a link will now additionally cause
non-optimal IP forwarding within the network. However, as discussed
above this is considered beneficial as it prevents MPLS traffic from
being dropped.
Jork, et al. Expires August 22, 2005 [Page 7]
Internet-Draft LDP IGP Synchronization February 2005
6. IANA Considerations
This document has no actions for IANA.
7. References
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and
B. Thomas, "LDP Specification", RFC 3036, January 2001.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A. and D.
McPherson, "OSPF Stub Router Advertisement", RFC 3137,
June 2001.
[ISO.10589.1992]
International Organization for Standardization,
"Intermediate system to intermediate system
intra-domain-routing routine information exchange protocol
for use in conjunction with the protocol for providing the
connectionless-mode Network Service (ISO 8473)",
ISO Standard 10589, 1992.
[LDP-Fail]
Fang, L., Atlas, A., Chiussi, F., Kompella, K. and G.
Swallow, "LDP Failure Detection and Recovery", IEEE
Communications Vol.42 No.10, October 2004.
Authors' Addresses
Markus Jork
Quarry Technologies
8 New England Executive Park
Burlington, MA 01803
US
Phone: +1 781 359 5071
Email: mjork@quarrytech.com
Jork, et al. Expires August 22, 2005 [Page 8]
Internet-Draft LDP IGP Synchronization February 2005
Alia Atlas
Avici Systems, Inc.
101 Billerica Ave
North Billerica, MA 01862
US
Phone: +1 978 964 2070
Email: aatlas@avici.com
Luyuan Fang
AT&T
Room C2-3B35
200 Laurel Avenue
Middletown, NJ 07748
US
Phone: +1 732 420 1921
Email: luyuanfang@att.com
Jork, et al. Expires August 22, 2005 [Page 9]
Internet-Draft LDP IGP Synchronization February 2005
Intellectual Property Statement
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.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Jork, et al. Expires August 22, 2005 [Page 10]