Network Working Group Danny McPherson
INTERNET DRAFT Amber Networks, Inc.
December 2000
IS-IS Transient Blackhole Avoidance
<draft-mcpherson-isis-transient-00.txt>
1. Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
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.
2. Abstract
This document describes a simple, interoperable mechanism that can be
employed in IS-IS networks in order to decrease data loss associated
with deterministic blackholing of packets during transient network
conditions. The mechanism proposed here requires no IS-IS protocol
changes and is completely interoperable with the existing IS-IS
specification.
McPherson, D. [Page 1]
INTERNET DRAFT December 2000
3. Specification of Requirements
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 [RFC 2119].
4. Introduction
When an IS-IS router that was previously a transit router becomes
unavailable as a result of some transient condition such as a reboot,
other routers within the routing domain must select an alternative
path to reach destinations which had previously transited the failed
router. Presumably, the newly selected router(s) comprising the path
have been available for some time and, as a result, have complete
forwarding information bases (FIBs) which contain a full set of
reachability information for both internal and external (e.g. BGP)
destination networks.
When the previously failed router becomes available again, in only a
few seconds paths that had previously transited the router are again
selected as the optimal path by the IGP. As a result, forwarding
tables are updated and packets are once again forwarded along the
path. Unfortunately, external destination reachability information
(e.g. learned via BGP) is not yet available to the router, and as a
result, packets bound for destinations not learned via the IGP are
unnecessarily discarded.
A mechanism to alleviate the offshoot associated with this
deterministic behavior is discussed below.
5. Discussion
This document describes a simple, interoperable mechanism that can be
employed in IS-IS [1] and [2] networks in order to avoid transition
to a newly available path until other associated routing protocols
such as BGP have had sufficient time to converge.
The benefits of such a mechanism can realized when considering the
following scenario.
McPherson, D. [Page 2]
INTERNET DRAFT December 2000
D.1
|
+-------+
| RtrD |
+-------+
/ \
/ \
+-------+ +-------+
| RtrB | | RtrC |
+-------+ +-------+
\ /
\ /
+-------+
| RtrA |
+-------+
|
S.1
Host S.1 is transmitting data to destination D.1 via a primary path
of RtrA->RtrB->RtrD. Routers A, B and C learn of reachability to
destination D.1 via BGP from RtrD. RtrA's primary path to D.1 is
selected because when calculating the path to BGP NEXT_HOP of RtrD
the sum of the IS-IS link metrics on the RtrA-RtrB-RtrD path is less
than the sum of the metrics of the RtrA-RtrC-RtrD path.
Assume RtrB becomes unavailable and as a result the RtrC path to RtrD
is used. Once RtrA's FIB is updated and it begins forwarding packets
to RtrC everything should behave properly as RtrC has existing
forwarding information regarding destination D.1's availability via
BGP NEXT_HOP RtrD.
Assume now that RtrB comes back online. In only a few seconds IS-IS
neighbor state has been established with RtrA and RtrD and database
synchronization has occurred. RtrA now realizes that the best path
to destination D.1 is via RtrB, and therefore updates it FIB
appropriately. RtrA begins to forward packets destined to D.1 to
RtrB. Though, because RtrB has yet to establish and synchronization
it's BGP neighbor relationship and routing information with RtrD,
RtrB has no knowledge regarding reachability of destination D.1, and
therefore discards the packets received from RtrA destined to D.1.
If RtrB were to temporarily set it's LSP Overload bit while
synchronizing BGP tables with it's neighbors, RtrA would continue to
use the working RtrA->RtrC->RtrD path, and the LSP should only be
used to obtain reachability to locally connected networks (rather
than for calculating transit paths through the router, as defined in
[1]).
McPherson, D. [Page 3]
INTERNET DRAFT December 2000
After initial synchronization of BGP tables with neighboring routers,
RtrB would generate a new LSP, clearing the Overload bit, and RtrA
could again begin using the optimal path via RtrB.
Typically, in service provider networks IBGP connections are done via
peerings with 'loopback' addresses. As such, the newly available
router must advertise it's own loopback, as well as associated
adjacencies, in order to make the loopbacks accessible to other
routers within the routing domain. It's because of this that simply
flooding an empty LSP is not sufficient.
6. Deployment Considerations
Such a mechanism increases overall network availability and allows
network operators to alleviate the deterministic blackholing behavior
introduced in this scenario. Similar mechanisms [3] have been
defined for OSPF, though only after realizing similar usefulness
obtained from that of the IS-IS Overload bit.
This mechanism has been deployed in several large IS-IS networks for
several of years.
Triggers for setting the Overload bit as described are left to the
implementor. Some potential triggers could perhaps include "N
seconds after booting", or "N number of BGP prefixes in the BGP Loc-
RIB".
Unlike similar mechanisms employed in [3], if the Overload bit is set
in a router's LSP, NO transit paths are calculated through the
router. As such, if no alternative paths are available to the
destination network, employing such a mechanism may actually have a
negative impact on convergence.
Finally, if all systems within an IS-IS routing domain haven't
implemented the Overload bit correctly, forwarding loops may occur.
McPherson, D. [Page 4]
INTERNET DRAFT December 2000
7. Security Considerations
The mechanisms specified in this memo introduces no new security
issues to IS-IS.
8. Acknowledgements
The author of this document makes no claim to the originality of the
idea. Others To be supplied...
9. References
[1] ISO, "Intermediate system to Intermediate system routeing
information exchange protocol for use in conjunction with the
Protocol for providing the Connectionless-mode Network Service
(ISO 8473)," ISO/IEC 10589:1992.
[2] Callon, R., "OSI IS-IS for IP and Dual Environment," RFC 1195,
December 1990.
[3] Retana et al., "OSPF Stub Router Advertisement", "Work in
Progress", November 2000.
10. Authors' Address
Danny McPherson
Amber Networks, Inc.
48664 Milmont Drive
Fremont, CA 94538
Phone: 510.687.5200
Email: danny@ambernetworks.com
McPherson, D. [Page 5]