idnits 2.17.1 draft-mcpherson-ospf-transient-00.txt: 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 223 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (July 2000) is 8679 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) == Missing Reference: 'RFC2119' is mentioned on line 45, but not defined Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Netwok Working Group Danny McPherson 2 Internet Draft Amber Networks 3 Tony Przygienda 4 Redback 6 draft-mcpherson-ospf-transient-00.txt July 2000 8 OSPF Transient Blackhole Avoidance 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document describes a simple, interoperable mechanism that can be 34 employed in OSPF networks in order to decrease data loss associated 35 with deterministic blackholing of packets during transient network 36 conditions. The mechanism proposed here requires no OSPF protocol 37 changes and is completely interoperable with the existing OSPF 38 specification. 40 Specification of Requirements 42 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 43 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 44 document are to be interpreted as described in [RFC2119]. 46 Table of Contents 48 1. Overview 49 2. Discussion 50 3. Deployment Considerations 51 4. Security Considerations 52 5. Acknowledgements 53 6. References 54 7. Authors' Address 56 1. Overview 58 When an OSPF router that was previously a transit router becomes 59 unavailable as a result of some transient condition such as a reboot, 60 other routers within the routing domain must select an alternative 61 path to reach destinations which had previously transited the failed 62 router. Presumably, the newly selected router(s) comprising the path 63 have been available for some time and, as a result, have complete 64 forwarding information bases (FIBs) which contain a full set of 65 reachibility information for both internal and external (e.g. BGP) 66 destinations. 68 When the previously failed router becomes available again, in only a 69 few seconds paths that had previously transited the router are again 70 selected as the optimal path by the IGP. As a result, forwarding 71 tables are updated and packets are once again forwarded along the 72 path. Unfortunately, external destination reachibility information 73 (e.g. learned via BGP) is not yet available to the router, and as a 74 result, packets bound for destinations not learned via the IGP are 75 unnecessarily discarded. 77 A mechanism to alleviate the offshoot associated with this 78 deterministic behavior is discussed below. 80 2. Discussion 82 This document describes a simple, interoperable mechanism that can be 83 employed in OSPF [RFC2328] networks in order to avoid transition to a 84 newly available path until other associated routing protocols such as 85 BGP have had sufficient time to converge. 87 The benefits of such a mechanism can realized when considering the 88 following scenario. 90 D.1 91 | 92 +-------+ 93 | RtrD | 94 +-------+ 95 / \ 96 / \ 97 +-------+ +-------+ 98 | RtrB | | RtrC | 99 +-------+ +-------+ 100 \ / 101 \ / 102 +-------+ 103 | RtrA | 104 +-------+ 105 | 106 S.1 108 Host S.1 is transmitting data to destination D.1 via a primary path 109 of RtrA->RtrB->RtrD. Routers A, B and C learn of reachibility to 110 destination D.1 via BGP from RtrD. RtrA's primary path to D.1 is 111 selected because when calculatng the path to BGP NEXT_HOP of RtrD the 112 sum of the OSPF link costs on the RtrA-RtrB-RtrD path is less than 113 the sum of the costs of the RtrA-RtrC-RtrD path. 115 Assume RtrB becomes unavailable and as a result the RtrC path to RtrD 116 is used. Once RtrA's FIB is updated and it begins forwarding packets 117 to RtrC everything should behave properly as RtrC has existing 118 forwarding information regarding destination D.1's availability via 119 BGP NEXT_HOP RtrD. 121 Assume now that RtrB comes back online. In only a few seconds OSPF 122 neighbor state is been established with RtrA and RtrD and database 123 synchronization has occurred. RtrA now realizes that the best path 124 to destination D.1 is via RtrB, and therefore updates it FIB 125 appropriately. RtrA begins to forward packets destined to D.1 to 126 RtrB. Though, because RtrB has yet to establish and synchronization 127 it's BGP neighbor relationship and routing information with RtrD, 128 RtrB has no knowledge regarding reachibililty of destination D.1, and 129 therefore discards the packets received from RtrA. 131 If RtrB were to temporarily set it's link costs to 0xFFFF while 132 synchronizing with BGP tables with it's neighbors, RtrA would 133 continue to use the working RtrA->RtrC->RtrD path. Upon intial 134 synchronization of BGP tables with neighboring router, RtrB would 135 generate a new LSA describing the actual link costs associated with 136 each connection, and RtrA could again begin using the optimal path 137 via RtrB. 139 However, if no alternative path were available to destination D.1 140 RtrA would still be able to use the path via RtrB, and manipulation 141 of the link costs would result in no adverse effect. 143 3. Deployment Considerations 145 Such a mechanism increases overall network availablity and allows 146 network operators to alleviate the deterministic blackholing behavoir 147 introduced in this scenario. The IS-IS overload bit has been 148 employed in IS-IS routing domains to achieve similar behavior. 150 Triggers for setting the link costs as described are left to the 151 implementor. Some potential triggers could include N seconds after 152 booting, or N number of BGP prefixes in the BGP Loc-RIB. 154 Also, understand that this mechanism assumes actual deployments 155 assign substantially lower values for link costs (and the sum of 156 subsequent path costs), and that a value of 0xFFFF for an individual 157 link within a path would be sufficiently large enough to discourage 158 transit traffic from entering the router. 160 4. Security Considerations 162 Security issues are not discussed in this memo. 164 5. Acknowledgements 166 The authors would like to acknowledge John Moy of Sycamore 167 Networks for his valuable input. 169 6. References 171 [RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 173 7. Authors' Address 175 Danny McPherson 176 Amber Networks 177 2465 Augustine Drive 178 Santa Clara, CA 95054 179 Phone: +1 408.486.6336 180 Email: danny@ambernetworks.com 181 John Moy 182 Sycamore Networks 184 Tony Przygienda 185 Redback 186 350 Holger Way 187 San Jose, CA 95134 188 Email: prz@redback.com