idnits 2.17.1 draft-ietf-ospf-dc-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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 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 6 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 a Security Considerations 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 abstract seems to contain references ([RFC2328], [RFC1793]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (November 2000) is 8563 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 section? 'RFC2328' on line 254 looks like a reference -- Missing reference section? 'RFC1793' on line 258 looks like a reference -- Missing reference section? 'LLS' on line 263 looks like a reference -- Missing reference section? 'HELLO' on line 266 looks like a reference -- Missing reference section? 'OOB' on line 270 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Sira Panduranga Rao 3 Internet Draft UTA 4 Expiration Date: July 2001 Alex Zinin 5 File name: draft-ietf-ospf-dc-00.txt Cisco Systems 7 November 2000 9 Detecting Inactive Neighbors over OSPF Demand Circuits 10 draft-ietf-ospf-dc-00.txt 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its Areas, and its Working Groups. Note that other 19 groups may also distribute working documents as Internet Drafts. 21 Internet Drafts are draft documents valid for a maximum of six 22 months. Internet Drafts may be updated, replaced, or obsoleted by 23 other documents at any time. It is not appropriate to use Internet 24 Drafts as reference material or to cite them other than as a "working 25 draft" or "work in progress". 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 34 OSPF [RFC2328] is a link-state intra-domain routing protocol used in 35 IP networks. OSPF behavior over demand circuits is optimized in 36 [RFC1793] to minimize the amount of overhead traffic. A part of OSPF 37 demand circuit extensions is the Hello suppression mechanism. This 38 technique allows a demand circuit to go down when no interesting 39 traffic is going through the link. However, it also introduces a 40 problem, where it becomes impossible to detect a OSPF-inactive 41 neighbor over such a link. This memo addresses the above problem by 42 introducing three mechanisms---Hello probes, limitation of the number 43 of LSA retransmits and flushing of self-originated LSAs. 45 1. Motivation 47 In some situations, when operating over demand circuits, the remote 48 neighbor may be unable to run OSPF, and, as a possible result, unable 49 to route application traffic. Possible scenarios include: 51 o The OSPF process might have died on the remote neighbor. 53 o Oversubscription (Section 7 of [RFC1793]) may cause a continuous 54 drop of application data at the link level. 56 The problem here is that the local router cannot identify the prob- 57 lems such as this, since Hello exchange is suppressed on demand cir- 58 cuits. If the topology of the network is such that other routers 59 cannot communicate their knowledge about the remote neighbor via 60 flooding, the local router and all routers behind it will never know 61 about the problem, so application traffic may continue being for- 62 warded to the OSPF-incapable router. 64 This memo describes two techniques that solve the described problem. 65 First, a neighbor probing mechanism using Hellos is introduced, and 66 second, the number of LSA retransmit attempts on demand circuits is 67 limited. We also encourage flushing of self-originated LSAs when the 68 OSPF process is going down. 70 2. Proposed Solution 72 The first part of the solution this document proposes makes use of 73 Hellos to detect whether the OSPF process is operational on the 74 remote neighbor. We call this process "Hello probing". The idea 75 behind this technique is to allow either of the two neighbors con- 76 nected over a demand circuit to test the remote neighbor at any time 77 (see Section 2.1.2). The routers across the demand circuit can be 78 connected by either a point-to-point link, or a virtual link, or a 79 point-to-multipoint interface. The case of routers connected by 80 broadcast networks or NBMA is not considered, since Hello suppression 81 is not used in these cases (Section 3.2 [RFC1793]). Since Hellos are 82 suppressed on demand circuit interfaces, the local router must make 83 sure the remote router supports Hello probing before testing it. Oth- 84 erwise the remote router may be mistakenly declared inoperational. To 85 accomplish this, we introduce a new capability bit that is exchanged 86 in DBD packets (see Section 2.1.1). 88 The Hello probing mechanism is used as follows. After a router has 89 synchronized the LSDB with its neighbor over the demand circuit, the 90 demand circuit may be torn down if there is no more application 91 traffic. When application traffic starts going over the link, the 92 link is brought up, and the routers may probe each other. The routers 93 may also probe each other any time the link is up (could be imple- 94 mented as a configurable option) with the caution that OSPF Hello 95 packets are not considered as interesting traffic and do not cause 96 the demand circuit to remain up. 98 The case when one or more of the router's links are oversubscribed 99 (see section 7 of [RFC1793]) should be considered by the implementa- 100 tions. In such a situation even if the link status is up and applica- 101 tion data being sent on the link, only a limited number of neighbors 102 is really reachable. To make sure temporarily unreachable neighbors 103 are not mistakenly declared down, Hello probing should be restricted 104 to those neighbors that are actually reachable (i.e., there is a cir- 105 cuit established with the neighbor at the moment the probing pro- 106 cedure needs to be initiated). This check itself is considered an 107 implementation detail. 109 The second part of the solution is limiting the number of times LSAs 110 can be retransmitted over a demand circuit. See Section 2.2 for more 111 details. 113 The third part of the solution is flushing of self-originated LSAs 114 whenever the OSPF process on a router is going down. 116 Hello probing and LSA retransmission limit may be used together or 117 alone. This memo does not dictate which one and how many of them 118 must be implemented, but only provides mechanisms to solve the 119 described problem. This memo, however, recommends to flush some 120 locally originated LSAs when possible when OSPF process is going 121 down. 123 2.1 Hello Probing 125 The Hello probing mechanism allows routers connected over a demand 126 circuit to test each other's OSPF capabilities. In order to do so, 127 both routers need to support this functionality, otherwise opera- 128 tional routers may mistakenly be declared unreachable. We insure this 129 by introducing a new capability bit in the Extended Options TLV 130 announced in the link-local signaling (LLS) data block of DBD packets 131 (see [LLS] for more information on LLS). 133 We also use the same bit in Hello packets as a Hello reply request 134 (RR) flag. This helps avoid racing conditions when a Hello sent in 135 reply causes another reply to be sent, and so on. When a router needs 136 to probe its neighbor, it sends a Hello with the RR bit set. The 137 receiving side sends a Hello packet in reply with RR bit clear. 139 2.1.1 Extended Options TLV 141 The Extended Options TLV is a part of LLS specification (see [LLS]) 142 and is announced in both Hello and DBD packets. 144 A new bit is introduced in the Value field of this TLV as shown in 145 Figure 1. The value of the bit is 0x00000004. 147 +---+---+---+---+---+---+---+- -+---+---+---+---+-----+---+---+ 148 | * | * | * | * | * | * | * |...| * | * | * | * |HP/RR| RS| OR| 149 +---+---+---+---+---+---+---+- -+---+---+---+---+-----+---+---+ 151 Figure 1. Bits in Extended Options TLV 153 When used in DBD packets, the new bit indicates router's Hello Prob- 154 ing capability and is called the HP-bit. When used in Hello packets, 155 the new bit means that a Hello must be sent in reply and is called 156 the Reply Request (RR) bit. 158 Routers supporting Hello probing must always set the HP bit in their 159 DBD packets. 161 For description of RS and OR bits, see [HELLO] and [OOB] correspond- 162 ingly. 164 2.1.2 Hello Probing Procedure 166 OSPF routers are allowed to perform Hello probing at any time. How- 167 ever, it is not recommended to do so when the link is down, because, 168 in its one extreme, it will keep the demand circuit up or bouncing, 169 or, in its other extreme, it may cause a neighbor to be mistakenly 170 declared unreachable. 172 It is recommended that both sides perform Hello probing whenever the 173 demand circuit goes up, and periodically if the circuit stays in the 174 active state. Note however that care must be taken not to let OSPF 175 Hello probes keep the circuit in the active state without any appli- 176 cation traffic going through it. 178 When a router needs to probe a neighbor, it should start its Hello 179 and Dead timers and send Hello packets with the RR-bit set. If asso- 180 ciated interface is point-to-multipoint, it is recommended to account 181 for neighbor-specific timers and send Hello probes as IP unicasts. 182 On the receiving side, when a packet with the RR-bit set is received, 183 the router should immediately reply with a unicast Hello packet 184 without setting the RR-bit. Unicast Hello limits the scope of Hello 185 probing. 187 The described procedure makes it possible for the sides to probe 188 their corresponding neighbors asynchronously and without coordina- 189 tion. 191 2.2 Limiting Number of LSA Retransmissions 193 An alternative method (that can be used together with Hello probing) 194 to identify OSPF-incapable neighbors is to limit the amount of LSA 195 retransmits over a demand circuit. The router should count the number 196 of retransmit attempts for each neighbor. When an LSA is acknowledged 197 by the neighbor, the router should zero the counter. When the counter 198 reaches a predefined (or configured) value, a KillNbr event should be 199 generated for the neighbor experiencing the problem. 201 Note that this method does not require cooperation of the routers on 202 both sides of a demand circuit and can be used with already installed 203 OSPF routers without requiring them to be upgraded with new software. 205 2.3 OSPF Process Shutdown and Flushing of LSAs 207 It is recommended for an OSPF process to flush its self-originated 208 LSAs when the OSPF process is going down. This way the router informs 209 all other routers in the area that they should not consider it tran- 210 sit any more and should look for alternative routes. 212 Care must be taken not to introduce instability in the network by 213 flushing all LSAs. It is acceptable to flush only the self-originated 214 router-LSA in the appropriate area and let other LSAs age out. 216 Note that there can happen situations where the router cannot reli- 217 ably flush its LSAs within reasonable time frame. This could be due 218 to the loss of the packets, the demand circuit being down or the 219 delay in establishing a path to the neighbor. A situation highlight- 220 ing this problem is when the router is oversubscribed (see Section 7 221 of [RFC1793]) and thus cannot communicate the news to its neighbors. 223 3. Support of Virtual Links and Point-to-multipoint Interfaces 225 Virtual links can be treated analogous to point-to-point links and so 226 the techniques described in this memo are applicable to virtual links 227 as well. The case of point-to-multipoint interface running as demand 228 circuit (section 3.5 [RFC1793]) can be treated as individual point- 229 to-point links, for which the solution has been described in section 230 2. 232 4. Compatibility issues 234 Backward compatibility of the Hello probing mechanism is insured by 235 introducing the HP bit in the Extended Options TLV. 237 Limiting the number of LSA retransmission is a backward-compatible 238 technique by its nature. 240 5. Considerations 242 In addition to the lost functionality mentioned in Section 6 of 243 [RFC1793], there is an added overhead in terms of the amount of data 244 (hello packets) being transmitted due to Hello probing whenever the 245 link is up and thereby increasing the overall cost. 247 6. Acknowledgements 249 The authors would like to thank John Moy, Vijayapal Reddy Patil, SVR 250 Anand, and Peter Psenak for their comments on this work. 252 7. References 254 [RFC2328] 255 J.Moy, OSPF Version 2. Technical Report RFC2328 Internet Engineer- 256 ing Task Force, 1998 ftp://ftp.isi.edu/in-notes/rfc2328.txt 258 [RFC1793] 259 J.Moy, Extending OSPF to support Demand Circuits. Technical Report 260 RFC1793 Internet Engineering Task Force, 1995 261 ftp://ftp.isi.edu/in-notes/rfc1793.txt 263 [LLS] Zinin, Friedman, Roy, Nguyen, Yeung, "OSPF Link-local Signaling", 264 draft-ietf-ospf-lls-00.txt, Work in progress. 266 [HELLO] 267 Zinin, Roy, Nguyen, "OSPF Restart Signaling", draft-ietf-ospf- 268 restart-00.txt, Work in progress. 270 [OOB] Zinin, Roy, Nguyen, "OSPF Out-of-band LSDB resynchronization", 271 draft-ietf-ospf-oob-resync-00.txt, Work in progress. 273 8. Authors' addresses 275 Sira Panduranga Rao 276 The University of Texas at Arlington 277 Arlington, TX 76013 278 Email: siraprao@hotmail.com 280 Alex Zinin 281 Cisco Systems 282 150 West Tasman Dr. 283 San Jose, CA 95134 284 Email: azinin@cisco.com