idnits 2.17.1 draft-ietf-bfd-multipoint-active-tail-07.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC5880, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC7880, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5880, updated by this document, for RFC5378 checks: 2004-07-13) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 21, 2018) is 2254 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-13 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). 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 Updates: 5880, 7880 (if approved) D. Ward 5 Intended status: Standards Track Cisco Systems 6 Expires: August 25, 2018 S. Pallagatti, Ed. 7 Individual Contributor 8 G. Mirsky, Ed. 9 ZTE Corp. 10 February 21, 2018 12 BFD Multipoint Active Tails. 13 draft-ietf-bfd-multipoint-active-tail-07 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 August 25, 2018. 46 Copyright Notice 48 Copyright (c) 2018 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. Operational Scenarios . . . . . . . . . . . . . . . . . . . . 4 66 3.1. No Head Notification . . . . . . . . . . . . . . . . . . 4 67 3.2. Unreliable Head Notification . . . . . . . . . . . . . . 5 68 3.3. Semi-reliable Head Notification and Tail Solicitation . . 5 69 3.4. Reliable Head Notification . . . . . . . . . . . . . . . 5 70 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 6 71 4.1. Multipoint Client Session . . . . . . . . . . . . . . . . 7 72 4.2. Multipoint Client Session Failure . . . . . . . . . . . . 7 73 4.3. State Variables . . . . . . . . . . . . . . . . . . . . . 7 74 4.3.1. New State Variables . . . . . . . . . . . . . . . . . 7 75 4.3.2. New State Variable Value . . . . . . . . . . . . . . 8 76 4.3.3. State Variable Initialization and Maintenance . . . . 8 77 4.4. Controlling Multipoint BFD Options . . . . . . . . . . . 9 78 4.5. State Machine . . . . . . . . . . . . . . . . . . . . . . 10 79 4.6. Session Establishment . . . . . . . . . . . . . . . . . . 10 80 4.7. Discriminators and Packet Demultiplexing . . . . . . . . 10 81 4.8. Controlling Tail Packet Transmission . . . . . . . . . . 11 82 4.9. Soliciting the Tails . . . . . . . . . . . . . . . . . . 11 83 4.10. Verifying Connectivity to Specific Tails . . . . . . . . 12 84 4.11. Detection Times . . . . . . . . . . . . . . . . . . . . . 13 85 4.12. MultipointClient Down/AdminDown Sessions . . . . . . . . 13 86 4.13. Base BFD Specification Text Replacement . . . . . . . . . 13 87 4.13.1. Reception of BFD Control Packets . . . . . . . . . . 14 88 4.13.2. Demultiplexing BFD Control Packets . . . . . . . . . 14 89 4.13.3. Transmitting BFD Control Packets . . . . . . . . . . 15 90 5. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 15 91 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 92 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 93 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 94 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 95 10. Normative References . . . . . . . . . . . . . . . . . . . . 16 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 98 1. Introduction 100 This application of BFD is an extension to Multipoint BFD 101 [I-D.ietf-bfd-multipoint], which allows tails to unreliably notify 102 the head of the lack of multipoint connectivity. As a further 103 option, this notification can be made reliable. Notification to the 104 head can be enabled for all tails, or for only a subset of the tails. 106 Multipoint BFD base document [I-D.ietf-bfd-multipoint] describes 107 procedures to verify only the head-to-tail connectivity over the 108 multipoint path. Although it may use unicast paths in both 109 directions, Multipoint BFD does not verify those paths (and in fact 110 it is preferable if unicast paths share as little fate with the 111 multipoint path as is feasible, so to increase probability of 112 delivering the notification from the tail to the head). 114 The goal of this application is for the head to reasonably rapidly 115 have knowledge of tails that have lost connectivity from the head. 117 Since scaling is a primary concern (particularly state explosion 118 toward the head), it is required that the head be in control of all 119 timing aspects of the mechanism, and that BFD packets from the tails 120 to the head not be synchronized. 122 Throughout this document, the term "multipoint" is defined as a 123 mechanism by which one or more systems receive packets sent by a 124 single sender. This specifically includes such things as IP 125 multicast and point-to-multipoint MPLS. 127 Term "connectivity" in this document is not being used in context of 128 connectivity verification in transport network but as an alternative 129 to "continuity", i.e. existence of a path between the sender and the 130 receiver. 132 This document effectively modifies and adds to the base BFD 133 specification [RFC5880] and base BFD multipoint document 134 [I-D.ietf-bfd-multipoint]. 136 2. Overview 138 A head may wish to be alerted to the tails' connectivity (or lack 139 thereof), there are a number of options. First, if all that is 140 needed is an unreliable failure notification, as discussed in 141 Section 3.2, the head can request the tails to transmit unicast BFD 142 Control packets back to the head when the path fails, as described in 143 Section 4.4. 145 If the head wishes to know the identity of the tails on the 146 multipoint path, it may solicit membership by sending a multipoint 147 BFD Control packet with the Poll (P) bit set, which will induce the 148 tails to return a unicast BFD Control packet with the Final (F) bit 149 set. The head can then create BFD session state for each of the 150 tails that have multipoint connectivity. If the head sends such a 151 packet on occasion, it can keep track of which tails answer, thus 152 providing a somewhat reliable mechanism for detecting which tails 153 fail to respond (implying a loss of multipoint connectivity). 155 If the head wishes a reliable indication of the tails' connectivity, 156 it may do all of the above, but if it detects that a tail did not 157 answer the previous multipoint poll, it may initiate a Demand mode 158 Poll Sequence as a unicast to that tail. This covers the case where 159 either the multipoint poll or the single reply also is lost in 160 transit. If desired, the head may Poll one or more tails proactively 161 to track the tails' connectivity. 163 If the awareness of the state of some nodes is more important for the 164 head, in the sense that the head needs to detect the lack of 165 multipoint connectivity to a subset of tails at a different rate, the 166 head may transmit unicast BFD Polls to that subset of tails. In this 167 case, the timing may be independent on a tail-by-tail basis. 169 Individual tails may be configured so that they never send BFD 170 control packets to the head, even when the head wishes notification 171 of path failure from the tail. Such tails will never be known to the 172 head, but will still be able to detect multipoint path failures from 173 the head. 175 3. Operational Scenarios 177 It is worth analyzing how this protocol reacts to various scenarios. 178 There are three path components present, namely, the multipoint path, 179 the forward unicast path (from head to a particular tail), and the 180 reverse unicast path (from a tail to the head). There are also four 181 options as to how the head is notified about failures from the tail. 183 3.1. No Head Notification 185 Since the only path used in this scenario is the multipoint path, 186 none of the others matter. A failure in the multipoint path will 187 result in the tail noticing the failure within a detection time, and 188 the head will remain ignorant of the tail state. 190 3.2. Unreliable Head Notification 192 In this scenario, the tail sends back unsolicited BFD packets in 193 response to the detection of a multipoint path failure. It uses the 194 reverse unicast path, but not the forward unicast path. 196 If the multipoint path fails but the reverse unicast path stays up, 197 the tail will detect the failure within a detection time, and the 198 head will know about it within one reverse packet time (since the 199 notification is delayed). 201 If both the multipoint path and the reverse unicast paths fail, the 202 tail will detect the failure but the head will remain unaware of it. 204 3.3. Semi-reliable Head Notification and Tail Solicitation 206 In this scenario, the head sends occasional multipoint Polls in 207 addition to (or in lieu of) non-Poll multipoint BFD Control packets, 208 expecting the tails to reply with Final. This also uses the reverse 209 unicast path, but not the forward unicast path. 211 If the multipoint path fails but the reverse unicast path stays up, 212 the tail will detect the failure within a detection time, and the 213 head will know about it within one reverse packet time (the 214 notification is delayed to avoid synchronization of the tails). 216 If both the multipoint path and the reverse unicast paths fail, the 217 tail will detect the failure but the head will remain unaware of this 218 fact. 220 If the reverse unicast path fails but the multipoint path stays up, 221 the head will see the BFD session fail, but the state of the 222 multipoint path will be unknown to the head. The tail will continue 223 to receive multipoint data traffic. 225 If either the multipoint Poll or the unicast reply is lost in 226 transit, the head will see the BFD session fail, but the state of the 227 multipoint path will be unknown to the head. The tail will continue 228 to receive multipoint data traffic. 230 3.4. Reliable Head Notification 232 In this scenario, the head sends occasional multipoint Polls in 233 addition to (or in lieu of) non-Poll multipoint BFD control packets, 234 expecting the tails to reply with Final. If a tail that had 235 previously replied to a multipoint Poll fails to reply (or if the 236 head simply wishes to verify tail connectivity), the head issues a 237 unicast Poll Sequence to the tail. This scenario makes use of all 238 three paths. 240 If the multipoint path fails but the two unicast paths stay up, the 241 tail will detect the failure within a detection time, and the head 242 will know about it within one reverse packet time (since the 243 notification is delayed). Note that the reverse packet time may be 244 smaller in this case if the head has previously issued a unicast Poll 245 (since the tail will not delay transmission of the notification in 246 this case). 248 If both the multipoint path and the reverse unicast paths fail 249 (regardless of the state of the forward unicast path), the tail will 250 detect the failure but the head will remain unaware of this fact. 251 The head will detect a BFD session failure to the tail but cannot 252 make a determination about the state of the tail's multipoint 253 connectivity. 255 If the forward unicast path fails but the reverse unicast path stays 256 up, the head will detect a BFD session failure to the tail if it 257 happens to send a unicast Poll sequence, but cannot make a 258 determination about the state of the tail's multipoint connectivity. 259 If the multipoint path to the tail fails prior to any unicast Poll 260 being sent, the tail will detect the failure within a detection time, 261 and the head will know about it within one reverse packet time (since 262 the notification is delayed). 264 If the multipoint path stays up but the reverse unicast path fails, 265 the head will see the BFD session fail if it happens to send a Poll 266 Sequence, but the state of the multipoint path will be unknown to the 267 head. The tail will continue to receive multipoint data traffic. 269 If the multipoint path and the reverse unicast path both stay up but 270 the forward unicast path fails, neither side will notice so long as a 271 unicast Poll Sequence is never sent by the head. If the head sends a 272 unicast Poll Sequence, the head will see the BFD session fail, but 273 the state of the multipoint path will be unknown to the head. The 274 tail will continue to receive multipoint data traffic. 276 4. Protocol Details 278 This section describes the operation of BFD Multipoint active tail in 279 detail. This section is an update to section 4 of 280 [I-D.ietf-bfd-multipoint]. 282 4.1. Multipoint Client Session 284 If the head is keeping track of some or all of the tails, it has a 285 session of type MultipointClient per tail that it cares about. All 286 of the MultipointClient sessions for tails on a particular multipoint 287 path are grouped with the MultipointHead session to which the clients 288 are listening. A BFD Poll Sequence may be sent over such a session 289 to a tail if the head wishes to verify connectivity. These sessions 290 receive any BFD Control packets sent by the tails, and never transmit 291 periodic BFD Control packets other than Poll Sequences (since 292 periodic transmission is always done by the MultipointHead session). 294 4.2. Multipoint Client Session Failure 296 If a MultipointClient session receives a BFD Control packet from the 297 tail with state Down or AdminDown, the head reliably knows that the 298 tail has lost multipoint connectivity. If the Detection Time expires 299 on a MultipointClient session, it is ambiguous as to whether the 300 multipoint connectivity failed or whether there was a unicast path 301 problem in one direction or the other, so the head does not reliably 302 know the tail's state. 304 4.3. State Variables 306 BFD Multipoint active tail introduces new state variables and 307 modifies the usage of a few existing ones defined in section 4.4 of 308 [I-D.ietf-bfd-multipoint]. 310 4.3.1. New State Variables 312 Few state variables are added in support of Multipoint BFD active 313 tail. 315 bfd.SilentTail 317 If 0, a tail may send packets to the head according to other 318 parts of this specification. Setting this to 1 allows tails to 319 be provisioned to always be silent, even when the head is 320 soliciting traffic from the tails. This can be useful, for 321 example, in deployments of a large number of tails when the 322 head wishes to track the state of a subset of them. This 323 variable MUST be initialized based on configuration. 325 This variable is only pertinent when bfd.SessionType is 326 MultipointTail and SHOULD NOT be modified after the 327 MultipointTail session has been created. 329 bfd.ReportTailDown 330 Set to 1 if the head wishes tails to notify the head, via 331 periodic BFD Control packets, when they see the BFD session 332 fail. If 0, the tail will never send periodic BFD Control 333 packets, and the head will not be notified of session failures 334 by the tails. This variable MUST be initialized based on 335 configuration. 337 This variable is only pertinent when bfd.SessionType is 338 MultipointHead or MultipointClient. 340 bfd.UnicastRcvd 342 Set to 1 if a tail receives a unicast BFD Control packet from 343 the head. This variable MUST be set to zero if the session 344 transitions from Up state to some other state. 346 This variable MUST be initialized to zero. 348 This variable is only pertinent when bfd.SessionType is 349 MultipointTail. 351 4.3.2. New State Variable Value 353 A new state variable value being added to: 355 bfd.SessionType 357 The type of this session as defined in [RFC7880]. A new value 358 introduced is: 360 MultipointClient: A session on the head that tracks the state 361 of an individual tail, when desirable. 363 This variable MUST be initialized to the appropriate type when the 364 session is created, according to the rules in section 4.13 of 365 [I-D.ietf-bfd-multipoint]. 367 4.3.3. State Variable Initialization and Maintenance 369 Some state variables defined in section 6.8.1 of the [RFC5880] needs 370 to be initialized or manipulated differently depending on the session 371 type (see section 4.4.2 of [I-D.ietf-bfd-multipoint]). 373 bfd.LocalDiscr 375 For session type MultipointClient, this variable MUST always 376 match the value of bfd.LocalDiscr in the associated 377 MultipointHead session. 379 bfd.DesiredMinTxInterval 381 For session type MultipointClient, this variable MUST always 382 match the value of bfd.DesiredMinTxInterval in the associated 383 MultipointHead session. 385 bfd.RequiredMinRxInterval 387 It should be noted that for sessions of type MultipointTail, 388 this variable only affects the rate of unicast Polls sent by 389 the head; the rate of multipoint packets is necessarily 390 unaffected by it. 392 bfd.DemandMode 394 This variable MUST be initialized to 1 for session types 395 MultipointClient. 397 bfd.DetectMult 399 For session type MultipointClient, this variable MUST always 400 match the value of bfd.DetectMult in the associated 401 MultipointHead session. 403 4.4. Controlling Multipoint BFD Options 405 The state variables defined above are used to choose which 406 operational options are active. 408 The most basic form of operation, as explained in 409 [I-D.ietf-bfd-multipoint], in which BFD Control packets flow only 410 from the head and no tracking is desired of tail state at the head, 411 is accomplished by setting bfd.ReportTailDown to 0 in the 412 MultipointHead session (Section 3.1). 414 If the head wishes to know the identity of the tails, it sends 415 multipoint Polls as needed. Previously known tails that don't 416 respond to the Polls will be detected (as per Section 3.3). 418 If the head wishes to be notified by the tails when they lose 419 connectivity, it sets bfd.ReportTailDown to 1 in either the 420 MultipointHead session (if such notification is desired from all 421 tails) or in the MultipointClient session (if notification is desired 422 from a particular tail). Note that the setting of this variable in a 423 MultipointClient session for a particular tail overrides the setting 424 in the MultipointHead session. 426 If the head wishes to verify the state of a tail on an ongoing basis, 427 it sends a Poll Sequence from the MultipointClient session associated 428 with that tail as needed. 430 If the head wants to more quickly be alerted to a session failure 431 from a particular tail, it sends a BFD Control packet from the 432 MultipointClient session associated with that tail. This has the 433 effect of eliminating the initial delay, described in Section 4.13.3, 434 that the tail would otherwise insert prior to transmission of the 435 packet. 437 If a tail wishes to operate silently (sending no BFD Control packets 438 to the head) it sets bfd.SilentTail to 1 in the MultipointTail 439 session. This allows a tail to be silent independent of the settings 440 on the head. 442 4.5. State Machine 444 The state machine for session of type MultipointClient is same as 445 defined in section 4.5 of [I-D.ietf-bfd-multipoint]. 447 4.6. Session Establishment 449 If BFD Control packets are received at the head, they are 450 demultiplexed to sessions of type MultipointClient, which represent 451 the set of tails that the head is interested in tracking. These 452 sessions will typically also be established dynamically based on the 453 receipt of BFD Control packets. The head has broad latitude in 454 choosing which tails to track, if any, without affecting the basic 455 operation of the protocol. The head directly controls whether or not 456 tails are allowed to send BFD Control packets back to the head. 458 4.7. Discriminators and Packet Demultiplexing 460 When the tails send BFD Control packets to the head from the 461 MultipointTail session, the contents of Your Discr (the discriminator 462 received from the head) will not be sufficient for the head to 463 demultiplex the packet, since the same value will be received from 464 all tails on the multicast tree. In this case, the head MUST 465 demultiplex packets based on the source address and the value of Your 466 Discr, which together uniquely identify the tail and the multipoint 467 path. 469 When the head sends unicast BFD Control packets to a tail from a 470 MultipointClient session, the value of Your Discr will be valid, and 471 the tail MUST demultiplex the packet based solely on Your Discr. 473 4.8. Controlling Tail Packet Transmission 475 As the fan-in from the tails to the head may be very large, it is 476 critical that the flow of BFD Control packets from the tails is 477 controlled. 479 The head always operates in Demand mode. This means that no tail 480 will send an asynchronous BFD Control packet as long as the session 481 is Up. 483 The value of Required Min Rx Interval received by a tail in a unicast 484 BFD Control packet, if any, always takes precedence over the value 485 received in Multipoint BFD Control packets. This allows the packet 486 rate from individual tails to be controlled separately as desired by 487 sending a BFD Control packet from the corresponding MultipointClient 488 session. This also eliminates the random delay, as discussed in 489 Section 4.13.3, prior to transmission from the tail that would 490 otherwise be inserted, reducing the latency of reporting a failure to 491 the head. 493 If the head wishes to suppress traffic from the tails when they 494 detect a session failure, it MAY set bfd.RequiredMinRxInterval to 495 zero, which is a reserved value that indicates that the sender wishes 496 to receive no periodic traffic. This can be set in the 497 MultipointHead session (suppressing traffic from all tails) or it can 498 be set in a MultipointClient session (suppressing traffic from only a 499 single tail). 501 Any tail may be provisioned to never send *any* BFD Control packets 502 to the head by setting bfd.SilentTail to 1. This provides a 503 mechanism by which only a subset of tails report their session status 504 to the head. 506 4.9. Soliciting the Tails 508 If the head wishes to know the identities of the tails, the 509 MultipointHead session MAY send a BFD Control packet as specified in 510 Section 4.13.3, with the Poll (P) bit set to 1. This will cause all 511 of the tails to reply with a unicast BFD Control Packet, randomized 512 across one packet interval. 514 The decision as to when to send a multipoint Poll is outside the 515 scope of this specification. However, it must never be sent more 516 often than the regular multipoint BFD Control packet. Since the tail 517 will treat a multipoint Poll like any other multipoint BFD Control 518 packet, Polls may be sent in lieu of non-Poll packets. 520 Soliciting the tails also starts the Detection Timer for each 521 associated MultipointClient session, which will cause those sessions 522 to time out if the associated tails do not respond. 524 Note that for this mechanism to work properly, the Detection Time 525 (which is equal to bfd.DesiredMinTxInterval) MUST be greater than the 526 round trip time of BFD Control packets from the head to the tail (via 527 the multipoint path) and back (via a unicast path). See Section 4.11 528 for more details. 530 4.10. Verifying Connectivity to Specific Tails 532 If the head wishes to verify connectivity to a specific tail, the 533 corresponding MultipointClient session MAY send a BFD Poll Sequence 534 to said tail. This might be done in reaction to the expiration of 535 the Detection Timer (the tail didn't respond to a multipoint Poll), 536 or it might be done on a proactive basis. 538 The interval between transmitted packets in the Poll Sequence MUST be 539 calculated as specified in the base BFD specification [RFC5880] (the 540 greater of bfd.DesiredMinTxInterval and bfd.RemoteMinRxInterval). 542 The value transmitted in Required Min RX Interval will be used by the 543 tail (rather than the value received in any multipoint packet) when 544 it transmits BFD Control packets to the head notifying it of a 545 session failure, and the transmitted packets will not be delayed. 546 This value can potentially be set much lower than in the multipoint 547 case, in order to speed up notification to the head, since the value 548 will be used only by the single tail. This value (and the lack of 549 delay) are "sticky", in that once the tail receives it, it will 550 continue to use it indefinitely. Therefore, if the head no longer 551 wishes to single out the tail, it SHOULD reset the timer to the 552 default by sending a Poll Sequence with the same value of Required 553 Min Rx Interval as is carried in the multipoint packets, or it MAY 554 reset the tail session by sending a Poll Sequence with state 555 AdminDown (after the completion of which the session will come back 556 up). 558 Note that a failure of the head to receive a response to a Poll 559 Sequence does not necessarily mean that the tail has lost multipoint 560 connectivity, though a reply to a Poll Sequence does reliably 561 indicate connectivity or lack thereof (by virtue of the tail's state 562 not being Up in the BFD Control packet). 564 4.11. Detection Times 566 MultipointClient sessions at the head are always in Demand mode, and 567 as such only care about detection time in two cases. First, if a 568 Poll Sequence is being sent on a MultipointClient session, the 569 detection time on this session is calculated according to the base 570 BFD specification [RFC5880], that is, the transmission interval 571 multiplied by bfd.DetectMult. Second, when a multipoint Poll is sent 572 to solicit tail replies, the detection time on all associated 573 MultipointClient sessions that aren't currently sending Poll 574 Sequences is set to a value greater than or equal to 575 bfd.RequiredMinRxInterval (one packet time). This value can be made 576 arbitrarily large in order to ensure that the detection time is 577 greater than the round trip time of a BFD Control packet between the 578 head and the tail with no ill effects, other than delaying the 579 detection of unresponsive tails. Note that a detection time 580 expiration on a MultipointClient session at the head, while 581 indicating a BFD session failure, cannot be construed to mean that 582 the tail is not hearing multipoint packets from the head. 584 4.12. MultipointClient Down/AdminDown Sessions 586 If the MultipointHead session is going down (which only happens 587 administratively), all associated MultipointClient sessions SHOULD be 588 destroyed as they are superfluous. 590 If a MultipointClient session goes down due to the receipt of an 591 unsolicited BFD Control packet from the tail with state Down or 592 AdminDown (not in response to a Poll), and tail connectivity 593 verification is not being done, the session MAY be destroyed. If 594 verification is desired, the session SHOULD send a Poll Sequence and 595 the session SHOULD be maintained. 597 If the tail replies to a Poll Sequence with state Down or AdminDown, 598 it means that the tail session is definitely down. In this case, the 599 session MAY be destroyed. 601 If the Detection Time expires on a MultipointClient session (meaning 602 that the tail did not reply to a Poll Sequence) the session MAY be 603 destroyed. 605 4.13. Base BFD Specification Text Replacement 607 The following sections are meant to replace the corresponding 608 sections in the base specifications [RFC5880] and 609 [I-D.ietf-bfd-multipoint]. 611 4.13.1. Reception of BFD Control Packets 613 The following procedure replaces section 6.8.6 of [RFC5880]. 615 When a BFD Control packet is received, procedure defined in section 616 4.13.1 of [I-D.ietf-bfd-multipoint] MUST be followed, in the order 617 specified. If the packet is discarded according to these rules, 618 processing of the packet MUST cease at that point. In addition to 619 that, if tail tracking is desired by head, below procedure MUST be 620 applied. 622 If bfd.SessionType is MultipointTail 624 If bfd.UnicastRcvd is 0 or the M bit is clear, set 625 bfd.RemoteMinRxInterval to the value of Required Min RX 626 Interval. 628 If the M bit is clear, set bfd.UnicastRcvd to 1. 630 Else (not MultipointTail) 632 Set bfd.RemoteMinRxInterval to the value of Required Min RX 633 Interval. 635 If the Poll (P) bit is set, and bfd.SilentTail is zero, send a BFD 636 Control packet to the remote system with the Poll (P) bit clear, 637 and the Final (F) bit set (see Section 4.13.3). 639 4.13.2. Demultiplexing BFD Control Packets 641 This section is part of the replacement for [RFC5880] section 6.8.6 642 and addition to section 4.13.2 of [I-D.ietf-bfd-multipoint], 643 separated for clarity. 645 If Multipoint (M) bit is clear 647 If the Your Discriminator field is nonzero 649 Select a session based on the value of Your Discriminator. 650 If no session is found, the packet MUST be discarded. 652 If bfd.SessionType is MulticastHead 654 Find a MultipointClient session grouped to this 655 MulticastHead session, based on the source address and 656 the value of Your Discriminator. If a session is found 657 and is not MulticastClient, the packet MUST be discarded. 658 If no session is found, a new session of type 659 MultipointClient MAY be created, or the packet MAY be 660 discarded. This choice is outside the scope of this 661 specification. 663 If bfd.SessionType is not MulticastClient, the packet 664 MUST be discarded. 666 4.13.3. Transmitting BFD Control Packets 668 The following procedure replaces section 6.8.7 of [RFC5880]. 670 A system MUST NOT periodically transmit BFD Control packets if 671 bfd.SessionType is MulticastClient and a Poll Sequence is not being 672 transmitted. 674 If bfd.SessionType is MulticastTail and periodic transmission of BFD 675 Control packets is just starting (due to Demand mode not being active 676 on the remote system), the first packet to be transmitted MUST be 677 delayed by a random amount of time between zero and (0.9 * 678 bfd.RemoteMinRxInterval). 680 If a BFD Control packet is received with the Poll (P) bit set to 1, 681 the receiving system MUST transmit a BFD Control packet with the Poll 682 (P) bit clear and the Final (F) bit, without respect to the 683 transmission timer or any other transmission limitations, without 684 respect to the session state, and without respect to whether Demand 685 mode is active on either system. A system MAY limit the rate at 686 which such packets are transmitted. If rate limiting is in effect, 687 the advertised value of Desired Min TX Interval MUST be greater than 688 or equal to the interval between transmitted packets imposed by the 689 rate limiting function. If the Multipoint (M) bit is set in the 690 received packet, the packet transmission MUST be delayed by a random 691 amount of time between zero and (0.9 * bfd.RemoteMinRxInterval). 692 Otherwise, the packet MUST be transmitted as soon as practicable. 694 A system MUST NOT set the Demand (D) bit if bfd.SessionType is 695 MultipointClient unless bfd.DemandMode is 1, bfd.SessionState is Up, 696 and bfd.RemoteSessionState is Up. 698 Contents of transmitted packet MUST be as explained in section 4.13.3 699 of [I-D.ietf-bfd-multipoint]. 701 5. Assumptions 703 If head notification is to be used, it is assumed that a multipoint 704 BFD packet encapsulation contains enough information so that a tail 705 can address a unicast BFD packet to the head. 707 If head notification is to be used, it is assumed that is that there 708 is bidirectional unicast communication available (at the same 709 protocol layer within which BFD is being run) between the tail and 710 head. 712 For the head to know reliably that a tail has lost multipoint 713 connectivity, the unicast paths in both directions between that tail 714 and the head must remain operational when the multipoint path fails. 715 It is thus desirable that unicast paths not share fate with the 716 multipoint path to the extent possible if the head wants reliable 717 knowledge of tail state. 719 Since the normal BFD three-way handshake is not used in this 720 application, a tail transitioning from state Up to Down and back to 721 Up again may not be reliably detected at the head. 723 6. IANA Considerations 725 This document has no actions for IANA. 727 7. Security Considerations 729 The same security considerations as those described in [RFC5880] and 730 [I-D.ietf-bfd-multipoint] apply to this document. 732 This specification does not raise any additional security issues 733 beyond those of the specifications referred to in the list of 734 normative references. 736 8. Contributors 738 Rahul Aggarwal of Juniper Networks and George Swallow of Cisco 739 Systems provided the initial idea for this specification and 740 contributed to its development. 742 9. Acknowledgements 744 Authors would also like to thank Nobo Akiya, Vengada Prasad Govindan, 745 Jeff Haas, Wim Henderickx, Gregory Mirsky and Mingui Zhang who have 746 greatly contributed to this document. 748 10. Normative References 750 [I-D.ietf-bfd-multipoint] 751 Katz, D., Ward, D., Networks, J., and G. Mirsky, "BFD for 752 Multipoint Networks", draft-ietf-bfd-multipoint-13 (work 753 in progress), January 2018. 755 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 756 Requirement Levels", BCP 14, RFC 2119, 757 DOI 10.17487/RFC2119, March 1997, 758 . 760 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 761 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 762 . 764 [RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. 765 Pallagatti, "Seamless Bidirectional Forwarding Detection 766 (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, 767 . 769 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 770 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 771 May 2017, . 773 Authors' Addresses 775 Dave Katz 776 Juniper Networks 777 1194 N. Mathilda Ave. 778 Sunnyvale, California 94089-1206 779 USA 781 Email: dkatz@juniper.net 783 Dave Ward 784 Cisco Systems 785 170 West Tasman Dr. 786 San Jose, California 95134 787 USA 789 Email: wardd@cisco.com 791 Santosh Pallagatti (editor) 792 Individual Contributor 793 Embassy Business Park 794 Bangalore, KA 560093 795 India 797 Email: santosh.pallagatti@gmail.com 798 Greg Mirsky (editor) 799 ZTE Corp. 801 Email: gregimirsky@gmail.com