idnits 2.17.1 draft-ietf-bfd-generic-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 640. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 611. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 618. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 624. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'KEYWORDS' is mentioned on line 44, but not defined == Missing Reference: 'BFD-MULTIHOP' is mentioned on line 490, but not defined == Unused Reference: 'ISIS-GRACE' is defined on line 553, but no explicit reference was found in the text == Unused Reference: 'KEYWORD' is defined on line 556, but no explicit reference was found in the text == Unused Reference: 'OSPF-GRACE' is defined on line 563, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-bfd-base-06 == Outdated reference: A later version (-11) exists of draft-ietf-bfd-v4v6-1hop-06 == Outdated reference: A later version (-07) exists of draft-ietf-bfd-mpls-04 == Outdated reference: A later version (-09) exists of draft-ietf-bfd-multihop-05 ** Obsolete normative reference: RFC 3847 (ref. 'ISIS-GRACE') (Obsoleted by RFC 5306) ** Obsolete normative reference: RFC 2740 (ref. 'OSPFv3') (Obsoleted by RFC 5340) Summary: 3 errors (**), 0 flaws (~~), 11 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Katz 3 Internet Draft Juniper Networks 4 D. Ward 5 Cisco Systems 6 Expires: September, 2007 March, 2007 8 Generic Application of BFD 9 draft-ietf-bfd-generic-03.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 Abstract 35 This document describes the generic application of the Bidirectional 36 Forwarding Detection (BFD) protocol. Comments on this draft should 37 be directed to rtg-bfd@ietf.org. 39 Conventions used in this document 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 [KEYWORDS]. 45 1. Introduction 47 The Bidirectional Forwarding Detection protocol [BFD] provides a 48 liveness detection mechanism that can be utilized by other network 49 components for which their integral liveness mechanisms are either 50 too slow, inappropriate, or nonexistent. Other drafts have detailed 51 the use of BFD with specific encapsulations ([BFD-1HOP], [BFD-MULTI], 52 [BFD-MPLS]). As the utility of BFD has become understood, there have 53 been calls to specify BFD interactions with a growing list of network 54 functions. Rather than producing a long series of short documents on 55 the application of BFD, it seemed worthwhile to describe the 56 interactions between BFD and other network functions in a broad way. 58 This document describes the generic application of BFD. Specific 59 protocol applications are provided for illustrative purposes. 61 2. Overview 63 The Bidirectional Forwarding Detection (BFD) specification defines a 64 protocol with simple and specific semantics. Its sole purpose is to 65 verify connectivity between a pair of systems, for a particular data 66 protocol across a path (which may be of any technology, length, or 67 OSI layer). The promptness of the detection of a path failure can be 68 controlled by trading off protocol overhead and system load with 69 detection times. 71 BFD is *not* intended to directly provide control protocol liveness 72 information; those protocols have their own means and vagaries. 73 Rather, control protocols can use the services provided by BFD to 74 inform their operation. BFD can be viewed as a service provided by 75 the layer in which it is running. 77 The service interface with BFD is straightforward. The application 78 supplies session parameters (neighbor address, time parameters, 79 protocol options), and BFD provides the session state, of which the 80 most interesting transitions are to and from the Up state. The 81 application is expected to bootstrap the BFD session, as BFD has no 82 discovery mechanism. 84 An implementation SHOULD establish only a single BFD session per data 85 protocol path, regardless of the number of applications that wish to 86 utilize it. There is no additional value in having multiple BFD 87 sessions to the same endpoints. If multiple applications request 88 different session parameters, it is a local issue as to how to 89 resolve the parameter conflicts. BFD in turn will notify all 90 applications bound to a session when a session state change occurs. 92 BFD should be viewed as having an advisory role to the protocol or 93 protocols or other network functions with which it is interacting, 94 which will then use their own mechanisms to effect any state 95 transitions. The interaction is very much at arm's length, which 96 keeps things simple and decoupled. In particular, BFD explicitly 97 does not carry application-specific information, partly for 98 architectural reasons, and partly because BFD may have curious and 99 unpredictable latency characteristics and as such makes a poor 100 transport mechanism. 102 It is important to remember that the interaction between BFD and its 103 client applications has essentially no interoperability issues, 104 because BFD is acting in an advisory nature (similar to hardware 105 signaling the loss of light on a fiber optic circuit, for example) 106 and existing mechanisms in the client applications are used in 107 reaction to BFD events. In fact, BFD may interact with only one of a 108 pair of systems for a particular client application without any ill 109 effect. 111 3. Control Protocol Interactions 113 Very common client applications of BFD are control protocols, such as 114 routing protocols. The object when BFD interacts with a control 115 protocol is to advise the control protocol of the connectivity of the 116 data protocol. In the case of routing protocols, for example, this 117 allows the connectivity failure to trigger the rerouting of traffic 118 around the failed path more quickly than the native detection 119 mechanisms. 121 3.1. Session Establishment 123 If the session state on either the local or remote system (if known) 124 is AdminDown, BFD has been administratively disabled, and the 125 establishment of a control protocol adjacency MUST be allowed. 127 BFD sessions are typically bootstrapped by the control protocol, 128 using the mechanism (discovery, configuration) used by the control 129 protocol to find neighbors. Note that it is possible in some failure 130 scenarios for the network to be in a state such that the control 131 protocol is capable of coming up, but the BFD session cannot be 132 established, and, more particularly, data cannot be forwarded. To 133 avoid this situation, it would be beneficial to not allow the control 134 protocol to establish a neighbor adjacency. However, this would 135 preclude the operation of the control protocol in an environment in 136 which not all systems support BFD. 138 Therefore, if the control protocol carries signaling that indicates 139 the that both systems are willing to establish a BFD session, or it 140 is known that the remote system is BFD-capable (either by out-of-band 141 means or by the knowledge that the remote system previously sent BFD 142 Control packets), and the BFD session on the local system is in state 143 Down or Init, and the BFD session on the remote system is not 144 AdminDown, the fact that the BFD session is not in Up state SHOULD be 145 used to block establishment of a control protocol adjacency. 147 If it appears that the neighboring system does not support BFD (no 148 BFD Control packets have been received from the neighbor), the 149 establishment of a control protocol adjacency SHOULD NOT be blocked. 150 Furthermore, a system MAY increase the interval between transmitted 151 BFD Control packets beyond the minimum specified in [BFD]. This will 152 have negligible impact on BFD session establishment if the neighbor 153 decides to run BFD after all, since BFD Control packets will be sent 154 on an event-driven basis once the first packet is seen from the 155 neighbor. 157 The setting of BFD's various timing parameters and modes are not 158 subject to standardization. Note that all protocols sharing a 159 session will operate using the same parameters. The mechanism for 160 choosing the parameters among those desired by the various protocols 161 are outside the scope of this specification. It is generally useful 162 to choose the parameters resulting in the shortest detection time; a 163 particular client application can always apply hysteresis to the 164 notifications from BFD if it desires longer detection times. 166 3.2. Reaction to BFD Session State Changes 168 If a BFD session transitions from state Up to AdminDown, or the 169 session transitions from Up to Down because the remote system is 170 indicating that the session is in state AdminDown, clients SHOULD NOT 171 take any control protocol action. 173 Otherwise, the mechanism by which the control protocol reacts to a 174 path failure signaled by BFD depends on the capabilities of the 175 protocol. 177 3.2.1. Control Protocols with a Single Data Protocol 179 A control protocol that is tightly bound to a single failing data 180 protocol SHOULD take action to ensure that data traffic is no longer 181 directed to the failing path. Note that this should not be 182 interpreted as BFD replacing the control protocol liveness mechanism, 183 if any, as the control protocol may rely on mechanisms not verified 184 by BFD (multicast, for instance) so BFD most likely cannot detect all 185 failures that would impact the control protocol. However, a control 186 protocol MAY choose to use BFD session state information to more 187 rapidly detect an impending control protocol failure, particularly if 188 the control protocol operates in-band (over the data protocol.) 190 Therefore, when a BFD session transitions from Up to Down, action 191 SHOULD be taken in the control protocol to signal the lack of 192 connectivity for the data protocol over which BFD is running. If the 193 control protocol has an explicit mechanism for announcing path state, 194 a system SHOULD use that mechanism rather than impacting the 195 connectivity of the control protocol, particularly if the control 196 protocol operates out-of-band from the failed data protocol. 197 However, if such a mechanism is not available, a control protocol 198 timeout SHOULD be emulated for the associated neighbor. 200 3.2.2. Control Protocols with Multiple Data Protocols 202 Slightly different mechanisms are used if the control protocol 203 supports the routing of multiple data protocols, depending on whether 204 the control protocol supports separate topologies for each data 205 protocol. 207 3.2.2.1. Shared Topologies 209 With a shared topology, if one of the data protocols fails (as 210 signaled by the associated BFD session), it is necessary to consider 211 the path to have failed for all data protocols. Otherwise, there is 212 no way for the control protocol to turn away traffic for the failed 213 data protocol (and such traffic would be black-holed indefinitely.) 215 Therefore, when a BFD session transitions from Up to Down, action 216 SHOULD be taken in the control protocol to signal the lack of 217 connectivity for all data protocols sharing the topology. If this 218 cannot be signaled otherwise, a control protocol timeout SHOULD be 219 emulated for the associated neighbor. 221 3.2.2.2. Independent Topologies 223 With individual routing topologies for each data protocol, only the 224 failed data protocol needs to be rerouted around the failed path. 226 Therefore, when a BFD session transitions from Up to Down, action 227 SHOULD be taken in the control protocol to signal the lack of 228 connectivity for the data protocol over which BFD is running. 229 Generally this can be done without impacting the connectivity of 230 other data protocols (since otherwise it is very difficult to support 231 separate topologies for multiple data protocols.) 233 3.3. Interactions with Graceful Restart Mechanisms 235 A number of control protocols support Graceful Restart mechanisms. 236 These mechanisms are designed to allow a control protocol to restart 237 without perturbing network connectivity state (lest it appear that 238 the system and/or all of its links had failed.) They are predicated 239 on the existence of a separate forwarding plane that does not 240 necessarily share fate with the control plane in which the routing 241 protocols operate. In particular, the assumption is that the 242 forwarding plane can continue to function while the protocols restart 243 and sort things out. 245 BFD implementations announce via the Control Plane Independent (C) 246 bit whether or not BFD shares fate with the control plane. This 247 information is used to determine the actions to be taken in 248 conjunction with Graceful Restart. If BFD does not share its fate 249 with the control plane on either system, it can be used to determine 250 whether Graceful Restart in a control protocol is NOT viable (the 251 forwarding plane is not operating.) 253 If the control protocol has a Graceful Restart mechanism, BFD may be 254 used in conjunction with this mechanism. The interaction between BFD 255 and the control protocol depends on the capabilities of the control 256 protocol, and whether or not BFD shares fate with the control plane. 257 In particular, it may be desirable for a BFD session failure to abort 258 the Graceful Restart process and allow the failure to be visible to 259 the network. 261 3.3.1. BFD Fate Independent of the Control Plane 263 If BFD is implemented in the forwarding plane and does not share fate 264 with the control plane on either system (the "C" bit is set in the 265 BFD Control packets in both directions), control protocol restarts 266 should not affect the BFD Session. In this case, a BFD session 267 failure implies that data can no longer be forwarded, so any Graceful 268 Restart in progress at the time of the BFD session failure SHOULD be 269 aborted in order to avoid black holes, and a topology change SHOULD 270 be signaled in the control protocol. 272 3.3.2. BFD Shares Fate with the Control Plane 274 If BFD shares fate with the control plane on either system (the "C" 275 bit is clear in either direction), a BFD session failure cannot be 276 disentangled from other events taking place in the control plane. In 277 many cases, the BFD session will fail as a side effect of the restart 278 taking place. As such, it would be best to avoid aborting any 279 Graceful Restart taking place, if possible (since otherwise BFD and 280 Graceful Restart cannot coexist.) 282 There is some risk in doing so, since a simultaneous failure or 283 restart of the forwarding plane will not be detected, but this is 284 always an issue when BFD shares fate with the control plane. 286 3.3.2.1. Control Protocols with Planned Restart Signaling 288 Some control protocols can signal a planned restart prior to the 289 restart taking place. In this case, if a BFD session failure occurs 290 during the restart, such a planned restart SHOULD NOT be aborted and 291 the session failure SHOULD NOT result in a topology change being 292 signaled in the control protocol. 294 3.3.2.2. Control Protocols Without Planned Restart Signaling 296 Control protocols that cannot signal a planned restart depend on the 297 recently restarted system to signal the Graceful Restart prior to the 298 control protocol adjacency timeout. In most cases, whether the 299 restart is planned or unplanned, it is likely that the BFD session 300 will time out prior to the onset of Graceful Restart, in which case a 301 topology change SHOULD be signaled in the control protocol as 302 specified in section 3.2. 304 However, if the restart is in fact planned, an implementation MAY 305 adjust the BFD session timing parameters prior to restarting in such 306 a way that the detection time in each direction is longer than the 307 restart period of the control protocol, providing the restarting 308 system the same opportunity to enter Graceful Restart as it would 309 have without BFD. The restarting system SHOULD NOT send any BFD 310 Control packets until there is a high likelihood that its neighbors 311 know a Graceful Restart is taking place, as the first BFD Control 312 packet will cause the BFD session to fail. 314 3.4. Interactions with Multiple Control Protocols 316 If multiple control protocols wish to establish BFD sessions with the 317 same remote system for the same data protocol, all MUST share a 318 single BFD session. 320 If hierarchical or dependent layers of control protocols are in use 321 (say, OSPF and IBGP), it may not be useful for more than one of them 322 to interact with BFD. In this example, because IBGP is dependent on 323 OSPF for its routing information, the faster failure detection 324 relayed to IBGP may actually be detrimental. The cost of a peer 325 state transition is high in BGP, and OSPF will naturally heal the 326 path through the network if it were to receive the failure detection. 328 In general, it is best for the protocol at the lowest point in the 329 hierarchy to interact with BFD, and then to use existing interactions 330 between the control protocols to effect changes as necessary. This 331 will provide the fastest possible failure detection and recovery in a 332 network. 334 4. Interactions With Non-Protocol Functions 336 BFD session status may be used to affect other system functions that 337 are not protocol-based (for example, static routes.) If the path to 338 a remote system fails, it may be desirable to avoid passing traffic 339 to that remote system, so the local system may wish to take internal 340 measures to accomplish this (such as withdrawing a static route and 341 withdrawing that route from routing protocols.) 343 If either the local session state or the remote session state (if 344 known) of a BFD session is AdminDown, the local system MUST NOT take 345 any action in the non-protocol function (such as withdrawing a static 346 route), since the session is being administratively disabled and the 347 liveness of the forwarding path is unknown. 349 If it is known that the remote system is BFD-capable (either by out- 350 of-band means or by the knowledge that the remote system previously 351 sent BFD Control packets), and the BFD session on the local system is 352 in state Down or Init, and the BFD session on the remote system is 353 not AdminDown, the fact that the BFD session is not in Up state 354 SHOULD be used to take appropriate action (such as withdrawing a 355 static route.) 356 If it appears that the neighboring system does not support BFD (no 357 BFD Control packets have been received from the neighbor), action 358 such as withdrawing a static route SHOULD NOT be taken. Furthermore, 359 a system MAY increase the interval between transmitted BFD Control 360 packets beyond the minimum specified in [BFD]. This will have 361 negligible impact on BFD session establishment if the neighbor 362 decides to run BFD after all, since BFD Control packets will be sent 363 on an event-driven basis once the first packet is seen from the 364 neighbor. 366 Bootstrapping of the BFD session in the non-protocol case is likely 367 to be derived from configuration information. 369 There is no need to exchange endpoints or discriminator values via 370 any mechanism other than configuration (via Operational Support 371 Systems or any other means) as the endpoints must be known and 372 configured by the same means. 374 5. Data Protocols and Demultiplexing 376 BFD is intended to protect a single "data protocol" and is 377 encapsulated within that protocol. A pair of systems may have 378 multiple BFD sessions over the same topology if they support (and are 379 encapsulated by) different protocols. For example, if two systems 380 have IPv4 and IPv6 running across the same link between them, these 381 are considered two separate paths and require two separate BFD 382 sessions. 384 This same technique is used for more fine-grained paths. For 385 example, if multiple differentiated services [DIFFSERV] are being 386 operated on over IPv4, an independent BFD session may be run for each 387 service level. The BFD Control packets must be marked in the same 388 way as the data packets, partly to ensure as much fate sharing as 389 possible between BFD and data traffic, and also to demultiplex the 390 initial packet if the discriminator values have not been exchanged. 392 6. Other Application Issues 394 BFD can provide liveness detection for OAM-like functions in 395 tunneling and pseudowire protocols. Running BFD inside the tunnel is 396 recommended, as it exercises more aspects of the path. One way to 397 accommodate this is to address BFD packets based on the tunnel 398 endpoints, assuming that they are numbered. 400 If a planned outage is to take place on a path over which BFD is run, 401 it is preferable to take down the BFD session by going into AdminDown 402 state prior to the outage. 404 7. Interoperability Issues 406 The BFD protocol itself is designed so that it will always 407 interoperate at a basic level; asynchronous mode is mandatory and is 408 always available, and other modes and functions are negotiated at run 409 time. Since the service provided by BFD is identical regardless of 410 the variants used, the particular choice of BFD options has no 411 bearing on interoperability. 413 The interaction between BFD and other protocols and control functions 414 is very loosely coupled. The actions taken are based on existing 415 mechanisms in those protocols and functions, so interoperability 416 problems are very unlikely unless BFD is applied in contradictory 417 ways (such as a BFD session failure causing one implementation to go 418 down and another implementation to come up.) In fact, BFD may be 419 advising one system for a particular control function but not the 420 other; the only impact of this would be potentially asymmetric 421 control protocol failure detection. 423 8. Specific Protocol Interactions (Non-Normative) 425 As noted above, there are no interoperability concerns regarding 426 interactions between BFD and control protocols. However, there is 427 enough concern and confusion in this area so that it is worthwhile to 428 provide examples of interactions with specific protocols. 430 Since the interactions do not affect interoperability, they are non- 431 normative. 433 8.1. BFD Interactions with OSPFv2, OSPFv3, and IS-IS 435 The two versions of OSPF ([OSPFv2] and [OSPFv3]), as well as IS-IS 436 [ISIS], all suffer from an architectural limitation, namely that 437 their Hello protocols are limited in the granularity of their failure 438 detection times. In particular, OSPF has a minimum detection time of 439 two seconds, and IS-IS has a minimum detection time of one second. 441 BFD may be used to achieve arbitrarily small detection times for 442 these protocols by supplementing the Hello protocols used in each 443 case. 445 8.1.1. Session Establishment 447 The most obvious choice for triggering BFD session establishment with 448 these protocols would be to use the discovery mechanism inherent in 449 the Hello protocols in OSPF and IS-IS to bootstrap the establishment 450 of the BFD session. Any BFD sessions established to support OSPF and 451 IS-IS across a single IP hop must operate in accordance with 452 [BFD-1HOP]. 454 8.1.2. Reaction to BFD State Changes 456 The basic mechanisms are covered in section 3 above. At this time, 457 OSPFv2 and OSPFv3 carry routing information for a single data 458 protocol (IPv4 and IPv6, respectively) so when it is desired to 459 signal a topology change after a BFD session failure, this should be 460 done by tearing down the corresponding OSPF neighbor. 462 ISIS may be used to support only one data protocol, or multiple data 463 protocols. [ISIS] specifies a common topology for multiple data 464 protocols, but work is underway to support multiple topologies. If 465 multiple data protocols are advertised in the ISIS Hello, and 466 independent topologies are in use, the failing data protocol should 467 no longer be advertised in ISIS Hello packets in order to signal a 468 lack of connectivity for that protocol. Otherwise, a failing BFD 469 session should be signaled by simulating an ISIS adjacency failure. 471 OSPF has a planned restart signaling mechanism, whereas ISIS does 472 not. The appropriate mechanisms outlined in section 3.3 should be 473 used. 475 8.1.3. OSPF Virtual Links 477 If it is desired to use BFD for failure detction of OSPF Virtual 478 Links, the mechanism described in [BFD-MULTI] MUST be used, since 479 OSPF Virtual Links may traverse an arbitrary number of hops. BFD 480 Authentication SHOULD be used and is strongly encouraged. 482 8.2. Interactions with BGP 484 BFD may be useful with EBGP sessions [BGP] in order to more rapidly 485 trigger topology changes in the face of path failure. As noted in 486 section 3.4, it is generally unwise for IBGP sessions to interact 487 with BFD if the underlying IGP is already doing so. 489 EBGP sessions being advised by BFD may establish either a one hop 490 [BFD-1HOP] or a multihop [BFD-MULTIHOP] session, depending on whether 491 the neighbor is immediately adjacent or not. The BFD session should 492 be established to the BGP neighbor (as opposed to any other Next Hop 493 advertised in BGP.) 495 [BGP-GRACE] describes a Graceful Restart mechanism for BGP. If 496 Graceful Restart is not taking place on an EBGP session, and the 497 corresponding BFD session fails, the EBGP session should be torn down 498 in accordance with section 3.2. If Graceful Restart is taking place, 499 the basic procedures in section 3.3 applies. BGP Graceful Restart 500 does not signal planned restarts, so section 3.3.2.2 applies. If 501 Graceful Restart is aborted due to the rules described in section 502 3.3, the "receiving speaker" should act as if the "restart timer" 503 expired (as described in [BGP-GRACE].) 505 8.3. Interactions with RIP 507 The RIP protocol [RIP] is somewhat unique in that, at least as 508 specified, neighbor adjacency state is not stored per se. Rather, 509 installed routes contain a next hop address, which in most cases is 510 the address of the advertising neighbor (but may not be.) 512 In the case of RIP, when the BFD session associated with a neighbor 513 fails, an expiration of the "timeout" timer for each route installed 514 from the neighbor (for which the neighbor is the next hop) should be 515 simulated. 517 Note that if a BFD session fails, and a route is received from that 518 neighbor with a next hop address that is not the address of the 519 neighbor itself, the route will linger until it naturally times out 520 (after 180 seconds.) However, if an implementation keeps track of 521 all of the routes received from each neighbor, all of the routes from 522 the neighbor corresponding to the failed BFD session should be timed 523 out, regardless of the next hop specified therein, and thereby 524 avoiding the lingering route problem. 526 Normative References 528 [BFD] Katz, D., and Ward, D., "Bidirectional Forwarding Detection", 529 draft-ietf-bfd-base-06.txt, March, 2007. 531 [BFD-1HOP] Katz, D., and Ward, D., "BFD for IPv4 and IPv6 (Single 532 Hop)", draft-ietf-bfd-v4v6-1hop-06.txt, March, 2007. 534 [BFD-MPLS] Aggarwal, R., and Kompella, K., "BFD for MPLS LSPs", 535 draft-ietf-bfd-mpls-04.txt, March, 2007. 537 [BFD-MULTI] Katz, D., and Ward, D., "BFD for Multihop Paths", draft- 538 ietf-bfd-multihop-05.txt, March, 2007. 540 [BGP] Rekhter, Y., Li, T. et al, "A Border Gateway Protocol 4 541 (BGP-4)", RFC 4271, January, 2006. 543 [BGP-GRACE] Sangli, S., Chen, E., et al, "Graceful Restart Mechanism 544 for BGP", RFC 4724, January, 2007. 546 [DIFFSERV] Nichols, K. et al, "Definition of the Differentiated 547 Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 548 2474, December, 1998. 550 [ISIS] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual 551 environments", RFC 1195, December 1990. 553 [ISIS-GRACE] Shand, M., and Ginsberg, L., "Restart signaling for IS- 554 IS", RFC 3847, July 2004. 556 [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate 557 Requirement Levels", RFC 2119, March 1997. 559 [OSPFv2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 561 [OSPFv3] Coltun, R., et al, "OSPF for IPv6", RFC 2740, December 1999. 563 [OSPF-GRACE] Moy, J., et al, "Graceful OSPF Restart", RFC 3623, 564 November 2003. 566 [RIP] Malkin, G., "RIP Version 2", RFC 2453, November, 1998. 568 Security Considerations 570 This specification does not raise any additional security issues 571 beyond those of the specifications referred to in the list of 572 normative references. 574 IANA Considerations 576 This document has no actions for IANA. 578 Authors' Addresses 580 Dave Katz 581 Juniper Networks 582 1194 N. Mathilda Ave. 583 Sunnyvale, California 94089-1206 USA 584 Phone: +1-408-745-2000 585 Email: dkatz@juniper.net 587 Dave Ward 588 Cisco Systems 589 170 W. Tasman Dr. 590 San Jose, CA 95134 USA 591 Phone: +1-408-526-4000 592 Email: dward@cisco.com 594 Changes from the previous draft 596 The only significant change to this draft was to add specific text 597 regarding the difference between Down and AdminDown states. Some 598 redundant text was removed or merged. 600 All other changes were purely editorial in nature. 602 IPR Disclaimer 604 The IETF takes no position regarding the validity or scope of any 605 Intellectual Property Rights or other rights that might be claimed to 606 pertain to the implementation or use of the technology described in 607 this document or the extent to which any license under such rights 608 might or might not be available; nor does it represent that it has 609 made any independent effort to identify any such rights. Information 610 on the procedures with respect to rights in RFC documents can be 611 found in BCP 78 and BCP 79. 613 Copies of IPR disclosures made to the IETF Secretariat and any 614 assurances of licenses to be made available, or the result of an 615 attempt made to obtain a general license or permission for the use of 616 such proprietary rights by implementers or users of this 617 specification can be obtained from the IETF on-line IPR repository at 618 http://www.ietf.org/ipr. 620 The IETF invites any interested party to bring to its attention any 621 copyrights, patents or patent applications, or other proprietary 622 rights that may cover technology that may be required to implement 623 this standard. Please address the information to the IETF at ietf- 624 ipr@ietf.org. 626 Full Copyright Notice 628 Copyright (C) The IETF Trust (2007). 630 This document is subject to the rights, licenses and restrictions 631 contained in BCP 78, and except as set forth therein, the authors 632 retain all their rights. 634 This document and the information contained herein are provided on an 635 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 636 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 637 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 638 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 639 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 640 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 642 Acknowledgement 644 Funding for the RFC Editor function is currently provided by the 645 Internet Society. 647 This document expires in September, 2007.