idnits 2.17.1 draft-ietf-bfd-multipoint-active-tail-06.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 (December 19, 2017) is 2319 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-11 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: June 22, 2018 Cisco Systems 6 S. Pallagatti, Ed. 7 Individual Contributor 8 G. Mirsky, Ed. 9 ZTE Corp. 10 December 19, 2017 12 BFD Multipoint Active Tails. 13 draft-ietf-bfd-multipoint-active-tail-06 15 Abstract 17 This document describes active tail extensions to the Bidirectional 18 Forwarding Detection (BFD) protocol for multipoint and multicast 19 networks. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 25 "OPTIONAL" in this document are to be interpreted as described in BCP 26 14 [RFC2119] [RFC8174] when, and only when, they appear in all 27 capitals, as shown here. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on June 22, 2018. 46 Copyright Notice 48 Copyright (c) 2017 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 4 66 3.1. Multipoint Client Session . . . . . . . . . . . . . . . . 4 67 3.2. Multipoint Client Session Failure . . . . . . . . . . . . 5 68 3.3. State Variables . . . . . . . . . . . . . . . . . . . . . 5 69 3.3.1. New State Variables . . . . . . . . . . . . . . . . . 5 70 3.3.2. State Variable Initialization and Maintenance . . . . 6 71 3.4. Controlling Multipoint BFD Options . . . . . . . . . . . 7 72 3.5. State Machine . . . . . . . . . . . . . . . . . . . . . . 8 73 3.6. Session Establishment . . . . . . . . . . . . . . . . . . 8 74 3.7. Discriminators and Packet Demultiplexing . . . . . . . . 8 75 3.8. Controlling Tail Packet Transmission . . . . . . . . . . 8 76 3.9. Soliciting the Tails . . . . . . . . . . . . . . . . . . 9 77 3.10. Verifying Connectivity to Specific Tails . . . . . . . . 9 78 3.11. Detection Times . . . . . . . . . . . . . . . . . . . . . 10 79 3.12. MultipointClient Down/AdminDown Sessions . . . . . . . . 11 80 3.13. Base BFD Specification Text Replacement . . . . . . . . . 11 81 3.13.1. Reception of BFD Control Packets . . . . . . . . . . 11 82 3.13.2. Demultiplexing BFD Control Packets . . . . . . . . . 12 83 3.13.3. Transmitting BFD Control Packets . . . . . . . . . . 12 84 4. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 13 85 5. Operational Scenarios . . . . . . . . . . . . . . . . . . . . 13 86 5.1. No Head Notification . . . . . . . . . . . . . . . . . . 14 87 5.2. Unreliable Head Notification . . . . . . . . . . . . . . 14 88 5.3. Semi-reliable Head Notification and Tail Solicitation . . 14 89 5.4. Reliable Head Notification . . . . . . . . . . . . . . . 15 90 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 91 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 92 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 93 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 94 10. Normative References . . . . . . . . . . . . . . . . . . . . 16 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 97 1. Introduction 99 This application of BFD is an extension to Multipoint BFD 100 [I-D.ietf-bfd-multipoint], which allows tail to unreliably notify the 101 head of the lack of multipoint connectivity. As a further option, 102 this notification can be made reliable. Notification to the head can 103 be enabled for all tails, or for only a subset of the tails. 105 Multipoint BFD base document [I-D.ietf-bfd-multipoint] describes 106 procedures to verify only the head-to-tail connectivity over the 107 multipoint path. Although it may use unicast paths in both 108 directions, Multipoint BFD does not verify those paths (and in fact 109 it is preferable if unicast paths share as little fate with the 110 multipoint path as is feasible.) 112 Goal of this application is for the head to reasonably rapidly have 113 knowledge of tails that have lost connectivity from the head. 115 Since scaling is a primary concern (particularly state implosion 116 toward the head), it is required that the head be in control of all 117 timing aspects of the mechanism, and that BFD packets from the tails 118 to the head not be synchronized. 120 Throughout this document, the term "multipoint" is defined as a 121 mechanism by which one or more systems receive packets sent by a 122 single sender. This specifically includes such things as IP 123 multicast and point-to-multipoint MPLS. 125 Term "connectivity" in this document is not being used in context of 126 connectivity verification in transport network but as an alternative 127 to "continuity", i.e. existence of a path between the sender and the 128 receiver. 130 This document effectively modifies and adds to the base BFD 131 specification [RFC5880] and base BFD multipoint document 132 [I-D.ietf-bfd-multipoint]. 134 2. Overview 136 Head may wish to be alerted to the tails' connectivity (or lack 137 thereof), there are a number of options. First, if all that is 138 needed is an unreliable failure notification, the head can direct the 139 tails to transmit unicast BFD Control packets back to the head when 140 the path fails. 142 If the head wishes to know the identity of the tails on the 143 multipoint path, it may solicit membership by sending a multipoint 144 BFD Control packet with the Poll (P) bit set, which will induce the 145 tails to return a unicast BFD Control packet with the Final (F) bit 146 set. The head can then create BFD session state for each of the 147 tails that have multipoint connectivity. If the head sends such a 148 packet on occasion, it can keep track of which tails answer, thus 149 providing a somewhat reliable mechanism for detecting which tails 150 fail to respond (implying a loss of multipoint connectivity.) 152 If the head wishes a reliable indication of the tails' connectivity, 153 it may do all of the above, but if it detects that a tail did not 154 answer the previous multipoint poll, it may initiate a Demand mode 155 Poll Sequence as a unicast to the tail. This covers the case where 156 either the multipoint poll or the single reply thereto is lost in 157 transit. If desired, the head may Poll one or more tails proactively 158 to track the tails' connectivity. 160 If some tails are more equal than others, in the sense that the head 161 needs to detect the lack of multipoint connectivity to a subset of 162 tails at a different rate, the head may transmit unicast BFD Polls to 163 that subset of tails. In this case, the timing may be independent on 164 a tail-by-tail basis. 166 Individual tails may be configured so that they never send BFD 167 control packets to the head, even when the head wishes notification 168 of path failure from the tail. Such tails will never be known to the 169 head, but will still be able to detect multipoint path failures from 170 the head. 172 3. Protocol Details 174 This section describes the operation of BFD Multipoint active tail in 175 detail. This section is update to section 4 of 176 [I-D.ietf-bfd-multipoint]. 178 3.1. Multipoint Client Session 180 If the head is keeping track of some or all of the tails, it has a 181 session of type MultipointClient per tail that it cares about. All 182 of the MultipointClient sessions for tails on a particular multipoint 183 path are grouped with the MultipointHead session to which the clients 184 are listening. A BFD Poll Sequence may be sent over such a session 185 to a tail if the head wishes to verify connectivity. These sessions 186 receive any BFD Control packets sent by the tails, and never transmit 187 periodic BFD Control packets other than Poll Sequences (since 188 periodic transmission is always done by the MultipointHead session.) 190 3.2. Multipoint Client Session Failure 192 If a MultipointClient session receives a BFD Control packet from the 193 tail with state Down or AdminDown, the head reliably knows that the 194 tail has lost multipoint connectivity. If the Detection Time expires 195 on a MultipointClient session, it is ambiguous as to whether the 196 multipoint connectivity failed or whether there was a unicast path 197 problem in one direction or the other, so the head does not reliably 198 know the tail state. 200 3.3. State Variables 202 BFD Multipoint active tail introduces new state variables and 203 modifies the usage of a few existing ones defined in section 4.4 of 204 [I-D.ietf-bfd-multipoint]. 206 3.3.1. New State Variables 208 Few state variables are added and modified support of Multipoint BFD 209 active tail. 211 bfd.SessionType 213 The type of this session as defined in [RFC7880]. A new value 214 introduced is: 216 MultipointClient: A session on the head that tracks the 217 state of an individual tail, when desirable. 219 This variable MUST be initialized to the appropriate type when 220 the session is created, according to the rules in section 4.13 221 of [I-D.ietf-bfd-multipoint]. 223 bfd.SilentTail 225 If 0, a tail may send packets to the head according to other 226 parts of this specification. Setting this to 1 allows tails to 227 be provisioned to always be silent, even when the head is 228 soliciting traffic from the tails. This can be useful, for 229 example, in deployments of a large number of tails when the 230 head wishes to track the state of a subset of them. This 231 variable MUST be initialized based on configuration. 233 This variable is only pertinent when bfd.SessionType is 234 MultipointTail. 236 bfd.ReportTailDown 237 Set to 1 if the head wishes tails to notify the head, via 238 periodic BFD Control packets, when they see the BFD session 239 fail. If 0, the tail will never send periodic BFD Control 240 packets, and the head will not be notified of session failures 241 by the tails. This variable MUST be initialized based on 242 configuration. 244 This variable is only pertinent when bfd.SessionType is 245 MultipointHead or MultipointClient. 247 bfd.UnicastRcvd 249 Set to 1 if a tail receives a unicast BFD Control packet from 250 the head. This variable MUST be set to zero if the session 251 transitions from Up state to some other state. 253 This variable MUST be initialized to zero. 255 This variable is only pertinent when Bfd.SessionType is 256 MultipointTail. 258 3.3.2. State Variable Initialization and Maintenance 260 Some state variables defined in section 6.8.1 of the [RFC5880] needs 261 to be initialized or manipulated differently depending on the session 262 type (see section 4.4.2 of [I-D.ietf-bfd-multipoint]). 264 bfd.LocalDiscr 266 For session type MultipointClient, this variable MUST always 267 match the value of bfd.LocalDiscr in the associated 268 MultipointHead session. 270 bfd.DesiredMinTxInterval 272 For session type MultipointClient, this variable MUST always 273 match the value of bfd.DesiredMinTxInterval in the associated 274 MultipointHead session. 276 bfd.RequiredMinRxInterval 278 It should be noted that for sessions of type MultipointTail, 279 this variable only affects the rate of unicast Polls sent by 280 the head; the rate of multipoint packets is necessarily 281 unaffected by it. 283 bfd.DemandMode 284 This variable MUST be initialized to 1 for session types 285 MultipointClient. 287 bfd.DetectMult 289 For session type MultipointClient, this variable MUST always 290 match the value of bfd.DetectMult in the associated 291 MultipointHead session. 293 3.4. Controlling Multipoint BFD Options 295 The state variables defined above are used to choose which 296 operational options are active. 298 The most basic form of operation as explained in 299 [I-D.ietf-bfd-multipoint], in which BFD Control packets flow only 300 from the head and no tracking is desired of tail state at the head, 301 is accomplished by setting bfd.ReportTailDown to 0 in the 302 MultipointHead session. 304 If the head wishes to know the identity of the tails, it sends 305 multipoint Polls as needed. Previously known tails that don't 306 respond to the Polls will be detected. 308 If the head wishes to be notified by the tails when they lose 309 connectivity, it sets bfd.ReportTailDown to 1 in either the 310 MultipointHead session (if such notification is desired from all 311 tails) or in the MultipointClient session (if notification is desired 312 from a particular tail.) Note that the setting of this variable in a 313 MultipointClient session for a particular tail overrides the setting 314 in the MultipointHead session. 316 If the head wishes to verify the state of a tail on an ongoing basis, 317 it sends a Poll Sequence from the MultipointClient session associated 318 with that tail as needed. 320 If the head wants to more quickly be alerted to a session failure 321 from a particular tail, it sends a BFD Control packet from the 322 MultipointClient session associated with that tail. This has the 323 effect of eliminating the initial delay that the tail would otherwise 324 insert prior to transmission of the packet. 326 If a tail wishes to operate silently (sending no BFD Control packets 327 to the head) it sets bfd.SilentTail to 1 in the MultipointTail 328 session. This allows a tail to be silent independent of the settings 329 on the head. 331 3.5. State Machine 333 State machine for session of type MultipointClient is same as defined 334 in section 4.5 of [I-D.ietf-bfd-multipoint]. 336 3.6. Session Establishment 338 If BFD Control packets are received at the head, they are 339 demultiplexed to sessions of type MultipointClient, which represent 340 the set of tails that the head is interested in tracking. These 341 sessions will typically also be established dynamically based on the 342 receipt of BFD Control packets. The head has broad latitude in 343 choosing which tails to track, if any, without affecting the basic 344 operation of the protocol. The head directly controls whether or not 345 tails are allowed to send BFD Control packets back to the head. 347 3.7. Discriminators and Packet Demultiplexing 349 When the tails send BFD Control packets to the head from the 350 MultipointTail session, the contents of Your Discr (the discriminator 351 received from the head) will not be sufficient for the head to 352 demultiplex the packet, since the same value will be received from 353 all tails on the multicast tree. In this case, the head MUST 354 demultiplex packets based on the source address and the value of Your 355 Discr, which together uniquely identify the tail and the multipoint 356 path. 358 When the head sends unicast BFD Control packets to a tail from a 359 MultipointClient session, the value of Your Discr will be valid, and 360 the tail MUST demultiplex the packet based solely on Your Discr. 362 3.8. Controlling Tail Packet Transmission 364 As the fan-in from the tails to the head may be very large, it is 365 critical that the flow of BFD Control packets from the tails is 366 controlled. 368 The head always operates in Demand mode. This means that no tail 369 will send an asynchronous BFD Control packet as long as the session 370 is Up. 372 The value of Required Min Rx Interval received by a tail in a unicast 373 BFD Control packet, if any, always takes precedence over the value 374 received in Multipoint BFD Control packets. This allows the packet 375 rate from individual tails to be controlled separately as desired by 376 sending a BFD Control packet from the corresponding MultipointClient 377 session. This also eliminates the random delay prior to transmission 378 from the tail that would otherwise be inserted, reducing the latency 379 of reporting a failure to the head. 381 If the head wishes to suppress traffic from the tails when they 382 detect a session failure, it MAY set bfd.RequiredMinRxInterval to 383 zero, which is a reserved value that indicates that the sender wishes 384 to receive no periodic traffic. This can be set in the 385 MultipointHead session (suppressing traffic from all tails) or it can 386 be set in a MultipointClient session (suppressing traffic from only a 387 single tail.) 389 Any tail may be provisioned to never send *any* BFD Control packets 390 to the head by setting bfd.SilentTail to 1. This provides a 391 mechanism by which only a subset of tails report their session status 392 to the head. 394 3.9. Soliciting the Tails 396 If the head wishes to know the identities of the tails, the 397 MultipointHead session MAY send a BFD Control packet as specified in 398 Section 3.13.3, with the Poll (P) bit set to 1. This will cause all 399 of the tails to reply with a unicast BFD Control Packet, randomized 400 across one packet interval. 402 The decision as to when to send a multipoint Poll is outside the 403 scope of this specification. However, it must never be sent more 404 often than the regular multipoint BFD Control packet. Since the tail 405 will treat a multipoint Poll like any other multipoint BFD Control 406 packet, Polls may be sent in lieu of non-Poll packets. 408 Soliciting the tails also starts the Detection Timer for each 409 associated MultipointClient session, which will cause those sessions 410 to time out if the associated tails do not respond. 412 Note that for this mechanism to work properly, the Detection Time 413 (which is equal to bfd.DesiredMinTxInterval) MUST be greater than the 414 round trip time of BFD Control packets from the head to the tail (via 415 the multipoint path) and back (via a unicast path.) See Section 3.11 416 for more details. 418 3.10. Verifying Connectivity to Specific Tails 420 If the head wishes to verify connectivity to a specific tail, the 421 corresponding MultipointClient session MAY send a BFD Poll Sequence 422 to said tail. This might be done in reaction to the expiration of 423 the Detection Timer (the tail didn't respond to a multipoint Poll), 424 or it might be done on a proactive basis. 426 The interval between transmitted packets in the Poll Sequence MUST be 427 calculated as specified in the base BFD specification [RFC5880] (the 428 greater of bfd.DesiredMinTxInterval and bfd.RemoteMinRxInterval.) 430 The value transmitted in Required Min RX Interval will be used by the 431 tail (rather than the value received in any multipoint packet) when 432 it transmits BFD Control packets to the head notifying it of a 433 session failure, and the transmitted packets will not be delayed. 434 This value can potentially be set much lower than in the multipoint 435 case, in order to speed up notification to the head, since the value 436 will be used only by the single tail. This value (and the lack of 437 delay) are "sticky", in that once the tail receives it, it will 438 continue to use it indefinitely. Therefore, if the head no longer 439 wishes to single out the tail, it SHOULD reset the timer to the 440 default by sending a Poll Sequence with the same value of Required 441 Min Rx Interval as is carried in the multipoint packets, or it MAY 442 reset the tail session by sending a Poll Sequence with state 443 AdminDown (after the completion of which the session will come back 444 up.) 446 Note that a failure of the head to receive a response to a Poll 447 Sequence does not necessarily mean that the tail has lost multipoint 448 connectivity, though a reply to a Poll Sequence does reliably 449 indicate connectivity or lack thereof (by virtue of the tail's state 450 not being Up in the BFD Control packet.) 452 3.11. Detection Times 454 MultipointClient sessions at the head are always in Demand mode, and 455 as such only care about detection time in two cases. First, if a 456 Poll Sequence is being sent on a MultipointClient session, the 457 detection time on this session is calculated according to the base 458 BFD specification [RFC5880], that is, the transmission interval 459 multiplied by bfd.DetectMult. Second, when a multipoint Poll is sent 460 to solicit tail replies, the detection time on all associated 461 MultipointClient sessions that aren't currently sending Poll 462 Sequences is set to a value greater than or equal to 463 bfd.RequiredMinRxInterval (one packet time.) This value can be made 464 arbitrarily large in order to ensure that the detection time is 465 greater than the round trip time of a BFD Control packet between the 466 head and the tail with no ill effects, other than delaying the 467 detection of unresponsive tails. Note that a detection time 468 expiration on a MultipointClient session at the head, while 469 indicating a BFD session failure, cannot be construed to mean that 470 the tail is not hearing multipoint packets from the head. 472 3.12. MultipointClient Down/AdminDown Sessions 474 If the MultipointHead session is going down (which only happens 475 administratively), all associated MultipointClient sessions SHOULD be 476 destroyed as they are superfluous. 478 If a MultipointClient session goes down due to the receipt of an 479 unsolicited BFD Control packet from the tail with state Down or 480 AdminDown (not in response to a Poll), and tail connectivity 481 verification is not being done, the session MAY be destroyed. If 482 verification is desired, the session SHOULD send a Poll Sequence and 483 the session SHOULD be maintained. 485 If the tail replies to a Poll Sequence with state Down or AdminDown, 486 it means that the tail session is definitely down. In this case, the 487 session MAY be destroyed. 489 If the Detection Time expires on a MultipointClient session (meaning 490 that the tail did not reply to a Poll Sequence) the session MAY be 491 destroyed. 493 3.13. Base BFD Specification Text Replacement 495 The following sections are meant to replace the corresponding 496 sections in the base specification. 498 3.13.1. Reception of BFD Control Packets 500 The following procedure replaces section 6.8.6 of [RFC5880]. 502 When a BFD Control packet is received, procedure defined in section 503 4.13.1 of [I-D.ietf-bfd-multipoint] MUST be followed, in the order 504 specified. If the packet is discarded according to these rules, 505 processing of the packet MUST cease at that point. In addition to 506 that if tail tracking is desired by head below procedure MUST be 507 applied. 509 If bfd.SessionType is MultipointTail 511 If bfd.UnicastRcvd is 0 or the M bit is clear, set 512 bfd.RemoteMinRxInterval to the value of Required Min RX 513 Interval. 515 If the M bit is clear, set bfd.UnicastRcvd to 1. 517 Else (not MultipointTail) 518 Set bfd.RemoteMinRxInterval to the value of Required Min RX 519 Interval. 521 If the Poll (P) bit is set, and bfd.SilentTail is zero, send a BFD 522 Control packet to the remote system with the Poll (P) bit clear, 523 and the Final (F) bit set (see Section 3.13.3.) 525 3.13.2. Demultiplexing BFD Control Packets 527 This section is part of the replacement for [RFC5880] section 6.8.6 528 and addition to section 4.13.2 of [I-D.ietf-bfd-multipoint], 529 separated for clarity. 531 If Multipoint (M) bit is clear 533 If the Your Discriminator field is nonzero 535 Select a session based on the value of Your Discriminator. 536 If no session is found, the packet MUST be discarded. 538 If bfd.SessionType is MulticastHead 540 Find a MultipointClient session grouped to this 541 MulticastHead session, based on the source address and 542 the value of Your Discriminator. If a session is found 543 and is not MulticastClient, the packet MUST be discarded. 544 If no session is found, a new session of type 545 MultipointClient MAY be created, or the packet MAY be 546 discarded. This choice is outside the scope of this 547 specification. 549 If bfd.SessionType is not MulticastClient, the packet 550 MUST be discarded. 552 3.13.3. Transmitting BFD Control Packets 554 The following procedure replaces section 6.8.7 of [RFC5880]. 556 A system MUST NOT periodically transmit BFD Control packets if 557 bfd.SessionType is MulticastClient and a Poll Sequence is not being 558 transmitted. 560 If bfd.SessionType is MulticastTail and periodic transmission of BFD 561 Control packets is just starting (due to Demand mode not being active 562 on the remote system), the first packet to be transmitted MUST be 563 delayed by a random amount of time between zero and (0.9 * 564 bfd.RemoteMinRxInterval). 566 If a BFD Control packet is received with the Poll (P) bit set to 1, 567 the receiving system MUST transmit a BFD Control packet with the Poll 568 (P) bit clear and the Final (F) bit, without respect to the 569 transmission timer or any other transmission limitations, without 570 respect to the session state, and without respect to whether Demand 571 mode is active on either system. A system MAY limit the rate at 572 which such packets are transmitted. If rate limiting is in effect, 573 the advertised value of Desired Min TX Interval MUST be greater than 574 or equal to the interval between transmitted packets imposed by the 575 rate limiting function. If the Multipoint (M) bit is set in the 576 received packet, the packet transmission MUST be delayed by a random 577 amount of time between zero and (0.9 * bfd.RemoteMinRxInterval). 578 Otherwise, the packet MUST be transmitted as soon as practicable. 580 A system MUST NOT set the Demand (D) bit if bfd.SessionType is 581 MultipointClient unless bfd.DemandMode is 1, bfd.SessionState is Up, 582 and bfd.RemoteSessionState is Up. 584 Contents of transmitted packet MUST be as explained in section 4.13.3 585 of [I-D.ietf-bfd-multipoint]. 587 4. Assumptions 589 If head notification is to be used, it is assumed that a multipoint 590 BFD packet encapsulation contains enough information so that a tail 591 can address a unicast BFD packet to the head. 593 If head notification is to be used, it is assumed that is that there 594 is bidirectional unicast communication available (at the same 595 protocol layer within which BFD is being run) between the tail and 596 head. 598 For the head to know reliably that a tail has lost multipoint 599 connectivity, the unicast paths in both directions between that tail 600 and the head must remain operational when the multipoint path fails. 601 It is thus desirable that unicast paths not share fate with the 602 multipoint path to the extent possible if the head wants reliable 603 knowledge of tail state. 605 Since the normal BFD three-way handshake is not used in this 606 application, a tail transitioning from state Up to Down and back to 607 Up again may not be reliably detected at the head. 609 5. Operational Scenarios 611 It is worth analyzing how this protocol reacts to various scenarios. 612 There are three path components present, namely, the multipoint path, 613 the forward unicast path (from head to a particular tail), and the 614 reverse unicast path (from a tail to the head.) There are also four 615 options as to how the head is notified about failures from the tail. 617 5.1. No Head Notification 619 Since the only path used in this scenario is the multipoint path, 620 none of the others matter. A failure in the multipoint path will 621 result in the tail noticing the failure within a detection time, and 622 the head will remain ignorant of the tail state. 624 5.2. Unreliable Head Notification 626 In this scenario, the tail sends back unsolicited BFD packets in 627 response to the detection of a multipoint path failure. It uses the 628 reverse 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 (since the 633 notification is delayed.) 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 it. 638 5.3. Semi-reliable Head Notification and Tail Solicitation 640 In this scenario, the head sends occasional multipoint Polls in 641 addition to (or in lieu of) non-Poll multipoint BFD Control packets, 642 expecting the tails to reply with Final. This also uses the reverse 643 unicast path, but not the forward unicast path. 645 If the multipoint path fails but the reverse unicast path stays up, 646 the tail will detect the failure within a detection time, and the 647 head will know about it within one reverse packet time (the 648 notification is delayed to avoid synchronization of the tails.) 650 If both the multipoint path and the reverse unicast paths fail, the 651 tail will detect the failure but the head will remain unaware of this 652 fact. 654 If the reverse unicast path fails but the multipoint path stays up, 655 the head will see the BFD session fail, but the state of the 656 multipoint path will be unknown to the head. The tail will continue 657 to receive multipoint data traffic. 659 If either the multipoint Poll or the unicast reply is lost in 660 transit, the head will see the BFD session fail, but the state of the 661 multipoint path will be unknown to the head. The tail will continue 662 to receive multipoint data traffic. 664 5.4. Reliable Head Notification 666 In this scenario, the head sends occasional multipoint Polls in 667 addition to (or in lieu of) non-Poll multipoint BFD control packets, 668 expecting the tails to reply with Final. If a tail that had 669 previously replied to a multipoint Poll fails to reply (or if the 670 head simply wishes to verify tail connectivity,) the head issues a 671 unicast Poll Sequence to the tail. This scenario makes use of all 672 three paths. 674 If the multipoint path fails but the two unicast paths stay up, the 675 tail will detect the failure within a detection time, and the head 676 will know about it within one reverse packet time (since the 677 notification is delayed.) Note that the reverse packet time may be 678 smaller in this case if the head has previously issued a unicast Poll 679 (since the tail will not delay transmission of the notification in 680 this case.) 682 If both the multipoint path and the reverse unicast paths fail 683 (regardless of the state of the forward unicast path), the tail will 684 detect the failure but the head will remain unaware of this fact. 685 The head will detect a BFD session failure to the tail but cannot 686 make a determination about the state of the tail's multipoint 687 connectivity. 689 If the forward unicast path fails but the reverse unicast path stays 690 up, the head will detect a BFD session failure to the tail if it 691 happens to send a unicast Poll sequence, but cannot make a 692 determination about the state of the tail's multipoint connectivity. 693 If the multipoint path to the tail fails prior to any unicast Poll 694 being sent, the tail will detect the failure within a detection time, 695 and the head will know about it within one reverse packet time (since 696 the notification is delayed.) 698 If the multipoint path stays up but the reverse unicast path fails, 699 the head will see the BFD session fail if it happens to send a Poll 700 Sequence, but the state of the multipoint path will be unknown to the 701 head. The tail will continue to receive multipoint data traffic. 703 If the multipoint path and the reverse unicast path both stay up but 704 the forward unicast path fails, neither side will notice so long as a 705 unicast Poll Sequence is never sent by the head. If the head sends a 706 unicast Poll Sequence, the head will see the BFD session fail, but 707 the state of the multipoint path will be unknown to the head. The 708 tail will continue to receive multipoint data traffic. 710 6. IANA Considerations 712 This document has no actions for IANA. 714 7. Security Considerations 716 This specification does not raise any additional security issues 717 beyond those of the specifications referred to in the list of 718 normative references. 720 8. Contributors 722 Rahul Aggarwal of Juniper Networks and George Swallow of Cisco 723 Systems provided the initial idea for this specification and 724 contributed to its development. 726 9. Acknowledgements 728 Authors would also like to thank Nobo Akiya, Vengada Prasad Govindan, 729 Jeff Haas, Wim Henderickx, Gregory Mirsky and Mingui Zhang who have 730 greatly contributed to this document. 732 10. Normative References 734 [I-D.ietf-bfd-multipoint] 735 Katz, D., Ward, D., and J. Networks, "BFD for Multipoint 736 Networks", draft-ietf-bfd-multipoint-11 (work in 737 progress), December 2017. 739 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 740 Requirement Levels", BCP 14, RFC 2119, 741 DOI 10.17487/RFC2119, March 1997, 742 . 744 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 745 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 746 . 748 [RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. 749 Pallagatti, "Seamless Bidirectional Forwarding Detection 750 (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, 751 . 753 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 754 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 755 May 2017, . 757 Authors' Addresses 759 Dave Katz 760 Juniper Networks 761 1194 N. Mathilda Ave. 762 Sunnyvale, California 94089-1206 763 USA 765 Email: dkatz@juniper.net 767 Dave Ward 768 Cisco Systems 769 170 West Tasman Dr. 770 San Jose, California 95134 771 USA 773 Email: wardd@cisco.com 775 Santosh Pallagatti (editor) 776 Individual Contributor 777 Embassy Business Park 778 Bangalore, KA 560093 779 India 781 Email: santosh.pallagatti@gmail.com 783 Greg Mirsky (editor) 784 ZTE Corp. 786 Email: gregimirsky@gmail.com