idnits 2.17.1 draft-ietf-bfd-multipoint-active-tail-03.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 (October 13, 2016) is 2750 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-09 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: April 16, 2017 Cisco Systems 6 S. Pallagatti, Ed. 7 Individual Contributor 8 October 13, 2016 10 BFD Multipoint Active Tails. 11 draft-ietf-bfd-multipoint-active-tail-03 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 April 16, 2017. 43 Copyright Notice 45 Copyright (c) 2016 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. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 91 10. Normative References . . . . . . . . . . . . . . . . . . . . 16 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 94 1. Introduction 96 This application of BFD is an extension to Multipoint BFD 97 [I-D.ietf-bfd-multipoint] which allows tail to unreliably notify the 98 head of the lack of multipoint connectivity. As a further option, 99 this notification can be made reliable. Notification to the head can 100 be enabled for all tails, or for only a subset of the tails. 102 Multipoint BFD base document [I-D.ietf-bfd-multipoint] describes 103 procedures to verify only the head-to-tail connectivity over the 104 multipoint path. Although it may use unicast paths in both 105 directions, Multipoint BFD does not verify those paths (and in fact 106 it is preferable if unicast paths share as little fate with the 107 multipoint path as is feasible.) 109 Goal of this application is for the head to reasonably rapidly have 110 knowledge of tails that have lost connectivity from the head. 112 Since scaling is a primary concern (particularly state implosion 113 toward the head), it is a required that the head be in control of all 114 timing aspects of the mechanism, and that BFD packets from the tails 115 to the head not be synchronized. 117 This document effectively modifies and adds to the base BFD 118 specification and base BFD multipoint document. 120 2. Overview 122 Head may wish to be alerted to the tails' connectivity (or lack 123 thereof), there are a number of options. First, if all that is 124 needed is an unreliable failure notification, the head can direct the 125 tails to transmit unicast BFD Control packets back to the head when 126 the path fails. 128 If the head wishes to know the identity of the tails on the 129 multipoint path, it may solicit membership by sending a multipoint 130 BFD Control packet with the Poll (P) bit set, which will induce the 131 tails to return a unicast BFD Control packet with the Final (F) bit 132 set. The head can then create BFD session state for each of the 133 tails that have multipoint connectivity. If the head sends such a 134 packet on occasion, it can keep track of which tails answer, thus 135 providing a somewhat reliable mechanism for detecting which tails 136 fail to respond (implying a loss of multipoint connectivity.) 138 If the head wishes a reliable indication of the tails' connectivity, 139 it may do all of the above, but if it detects that a tail did not 140 answer the previous multipoint poll, it may initiate a Demand mode 141 Poll Sequence as a unicast to the tail. This covers the case where 142 either the multipoint poll or the single reply thereto is lost in 143 transit. If desired, the head may Poll one or more tails proactively 144 to track the tails' connectivity. 146 If some tails are more equal than others, in the sense that the head 147 needs to detect the lack of multipoint connectivity to a subset of 148 tails at a different rate, the head may transmit unicast BFD Polls to 149 that subset of tails. In this case, the timing may be independent on 150 a tail-by-tail basis. 152 Individual tails may be configured so that they never send BFD 153 control packets to the head, even when the head wishes notification 154 of path failure from the tail. Such tails will never be known to the 155 head, but will still be able to detect multipoint path failures from 156 the head. 158 3. Protocol Details 160 This section describes the operation of BFD Multipoint active tail in 161 detail. This section is update to section 4 of 162 [I-D.ietf-bfd-multipoint] 164 3.1. Multipoint Client Session 166 If the head is keeping track of some or all of the tails, it has a 167 session of type MultipointClient per tail that it cares about. All 168 of the MultipointClient sessions for tails on a particular multipoint 169 path are grouped with the MultipointHead session to which the clients 170 are listening. A BFD Poll Sequence may be sent over such a session 171 to a tail if the head wishes to verify connectivity. These sessions 172 receive any BFD Control packets sent by the tails, and never transmit 173 periodic BFD Control packets other than Poll Sequences (since 174 periodic transmission is always done by the MultipointHead session.) 176 3.2. Multipoint Client Session Failure 178 If a MultipointClient session receives a BFD Control packet from the 179 tail with state Down or AdminDown, the head reliably knows that the 180 tail has lost multipoint connectivity. If the Detection Time expires 181 on a MultipointClient session, it is ambiguous as to whether the 182 multipoint connectivity failed or whether there was a unicast path 183 problem in one direction or the other, so the head does not reliably 184 know the tail state. 186 3.3. State Variables 188 BFD Multipoint active tail introduces new state variables and 189 modifies the usage of a few existing ones defined in section 4.4 of 190 [I-D.ietf-bfd-multipoint]. 192 3.3.1. New State Variables 194 Few state variables are added and modified support of Multipoint BFD 195 active tail. 197 bfd.SessionType 199 The type of this session as defined in 200 [I-D.ietf-bfd-multipoint]. A new value introduced is: 202 MultipointClient: A session on the head that tracks the 203 state of an individual tail, when desirable. 205 This variable MUST be initialized to the appropriate type when 206 the session is created, according to the rules in section 4.13 207 of [I-D.ietf-bfd-multipoint]. 209 bfd.SilentTail 211 If 0, a tail may send packets to the head according to other 212 parts of this specification. Setting this to 1 allows tails to 213 be provisioned to always be silent, even when the head is 214 soliciting traffic from the tails. This can be useful, for 215 example, in deployments of a large number of tails when the 216 head wishes to track the state of a subset of them. This 217 variable MUST be initialized based on configuration. 219 This variable is only pertinent when bfd.SessionType is 220 MultipointTail. 222 bfd.ReportTailDown 224 Set to 1 if the head wishes tails to notify the head, via 225 periodic BFD Control packets, when they see the BFD session 226 fail. If 0, the tail will never send periodic BFD Control 227 packets, and the head will not be notified of session failures 228 by the tails. This variable MUST be initialized based on 229 configuration. 231 This variable is only pertinent when bfd.SessionType is 232 MultipointHead or MultipointClient. 234 bfd.UnicastRcvd 236 Set to 1 if a tail receives a unicast BFD Control packet from 237 the head. This variable MUST be set to zero if the session 238 transitions from Up state to some other state. 240 This variable MUST be initialized to zero. 242 This variable is only pertinent when Bfd.SessionType is 243 MultipointTail. 245 3.3.2. State Variable Initialization and Maintenance 247 Some state variables defined in section 6.8.1 of the [RFC5880] needs 248 to be initialized or manipulated differently depending on the session 249 type (see section 4.4.2 of [I-D.ietf-bfd-multipoint]). 251 bfd.LocalDiscr 253 For session type MultipointClient, this variable MUST always 254 match the value of bfd.LocalDiscr in the associated 255 MultipointHead session. 257 bfd.DesiredMinTxInterval 259 For session type MultipointClient, this variable MUST always 260 match the value of bfd.DesiredMinTxInterval in the associated 261 MultipointHead session. 263 bfd.RequiredMinRxInterval 265 It should be noted that for sessions of type MultipointTail, 266 this variable only affects the rate of unicast Polls sent by 267 the head; the rate of multipoint packets is necessarily 268 unaffected by it. 270 bfd.DemandMode 272 This variable MUST be initialized to 1 for session types 273 MultipointClient. 275 bfd.DetectMult 277 For session type MultipointClient, this variable MUST always 278 match the value of bfd.DetectMult in the associated 279 MultipointHead session. 281 3.4. Controlling Multipoint BFD Options 283 The state variables defined above are used to choose which 284 operational options are active. 286 The most basic form of operation as explained in 287 [I-D.ietf-bfd-multipoint], in which BFD Control packets flow only 288 from the head and no tracking is desired of tail state at the head, 289 is accomplished by setting bfd.ReportTailDown to 0 in the 290 MultipointHead session. 292 If the head wishes to know the identity of the tails, it sends 293 multipoint Polls as needed. Previously known tails that don't 294 respond to the Polls will be detected. 296 If the head wishes to be notified by the tails when they lose 297 connectivity, it sets bfd.ReportTailDown to 1 in either the 298 MultipointHead session (if such notification is desired from all 299 tails) or in the MultipointClient session (if notification is desired 300 from a particular tail.) Note that the setting of this variable in a 301 MultipointClient session for a particular tail overrides the setting 302 in the MultipointHead session. 304 If the head wishes to verify the state of a tail on an ongoing basis, 305 it sends a Poll Sequence from the MultipointClient session associated 306 with that tail as needed. 308 If the head wants to more quickly be alerted to a session failure 309 from a particular tail, it sends a BFD Control packet from the 310 MultipointClient session associated with that tail. This has the 311 effect of eliminating the initial delay that the tail would otherwise 312 insert prior to transmission of the packet. 314 If a tail wishes to operate silently (sending no BFD Control packets 315 to the head) it sets bfd.SilentTail to 1 in the MultipointTail 316 session. This allows a tail to be silent independent of the settings 317 on the head. 319 3.5. State Machine 321 State machine for session of type MultipointClient is same as defined 322 in section 4.5 of [I-D.ietf-bfd-multipoint]. 324 3.6. Session Establishment 326 If BFD Control packets are received at the head, they are 327 demultiplexed to sessions of type MultipointClient, which represent 328 the set of tails that the head is interested in tracking. These 329 sessions will typically also be established dynamically based on the 330 receipt of BFD Control packets. The head has broad latitude in 331 choosing which tails to track, if any, without affecting the basic 332 operation of the protocol. The head directly controls whether or not 333 tails are allowed to send BFD Control packets back to the head. 335 3.7. Discriminators and Packet Demultiplexing 337 When the tails send BFD Control packets to the head from the 338 MultipointTail session, the contents of Your Discr (the discriminator 339 received from the head) will not be sufficient for the head to 340 demultiplex the packet, since the same value will be received from 341 all tails on the multicast tree. In this case, the head MUST 342 demultiplex packets based on the source address and the value of Your 343 Discr, which together uniquely identify the tail and the multipoint 344 path. 346 When the head sends unicast BFD Control packets to a tail from a 347 MultipointClient session, the value of Your Discr will be valid, and 348 the tail MUST demultiplex the packet based solely on Your Discr. 350 3.8. Controlling Tail Packet Transmission 352 As the fan-in from the tails to the head may be very large, it is 353 critical that the flow of BFD Control packets from the tails is 354 controlled. 356 The head always operates in Demand mode. This means that no tail 357 will send an asynchronous BFD Control packet as long as the session 358 is Up. 360 The value of Required Min Rx Interval received by a tail in a unicast 361 BFD Control packet, if any, always takes precedence over the value 362 received in Multipoint BFD Control packets. This allows the packet 363 rate from individual tails to be controlled separately as desired by 364 sending a BFD Control packet from the corresponding MultipointClient 365 session. This also eliminates the random delay prior to transmission 366 from the tail that would otherwise be inserted, reducing the latency 367 of reporting a failure to the head. 369 If the head wishes to suppress traffic from the tails when they 370 detect a session failure, it MAY set bfd.RequiredMinRxInterval to 371 zero, which is a reserved value that indicates that the sender wishes 372 to receive no periodic traffic. This can be set in the 373 MultipointHead session (suppressing traffic from all tails) or it can 374 be set in a MultipointClient session (suppressing traffic from only a 375 single tail.) 376 Any tail may be provisioned to never send *any* BFD Control packets 377 to the head by setting bfd.SilentTail to 1. This provides a 378 mechanism by which only a subset of tails report their session status 379 to the head. 381 3.9. Soliciting the Tails 383 If the head wishes to know the identities of the tails, the 384 MultipointHead session MAY send a BFD Control packet as specified in 385 Section 3.13.3, with the Poll (P) bit set to 1. This will cause all 386 of the tails to reply with a unicast BFD Control Packet, randomized 387 across one packet interval. 389 The decision as to when to send a multipoint Poll is outside the 390 scope of this specification. However, it must never be sent more 391 often than the regular multipoint BFD Control packet. Since the tail 392 will treat a multipoint Poll like any other multipoint BFD Control 393 packet, Polls may be sent in lieu of non-Poll packets. 395 Soliciting the tails also starts the Detection Timer for each 396 associated MultipointClient session, which will cause those sessions 397 to time out if the associated tails do not respond. 399 Note that for this mechanism to work properly, the Detection Time 400 (which is equal to bfd.DesiredMinTxInterval) MUST be greater than the 401 round trip time of BFD Control packets from the head to the tail (via 402 the multipoint path) and back (via a unicast path.) See Section 3.11 403 for more details. 405 3.10. Verifying Connectivity to Specific Tails 407 If the head wishes to verify connectivity to a specific tail, the 408 corresponding MultipointClient session MAY send a BFD Poll Sequence 409 to said tail. This might be done in reaction to the expiration of 410 the Detection Timer (the tail didn't respond to a multipoint Poll), 411 or it might be done on a proactive basis. 413 The interval between transmitted packets in the Poll Sequence MUST be 414 calculated as specified in the base specification (the greater of 415 bfd.DesiredMinTxInterval and bfd.RemoteMinRxInterval.) 417 The value transmitted in Required Min RX Interval will be used by the 418 tail (rather than the value received in any multipoint packet) when 419 it transmits BFD Control packets to the head notifying it of a 420 session failure, and the transmitted packets will not be delayed. 421 This value can potentially be set much lower than in the multipoint 422 case, in order to speed up notification to the head, since the value 423 will be used only by the single tail. This value (and the lack of 424 delay) are "sticky", in that once the tail receives it, it will 425 continue to use it indefinitely. Therefore, if the head no longer 426 wishes to single out the tail, it SHOULD reset the timer to the 427 default by sending a Poll Sequence with the same value of Required 428 Min Rx Interval as is carried in the multipoint packets, or it MAY 429 reset the tail session by sending a Poll Sequence with state 430 AdminDown (after the completion of which the session will come back 431 up.) 433 Note that a failure of the head to receive a response to a Poll 434 Sequence does not necessarily mean that the tail has lost multipoint 435 connectivity, though a reply to a Poll Sequence does reliably 436 indicate connectivity or lack thereof (by virtue of the tail's state 437 not being Up in the BFD Control packet.) 439 3.11. Detection Times 441 MultipointClient sessions at the head are always in Demand mode, and 442 as such only care about detection time in two cases. First, if a 443 Poll Sequence is being sent on a MultipointClient session, the 444 detection time on this session is calculated according to the base 445 specification, that is, the transmission interval multiplied by 446 bfd.DetectMult. Second, when a multipoint Poll is sent to solicit 447 tail replies, the detection time on all associated MultipointClient 448 sessions that aren't currently sending Poll Sequences is set to a 449 value greater than or equal to bfd.RequiredMinRxInterval (one packet 450 time.) This value can be made arbitrarily large in order to ensure 451 that the detection time is greater than the BFD round trip time 452 between the head and the tail with no ill effects, other than 453 delaying the detection of unresponsive tails. Note that a detection 454 time expiration on a MultipointClient session at the head, while 455 indicating a BFD session failure, cannot be construed to mean that 456 the tail is not hearing multipoint packets from the head. 458 3.12. MultipointClient Down/AdminDown Sessions 460 If the MultipointHead session is going down (which only happens 461 administratively), all associated MultipointClient sessions SHOULD be 462 destroyed as they are superfluous. 464 If a MultipointClient session goes down due to the receipt of an 465 unsolicited BFD Control packet from the tail with state Down or 466 AdminDown (not in response to a Poll), and tail connectivity 467 verification is not being done, the session MAY be destroyed. If 468 verification is desired, the session SHOULD send a Poll Sequence and 469 the session SHOULD be maintained. 471 If the tail replies to a Poll Sequence with state Down or AdminDown, 472 it means that the tail session is definitely down. In this case, the 473 session MAY be destroyed. 475 If the Detection Time expires on a MultipointClient session (meaning 476 that the tail did not reply to a Poll Sequence) the session MAY be 477 destroyed. 479 3.13. Base Specification Text Replacement 481 The following sections are meant to replace the corresponding 482 sections in the base specification. 484 3.13.1. Reception of BFD Control Packets 486 The following procedure replaces section 6.8.6 of [RFC5880]. 488 When a BFD Control packet is received, procedure defined in section 489 4.13.1 of [I-D.ietf-bfd-multipoint] MUST be followed, in the order 490 specified. If the packet is discarded according to these rules, 491 processing of the packet MUST cease at that point. In addition to 492 that if tail tracking is desired by head below procedure MUST be 493 applied. 495 If bfd.SessionType is MultipointTail 497 If bfd.UnicastRcvd is 0 or the M bit is clear, set 498 bfd.RemoteMinRxInterval to the value of Required Min RX 499 Interval. 501 If the M bit is clear, set bfd.UnicastRcvd to 1. 503 Else (not MultipointTail) 505 Set bfd.RemoteMinRxInterval to the value of Required Min RX 506 Interval. 508 If the Poll (P) bit is set, and bfd.SilentTail is zero, send a BFD 509 Control packet to the remote system with the Poll (P) bit clear, 510 and the Final (F) bit set (see Section 3.13.3.) 512 3.13.2. Demultiplexing BFD Control Packets 514 This section is part of the replacement for [RFC5880] section 6.8.6 515 and addition to section 4.13.2 of [I-D.ietf-bfd-multipoint], 516 separated for clarity. 518 If Multipoint (M) bit is clear 519 If the Your Discriminator field is nonzero 521 Select a session based on the value of Your Discriminator. 522 If no session is found, the packet MUST be discarded. 524 If bfd.SessionType is MulticastHead 526 Find a MultipointClient session grouped to this 527 MulticastHead session, based on the source address and 528 the value of Your Discriminator. If a session is found 529 and is not MulticastClient, the packet MUST be discarded. 530 If no session is found, a new session of type 531 MultipointClient MAY be created, or the packet MAY be 532 discarded. This choice is outside the scope of this 533 specification. 535 If bfd.SessionType is not MulticastClient, the packet 536 MUST be discarded. 538 3.13.3. Transmitting BFD Control Packets 540 The following procedure replaces section 6.8.7 of [RFC5880]. 542 A system MUST NOT periodically transmit BFD Control packets if 543 bfd.SessionType is MulticastClient and a Poll Sequence is not being 544 transmitted. 546 If bfd.SessionType is MulticastTail and periodic transmission of BFD 547 Control packets is just starting (due to Demand mode not being active 548 on the remote system), the first packet to be transmitted MUST be 549 delayed by a random amount of time between zero and (0.9 * 550 bfd.RemoteMinRxInterval). 552 If a BFD Control packet is received with the Poll (P) bit set to 1, 553 the receiving system MUST transmit a BFD Control packet with the Poll 554 (P) bit clear and the Final (F) bit, without respect to the 555 transmission timer or any other transmission limitations, without 556 respect to the session state, and without respect to whether Demand 557 mode is active on either system. A system MAY limit the rate at 558 which such packets are transmitted. If rate limiting is in effect, 559 the advertised value of Desired Min TX Interval MUST be greater than 560 or equal to the interval between transmitted packets imposed by the 561 rate limiting function. If the Multipoint (M) bit is set in the 562 received packet, the packet transmission MUST be delayed by a random 563 amount of time between zero and (0.9 * bfd.RemoteMinRxInterval). 564 Otherwise, the packet MUST be transmitted as soon as practicable. 566 A system MUST NOT set the Demand (D) bit if bfd.SessionType is 567 MultipointClient unless bfd.DemandMode is 1, bfd.SessionState is Up, 568 and bfd.RemoteSessionState is Up. 570 Contents of transmitted packet MUST be as explained in section 4.13.3 571 of [I-D.ietf-bfd-multipoint]. 573 4. Assumptions 575 If head notification is to be used, it is assumed that a multipoint 576 BFD packet encapsulation contains enough information so that a tail 577 can address a unicast BFD packet to the head. 579 If head notification is to be used, it is assumed that is that there 580 is bidirectional unicast communication available (at the same 581 protocol layer within which BFD is being run) between the tail and 582 head. 584 For the head to know reliably that a tail has lost multipoint 585 connectivity, the unicast paths in both directions between that tail 586 and the head must remain operational when the multipoint path fails. 587 It is thus desirable that unicast paths not share fate with the 588 multipoint path to the extent possible if the head wants reliable 589 knowledge of tail state. 591 Since the normal BFD three-way handshake is not used in this 592 application, a tail transitioning from state Up to Down and back to 593 Up again may not be reliably detected at the head. 595 5. Operational Scenarios 597 It is worth analyzing how this protocol reacts to various scenarios. 598 There are three path components present, namely, the multipoint path, 599 the forward unicast path (from head to a particular tail), and the 600 reverse unicast path (from a tail to the head.) There are also four 601 options as to how the head is notified about failures from the tail. 603 5.1. No Head Notification 605 Since the only path used in this scenario is the multipoint path, 606 none of the others matter. A failure in the multipoint path will 607 result in the tail noticing the failure within a detection time, and 608 the head will remain ignorant of the tail state. 610 5.2. Unreliable Head Notification 612 In this scenario, the tail sends back unsolicicted BFD packets in 613 response to the detection of a multipoint path failure. It uses the 614 reverse unicast path, but not the forward unicast path. 616 If the multipoint path fails but the reverse unicast path stays up, 617 the tail will detect the failure within a detection time, and the 618 head will know about it within one reverse packet time (since the 619 notification is delayed.) 621 If both the multipoint path and the reverse unicast paths fail, the 622 tail will detect the failure but the head will remain unaware of it. 624 5.3. Semi-reliable Head Notification and Tail Solicitation 626 In this scenario, the head sends occasional multipoint Polls in 627 addition to (or in lieu of) non-Poll multipoint BFD Control packets, 628 expecting the tails to reply with Final. This also uses the reverse 629 unicast path, but not the forward unicast path. 631 If the multipoint path fails but the reverse unicast path stays up, 632 the tail will detect the failure within a detection time, and the 633 head will know about it within one reverse packet time (the 634 notification is delayed to avoid synchronization of the tails.) 636 If both the multipoint path and the reverse unicast paths fail, the 637 tail will detect the failure but the head will remain unaware of this 638 fact. 640 If the reverse unicast path fails but the multipoint path stays up, 641 the head will see the BFD session fail, but the state of the 642 multipoint path will be unknown to the head. The tail will continue 643 to receive multipoint data traffic. 645 If either the multipoint Poll or the unicast reply is lost in 646 transit, the head will see the BFD session fail, but the state of the 647 multipoint path will be unknown to the head. The tail will continue 648 to receive multipoint data traffic. 650 5.4. Reliable Head Notification 652 In this scenario, the head sends occasional multipoint Polls in 653 addition to (or in lieu of) non-Poll multipoint BFD control packets, 654 expecting the tails to reply with Final. If a tail that had 655 previously replied to a multipoint Poll fails to reply (or if the 656 head simply wishes to verify tail connectivity,) the head issues a 657 unicast Poll Sequence to the tail. This scenario makes use of all 658 three paths. 660 If the multipoint path fails but the two unicast paths stay up, the 661 tail will detect the failure within a detection time, and the head 662 will know about it within one reverse packet time (since the 663 notification is delayed.) Note that the reverse packet time may be 664 smaller in this case if the head has previously issued a unicast Poll 665 (since the tail will not delay transmission of the notification in 666 this case.) 668 If both the multipoint path and the reverse unicast paths fail 669 (regardless of the state of the forward unicast path), the tail will 670 detect the failure but the head will remain unaware of this fact. 671 The head will detect a BFD session failure to the tail but cannot 672 make a determination about the state of the tail's multipoint 673 connectivity. 675 If the forward unicast path fails but the reverse unicast path stays 676 up, the head will detect a BFD session failure to the tail if it 677 happens to send a unicast Poll sequence, but cannot make a 678 determination about the state of the tail's multipoint connectivity. 679 If the multipoint path to the tail fails prior to any unicast Poll 680 being sent, the tail will detect the failure within a detection time, 681 and the head will know about it within one reverse packet time (since 682 the notification is delayed.) 684 If the multipoint path stays up but the reverse unicast path fails, 685 the head will see the BFD session fail if it happens to send a Poll 686 Sequence, but the state of the multipoint path will be unknown to the 687 head. The tail will continue to receive multipoint data traffic. 689 If the multipoint path and the reverse unicast path both stay up but 690 the forward unicast path fails, neither side will notice so long as a 691 unicast Poll Sequence is never sent by the head. If the head sends a 692 unicast Poll Sequence, the head will see the BFD session fail, but 693 the state of the multipoint path will be unknown to the head. The 694 tail will continue to receive multipoint data traffic. 696 6. IANA Considerations 698 This document has no actions for IANA. 700 7. Security Considerations 702 This specification does not raise any additional security issues 703 beyond those of the specifications referred to in the list of 704 normative references. 706 8. Contributors 708 Rahul Aggarwal of Juniper Networks and George Swallow of Cisco 709 Systems provided the initial idea for this specification and 710 contributed to its development. 712 9. Acknowledgements 714 Authors would also like to thank Nobo Akiya, Vengada Prasad Govindan, 715 Jeff Haas, Wim Henderickx, Gregory Mirsky and Mingui Zhang who have 716 greatly contributed to this document. 718 10. Normative References 720 [I-D.ietf-bfd-multipoint] 721 Katz, D., Ward, D., and J. Networks, "BFD for Multipoint 722 Networks", draft-ietf-bfd-multipoint-09 (work in 723 progress), October 2016. 725 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 726 Requirement Levels", BCP 14, RFC 2119, 727 DOI 10.17487/RFC2119, March 1997, 728 . 730 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 731 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 732 . 734 Authors' Addresses 736 Dave Katz 737 Juniper Networks 738 1194 N. Mathilda Ave. 739 Sunnyvale, California 94089-1206 740 USA 742 Email: dkatz@juniper.net 744 Dave Ward 745 Cisco Systems 746 170 West Tasman Dr. 747 San Jose, California 95134 748 USA 750 Email: wardd@cisco.com 751 Santosh Pallagatti (editor) 752 Individual Contributor 753 Embassy Business Park 754 Bangalore, KA 560093 755 India 757 Email: santosh.pallagatti@gmail.com