idnits 2.17.1 draft-spallagatti-bfd-multipoint-active-tail-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 date (February 2, 2015) is 3370 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) == Outdated reference: A later version (-19) exists of draft-ietf-bfd-multipoint-05 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force D. Katz 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track D. Ward 5 Expires: August 6, 2015 Cisco Systems 6 S. Pallagatti, Ed. 7 Juniper Networks 8 February 2, 2015 10 BFD Multipoint Active Tails. 11 draft-spallagatti-bfd-multipoint-active-tail-00 13 Abstract 15 This document describes active tail extensions to the Bidirectional 16 Forwarding Detection (BFD) protocol for multipoint and multicast 17 networks. Comments on this draft should be directed to rtg- 18 bfd@ietf.org. 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in RFC 2119 [RFC2119]. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on August 6, 2015. 43 Copyright Notice 45 Copyright (c) 2015 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 4 63 3.1. Multipoint Client Session . . . . . . . . . . . . . . . . 4 64 3.2. Multipoint Client Session Failure . . . . . . . . . . . . 4 65 3.3. State Variables . . . . . . . . . . . . . . . . . . . . . 5 66 3.3.1. New State Variables . . . . . . . . . . . . . . . . . 5 67 3.3.2. State Variable Initialization and Maintenance . . . . 6 68 3.4. Controlling Multipoint BFD Options . . . . . . . . . . . 7 69 3.5. State Machine . . . . . . . . . . . . . . . . . . . . . . 7 70 3.6. Session Establishment . . . . . . . . . . . . . . . . . . 7 71 3.7. Discriminators and Packet Demultiplexing . . . . . . . . 8 72 3.8. Controlling Tail Packet Transmission . . . . . . . . . . 8 73 3.9. Soliciting the Tails . . . . . . . . . . . . . . . . . . 9 74 3.10. Verifying Connectivity to Specific Tails . . . . . . . . 9 75 3.11. Detection Times . . . . . . . . . . . . . . . . . . . . . 10 76 3.12. MultipointClient Down/AdminDown Sessions . . . . . . . . 10 77 3.13. Base Specification Text Replacement . . . . . . . . . . . 11 78 3.13.1. Reception of BFD Control Packets . . . . . . . . . . 11 79 3.13.2. Demultiplexing BFD Control Packets . . . . . . . . . 11 80 3.13.3. Transmitting BFD Control Packets . . . . . . . . . . 12 81 4. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 5. Operational Scenarios . . . . . . . . . . . . . . . . . . . . 13 83 5.1. No Head Notification . . . . . . . . . . . . . . . . . . 13 84 5.2. Unreliable Head Notification . . . . . . . . . . . . . . 14 85 5.3. Semi-reliable Head Notification and Tail Solicitation . . 14 86 5.4. Reliable Head Notification . . . . . . . . . . . . . . . 14 87 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 88 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 89 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 90 9. Normative References . . . . . . . . . . . . . . . . . . . . 16 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 93 1. Introduction 95 This application of BFD is an extension to Multipoint BFD 96 [I-D.ietf-bfd-multipoint] which allows tail to unreliably notify the 97 head of the lack of multipoint connectivity. As a further option, 98 this notification can be made reliable. Notification to the head can 99 be enabled for all tails, or for only a subset of the tails. 101 Multipoint BFD base document [I-D.ietf-bfd-multipoint] describes 102 procedures to verify only the head-to-tail connectivity over the 103 multipoint path. Although it may use unicast paths in both 104 directions, Multipoint BFD does not verify those paths (and in fact 105 it is preferable if unicast paths share as little fate with the 106 multipoint path as is feasible.) 108 Goal of this application is for the head to reasonably rapidly have 109 knowledge of tails that have lost connectivity from the head. 111 Since scaling is a primary concern (particularly state implosion 112 toward the head), it is a required that the head be in control of all 113 timing aspects of the mechanism, and that BFD packets from the tails 114 to the head not be synchronized. 116 This document effectively modifies and adds to the base BFD 117 specification and base BFD multipoint document. 119 2. Overview 121 Head may wish to be alerted to the tails' connectivity (or lack 122 thereof), there are a number of options. First, if all that is 123 needed is an unreliable failure notification, the head can direct the 124 tails to transmit unicast BFD Control packets back to the head when 125 the path fails. 127 If the head wishes to know the identity of the tails on the 128 multipoint path, it may solicit membership by sending a multipoint 129 BFD Control packet with the Poll (P) bit set, which will induce the 130 tails to return a unicast BFD Control packet with the Final (F) bit 131 set. The head can then create BFD session state for each of the 132 tails that have multipoint connectivity. If the head sends such a 133 packet on occasion, it can keep track of which tails answer, thus 134 providing a somewhat reliable mechanism for detecting which tails 135 fail to respond (implying a loss of multipoint connectivity.) 137 If the head wishes a reliable indication of the tails' connectivity, 138 it may do all of the above, but if it detects that a tail did not 139 answer the previous multipoint poll, it may initiate a Demand mode 140 Poll Sequence as a unicast to the tail. This covers the case where 141 either the multipoint poll or the single reply thereto is lost in 142 transit. If desired, the head may Poll one or more tails proactively 143 to track the tails' connectivity. 145 If some tails are more equal than others, in the sense that the head 146 needs to detect the lack of multipoint connectivity to a subset of 147 tails at a different rate, the head may transmit unicast BFD Polls to 148 that subset of tails. In this case, the timing may be independent on 149 a tail-by-tail basis. 151 Individual tails may be configured so that they never send BFD 152 control packets to the head, even when the head wishes notification 153 of path failure from the tail. Such tails will never be known to the 154 head, but will still be able to detect multipoint path failures from 155 the head. 157 3. Protocol Details 159 This section describes the operation of BFD Multipoint active tail in 160 detail. This section is update to section 4 of 161 [I-D.ietf-bfd-multipoint] 163 3.1. Multipoint Client Session 165 If the head is keeping track of some or all of the tails, it has a 166 session of type MultipointClient per tail that it cares about. All 167 of the MultipointClient sessions for tails on a particular multipoint 168 path are grouped with the MultipointHead session to which the clients 169 are listening. A BFD Poll Sequence may be sent over such a session 170 to a tail if the head wishes to verify connectivity. These sessions 171 receive any BFD Control packets sent by the tails, and never transmit 172 periodic BFD Control packets other than Poll Sequences (since 173 periodic transmission is always done by the MultipointHead session.) 175 3.2. Multipoint Client Session Failure 177 If a MultipointClient session receives a BFD Control packet from the 178 tail with state Down or AdminDown, the head reliably knows that the 179 tail has lost multipoint connectivity. If the Detection Time expires 180 on a MultipointClient session, it is ambiguous as to whether the 181 multipoint connectivity failed or whether there was a unicast path 182 problem in one direction or the other, so the head does not reliably 183 know the tail state. 185 3.3. State Variables 187 BFD Multipoint active tail introduces new state variables and 188 modifies the usage of a few existing ones defined in section 4.4 of 189 [I-D.ietf-bfd-multipoint]. 191 3.3.1. New State Variables 193 Few state variables are added and modified support of Multipoint BFD 194 active tail. 196 bfd.SessionType 198 The type of this session as defined in 199 [I-D.ietf-bfd-multipoint]. A new value introduced is: 201 MultipointClient: A session on the head that tracks the 202 state of an individual tail, when desirable. 204 This variable MUST be initialized to the appropriate type when 205 the session is created, according to the rules in section 4.13 206 of [I-D.ietf-bfd-multipoint]. 208 bfd.SilentTail 210 If 0, a tail may send packets to the head according to other 211 parts of this specification. Setting this to 1 allows tails to 212 be provisioned to always be silent, even when the head is 213 soliciting traffic from the tails. This can be useful, for 214 example, in deployments of a large number of tails when the 215 head wishes to track the state of a subset of them. This 216 variable MUST be initialized based on configuration. 218 This variable is only pertinent when bfd.SessionType is 219 MultipointTail. 221 bfd.ReportTailDown 223 Set to 1 if the head wishes tails to notify the head, via 224 periodic BFD Control packets, when they see the BFD session 225 fail. If 0, the tail will never send periodic BFD Control 226 packets, and the head will not be notified of session failures 227 by the tails. This variable MUST be initialized based on 228 configuration. 230 This variable is only pertinent when bfd.SessionType is 231 MultipointHead or MultipointClient. 233 bfd.UnicastRcvd 235 Set to 1 if a tail receives a unicast BFD Control packet from 236 the head. This variable MUST be set to zero if the session 237 transitions from Up state to some other state. 239 This variable MUST be initialized to zero. 241 This variable is only pertinent when Bfd.SessionType is 242 MultipointTail. 244 3.3.2. State Variable Initialization and Maintenance 246 Some state variables defined in section 6.8.1 of the [RFC5880] needs 247 to be initialized or manipulated differently depending on the session 248 type (see section 4.4.2 of [I-D.ietf-bfd-multipoint]). 250 bfd.LocalDiscr 252 For session type MultipointClient, this variable MUST always 253 match the value of bfd.LocalDiscr in the associated 254 MultipointHead session. 256 bfd.DesiredMinTxInterval 258 For session type MultipointClient, this variable MUST always 259 match the value of bfd.DesiredMinTxInterval in the associated 260 MultipointHead session. 262 bfd.RequiredMinRxInterval 264 It should be noted that for sessions of type MultipointTail, 265 this variable only affects the rate of unicast Polls sent by 266 the head; the rate of multipoint packets is necessarily 267 unaffected by it. 269 bfd.DemandMode 271 This variable MUST be initialized to 1 for session types 272 MultipointClient. 274 bfd.DetectMult 276 For session type MultipointClient, this variable MUST always 277 match the value of bfd.DetectMult in the associated 278 MultipointHead session. 280 3.4. Controlling Multipoint BFD Options 282 The state variables defined above are used to choose which 283 operational options are active. 285 The most basic form of operation as explained in 286 [I-D.ietf-bfd-multipoint], in which BFD Control packets flow only 287 from the head and no tracking is desired of tail state at the head, 288 is accomplished by setting bfd.ReportTailDown to 0 in the 289 MultipointHead session. 291 If the head wishes to know the identity of the tails, it sends 292 multipoint Polls as needed. Previously known tails that don't 293 respond to the Polls will be detected. 295 If the head wishes to be notified by the tails when they lose 296 connectivity, it sets bfd.ReportTailDown to 1 in either the 297 MultipointHead session (if such notification is desired from all 298 tails) or in the MultipointClient session (if notification is desired 299 from a particular tail.) Note that the setting of this variable in a 300 MultipointClient session for a particular tail overrides the setting 301 in the MultipointHead session. 303 If the head wishes to verify the state of a tail on an ongoing basis, 304 it sends a Poll Sequence from the MultipointClient session associated 305 with that tail as needed. 307 If the head wants to more quickly be alerted to a session failure 308 from a particular tail, it sends a BFD Control packet from the 309 MultipointClient session associated with that tail. This has the 310 effect of eliminating the initial delay that the tail would otherwise 311 insert prior to transmission of the packet. 313 If a tail wishes to operate silently (sending no BFD Control packets 314 to the head) it sets bfd.SilentTail to 1 in the MultipointTail 315 session. This allows a tail to be silent independent of the settings 316 on the head. 318 3.5. State Machine 320 State machine for session of type MultipointClient is same as defined 321 in section 4.5 of [I-D.ietf-bfd-multipoint]. 323 3.6. Session Establishment 325 If BFD Control packets are received at the head, they are 326 demultiplexed to sessions of type MultipointClient, which represent 327 the set of tails that the head is interested in tracking. These 328 sessions will typically also be established dynamically based on the 329 receipt of BFD Control packets. The head has broad latitude in 330 choosing which tails to track, if any, without affecting the basic 331 operation of the protocol. The head directly controls whether or not 332 tails are allowed to send BFD Control packets back to the head. 334 3.7. Discriminators and Packet Demultiplexing 336 When the tails send BFD Control packets to the head from the 337 MultipointTail session, the contents of Your Discr (the discriminator 338 received from the head) will not be sufficient for the head to 339 demultiplex the packet, since the same value will be received from 340 all tails on the multicast tree. In this case, the head MUST 341 demultiplex packets based on the source address and the value of Your 342 Discr, which together uniquely identify the tail and the multipoint 343 path. 345 When the head sends unicast BFD Control packets to a tail from a 346 MultipointClient session, the value of Your Discr will be valid, and 347 the tail MUST demultiplex the packet based solely on Your Discr. 349 3.8. Controlling Tail Packet Transmission 351 As the fan-in from the tails to the head may be very large, it is 352 critical that the flow of BFD Control packets from the tails is 353 controlled. 355 The head always operates in Demand mode. This means that no tail 356 will send an asynchronous BFD Control packet as long as the session 357 is Up. 359 The value of Required Min Rx Interval received by a tail in a unicast 360 BFD Control packet, if any, always takes precedence over the value 361 received in Multipoint BFD Control packets. This allows the packet 362 rate from individual tails to be controlled separately as desired by 363 sending a BFD Control packet from the corresponding MultipointClient 364 session. This also eliminates the random delay prior to transmission 365 from the tail that would otherwise be inserted, reducing the latency 366 of reporting a failure to the head. 368 If the head wishes to suppress traffic from the tails when they 369 detect a session failure, it MAY set bfd.RequiredMinRxInterval to 370 zero, which is a reserved value that indicates that the sender wishes 371 to receive no periodic traffic. This can be set in the 372 MultipointHead session (suppressing traffic from all tails) or it can 373 be set in a MultipointClient session (suppressing traffic from only a 374 single tail.) 375 Any tail may be provisioned to never send *any* BFD Control packets 376 to the head by setting bfd.SilentTail to 1. This provides a 377 mechanism by which only a subset of tails report their session status 378 to the head. 380 3.9. Soliciting the Tails 382 If the head wishes to know the identities of the tails, the 383 MultipointHead session MAY send a BFD Control packet as specified in 384 Section 3.13.3, with the Poll (P) bit set to 1. This will cause all 385 of the tails to reply with a unicast BFD Control Packet, randomized 386 across one packet interval. 388 The decision as to when to send a multipoint Poll is outside the 389 scope of this specification. However, it must never be sent more 390 often than the regular multipoint BFD Control packet. Since the tail 391 will treat a multipoint Poll like any other multipoint BFD Control 392 packet, Polls may be sent in lieu of non-Poll packets. 394 Soliciting the tails also starts the Detection Timer for each 395 associated MultipointClient session, which will cause those sessions 396 to time out if the associated tails do not respond. 398 Note that for this mechanism to work properly, the Detection Time 399 (which is equal to bfd.DesiredMinTxInterval) MUST be greater than the 400 round trip time of BFD Control packets from the head to the tail (via 401 the multipoint path) and back (via a unicast path.) See Section 3.11 402 for more details. 404 3.10. Verifying Connectivity to Specific Tails 406 If the head wishes to verify connectivity to a specific tail, the 407 corresponding MultipointClient session MAY send a BFD Poll Sequence 408 to said tail. This might be done in reaction to the expiration of 409 the Detection Timer (the tail didn't respond to a multipoint Poll), 410 or it might be done on a proactive basis. 412 The interval between transmitted packets in the Poll Sequence MUST be 413 calculated as specified in the base specification (the greater of 414 bfd.DesiredMinTxInterval and bfd.RemoteMinRxInterval.) 416 The value transmitted in Required Min RX Interval will be used by the 417 tail (rather than the value received in any multipoint packet) when 418 it transmits BFD Control packets to the head notifying it of a 419 session failure, and the transmitted packets will not be delayed. 420 This value can potentially be set much lower than in the multipoint 421 case, in order to speed up notification to the head, since the value 422 will be used only by the single tail. This value (and the lack of 423 delay) are "sticky", in that once the tail receives it, it will 424 continue to use it indefinitely. Therefore, if the head no longer 425 wishes to single out the tail, it SHOULD reset the timer to the 426 default by sending a Poll Sequence with the same value of Required 427 Min Rx Interval as is carried in the multipoint packets, or it MAY 428 reset the tail session by sending a Poll Sequence with state 429 AdminDown (after the completion of which the session will come back 430 up.) 432 Note that a failure of the head to receive a response to a Poll 433 Sequence does not necessarily mean that the tail has lost multipoint 434 connectivity, though a reply to a Poll Sequence does reliably 435 indicate connectivity or lack thereof (by virtue of the tail's state 436 not being Up in the BFD Control packet.) 438 3.11. Detection Times 440 MultipointClient sessions at the head are always in Demand mode, and 441 as such only care about detection time in two cases. First, if a 442 Poll Sequence is being sent on a MultipointClient session, the 443 detection time on this session is calculated according to the base 444 specification, that is, the transmission interval multiplied by 445 bfd.DetectMult. Second, when a multipoint Poll is sent to solicit 446 tail replies, the detection time on all associated MultipointClient 447 sessions that aren't currently sending Poll Sequences is set to a 448 value greater than or equal to bfd.RequiredMinRxInterval (one packet 449 time.) This value can be made arbitrarily large in order to ensure 450 that the detection time is greater than the BFD round trip time 451 between the head and the tail with no ill effects, other than 452 delaying the detection of unresponsive tails. Note that a detection 453 time expiration on a MultipointClient session at the head, while 454 indicating a BFD session failure, cannot be construed to mean that 455 the tail is not hearing multipoint packets from the head. 457 3.12. MultipointClient Down/AdminDown Sessions 459 If the MultipointHead session is going down (which only happens 460 administratively), all associated MultipointClient sessions SHOULD be 461 destroyed as they are superfluous. 463 If a MultipointClient session goes down due to the receipt of an 464 unsolicited BFD Control packet from the tail with state Down or 465 AdminDown (not in response to a Poll), and tail connectivity 466 verification is not being done, the session MAY be destroyed. If 467 verification is desired, the session SHOULD send a Poll Sequence and 468 the session SHOULD be maintained. 470 If the tail replies to a Poll Sequence with state Down or AdminDown, 471 it means that the tail session is definitely down. In this case, the 472 session MAY be destroyed. 474 If the Detection Time expires on a MultipointClient session (meaning 475 that the tail did not reply to a Poll Sequence) the session MAY be 476 destroyed. 478 3.13. Base Specification Text Replacement 480 The following sections are meant to replace the corresponding 481 sections in the base specification. 483 3.13.1. Reception of BFD Control Packets 485 The following procedure replaces section 6.8.6 of [RFC5880]. 487 When a BFD Control packet is received, procedure defined in section 488 4.13.1 of [I-D.ietf-bfd-multipoint] MUST be followed, in the order 489 specified. If the packet is discarded according to these rules, 490 processing of the packet MUST cease at that point. In addition to 491 that if tail tracking is desired by head below procedure MUST be 492 applied. 494 If bfd.SessionType is MultipointTail 496 If bfd.UnicastRcvd is 0 or the M bit is clear, set 497 bfd.RemoteMinRxInterval to the value of Required Min RX 498 Interval. 500 If the M bit is clear, set bfd.UnicastRcvd to 1. 502 Else (not MultipointTail) 504 Set bfd.RemoteMinRxInterval to the value of Required Min RX 505 Interval. 507 If the Poll (P) bit is set, and bfd.SilentTail is zero, send a BFD 508 Control packet to the remote system with the Poll (P) bit clear, 509 and the Final (F) bit set (see Section 3.13.3.) 511 3.13.2. Demultiplexing BFD Control Packets 513 This section is part of the replacement for [RFC5880] section 6.8.6 514 and addition to section 4.13.2 of [I-D.ietf-bfd-multipoint], 515 separated for clarity. 517 If Multipoint (M) bit is clear 518 If the Your Discriminator field is nonzero 520 Select a session based on the value of Your Discriminator. 521 If no session is found, the packet MUST be discarded. 523 If bfd.SessionType is MulticastHead 525 Find a MultipointClient session grouped to this 526 MulticastHead session, based on the source address and 527 the value of Your Discriminator. If a session is found 528 and is not MulticastClient, the packet MUST be discarded. 529 If no session is found, a new session of type 530 MultipointClient MAY be created, or the packet MAY be 531 discarded. This choice is outside the scope of this 532 specification. 534 If bfd.SessionType is not MulticastClient, the packet 535 MUST be discarded. 537 3.13.3. Transmitting BFD Control Packets 539 The following procedure replaces section 6.8.7 of [RFC5880]. 541 A system MUST NOT periodically transmit BFD Control packets if 542 bfd.SessionType is MulticastClient and a Poll Sequence is not being 543 transmitted. 545 If bfd.SessionType is MulticastTail and periodic transmission of BFD 546 Control packets is just starting (due to Demand mode not being active 547 on the remote system), the first packet to be transmitted MUST be 548 delayed by a random amount of time between zero and (0.9 * 549 bfd.RemoteMinRxInterval). 551 If a BFD Control packet is received with the Poll (P) bit set to 1, 552 the receiving system MUST transmit a BFD Control packet with the Poll 553 (P) bit clear and the Final (F) bit, without respect to the 554 transmission timer or any other transmission limitations, without 555 respect to the session state, and without respect to whether Demand 556 mode is active on either system. A system MAY limit the rate at 557 which such packets are transmitted. If rate limiting is in effect, 558 the advertised value of Desired Min TX Interval MUST be greater than 559 or equal to the interval between transmitted packets imposed by the 560 rate limiting function. If the Multipoint (M) bit is set in the 561 received packet, the packet transmission MUST be delayed by a random 562 amount of time between zero and (0.9 * bfd.RemoteMinRxInterval). 563 Otherwise, the packet MUST be transmitted as soon as practicable. 565 A system MUST NOT set the Demand (D) bit if bfd.SessionType is 566 MultipointClient unless bfd.DemandMode is 1, bfd.SessionState is Up, 567 and bfd.RemoteSessionState is Up. 569 Contents of transmitted packet MUST be as explained in section 4.13.3 570 of [I-D.ietf-bfd-multipoint]. 572 4. Assumptions 574 If head notification is to be used, it is assumed that a multipoint 575 BFD packet encapsulation contains enough information so that a tail 576 can address a unicast BFD packet to the head. 578 If head notification is to be used, it is assumed that is that there 579 is bidirectional unicast communication available (at the same 580 protocol layer within which BFD is being run) between the tail and 581 head. 583 For the head to know reliably that a tail has lost multipoint 584 connectivity, the unicast paths in both directions between that tail 585 and the head must remain operational when the multipoint path fails. 586 It is thus desirable that unicast paths not share fate with the 587 multipoint path to the extent possible if the head wants reliable 588 knowledge of tail state. 590 Since the normal BFD three-way handshake is not used in this 591 application, a tail transitioning from state Up to Down and back to 592 Up again may not be reliably detected at the head. 594 5. Operational Scenarios 596 It is worth analyzing how this protocol reacts to various scenarios. 597 There are three path components present, namely, the multipoint path, 598 the forward unicast path (from head to a particular tail), and the 599 reverse unicast path (from a tail to the head.) There are also four 600 options as to how the head is notified about failures from the tail. 602 5.1. No Head Notification 604 Since the only path used in this scenario is the multipoint path, 605 none of the others matter. A failure in the multipoint path will 606 result in the tail noticing the failure within a detection time, and 607 the head will remain ignorant of the tail state. 609 5.2. Unreliable Head Notification 611 In this scenario, the tail sends back unsolicicted BFD packets in 612 response to the detection of a multipoint path failure. It uses the 613 reverse unicast path, but not the forward unicast path. 615 If the multipoint path fails but the reverse unicast path stays up, 616 the tail will detect the failure within a detection time, and the 617 head will know about it within one reverse packet time (since the 618 notification is delayed.) 620 If both the multipoint path and the reverse unicast paths fail, the 621 tail will detect the failure but the head will remain unaware of it. 623 5.3. Semi-reliable Head Notification and Tail Solicitation 625 In this scenario, the head sends occasional multipoint Polls in 626 addition to (or in lieu of) non-Poll multipoint BFD Control packets, 627 expecting the tails to reply with Final. This also uses the reverse 628 unicast path, but not the forward unicast path. 630 If the multipoint path fails but the reverse unicast path stays up, 631 the tail will detect the failure within a detection time, and the 632 head will know about it within one reverse packet time (the 633 notification is delayed to avoid synchronization of the tails.) 635 If both the multipoint path and the reverse unicast paths fail, the 636 tail will detect the failure but the head will remain unaware of this 637 fact. 639 If the reverse unicast path fails but the multipoint path stays up, 640 the head will see the BFD session fail, but the state of the 641 multipoint path will be unknown to the head. The tail will continue 642 to receive multipoint data traffic. 644 If either the multipoint Poll or the unicast reply is lost in 645 transit, the head will see the BFD session fail, but the state of the 646 multipoint path will be unknown to the head. The tail will continue 647 to receive multipoint data traffic. 649 5.4. Reliable Head Notification 651 In this scenario, the head sends occasional multipoint Polls in 652 addition to (or in lieu of) non-Poll multipoint BFD control packets, 653 expecting the tails to reply with Final. If a tail that had 654 previously replied to a multipoint Poll fails to reply (or if the 655 head simply wishes to verify tail connectivity,) the head issues a 656 unicast Poll Sequence to the tail. This scenario makes use of all 657 three paths. 659 If the multipoint path fails but the two unicast paths stay up, the 660 tail will detect the failure within a detection time, and the head 661 will know about it within one reverse packet time (since the 662 notification is delayed.) Note that the reverse packet time may be 663 smaller in this case if the head has previously issued a unicast Poll 664 (since the tail will not delay transmission of the notification in 665 this case.) 667 If both the multipoint path and the reverse unicast paths fail 668 (regardless of the state of the forward unicast path), the tail will 669 detect the failure but the head will remain unaware of this fact. 670 The head will detect a BFD session failure to the tail but cannot 671 make a determination about the state of the tail's multipoint 672 connectivity. 674 If the forward unicast path fails but the reverse unicast path stays 675 up, the head will detect a BFD session failure to the tail if it 676 happens to send a unicast Poll sequence, but cannot make a 677 determination about the state of the tail's multipoint connectivity. 678 If the multipoint path to the tail fails prior to any unicast Poll 679 being sent, the tail will detect the failure within a detection time, 680 and the head will know about it within one reverse packet time (since 681 the notification is delayed.) 683 If the multipoint path stays up but the reverse unicast path fails, 684 the head will see the BFD session fail if it happens to send a Poll 685 Sequence, but the state of the multipoint path will be unknown to the 686 head. The tail will continue to receive multipoint data traffic. 688 If the multipoint path and the reverse unicast path both stay up but 689 the forward unicast path fails, neither side will notice so long as a 690 unicast Poll Sequence is never sent by the head. If the head sends a 691 unicast Poll Sequence, the head will see the BFD session fail, but 692 the state of the multipoint path will be unknown to the head. The 693 tail will continue to receive multipoint data traffic. 695 6. IANA Considerations 697 This document has no actions for IANA. 699 7. Security Considerations 701 This specification does not raise any additional security issues 702 beyond those of the specifications referred to in the list of 703 normative references. 705 8. Contributors 707 Rahul Aggarwal of Juniper Networks and George Swallow of Cisco 708 Systems provided the initial idea for this specification and 709 contributed to its development. 711 9. Normative References 713 [I-D.ietf-bfd-multipoint] 714 Katz, D., Ward, D., and J. Networks, "BFD for Multipoint 715 Networks", draft-ietf-bfd-multipoint-05 (work in 716 progress), January 2015. 718 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 719 Requirement Levels", BCP 14, RFC 2119, March 1997. 721 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 722 (BFD)", RFC 5880, June 2010. 724 Authors' Addresses 726 Dave Katz 727 Juniper Networks 728 1194 N. Mathilda Ave. 729 Sunnyvale, California 94089-1206 730 USA 732 Email: dkatz@juniper.net 734 Dave Ward 735 Cisco Systems 736 170 West Tasman Dr. 737 San Jose, California 95134 738 USA 740 Email: wardd@cisco.com 742 Santosh Pallagatti (editor) 743 Juniper Networks 744 Embassy Business Park 745 Bangalore, KA 560093 746 India 748 Email: santoshpk@juniper.net