idnits 2.17.1 draft-ietf-bfd-multipoint-active-tail-09.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 (June 18, 2018) is 2136 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-17 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 Updates: XXXX (RFC BFD for Multi-point D. Ward 5 Networks) (if approved) Cisco Systems 6 Intended status: Standards Track S. Pallagatti, Ed. 7 Expires: December 20, 2018 Individual Contributor 8 G. Mirsky, Ed. 9 ZTE Corp. 10 June 18, 2018 12 BFD Multipoint Active Tails. 13 draft-ietf-bfd-multipoint-active-tail-09 15 Abstract 17 This document describes active tail extensions to and updates the 18 Bidirectional Forwarding Detection (BFD) protocol for multipoint 19 networks. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on December 20, 2018. 38 Copyright Notice 40 Copyright (c) 2018 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology and Acronyms . . . . . . . . . . . . . . . . . . 3 57 3. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 5. Operational Scenarios . . . . . . . . . . . . . . . . . . . . 4 60 5.1. No Head Notification . . . . . . . . . . . . . . . . . . 5 61 5.2. Head Notification . . . . . . . . . . . . . . . . . . . . 5 62 5.2.1. Head Notification Without Polling . . . . . . . . . . 5 63 5.2.2. Head Notification and Tail Solicitation with 64 Multipoint Polling . . . . . . . . . . . . . . . . . 6 65 5.2.3. Head Notification with Composite Polling . . . . . . 6 66 6. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 7 67 6.1. Multipoint Client Session . . . . . . . . . . . . . . . . 7 68 6.2. Multipoint Client Session Failure . . . . . . . . . . . . 8 69 6.3. State Variables . . . . . . . . . . . . . . . . . . . . . 8 70 6.3.1. New State Variables . . . . . . . . . . . . . . . . . 8 71 6.3.2. New State Variable Value . . . . . . . . . . . . . . 9 72 6.3.3. State Variable Initialization and Maintenance . . . . 9 73 6.4. Controlling Multipoint BFD Options . . . . . . . . . . . 10 74 6.5. State Machine . . . . . . . . . . . . . . . . . . . . . . 11 75 6.6. Session Establishment . . . . . . . . . . . . . . . . . . 11 76 6.7. Discriminators and Packet Demultiplexing . . . . . . . . 11 77 6.8. Controlling Tail Packet Transmission . . . . . . . . . . 12 78 6.9. Soliciting the Tails . . . . . . . . . . . . . . . . . . 12 79 6.10. Verifying Connectivity to Specific Tails . . . . . . . . 13 80 6.11. Detection Times . . . . . . . . . . . . . . . . . . . . . 14 81 6.12. MultipointClient Down/AdminDown Sessions . . . . . . . . 14 82 6.13. Base BFD for Multipoint Networks Specification Text 83 Replacement . . . . . . . . . . . . . . . . . . . . . . . 14 84 6.13.1. Reception of BFD Control Packets . . . . . . . . . . 15 85 6.13.2. Demultiplexing BFD Control Packets . . . . . . . . . 15 86 6.13.3. Transmitting BFD Control Packets . . . . . . . . . . 16 87 7. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 16 88 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 89 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 90 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 91 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 92 12. Normative References . . . . . . . . . . . . . . . . . . . . 18 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 95 1. Introduction 97 This application of BFD is an extension to Multipoint BFD 98 [I-D.ietf-bfd-multipoint], which allows tails to notify the head of 99 the lack of multipoint connectivity. As a further option, heads can 100 request a notification from the tails by means of a polling 101 mechanism. Notification to the head can be enabled for all tails, or 102 for only a subset of the tails. 104 The goal of this application is for the head to reasonably rapidly 105 have knowledge of tails that have lost connectivity from the head. 107 Since scaling is a primary concern (particularly state explosion 108 toward the head), it is required that the head be in control of all 109 timing aspects of the mechanism, and that BFD packets from the tails 110 to the head not be synchronized. 112 Throughout this document, the term "multipoint" is defined as a 113 mechanism by which one or more systems receive packets sent by a 114 single sender. This specifically includes such things as IP 115 multicast and point-to-multipoint MPLS. 117 Term "connectivity" in this document is not being used in the context 118 of connectivity verification in transport network but as an 119 alternative to "continuity", i.e. existence of a path between the 120 sender and the receiver. 122 This document effectively modifies and adds to Sections 5.12 and 5.13 123 of the base BFD multipoint document [I-D.ietf-bfd-multipoint]. 125 2. Terminology and Acronyms 127 BFD Bidirectional Forwarding Detection 129 c-poll Composite Poll 131 m-poll Multipoint Poll 133 3. Keywords 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 137 "OPTIONAL" in this document are to be interpreted as described in BCP 138 14 [RFC2119] [RFC8174] when, and only when, they appear in all 139 capitals, as shown here. 141 4. Overview 143 A head may wish to be alerted to the tails' connectivity (or lack 144 thereof), there are a number of options. First, if all that is 145 needed is a best-effort failure notification, as discussed in 146 Section 5.2.1, the tails can send unsolicited unicast BFD Control 147 packets to the head when the path fails, as described in Section 6.4. 149 If the head wishes to know of the active tails on the multipoint 150 path, it may send a multipoint BFD Control packet with the Poll (P) 151 bit set, which will induce the tails to return a unicast BFD Control 152 packet with the Final (F) bit set (detailed description in 153 Section 5.2.2). The head can then create BFD session state for each 154 of the tails that have multipoint connectivity. If the head sends 155 such a packet on occasion, it can keep track of which tails answer, 156 thus providing a more deterministic mechanism for detecting which 157 tails fail to respond (implying a loss of multipoint connectivity). 158 In this document, this method referenced to as Multipoint Poll 159 (m-poll). 161 If the head wishes the definite indication of the tails' 162 connectivity, it may do all of the above, but if it detects that a 163 tail did not answer the previous multipoint poll, it may initiate a 164 Demand mode Poll Sequence as a unicast to that tail (detailed 165 description in Section 5.2.3). This covers the case where either the 166 multipoint poll or the single reply also is lost in transit. If 167 desired, the head may Poll one or more tails proactively to track the 168 tails' connectivity. In this document this method that combines the 169 use of multipoint and unicast polling of tails by the head referenced 170 to as Composite Poll (c-poll). 172 If the awareness of the state of some nodes is more important for the 173 head, in the sense that the head needs to detect the lack of 174 multipoint connectivity to a subset of tails at a different rate, the 175 head may transmit unicast BFD Polls to that subset of tails. In this 176 case, the timing may be independent on a tail-by-tail basis. 178 Individual tails may be configured so that they never send BFD 179 control packets to the head. Such tails will never be known to the 180 head, but will still be able to detect multipoint path failures from 181 the head. 183 5. Operational Scenarios 185 It is worth analyzing how this protocol reacts to various scenarios. 186 There are three path components present, namely, the multipoint path, 187 the forward unicast path (from head to a particular tail), and the 188 reverse unicast path (from a tail to the head). There are also four 189 options as to how the head is notified about failures from the tail. 190 For the different modes described below the setting of new state 191 variables are given even if these are only introduced later in the 192 document (see Section 6.3). 194 5.1. No Head Notification 196 In this scenario, only the multipoint path is used and none of the 197 others matter. A failure in the multipoint path will result in the 198 tail noticing the failure within a detection time, and the head will 199 remain ignorant of the tail state. This mode emulates the behavior 200 described in [I-D.ietf-bfd-multipoint]. In this mode for 201 bfd.SessionType is MultipointTail, variable bfd.SilentTail (see 202 Section 6.3.1) MUST be set to 1. If bfd.SessionType is 203 MultipointHead or MultipointClient bfd.ReportTailDown MUST be set to 204 0. The head MAY set bfd.RequiredMinRxInterval to zero and thus 205 suppress tails sending any BFD control packets. 207 5.2. Head Notification 209 In these scenarios, the tail sends unsolicited or solicited BFD 210 packets in response to the detection of a multipoint path failure. 211 All these scenarios have common settings: 213 o if bfd.SessionType is MultipointTail, variable bfd.SilentTail (see 214 Section 6.3.1) MUST be set to 0; 216 o if bfd.SessionType is MultipointHead or MultipointClient 217 bfd.ReportTailDown MUST be set to 1; 219 o the head MUST set bfd.RequiredMinRxInterval to non-zero and thus 220 allow tails sending BFD control packets. 222 5.2.1. Head Notification Without Polling 224 In this scenario, the tail sends unsolicited BFD packets in response 225 to the detection of a multipoint path failure. It uses the reverse 226 unicast path, but not the forward unicast path. 228 If the multipoint path fails but the reverse unicast path stays up, 229 the tail will detect the failure within a detection time, and the 230 head will know about it within one reverse packet time (since the 231 notification is delayed). 233 If both the multipoint path and the reverse unicast paths fail, the 234 tail will detect the failure but the head will remain unaware of it. 236 5.2.2. Head Notification and Tail Solicitation with Multipoint Polling 238 In this scenario, the head sends occasional multipoint Polls in 239 addition to (or in lieu of) non-Poll multipoint BFD Control packets, 240 expecting the tails to reply with Final. This also uses the reverse 241 unicast path, but not the forward unicast path. 243 If the multipoint path fails but the reverse unicast path stays up, 244 the tail will detect the failure within a detection time, and the 245 head will know about it within one reverse packet time (the 246 notification is delayed to avoid synchronization of the tails). 248 If both the multipoint path and the reverse unicast paths fail, the 249 tail will detect the failure but the head will remain unaware of this 250 fact. 252 If the reverse unicast path fails but the multipoint path stays up, 253 the head will see the BFD session fail, but the state of the 254 multipoint path will be unknown to the head. The tail will continue 255 to receive multipoint data traffic. 257 If either the multipoint Poll or the unicast reply is lost in 258 transit, the head will see the BFD session fail, but the state of the 259 multipoint path will be unknown to the head. The tail will continue 260 to receive multipoint data traffic. 262 5.2.3. Head Notification with Composite Polling 264 In this scenario, the head sends occasional multipoint Polls in 265 addition to (or in lieu of) non-Poll multipoint BFD control packets, 266 expecting the tails to reply with Final. If a tail that had 267 previously replied to a multipoint Poll fails to reply (or if the 268 head simply wishes to verify tail connectivity), the head issues a 269 unicast Poll Sequence to the tail. This scenario makes use of all 270 three paths. In this mode for bfd.SessionType of MultipointTail, 271 variable bfd.SilentTail (see Section 6.3.1) MUST be set to 0. 273 If the multipoint path fails but the two unicast paths stay up, the 274 tail will detect the failure within a detection time, and the head 275 will know about it within one reverse packet time (since the 276 notification is delayed). Note that the reverse packet time may be 277 smaller in this case if the head has previously issued a unicast Poll 278 (since the tail will not delay transmission of the notification in 279 this case). 281 If both the multipoint path and the reverse unicast paths fail 282 (regardless of the state of the forward unicast path), the tail will 283 detect the failure but the head will remain unaware of this fact. 285 The head will detect a BFD session failure to the tail but cannot 286 make a determination about the state of the tail's multipoint 287 connectivity. 289 If the forward unicast path fails but the reverse unicast path stays 290 up, the head will detect a BFD session failure to the tail if it 291 happens to send a unicast Poll sequence, but cannot make a 292 determination about the state of the tail's multipoint connectivity. 293 If the multipoint path to the tail fails prior to any unicast Poll 294 being sent, the tail will detect the failure within a detection time, 295 and the head will know about it within one reverse packet time (since 296 the notification is delayed). 298 If the multipoint path stays up but the reverse unicast path fails, 299 the head will see the particular MultipointClient session fail if it 300 happens to send a Poll Sequence, but the state of the multipoint path 301 will be unknown to the head. The tail will continue to receive 302 multipoint data traffic. 304 If the multipoint path and the reverse unicast path both stay up but 305 the forward unicast path fails, neither side will notice this failure 306 so long as a unicast Poll Sequence is never sent by the head. If the 307 head sends a unicast Poll Sequence, the head will detect the failure 308 in the forward unicast path. The state of the multipoint path will 309 be determined by multipoint Poll. The tail will continue to receive 310 multipoint data traffic. 312 6. Protocol Details 314 This section describes the operation of BFD Multipoint active tail in 315 detail. This section updates the section 4 of 316 [I-D.ietf-bfd-multipoint] as the following: 318 o Section 6.3 introduces new state variables and modifies the usage 319 of a few existing ones; 321 o Section 6.13 replaces the corresponding sections in the base BFD 322 for multipoint networks specification. 324 6.1. Multipoint Client Session 326 If the head is keeping track of some or all of the tails, it has a 327 session of type MultipointClient per tail that it cares about. All 328 of the MultipointClient sessions for tails on a particular multipoint 329 path are associated with the MultipointHead session to which the 330 clients are listening. A BFD Poll Sequence may be sent over a 331 MultipointClient session to a tail if the head wishes to verify 332 connectivity. These sessions receive any BFD Control packets sent by 333 the tails, and MUST NOT transmit periodic BFD Control packets other 334 than Poll Sequences (since periodic transmission is always done by 335 the MultipointHead session). 337 6.2. Multipoint Client Session Failure 339 If a MultipointClient session receives a BFD Control packet from the 340 tail with state Down or AdminDown, the head reliably knows that the 341 tail has lost multipoint connectivity. If the Detection Time expires 342 on a MultipointClient session, it is ambiguous as to whether the 343 multipoint connectivity failed or whether there was a unicast path 344 problem in one direction or the other, so the head does not reliably 345 know the tail's state. 347 6.3. State Variables 349 BFD Multipoint active tail introduces new state variables and 350 modifies the usage of a few existing ones defined in section 4.4 of 351 [I-D.ietf-bfd-multipoint]. 353 6.3.1. New State Variables 355 Few state variables are added in support of Multipoint BFD active 356 tail. 358 bfd.SilentTail 360 If 0, a tail may send packets to the head according to other 361 parts of this specification. Setting this to 1 allows tails to 362 be provisioned to always be silent, even when the head is 363 soliciting traffic from the tails. This can be useful, for 364 example, in deployments of a large number of tails when the 365 head wishes to track the state of a subset of them. This 366 variable MUST be initialized based on configuration. 368 This variable is only pertinent when bfd.SessionType is 369 MultipointTail and SHOULD NOT be modified after the 370 MultipointTail session has been created. 372 bfd.ReportTailDown 374 Set to 1 if the head wishes tails to notify the head, via 375 periodic BFD Control packets, when they see the BFD session 376 fail. If 0, the tail will never send periodic BFD Control 377 packets, and the head will not be notified of session failures 378 by the tails. This variable MUST be initialized based on 379 configuration. 381 This variable is only pertinent when bfd.SessionType is 382 MultipointHead or MultipointClient. 384 bfd.UnicastRcvd 386 Set to 1 if a tail receives a unicast BFD Control packet from 387 the head. This variable MUST be set to zero if the session 388 transitions from Up state to some other state. 390 This variable MUST be initialized to zero. 392 This variable is only pertinent when bfd.SessionType is 393 MultipointTail. 395 6.3.2. New State Variable Value 397 A new state variable value being added to: 399 bfd.SessionType 401 The type of this session as defined in [RFC7880]. A new value 402 introduced is: 404 MultipointClient: A session on the head that tracks the state 405 of an individual tail, when desirable. 407 This variable MUST be initialized to the appropriate type when the 408 session is created, according to the rules in section 4.4 of 409 [I-D.ietf-bfd-multipoint]. 411 6.3.3. State Variable Initialization and Maintenance 413 Some state variables defined in section 6.8.1 of [RFC5880] need to be 414 initialized or manipulated differently depending on the session type. 415 The values of some of these variables relate to those of the same 416 variables of a MultipointHead session (see section 4.4.2 of 417 [I-D.ietf-bfd-multipoint]). 419 bfd.LocalDiscr 421 For session type MultipointClient, this variable MUST always 422 match the value of bfd.LocalDiscr in the associated 423 MultipointHead session. 425 bfd.DesiredMinTxInterval 426 For session type MultipointClient, this variable MUST always 427 match the value of bfd.DesiredMinTxInterval in the associated 428 MultipointHead session. 430 bfd.RequiredMinRxInterval 432 It MAY be set to zero at the head BFD system to suppress 433 traffic from the tails. Setting it to zero in the 434 MultipointHead session suppresses traffic from all tails, the 435 setting in a MultipointClient session suppresses traffic from a 436 single tail. 438 bfd.DemandMode 440 This variable MUST be initialized to 1 for session types 441 MultipointClient. 443 bfd.DetectMult 445 For session type MultipointClient, this variable MUST always 446 match the value of bfd.DetectMult in the associated 447 MultipointHead session. 449 6.4. Controlling Multipoint BFD Options 451 The state variables defined above are used to choose which 452 operational options are active. 454 The most basic form of operation, as explained in 455 [I-D.ietf-bfd-multipoint], in which BFD Control packets flow only 456 from the head and no tracking is desired of tail state at the head, 457 is accomplished by setting bfd.ReportTailDown to 0 in the 458 MultipointHead session (Section 5.1). 460 If the head wishes to know of active the tails, it sends multipoint 461 Polls as needed. Previously known tails that don't respond to the 462 Polls will be detected (as per Section 5.2.2). 464 If the head wishes to request a notification from the tails when they 465 lose connectivity, it sets bfd.ReportTailDown to 1 in either the 466 MultipointHead session (if such notification is desired from all 467 tails) or in the MultipointClient session (if notification is desired 468 from a particular tail). Note that the setting of this variable in a 469 MultipointClient session for a particular tail overrides the setting 470 in the MultipointHead session. 472 If the head wishes to verify the state of a tail on an ongoing basis, 473 it sends a Poll Sequence from the MultipointClient session associated 474 with that tail as needed. This has the effect of eliminating the 475 initial delay, described in Section 6.13.3, that the tail would 476 otherwise insert prior to transmission of the packet thus the head 477 may have notification of the session failure more quickly when 478 comparing with use of m-poll. 480 If a tail wishes to operate silently (sending no BFD Control packets 481 to the head) it sets bfd.SilentTail to 1 in the MultipointTail 482 session. This allows a tail to be silent independent of the settings 483 on the head. 485 6.5. State Machine 487 Though the state transitions for the state machine, as defined in 488 section 5.5 of [I-D.ietf-bfd-multipoint], for a session type 489 MultipointHead are only administratively driven, the state machine 490 for a session of type MultipointClient is same and the diagram is 491 applicable. 493 6.6. Session Establishment 495 If BFD Control packets are received at the head, they are 496 demultiplexed to sessions of type MultipointClient, which represent 497 the set of tails that the head is interested in tracking. These 498 sessions will typically also be established dynamically based on the 499 receipt of BFD Control packets. The head has broad latitude in 500 choosing which tails to track, if any, without affecting the basic 501 operation of the protocol. The head directly controls whether or not 502 tails are allowed to send BFD Control packets back to the head by 503 setting bfd.RequiredMinRxInterval to zero in a MultipointHead or a 504 MultipointClient session. 506 6.7. Discriminators and Packet Demultiplexing 508 When the tails send BFD Control packets to the head from the 509 MultipointTail session, the contents of Your Discr (the discriminator 510 received from the head) will not be sufficient for the head to 511 demultiplex the packet, since the same value will be received from 512 all tails on the multicast tree. In this case, the head MUST 513 demultiplex packets based on the source address and the value of Your 514 Discr, which together uniquely identify the tail and the multipoint 515 path. 517 When the head sends unicast BFD Control packets to a tail from a 518 MultipointClient session, the value of Your Discr will be valid, and 519 the tail MUST demultiplex the packet based solely on Your Discr. 521 6.8. Controlling Tail Packet Transmission 523 As the fan-in from the tails to the head may be very large, it is 524 critical that the flow of BFD Control packets from the tails is 525 controlled. 527 The head always operates in Demand mode. This means that no tail 528 will send an asynchronous BFD Control packet as long as the session 529 is Up. 531 The value of Required Min Rx Interval received by a tail in a unicast 532 BFD Control packet, if any, always takes precedence over the value 533 received in Multipoint BFD Control packets. This allows the packet 534 rate from individual tails to be controlled separately as desired by 535 sending a BFD Control packet from the corresponding MultipointClient 536 session. This also eliminates the random delay, as discussed in 537 Section 6.13.3, prior to transmission from the tail that would 538 otherwise be inserted, reducing the latency of reporting a failure to 539 the head. 541 If the head wishes to suppress traffic from the tails when they 542 detect a session failure, it MAY set bfd.RequiredMinRxInterval to 543 zero, which is a reserved value that indicates that the sender wishes 544 to receive no periodic traffic. This can be set in the 545 MultipointHead session (suppressing traffic from all tails) or it can 546 be set in a MultipointClient session (suppressing traffic from only a 547 single tail). 549 Any tail may be provisioned to never send *any* BFD Control packets 550 to the head by setting bfd.SilentTail to 1. This provides a 551 mechanism by which only a subset of tails reports their session 552 status to the head. 554 6.9. Soliciting the Tails 556 If the head wishes to know of the active tails, the MultipointHead 557 session MAY send a BFD Control packet as specified in Section 6.13.3, 558 with the Poll (P) bit set to 1. This will cause all of the tails to 559 reply with a unicast BFD Control Packet, randomized across one packet 560 interval. 562 The decision as to when to send a multipoint Poll is outside the 563 scope of this specification. However, it must never be sent more 564 often than the regular multipoint BFD Control packet. Since the tail 565 will treat a multipoint Poll like any other multipoint BFD Control 566 packet, Polls may be sent in lieu of non-Poll packets. 568 Soliciting the tails also starts the Detection Timer for each of the 569 associated MultipointClient sessions, which will cause those sessions 570 to time out if the associated tails do not respond. 572 Note that for this mechanism to work properly, the Detection Time 573 (which is equal to bfd.DesiredMinTxInterval) MUST be greater than the 574 round trip time of BFD Control packets from the head to the tail (via 575 the multipoint path) and back (via a unicast path). See Section 6.11 576 for more details. 578 6.10. Verifying Connectivity to Specific Tails 580 If the head wishes to verify connectivity to a specific tail, the 581 corresponding MultipointClient session MAY send a BFD Poll Sequence 582 to said tail. This might be done in reaction to the expiration of 583 the Detection Timer (the tail didn't respond to a multipoint Poll), 584 or it might be done on a proactive basis. 586 The interval between transmitted packets in the Poll Sequence MUST be 587 calculated as specified in the base BFD specification [RFC5880] (the 588 greater of bfd.DesiredMinTxInterval and bfd.RemoteMinRxInterval). 590 The value transmitted in Required Min RX Interval will be used by the 591 tail (rather than the value received in any multipoint packet) when 592 it transmits BFD Control packets to the head notifying it of a 593 session failure and the transmitted packets will not be delayed. 594 This value can potentially be set much lower than in the multipoint 595 case, in order to speed up a notification to the head, since the 596 value will be used only by the single tail. This value (and the lack 597 of delay) are "sticky", in that once the tail receives it, it will 598 continue to use it indefinitely. Therefore, if the head no longer 599 wishes to single out the tail, it SHOULD reset the timer to the 600 default by sending a Poll Sequence with the same value of Required 601 Min Rx Interval as is carried in the multipoint packets, or it MAY 602 reset the tail session by sending a Poll Sequence with state 603 AdminDown (after the completion of which the session will come back 604 up). 606 Note that a failure of the head to receive a response to a Poll 607 Sequence does not necessarily mean that the tail has lost multipoint 608 connectivity, though a reply to a Poll Sequence does reliably 609 indicate connectivity or lack thereof (by virtue of the tail's state 610 not being Up in the BFD Control packet). 612 6.11. Detection Times 614 MultipointClient sessions at the head are always in the Demand mode, 615 and as such only care about detection time in two cases. First, if a 616 Poll Sequence is being sent on a MultipointClient session, the 617 detection time on this session is calculated according to the base 618 BFD specification [RFC5880], that is, the transmission interval 619 multiplied by bfd.DetectMult. Second, when a multipoint Poll is sent 620 to solicit tail replies, the detection time on all associated 621 MultipointClient sessions that aren't currently sending Poll 622 Sequences is set to a value greater than or equal to 623 bfd.RequiredMinRxInterval (one packet time). This value can be made 624 arbitrarily large in order to ensure that the detection time is 625 greater than the round trip time of a BFD Control packet between the 626 head and the tail with no ill effects, other than delaying the 627 detection of unresponsive tails. Note that a detection time 628 expiration on a MultipointClient session at the head, while 629 indicating a BFD session failure, cannot be construed to mean that 630 the tail is not hearing multipoint packets from the head. 632 6.12. MultipointClient Down/AdminDown Sessions 634 If the MultipointHead session is going down (which only happens 635 administratively), all associated MultipointClient sessions SHOULD be 636 destroyed as they are superfluous. 638 If a MultipointClient session goes down due to the receipt of an 639 unsolicited BFD Control packet from the tail with state Down or 640 AdminDown (not in response to a Poll), and tail connectivity 641 verification is not being done, the session MAY be destroyed. If 642 verification is desired, the session SHOULD send a Poll Sequence and 643 the session SHOULD be maintained. 645 If the tail replies to a Poll Sequence with state Down or AdminDown, 646 it means that the tail session is definitely down. In this case, the 647 session MAY be destroyed. 649 If the Detection Time expires on a MultipointClient session (meaning 650 that the tail did not reply to a Poll Sequence) the session MAY be 651 destroyed. 653 6.13. Base BFD for Multipoint Networks Specification Text Replacement 655 The following sections are meant to extend the corresponding sections 656 in the base BFD for Multipoint Networks specification 657 [I-D.ietf-bfd-multipoint]. 659 6.13.1. Reception of BFD Control Packets 661 The following procedure updates parts of Section 5.13.1 of 662 [I-D.ietf-bfd-multipoint]. 664 When a BFD Control packet is received, the procedure defined in 665 Section 5.13.1 of [I-D.ietf-bfd-multipoint] MUST be followed, in the 666 order specified. If the packet is discarded according to these 667 rules, processing of the packet MUST cease at that point. In 668 addition to that, if tail tracking is desired by the head, below 669 procedure MUST be applied. 671 If bfd.SessionType is MultipointTail 673 If bfd.UnicastRcvd is 0 or the M bit is clear, set 674 bfd.RemoteMinRxInterval to the value of Required Min RX 675 Interval. 677 If the M bit is clear, set bfd.UnicastRcvd to 1. 679 Else (not MultipointTail) 681 Set bfd.RemoteMinRxInterval to the value of Required Min RX 682 Interval. 684 If the Poll (P) bit is set, and bfd.SilentTail is zero, send a BFD 685 Control packet to the remote system with the Poll (P) bit clear, 686 and the Final (F) bit set (see Section 6.13.3). 688 6.13.2. Demultiplexing BFD Control Packets 690 This section is part of the addition to Section 5.13.2 of 691 [I-D.ietf-bfd-multipoint], separated for clarity. 693 If Multipoint (M) bit is clear 695 If the Your Discriminator field is nonzero 697 Select a session based on the value of Your Discriminator. 698 If no session is found, the packet MUST be discarded. 700 If bfd.SessionType is MultipointHead 702 Find a MultipointClient session grouped to this 703 MultipointHead session, based on the source address and 704 the value of Your Discriminator. If a session is found 705 and is not MultipointClient, the packet MUST be 706 discarded. If no session is found, a new session of type 707 MultipointClient MAY be created, or the packet MAY be 708 discarded. This choice is outside the scope of this 709 specification. 711 If bfd.SessionType is not MultipointClient, the packet 712 MUST be discarded. 714 6.13.3. Transmitting BFD Control Packets 716 A system MUST NOT periodically transmit BFD Control packets if 717 bfd.SessionType is MultipointClient and a Poll Sequence is not being 718 transmitted. 720 If bfd.SessionType value is MultipointTail and periodic the 721 transmission of BFD Control packets is just starting (due to Demand 722 mode not being active on the remote system), the first packet to be 723 transmitted MUST be delayed by a random amount of time between zero 724 and (0.9 * bfd.RemoteMinRxInterval). 726 If a BFD Control packet is received with the Poll (P) bit set to 1, 727 the receiving system MUST transmit a BFD Control packet with the Poll 728 (P) bit clear and the Final (F) bit, without respect to the 729 transmission timer or any other transmission limitations, without 730 respect to the session state, and without respect to whether Demand 731 mode is active on either system. A system MAY limit the rate at 732 which such packets are transmitted. If rate limiting is in effect, 733 the advertised value of Desired Min TX Interval MUST be greater than 734 or equal to the interval between transmitted packets imposed by the 735 rate limiting function. If the Multipoint (M) bit is set in the 736 received packet, the packet transmission MUST be delayed by a random 737 amount of time between zero and (0.9 * bfd.RemoteMinRxInterval). 738 Otherwise, the packet MUST be transmitted as soon as practicable. 740 A system MUST NOT set the Demand (D) bit if bfd.SessionType is 741 MultipointClient unless bfd.DemandMode is 1, bfd.SessionState is Up, 742 and bfd.RemoteSessionState is Up. 744 Contents of transmitted packet MUST be as explained in section 5.13.3 745 of [I-D.ietf-bfd-multipoint]. 747 7. Assumptions 749 If head notification is to be used, it is assumed that a multipoint 750 BFD packet encapsulation contains enough information so that a tail 751 can address a unicast BFD packet to the head. 753 If head notification is to be used, it is assumed that is that there 754 is bidirectional unicast communication available (at the same 755 protocol layer within which BFD is being run) between the tail and 756 head. 758 For the head to know reliably that a tail has lost multipoint 759 connectivity, the unicast paths in both directions between that tail 760 and the head must remain operational when the multipoint path fails. 761 It is thus desirable that unicast paths not share fate with the 762 multipoint path to the extent possible if the head wants more 763 definite knowledge of the tail state. 765 Since the normal BFD three-way handshake is not used in this 766 application, a tail transitioning from state Up to Down and back to 767 Up again may not be reliably detected at the head. 769 8. IANA Considerations 771 This document has no actions for IANA. 773 9. Security Considerations 775 The same security considerations as those described in [RFC5880] and 776 [I-D.ietf-bfd-multipoint] apply to this document. 778 Additionally, implementations that create MultpointClient sessions 779 dynamically upon receipt of BFD Control packet from a tail MUST 780 implement protective measures to prevent an infinite number of 781 MultipointClient sessions being created. Below are listed some 782 points to be considered in such implementations. 784 When the number of MultipointClient sessions exceeds the number of 785 expected tails, then the implementation should generate an alarm 786 to users to indicate the anomaly. 788 The implementation should have a reasonable upper bound on the 789 number of MultipointClient sessions that can be created, with the 790 upper bound potentially being computed based on the number of 791 multicast streams that the system is expecting. 793 This specification does not raise any additional security issues 794 beyond those of the specifications referred to in the list of 795 normative references. 797 10. Contributors 799 Rahul Aggarwal of Juniper Networks and George Swallow of Cisco 800 Systems provided the initial idea for this specification and 801 contributed to its development. 803 11. Acknowledgments 805 Authors would also like to thank Nobo Akiya, Vengada Prasad Govindan, 806 Jeff Haas, Wim Henderickx and Mingui Zhang who have greatly 807 contributed to this document. 809 12. Normative References 811 [I-D.ietf-bfd-multipoint] 812 Katz, D., Ward, D., Networks, J., and G. Mirsky, "BFD for 813 Multipoint Networks", draft-ietf-bfd-multipoint-17 (work 814 in progress), June 2018. 816 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 817 Requirement Levels", BCP 14, RFC 2119, 818 DOI 10.17487/RFC2119, March 1997, 819 . 821 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 822 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 823 . 825 [RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. 826 Pallagatti, "Seamless Bidirectional Forwarding Detection 827 (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, 828 . 830 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 831 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 832 May 2017, . 834 Authors' Addresses 836 Dave Katz 837 Juniper Networks 838 1194 N. Mathilda Ave. 839 Sunnyvale, California 94089-1206 840 USA 842 Email: dkatz@juniper.net 843 Dave Ward 844 Cisco Systems 845 170 West Tasman Dr. 846 San Jose, California 95134 847 USA 849 Email: wardd@cisco.com 851 Santosh Pallagatti (editor) 852 Individual Contributor 853 Embassy Business Park 854 Bangalore, KA 560093 855 India 857 Email: santosh.pallagatti@gmail.com 859 Greg Mirsky (editor) 860 ZTE Corp. 862 Email: gregimirsky@gmail.com