idnits 2.17.1 draft-mcpherson-isis-transient-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 2000) is 8526 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFC 2119' on line 44 -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '3' Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Danny McPherson 3 INTERNET DRAFT Amber Networks, Inc. 4 December 2000 6 IS-IS Transient Blackhole Avoidance 7 9 1. Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC 2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 2. Abstract 32 This document describes a simple, interoperable mechanism that can be 33 employed in IS-IS networks in order to decrease data loss associated 34 with deterministic blackholing of packets during transient network 35 conditions. The mechanism proposed here requires no IS-IS protocol 36 changes and is completely interoperable with the existing IS-IS 37 specification. 39 3. Specification of Requirements 41 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 42 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 43 document are to be interpreted as described in [RFC 2119]. 45 4. Introduction 47 When an IS-IS router that was previously a transit router becomes 48 unavailable as a result of some transient condition such as a reboot, 49 other routers within the routing domain must select an alternative 50 path to reach destinations which had previously transited the failed 51 router. Presumably, the newly selected router(s) comprising the path 52 have been available for some time and, as a result, have complete 53 forwarding information bases (FIBs) which contain a full set of 54 reachability information for both internal and external (e.g. BGP) 55 destination networks. 57 When the previously failed router becomes available again, in only a 58 few seconds paths that had previously transited the router are again 59 selected as the optimal path by the IGP. As a result, forwarding 60 tables are updated and packets are once again forwarded along the 61 path. Unfortunately, external destination reachability information 62 (e.g. learned via BGP) is not yet available to the router, and as a 63 result, packets bound for destinations not learned via the IGP are 64 unnecessarily discarded. 66 A mechanism to alleviate the offshoot associated with this 67 deterministic behavior is discussed below. 69 5. Discussion 71 This document describes a simple, interoperable mechanism that can be 72 employed in IS-IS [1] and [2] networks in order to avoid transition 73 to a newly available path until other associated routing protocols 74 such as BGP have had sufficient time to converge. 76 The benefits of such a mechanism can realized when considering the 77 following scenario. 79 D.1 80 | 81 +-------+ 82 | RtrD | 83 +-------+ 84 / \ 85 / \ 86 +-------+ +-------+ 87 | RtrB | | RtrC | 88 +-------+ +-------+ 89 \ / 90 \ / 91 +-------+ 92 | RtrA | 93 +-------+ 94 | 95 S.1 97 Host S.1 is transmitting data to destination D.1 via a primary path 98 of RtrA->RtrB->RtrD. Routers A, B and C learn of reachability to 99 destination D.1 via BGP from RtrD. RtrA's primary path to D.1 is 100 selected because when calculating the path to BGP NEXT_HOP of RtrD 101 the sum of the IS-IS link metrics on the RtrA-RtrB-RtrD path is less 102 than the sum of the metrics of the RtrA-RtrC-RtrD path. 104 Assume RtrB becomes unavailable and as a result the RtrC path to RtrD 105 is used. Once RtrA's FIB is updated and it begins forwarding packets 106 to RtrC everything should behave properly as RtrC has existing 107 forwarding information regarding destination D.1's availability via 108 BGP NEXT_HOP RtrD. 110 Assume now that RtrB comes back online. In only a few seconds IS-IS 111 neighbor state has been established with RtrA and RtrD and database 112 synchronization has occurred. RtrA now realizes that the best path 113 to destination D.1 is via RtrB, and therefore updates it FIB 114 appropriately. RtrA begins to forward packets destined to D.1 to 115 RtrB. Though, because RtrB has yet to establish and synchronization 116 it's BGP neighbor relationship and routing information with RtrD, 117 RtrB has no knowledge regarding reachability of destination D.1, and 118 therefore discards the packets received from RtrA destined to D.1. 120 If RtrB were to temporarily set it's LSP Overload bit while 121 synchronizing BGP tables with it's neighbors, RtrA would continue to 122 use the working RtrA->RtrC->RtrD path, and the LSP should only be 123 used to obtain reachability to locally connected networks (rather 124 than for calculating transit paths through the router, as defined in 125 [1]). 127 After initial synchronization of BGP tables with neighboring routers, 128 RtrB would generate a new LSP, clearing the Overload bit, and RtrA 129 could again begin using the optimal path via RtrB. 131 Typically, in service provider networks IBGP connections are done via 132 peerings with 'loopback' addresses. As such, the newly available 133 router must advertise it's own loopback, as well as associated 134 adjacencies, in order to make the loopbacks accessible to other 135 routers within the routing domain. It's because of this that simply 136 flooding an empty LSP is not sufficient. 138 6. Deployment Considerations 140 Such a mechanism increases overall network availability and allows 141 network operators to alleviate the deterministic blackholing behavior 142 introduced in this scenario. Similar mechanisms [3] have been 143 defined for OSPF, though only after realizing similar usefulness 144 obtained from that of the IS-IS Overload bit. 146 This mechanism has been deployed in several large IS-IS networks for 147 several of years. 149 Triggers for setting the Overload bit as described are left to the 150 implementor. Some potential triggers could perhaps include "N 151 seconds after booting", or "N number of BGP prefixes in the BGP Loc- 152 RIB". 154 Unlike similar mechanisms employed in [3], if the Overload bit is set 155 in a router's LSP, NO transit paths are calculated through the 156 router. As such, if no alternative paths are available to the 157 destination network, employing such a mechanism may actually have a 158 negative impact on convergence. 160 Finally, if all systems within an IS-IS routing domain haven't 161 implemented the Overload bit correctly, forwarding loops may occur. 163 7. Security Considerations 165 The mechanisms specified in this memo introduces no new security 166 issues to IS-IS. 168 8. Acknowledgements 170 The author of this document makes no claim to the originality of the 171 idea. Others To be supplied... 173 9. References 175 [1] ISO, "Intermediate system to Intermediate system routeing 176 information exchange protocol for use in conjunction with the 177 Protocol for providing the Connectionless-mode Network Service 178 (ISO 8473)," ISO/IEC 10589:1992. 180 [2] Callon, R., "OSI IS-IS for IP and Dual Environment," RFC 1195, 181 December 1990. 183 [3] Retana et al., "OSPF Stub Router Advertisement", "Work in 184 Progress", November 2000. 186 10. Authors' Address 188 Danny McPherson 189 Amber Networks, Inc. 190 48664 Milmont Drive 191 Fremont, CA 94538 192 Phone: 510.687.5200 193 Email: danny@ambernetworks.com