idnits 2.17.1 draft-ietf-bfd-generic-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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.) -- The document date (February 5, 2009) is 5556 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: 'KEYWORDS' is mentioned on line 53, but not defined == Missing Reference: 'BFD-MULTIHOP' is mentioned on line 660, but not defined == Unused Reference: 'ISIS-GRACE' is defined on line 738, but no explicit reference was found in the text == Unused Reference: 'KEYWORD' is defined on line 741, but no explicit reference was found in the text == Unused Reference: 'OSPF-GRACE' is defined on line 748, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-bfd-base-09 == Outdated reference: A later version (-11) exists of draft-ietf-bfd-v4v6-1hop-08 == Outdated reference: A later version (-09) exists of draft-ietf-bfd-multihop-07 -- Obsolete informational reference (is this intentional?): RFC 3847 (ref. 'ISIS-GRACE') (Obsoleted by RFC 5306) -- Obsolete informational reference (is this intentional?): RFC 2740 (ref. 'OSPFv3') (Obsoleted by RFC 5340) Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 5 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 Intended status: Proposed Standard D. Ward 5 Cisco Systems 6 Expires: August, 2009 February 5, 2009 8 Generic Application of BFD 9 draft-ietf-bfd-generic-05.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-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/1id-abstracts.html 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 Copyright Notice 33 Copyright (c) 2009 IETF Trust and the persons identified as the 34 document authors. All rights reserved. 36 This document is subject to BCP 78 and the IETF Trust's Legal 37 Provisions Relating to IETF Documents 38 (http://trustee.ietf.org/license-info) in effect on the date of 39 publication of this document. Please review these documents 40 carefully, as they describe your rights and restrictions with respect 41 to this document. 43 Abstract 45 This document describes the generic application of the Bidirectional 46 Forwarding Detection (BFD) protocol. 48 Conventions used in this document 50 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 51 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 52 document are to be interpreted as described in RFC-2119 [KEYWORDS]. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Basic Interaction Between BFD Sessions and Clients . . . . . . 5 59 3.1 Session State Hysteresis . . . . . . . . . . . . . . . . . 5 60 3.2 AdminDown State . . . . . . . . . . . . . . . . . . . . . 5 61 3.3 Hitless Establishment/Reestablishment of BFD State . . . . 5 62 4. Control Protocol Interactions . . . . . . . . . . . . . . . . 6 63 4.1 Adjacency Establishment . . . . . . . . . . . . . . . . . 6 64 4.2 Reaction to BFD State Changes . . . . . . . . . . . . . . 7 65 4.2.1 Control Protocols with a Single Data Protocol . . . . . 7 66 4.2.2 Control Protocols with Multiple Data Protocols . . . . . 8 67 4.2.2.1 Shared Topologies . . . . . . . . . . . . . . . . . . 8 68 4.2.2.2 Independent Topologies . . . . . . . . . . . . . . . . 8 69 4.3 Interactions with Graceful Restart Mechanisms . . . . . . 9 70 4.3.1 BFD Fate Independent of the Control Plane . . . . . . . 9 71 4.3.2 BFD Shares Fate with the Control Plane . . . . . . . . . 9 72 4.3.2.1 Control Protocols with Planned Restart Signaling . . 10 73 4.3.2.2 Control Protocols Without Planned Restart Signaling 10 74 4.4 Interactions with Multiple Control Protocols . . . . . . 10 75 5. Interactions with Non-Protocol Functions . . . . . . . . . . 11 76 6. Data Protocols and Demultiplexing . . . . . . . . . . . . . 12 77 7. Multiple Link Subnetworks . . . . . . . . . . . . . . . . . 12 78 7.1 Complete Decoupling . . . . . . . . . . . . . . . . . . 12 79 7.2 Layer N-1 Hints . . . . . . . . . . . . . . . . . . . . 12 80 7.3 Aggregating BFD Sessions . . . . . . . . . . . . . . . . 13 81 7.4 Combinations of Scenarios . . . . . . . . . . . . . . . 13 82 8. Other Application Issues . . . . . . . . . . . . . . . . . . 13 83 9. Interoperability Issues . . . . . . . . . . . . . . . . . . 14 84 10. Specific Protocol Interactions (Non-Normative) . . . . . . 14 85 10.1 BFD Interactions with OSPFv2, OSPFv3, and IS-IS . . . . 14 86 10.1.1 Session Establishment . . . . . . . . . . . . . . 15 87 10.1.2 Reaction to BFD State Changes . . . . . . . . . . 15 88 10.1.3 OSPF Virtual Links . . . . . . . . . . . . . . . . 15 89 10.2 Interactions with BGP . . . . . . . . . . . . . . . . . 15 90 10.3 Interactions with RIP . . . . . . . . . . . . . . . . . 16 91 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 17 92 12. Security Considerations . . . . . . . . . . . . . . . . . . 17 93 13. References . . . . . . . . . . . . . . . . . . . . . . . . 17 94 13.1 Normative References . . . . . . . . . . . . . . . . . 17 95 13.2 Informative References . . . . . . . . . . . . . . . . 17 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 97 Changes from the previous draft . . . . . . . . . . . . . . . . 18 99 1. Introduction 101 The Bidirectional Forwarding Detection protocol [BFD] provides a 102 liveness detection mechanism that can be utilized by other network 103 components for which their integral liveness mechanisms are either 104 too slow, inappropriate, or nonexistent. Other drafts have detailed 105 the use of BFD with specific encapsulations ([BFD-1HOP], [BFD-MULTI], 106 [BFD-MPLS]). As the utility of BFD has become understood, there have 107 been calls to specify BFD interactions with a growing list of network 108 functions. Rather than producing a long series of short documents on 109 the application of BFD, it seemed worthwhile to describe the 110 interactions between BFD and other network functions ("BFD clients") 111 in a broad way. 113 This document describes the generic application of BFD. Specific 114 protocol applications are provided for illustrative purposes. 116 2. Overview 118 The Bidirectional Forwarding Detection (BFD) specification defines a 119 protocol with simple and specific semantics. Its sole purpose is to 120 verify connectivity between a pair of systems, for a particular data 121 protocol across a path (which may be of any technology, length, or 122 OSI layer). The promptness of the detection of a path failure can be 123 controlled by trading off protocol overhead and system load with 124 detection times. 126 BFD is *not* intended to directly provide control protocol liveness 127 information; those protocols have their own means and vagaries. 128 Rather, control protocols can use the services provided by BFD to 129 inform their operation. BFD can be viewed as a service provided by 130 the layer in which it is running. 132 The service interface with BFD is straightforward. The application 133 supplies session parameters (neighbor address, time parameters, 134 protocol options), and BFD provides the session state, of which the 135 most interesting transitions are to and from the Up state. The 136 application is expected to bootstrap the BFD session, as BFD has no 137 discovery mechanism. 139 An implementation SHOULD establish only a single BFD session per data 140 protocol path, regardless of the number of applications that wish to 141 utilize it. There is no additional value in having multiple BFD 142 sessions to the same endpoints. If multiple applications request 143 different session parameters, it is a local issue as to how to 144 resolve the parameter conflicts. BFD in turn will notify all 145 applications bound to a session when a session state change occurs. 147 BFD should be viewed as having an advisory role to the protocol or 148 protocols or other network functions with which it is interacting, 149 which will then use their own mechanisms to effect any state 150 transitions. The interaction is very much at arm's length, which 151 keeps things simple and decoupled. In particular, BFD explicitly 152 does not carry application-specific information, partly for 153 architectural reasons, and partly because BFD may have curious and 154 unpredictable latency characteristics and as such makes a poor 155 transport mechanism. 157 It is important to remember that the interaction between BFD and its 158 client applications has essentially no interoperability issues, 159 because BFD is acting in an advisory nature (similar to hardware 160 signaling the loss of light on a fiber optic circuit, for example) 161 and existing mechanisms in the client applications are used in 162 reaction to BFD events. In fact, BFD may interact with only one of a 163 pair of systems for a particular client application without any ill 164 effect. 166 3. Basic Interaction Between BFD Sessions and Clients 168 The interaction between a BFD session and its associated client 169 applications is, for the most part, an implementation issue that is 170 outside the scope of this specification. However, it is useful to 171 describe some mechanisms that implementors may use in order to 172 promote full-featured implementations. One way of modeling this 173 interaction is to create an adaptation layer between the BFD state 174 machine and the client applications. The adaptation layer is 175 cognizant of both the internals of the BFD implementation and the 176 requirements of the clients. 178 3.1. Session State Hysteresis 180 A BFD session can be tightly coupled to its client applications; for 181 example, any transition out of the Up state could cause signaling to 182 the clients to take failure action. But in some cases this may not 183 always be the best course of action. 185 Implementors may choose to hide rapid Up/Down/Up transitions of the 186 BFD session from its clients. This is useful in order to support 187 process restarts without necessitating complex protocol mechanisms, 188 for example. 190 As such, a system MAY choose not to notify clients if a BFD session 191 transitions from Up to Down state, and returns to Up state, if it 192 does so within a reasonable period of time (the length of which is 193 outside the scope of this specification.) If the BFD session does 194 not return to Up state within that timeframe, the clients SHOULD be 195 notified that a session failure has occurred. 197 3.2. AdminDown State 199 The AdminDown mechanism in BFD is intended to signal that the BFD 200 session is being taken down for administrative purposes, and the 201 session state is not indicative of the liveness of the data path. 203 Therefore, a system SHOULD NOT indicate a connectivity failure to a 204 client if either the local session state or the remote session state 205 (if known) transitions to AdminDown, so long as that client has 206 independent means of liveness detection (typically, control 207 protocols.) 209 If a client does not have any independent means of liveness 210 detection, a system SHOULD indicate a connectivity failure to a 211 client, and assume the semantics of Down state, if either the local 212 or remote session state transitions to AdminDown. Otherwise, the 213 client will not be able to determine whether the path is viable, and 214 unfortunate results may occur. 216 3.3. Hitless Establishment/Reestablishment of BFD State 218 It is useful to be able to configure a BFD session between a pair of 219 systems without impacting the state of any clients that will be 220 associated with that session. Similarly, it is useful for BFD state 221 to be reestablished without perturbing associated clients when all 222 BFD state is lost (such as in process restart situations.) This 223 interacts with the clients' ability to establish their state 224 independent of BFD. 226 The BFD state machine transitions that occur in the process of 227 bringing up a BFD session in such situations SHOULD NOT cause a 228 connectivity failure notification to the clients. 230 A client which is capable of establishing its state prior to the 231 configuration or restarting of a BFD session MAY do so if 232 appropriate. The means to do so is outside of the scope of this 233 specification. 235 4. Control Protocol Interactions 237 Very common client applications of BFD are control protocols, such as 238 routing protocols. The object when BFD interacts with a control 239 protocol is to advise the control protocol of the connectivity of the 240 data protocol. In the case of routing protocols, for example, this 241 allows the connectivity failure to trigger the rerouting of traffic 242 around the failed path more quickly than the native detection 243 mechanisms. 245 4.1. Adjacency Establishment 247 If the session state on either the local or remote system (if known) 248 is AdminDown, BFD has been administratively disabled, and the 249 establishment of a control protocol adjacency MUST be allowed. 251 BFD sessions are typically bootstrapped by the control protocol, 252 using the mechanism (discovery, configuration) used by the control 253 protocol to find neighbors. Note that it is possible in some failure 254 scenarios for the network to be in a state such that the control 255 protocol is capable of coming up, but the BFD session cannot be 256 established, and, more particularly, data cannot be forwarded. To 257 avoid this situation, it would be beneficial to not allow the control 258 protocol to establish a neighbor adjacency. However, this would 259 preclude the operation of the control protocol in an environment in 260 which not all systems support BFD. 262 Therefore, the establishment of control protocol adjacencies SHOULD 263 be blocked if both systems are willing to establish a BFD session but 264 a BFD session cannot be established. One method for determining that 265 both systems are willing to establish a BFD session is if the control 266 protocol carries explicit signaling of this fact. If there is no 267 explicit signaling, the willingness to establish a BFD session may be 268 determined by means outside the scope of this specification. 270 If it is believed that the neighboring system does not support BFD, 271 the establishment of a control protocol adjacency SHOULD NOT be 272 blocked. 274 The setting of BFD's various timing parameters and modes are not 275 subject to standardization. Note that all protocols sharing a 276 session will operate using the same parameters. The mechanism for 277 choosing the parameters among those desired by the various protocols 278 are outside the scope of this specification. It is generally useful 279 to choose the parameters resulting in the shortest Detection Time; a 280 particular client application can always apply hysteresis to the 281 notifications from BFD if it desires longer Detection Times. 283 Note that many control protocols assume full connectivity between all 284 systems on multiaccess media such as LANs. If BFD is running on only 285 a subset of systems on such a network, and adjacency establishment is 286 blocked by the absence of a BFD session, the assumptions of the 287 control protocol may be violated, with unpredictable results. 289 4.2. Reaction to BFD Session State Changes 291 If a BFD session transitions from state Up to AdminDown, or the 292 session transitions from Up to Down because the remote system is 293 indicating that the session is in state AdminDown, clients SHOULD NOT 294 take any control protocol action. 296 For other transitions from state Up to Down, the mechanism by which 297 the control protocol reacts to a path failure signaled by BFD depends 298 on the capabilities of the protocol, as specified in the following 299 subsections. 301 4.2.1. Control Protocols with a Single Data Protocol 303 A control protocol that is tightly bound to a single failing data 304 protocol SHOULD take action to ensure that data traffic is no longer 305 directed to the failing path. Note that this should not be 306 interpreted as BFD replacing the control protocol liveness mechanism, 307 if any, as the control protocol may rely on mechanisms not verified 308 by BFD (multicast, for instance) so BFD most likely cannot detect all 309 failures that would impact the control protocol. However, a control 310 protocol MAY choose to use BFD session state information to more 311 rapidly detect an impending control protocol failure, particularly if 312 the control protocol operates in-band (over the data protocol.) 314 Therefore, when a BFD session transitions from Up to Down, action 315 SHOULD be taken in the control protocol to signal the lack of 316 connectivity for the path over which BFD is running. If the control 317 protocol has an explicit mechanism for announcing path state, a 318 system SHOULD use that mechanism rather than impacting the 319 connectivity of the control protocol, particularly if the control 320 protocol operates out-of-band from the failed data protocol. 321 However, if such a mechanism is not available, a control protocol 322 timeout SHOULD be emulated for the associated neighbor. 324 4.2.2. Control Protocols with Multiple Data Protocols 326 Slightly different mechanisms are used if the control protocol 327 supports the routing of multiple data protocols, depending on whether 328 the control protocol supports separate topologies for each data 329 protocol. 331 4.2.2.1. Shared Topologies 333 With a shared topology, if one of the data protocols fails (as 334 signaled by the associated BFD session), it is necessary to consider 335 the path to have failed for all data protocols. Otherwise, there is 336 no way for the control protocol to turn away traffic for the failed 337 data protocol (and such traffic would be black-holed indefinitely.) 339 Therefore, when a BFD session transitions from Up to Down, action 340 SHOULD be taken in the control protocol to signal the lack of 341 connectivity for the path in the topology corresponding to the BFD 342 session. If this cannot be signaled otherwise, a control protocol 343 timeout SHOULD be emulated for the associated neighbor. 345 4.2.2.2. Independent Topologies 347 With individual routing topologies for each data protocol, only the 348 failed data protocol needs to be rerouted around the failed path. 350 Therefore, when a BFD session transitions from Up to Down, action 351 SHOULD be taken in the control protocol to signal the lack of 352 connectivity for the path in the topology over which BFD is running. 353 Generally this can be done without impacting the connectivity of 354 other topologies (since otherwise it is very difficult to support 355 separate topologies for multiple data protocols.) 357 4.3. Interactions with Graceful Restart Mechanisms 359 A number of control protocols support Graceful Restart mechanisms. 360 These mechanisms are designed to allow a control protocol to restart 361 without perturbing network connectivity state (lest it appear that 362 the system and/or all of its links had failed.) They are predicated 363 on the existence of a separate forwarding plane that does not 364 necessarily share fate with the control plane in which the routing 365 protocols operate. In particular, the assumption is that the 366 forwarding plane can continue to function while the protocols restart 367 and sort things out. 369 BFD implementations announce via the Control Plane Independent (C) 370 bit whether or not BFD shares fate with the control plane. This 371 information is used to determine the actions to be taken in 372 conjunction with Graceful Restart. If BFD does not share its fate 373 with the control plane on either system, it can be used to determine 374 whether Graceful Restart in a control protocol is NOT viable (the 375 forwarding plane is not operating.) 377 If the control protocol has a Graceful Restart mechanism, BFD may be 378 used in conjunction with this mechanism. The interaction between BFD 379 and the control protocol depends on the capabilities of the control 380 protocol, and whether or not BFD shares fate with the control plane. 381 In particular, it may be desirable for a BFD session failure to abort 382 the Graceful Restart process and allow the failure to be visible to 383 the network. 385 4.3.1. BFD Fate Independent of the Control Plane 387 If BFD is implemented in the forwarding plane and does not share fate 388 with the control plane on either system (the "C" bit is set in the 389 BFD Control packets in both directions), control protocol restarts 390 should not affect the BFD Session. In this case, a BFD session 391 failure implies that data can no longer be forwarded, so any Graceful 392 Restart in progress at the time of the BFD session failure SHOULD be 393 aborted in order to avoid black holes, and a topology change SHOULD 394 be signaled in the control protocol. 396 4.3.2. BFD Shares Fate with the Control Plane 398 If BFD shares fate with the control plane on either system (the "C" 399 bit is clear in either direction), a BFD session failure cannot be 400 disentangled from other events taking place in the control plane. In 401 many cases, the BFD session will fail as a side effect of the restart 402 taking place. As such, it would be best to avoid aborting any 403 Graceful Restart taking place, if possible (since otherwise BFD and 404 Graceful Restart cannot coexist.) 406 There is some risk in doing so, since a simultaneous failure or 407 restart of the forwarding plane will not be detected, but this is 408 always an issue when BFD shares fate with the control plane. 410 4.3.2.1. Control Protocols with Planned Restart Signaling 412 Some control protocols can signal a planned restart prior to the 413 restart taking place. In this case, if a BFD session failure occurs 414 during the restart, such a planned restart SHOULD NOT be aborted and 415 the session failure SHOULD NOT result in a topology change being 416 signaled in the control protocol. 418 4.3.2.2. Control Protocols Without Planned Restart Signaling 420 Control protocols that cannot signal a planned restart depend on the 421 recently restarted system to signal the Graceful Restart prior to the 422 control protocol adjacency timeout. In most cases, whether the 423 restart is planned or unplanned, it is likely that the BFD session 424 will time out prior to the onset of Graceful Restart, in which case a 425 topology change SHOULD be signaled in the control protocol as 426 specified in section 3.2. 428 However, if the restart is in fact planned, an implementation MAY 429 adjust the BFD session timing parameters prior to restarting in such 430 a way that the Detection Time in each direction is longer than the 431 restart period of the control protocol, providing the restarting 432 system the same opportunity to enter Graceful Restart as it would 433 have without BFD. The restarting system SHOULD NOT send any BFD 434 Control packets until there is a high likelihood that its neighbors 435 know a Graceful Restart is taking place, as the first BFD Control 436 packet will cause the BFD session to fail. 438 4.4. Interactions with Multiple Control Protocols 440 If multiple control protocols wish to establish BFD sessions with the 441 same remote system for the same data protocol, all MUST share a 442 single BFD session. 444 If hierarchical or dependent layers of control protocols are in use 445 (say, OSPF and IBGP), it may not be useful for more than one of them 446 to interact with BFD. In this example, because IBGP is dependent on 447 OSPF for its routing information, the faster failure detection 448 relayed to IBGP may actually be detrimental. The cost of a peer 449 state transition is high in BGP, and OSPF will naturally heal the 450 path through the network if it were to receive the failure detection. 452 In general, it is best for the protocol at the lowest point in the 453 hierarchy to interact with BFD, and then to use existing interactions 454 between the control protocols to effect changes as necessary. This 455 will provide the fastest possible failure detection and recovery in a 456 network. 458 5. Interactions With Non-Protocol Functions 460 BFD session status may be used to affect other system functions that 461 are not protocol-based (for example, static routes.) If the path to 462 a remote system fails, it may be desirable to avoid passing traffic 463 to that remote system, so the local system may wish to take internal 464 measures to accomplish this (such as withdrawing a static route and 465 withdrawing that route from routing protocols.) 467 If it is known, or presumed, that the remote system is BFD-capable 468 and the BFD session is not in Up state, appropriate action SHOULD be 469 taken (such as withdrawing a static route.) 471 If it is known, or presumed, that the remote system does not support 472 BFD, action such as withdrawing a static route SHOULD NOT be taken. 474 Bootstrapping of the BFD session in the non-protocol case is likely 475 to be derived from configuration information. 477 There is no need to exchange endpoints or discriminator values via 478 any mechanism other than configuration (via Operational Support 479 Systems or any other means) as the endpoints must be known and 480 configured by the same means. 482 6. Data Protocols and Demultiplexing 484 BFD is intended to protect a single "data protocol" and is 485 encapsulated within that protocol. A pair of systems may have 486 multiple BFD sessions over the same topology if they support (and are 487 encapsulated by) different protocols. For example, if two systems 488 have IPv4 and IPv6 running across the same link between them, these 489 are considered two separate paths and require two separate BFD 490 sessions. 492 This same technique is used for more fine-grained paths. For 493 example, if multiple differentiated services [DIFFSERV] are being 494 operated over IPv4, an independent BFD session may be run for each 495 service level. The BFD Control packets must be marked in the same 496 way as the data packets, partly to ensure as much fate sharing as 497 possible between BFD and data traffic, and also to demultiplex the 498 initial packet if the discriminator values have not been exchanged. 500 7. Multiple Link Subnetworks 502 A number of technologies exist for aggregating multiple parallel 503 links at layer N-1 and treating them as a single link at layer N. 504 BFD may be used in a number of ways to protect the path at layer N. 505 The exact mechanism used is outside the scope of this specification. 506 However, this section provides examples of some possible deployment 507 scenarios. Other scenarios are possible and are not precluded. 509 7.1. Complete Decoupling 511 The simplest approach is to simply run BFD over the layer N path, 512 with no interaction with the layer N-1 mechanisms. Doing so assumes 513 that the layer N-1 mechanism will deal with connectivity issues in 514 individual layer N-1 links. BFD will declare a failure in the layer 515 N path only when the session times out. 517 This approach will work whether or not the layer N-1 neighbor is the 518 same as the layer N neighbor. 520 7.2. Layer N-1 Hints 522 A slightly more intelligent approach than complete decoupling is to 523 have the layer N-1 mechanism inform the layer N BFD when the 524 aggregated link is no longer viable. In this case, the BFD session 525 will detect the failure more rapidly, as it need not wait for the 526 session to time out. This is analogous to triggering a session 527 failure based on the hardware-detected failure of a single link. 529 This approach will also work whether or not the layer N-1 neighbor is 530 the same as the layer N neighbor. 532 7.3. Aggregating BFD Sessions 534 Another approach would be to use BFD on each layer N-1 link, and to 535 aggregate the state of the multiple sessions into a single indication 536 to the layer N clients. This approach has the advantage that it is 537 independent of the layer N-1 technology. However, this approach only 538 works if the layer N neighbor is the same as the layer N-1 neighbor 539 (a single hop at layer N-1.) 541 7.4. Combinations of Scenarios 543 Combinations of more than one of the scenarios listed above (or 544 others) may be useful in some cases. For example, if the layer N 545 neighbor is not directly connected at layer N-1, a system might run a 546 BFD session across each layer N-1 link to the immediate layer N-1 547 neighbor, and then run another BFD session to the layer N neighbor. 548 The aggregate state of the layer N-1 BFD sessions could be used to 549 trigger a layer N BFD session failure. 551 8. Other Application Issues 553 BFD can provide liveness detection for OAM-like functions in 554 tunneling and pseudowire protocols. Running BFD inside the tunnel is 555 recommended, as it exercises more aspects of the path. One way to 556 accommodate this is to address BFD packets based on the tunnel 557 endpoints, assuming that they are numbered. 559 If a planned outage is to take place on a path over which BFD is run, 560 it is preferable to take down the BFD session by going into AdminDown 561 state prior to the outage. The system asserting AdminDown SHOULD do 562 so for at least one Detection Time in order to ensure that the remote 563 system is aware of it. 565 Similarly, if BFD is to be deconfigured from a system, it is 566 desirable to not trigger any client application action. Simply 567 ceasing the transmission of BFD Control packets will cause the remote 568 system to detect a session failure. In order to avoid this, the 569 system on which BFD is being deconfigured SHOULD put the session into 570 AdminDown state and maintain this state for a Detection Time to 571 ensure that the remote system is aware of it. 573 9. Interoperability Issues 575 The BFD protocol itself is designed so that it will always 576 interoperate at a basic level; asynchronous mode is mandatory and is 577 always available, and other modes and functions are negotiated at run 578 time. Since the service provided by BFD is identical regardless of 579 the variants used, the particular choice of BFD options has no 580 bearing on interoperability. 582 The interaction between BFD and other protocols and control functions 583 is very loosely coupled. The actions taken are based on existing 584 mechanisms in those protocols and functions, so interoperability 585 problems are very unlikely unless BFD is applied in contradictory 586 ways (such as a BFD session failure causing one implementation to go 587 down and another implementation to come up.) In fact, BFD may be 588 advising one system for a particular control function but not the 589 other; the only impact of this would be potentially asymmetric 590 control protocol failure detection. 592 10. Specific Protocol Interactions (Non-Normative) 594 As noted above, there are no interoperability concerns regarding 595 interactions between BFD and control protocols. However, there is 596 enough concern and confusion in this area so that it is worthwhile to 597 provide examples of interactions with specific protocols. 599 Since the interactions do not affect interoperability, they are non- 600 normative. 602 10.1. BFD Interactions with OSPFv2, OSPFv3, and IS-IS 604 The two versions of OSPF ([OSPFv2] and [OSPFv3]), as well as IS-IS 605 [ISIS], all suffer from an architectural limitation, namely that 606 their Hello protocols are limited in the granularity of their failure 607 detection times. In particular, OSPF has a minimum detection time of 608 two seconds, and IS-IS has a minimum detection time of one second. 610 BFD may be used to achieve arbitrarily small detection times for 611 these protocols by supplementing the Hello protocols used in each 612 case. 614 10.1.1. Session Establishment 616 The most obvious choice for triggering BFD session establishment with 617 these protocols would be to use the discovery mechanism inherent in 618 the Hello protocols in OSPF and IS-IS to bootstrap the establishment 619 of the BFD session. Any BFD sessions established to support OSPF and 620 IS-IS across a single IP hop must operate in accordance with 621 [BFD-1HOP]. 623 10.1.2. Reaction to BFD State Changes 625 The basic mechanisms are covered in section 3 above. At this time, 626 OSPFv2 and OSPFv3 carry routing information for a single data 627 protocol (IPv4 and IPv6, respectively) so when it is desired to 628 signal a topology change after a BFD session failure, this should be 629 done by tearing down the corresponding OSPF neighbor. 631 ISIS may be used to support only one data protocol, or multiple data 632 protocols. [ISIS] specifies a common topology for multiple data 633 protocols, but work is underway to support multiple topologies. If 634 multiple topologies are used to support multiple data protocols (or 635 multiple classes of service of the same data protocol) the topology- 636 specific path associated with a failing BFD session should no longer 637 be advertised in ISIS LSPs in order to signal a lack of connectivity. 638 Otherwise, a failing BFD session should be signaled by simulating an 639 ISIS adjacency failure. 641 OSPF has a planned restart signaling mechanism, whereas ISIS does 642 not. The appropriate mechanisms outlined in section 3.3 should be 643 used. 645 10.1.3. OSPF Virtual Links 647 If it is desired to use BFD for failure detection of OSPF Virtual 648 Links, the mechanism described in [BFD-MULTI] MUST be used, since 649 OSPF Virtual Links may traverse an arbitrary number of hops. BFD 650 Authentication SHOULD be used and is strongly encouraged. 652 10.2. Interactions with BGP 654 BFD may be useful with EBGP sessions [BGP] in order to more rapidly 655 trigger topology changes in the face of path failure. As noted in 656 section 3.4, it is generally unwise for IBGP sessions to interact 657 with BFD if the underlying IGP is already doing so. 659 EBGP sessions being advised by BFD may establish either a one hop 660 [BFD-1HOP] or a multihop [BFD-MULTIHOP] session, depending on whether 661 the neighbor is immediately adjacent or not. The BFD session should 662 be established to the BGP neighbor (as opposed to any other Next Hop 663 advertised in BGP.) BFD Authentication SHOULD be used and is 664 strongly encouraged. 666 [BGP-GRACE] describes a Graceful Restart mechanism for BGP. If 667 Graceful Restart is not taking place on an EBGP session, and the 668 corresponding BFD session fails, the EBGP session should be torn down 669 in accordance with section 3.2. If Graceful Restart is taking place, 670 the basic procedures in section 3.3 applies. BGP Graceful Restart 671 does not signal planned restarts, so section 3.3.2.2 applies. If 672 Graceful Restart is aborted due to the rules described in section 673 3.3, the "receiving speaker" should act as if the "restart timer" 674 expired (as described in [BGP-GRACE].) 676 10.3. Interactions with RIP 678 The RIP protocol [RIP] is somewhat unique in that, at least as 679 specified, neighbor adjacency state is not stored per se. Rather, 680 installed routes contain a next hop address, which in most cases is 681 the address of the advertising neighbor (but may not be.) 683 In the case of RIP, when the BFD session associated with a neighbor 684 fails, an expiration of the "timeout" timer for each route installed 685 from the neighbor (for which the neighbor is the next hop) should be 686 simulated. 688 Note that if a BFD session fails, and a route is received from that 689 neighbor with a next hop address that is not the address of the 690 neighbor itself, the route will linger until it naturally times out 691 (after 180 seconds.) However, if an implementation keeps track of 692 all of the routes received from each neighbor, all of the routes from 693 the neighbor corresponding to the failed BFD session should be timed 694 out, regardless of the next hop specified therein, and thereby 695 avoiding the lingering route problem. 697 11. IANA Considerations 699 This document has no actions for IANA. 701 12. Security Considerations 703 This specification does not raise any additional security issues 704 beyond those of the specifications referred to in the list of 705 normative references. 707 13. References 709 13.1. Normative References 711 [BFD] Katz, D., and Ward, D., "Bidirectional Forwarding Detection", 712 draft-ietf-bfd-base-09.txt, February, 2009. 714 [BFD-1HOP] Katz, D., and Ward, D., "BFD for IPv4 and IPv6 (Single 715 Hop)", draft-ietf-bfd-v4v6-1hop-08.txt, February, 2009. 717 [BFD-MPLS] Aggarwal, R.,Kompella, K., et al, "BFD for MPLS LSPs", 718 draft-ietf-bfd-mpls-07.txt, June, 2008. 720 [BFD-MULTI] Katz, D., and Ward, D., "BFD for Multihop Paths", draft- 721 ietf-bfd-multihop-07.txt, February, 2009. 723 13.2. Informative References 725 [BGP] Rekhter, Y., Li, T. et al, "A Border Gateway Protocol 4 726 (BGP-4)", RFC 4271, January, 2006. 728 [BGP-GRACE] Sangli, S., Chen, E., et al, "Graceful Restart Mechanism 729 for BGP", RFC 4724, January, 2007. 731 [DIFFSERV] Nichols, K. et al, "Definition of the Differentiated 732 Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 733 2474, December, 1998. 735 [ISIS] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual 736 environments", RFC 1195, December 1990. 738 [ISIS-GRACE] Shand, M., and Ginsberg, L., "Restart signaling for IS- 739 IS", RFC 3847, July 2004. 741 [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate 742 Requirement Levels", RFC 2119, March 1997. 744 [OSPFv2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 746 [OSPFv3] Coltun, R., et al, "OSPF for IPv6", RFC 2740, December 1999. 748 [OSPF-GRACE] Moy, J., et al, "Graceful OSPF Restart", RFC 3623, 749 November 2003. 751 [RIP] Malkin, G., "RIP Version 2", RFC 2453, November, 1998. 753 Authors' Addresses 755 Dave Katz 756 Juniper Networks 757 1194 N. Mathilda Ave. 758 Sunnyvale, California 94089-1206 USA 759 Phone: +1-408-745-2000 760 Email: dkatz@juniper.net 762 Dave Ward 763 Cisco Systems 764 170 W. Tasman Dr. 765 San Jose, CA 95134 USA 766 Phone: +1-408-526-4000 767 Email: dward@cisco.com 769 Changes from the previous draft 771 All changes are purely editorial in nature. 773 This document expires in August, 2009.