idnits 2.17.1 draft-ietf-bfd-multipoint-19.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. 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 (December 13, 2018) is 1933 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 (-15) exists of draft-ietf-bess-mvpn-fast-failover-04 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 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 (if approved) D. Ward 5 Intended status: Standards Track Cisco Systems 6 Expires: June 16, 2019 S. Pallagatti, Ed. 7 Rtbrick 8 G. Mirsky, Ed. 9 ZTE Corp. 10 December 13, 2018 12 BFD for Multipoint Networks 13 draft-ietf-bfd-multipoint-19 15 Abstract 17 This document describes extensions to the Bidirectional Forwarding 18 Detection (BFD) protocol for its use in multipoint and multicast 19 networks. 21 This document updates RFC 5880. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on June 16, 2019. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 5 62 5.1. Multipoint BFD Control Packets . . . . . . . . . . . . . 5 63 5.2. Session Model . . . . . . . . . . . . . . . . . . . . . . 5 64 5.3. Session Failure Semantics . . . . . . . . . . . . . . . . 5 65 5.4. State Variables . . . . . . . . . . . . . . . . . . . . . 5 66 5.4.1. New State Variable Values . . . . . . . . . . . . . . 6 67 5.4.2. State Variable Initialization and Maintenance . . . . 6 68 5.5. State Machine . . . . . . . . . . . . . . . . . . . . . . 6 69 5.6. Session Establishment . . . . . . . . . . . . . . . . . . 7 70 5.7. Discriminators and Packet Demultiplexing . . . . . . . . 7 71 5.8. Packet consumption on tails . . . . . . . . . . . . . . . 8 72 5.9. Bringing Up and Shutting Down Multipoint BFD Service . . 8 73 5.10. Timer Manipulation . . . . . . . . . . . . . . . . . . . 9 74 5.11. Detection Times . . . . . . . . . . . . . . . . . . . . . 10 75 5.12. State Maintenance for Down/AdminDown Sessions . . . . . . 10 76 5.12.1. MultipointHead Sessions . . . . . . . . . . . . . . 10 77 5.12.2. MultipointTail Sessions . . . . . . . . . . . . . . 10 78 5.13. Base Specification Text Replacement . . . . . . . . . . . 10 79 5.13.1. Reception of BFD Control Packets . . . . . . . . . . 11 80 5.13.2. Demultiplexing BFD Control Packets . . . . . . . . . 13 81 5.13.3. Transmitting BFD Control Packets . . . . . . . . . . 15 82 6. Congestion Considerations . . . . . . . . . . . . . . . . . . 18 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 84 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 85 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 86 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 87 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 88 11.1. Normative References . . . . . . . . . . . . . . . . . . 20 89 11.2. Informational References . . . . . . . . . . . . . . . . 20 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 92 1. Introduction 94 The Bidirectional Forwarding Detection protocol [RFC5880] specifies a 95 method for verifying unicast connectivity between a pair of systems. 96 This document updates [RFC5880] by defining a new method for using 97 BFD. This new method provides verification of multipoint or 98 multicast connectivity between a multipoint sender (the "head") and a 99 set of one or more multipoint receivers (the "tails"). 101 As multipoint transmissions are inherently unidirectional, this 102 mechanism purports only to verify this unidirectional connectivity. 103 Although this seems in conflict with the "Bidirectional" in BFD, the 104 protocol is capable of supporting this use case. Use of BFD in 105 Demand mode allows a tail to monitor the availability of a multipoint 106 path even without the existence of some kind of a return path to the 107 head. As an option, if a return path from a tail to the head exists, 108 the tail may notify the head of the lack of multipoint connectivity. 109 Details of tail notification to the head are outside the scope of 110 this document and are discussed in 111 [I-D.ietf-bfd-multipoint-active-tail]. 113 This application of BFD allows for the tails to detect a lack of 114 connectivity from the head. For some applications such detection of 115 the failure at the tail is useful. For example, use of multipoint 116 BFD to enable fast failure detection and faster failover in multicast 117 VPN described in [I-D.ietf-bess-mvpn-fast-failover]. Due to 118 unidirectional nature, virtually all options and timing parameters 119 are controlled by the head. 121 Throughout this document, the term "multipoint" is defined as a 122 mechanism by which one or more systems receive packets sent by a 123 single sender. This specifically includes such things as IP 124 multicast and point-to-multipoint MPLS. 126 The term "connectivity" in this document is not being used in the 127 context of connectivity verification in transport network but as an 128 alternative to "continuity", i.e., the existence of a forwarding path 129 between the sender and the receiver. 131 This document effectively updates and extends the base BFD 132 specification [RFC5880]. 134 2. Keywords 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 138 "OPTIONAL" in this document are to be interpreted as described in BCP 139 14 [RFC2119] [RFC8174] when, and only when, they appear in all 140 capitals, as shown here. 142 3. Goals 144 The primary goal of this mechanism is to allow tails to rapidly 145 detect the fact that multipoint connectivity from the head has 146 failed. 148 Another goal is for the mechanism to work on any multicast 149 technology. 151 A further goal is to support multiple, overlapping point-to- 152 multipoint paths, as well as multipoint-to-multipoint paths, and to 153 allow point-to-point BFD sessions to operate simultaneously among the 154 systems participating in Multipoint BFD. 156 It is not a goal for this protocol to verify point-to-point bi- 157 directional connectivity between the head and any tail. This can be 158 done independently (and with no penalty in protocol overhead) by 159 using point-to-point BFD. 161 4. Overview 163 The heart of this protocol is the periodic transmission of BFD 164 Control packets along a multipoint path, from the head to all tails 165 on the path. The contents of the BFD packets provide the means for 166 the tails to calculate the detection time for path failure. If no 167 BFD Control packets are received by a tail for a detection time, the 168 tail declares that the path has failed. For some applications this 169 is the only mechanism necessary; the head can remain ignorant of the 170 status of connectivity to the tails. 172 The head of a multipoint BFD session may wish to be alerted to the 173 tails' connectivity (or lack thereof). Details of how the head keeps 174 track of tails and how tails alert their connectivity to the head are 175 outside the scope of this document and are discussed in 176 [I-D.ietf-bfd-multipoint-active-tail]. 178 Although this document describes a single head and a set of tails 179 spanned by a single multipoint path, the protocol is capable of 180 supporting (and discriminating between) more than one multipoint path 181 at both heads and tails, as described in Section 5.7 and 182 Section 5.13.2. Furthermore, the same head and tail may share 183 multiple multipoint paths, and a multipoint path may have multiple 184 heads. 186 5. Protocol Details 188 This section describes the operation of Multipoint BFD in detail. 190 5.1. Multipoint BFD Control Packets 192 Multipoint BFD Control packets (packets sent by the head over a 193 multipoint path) are explicitly marked as such, via the setting of 194 the M bit [RFC5880]. This means that Multipoint BFD does not depend 195 on the recipient of a packet to know whether the packet was received 196 over a multipoint path. This can be useful in scenarios where this 197 information may not be available to the recipient. 199 5.2. Session Model 201 Multipoint BFD is modeled as a set of sessions of different types. 202 The elements of procedure differ slightly for each type. 204 The head has a session of type MultipointHead, as defined in 205 Section 5.4.1, that is bound to a multipoint path. Multipoint BFD 206 Control packets are sent by this session over the multipoint path, 207 and no BFD Control packets are received by it. 209 Each tail has a session of type MultipointTail, as defined in 210 Section 5.4.1, associated with a multipoint path. These sessions 211 receive BFD Control packets from the head over the multipoint path. 213 5.3. Session Failure Semantics 215 The semantics of session failure is subtle enough to warrant further 216 explanation. 218 MultipointHead sessions cannot fail (since they are controlled 219 administratively). 221 If a MultipointTail session fails, it means that the tail definitely 222 has lost contact with the head (or the head has been administratively 223 disabled) and the tail may use mechanisms other than BFD, e.g., 224 logging or NETCONF [RFC6241], to send a notification to the user. 226 5.4. State Variables 228 Multipoint BFD introduces some new state variables and modifies the 229 usage of a few existing ones. 231 5.4.1. New State Variable Values 233 A number of new values of the state variable bfd.SessionType are 234 added to the base BFD [RFC5880] and base S-BFD [RFC7880] 235 specifications in support of Multipoint BFD. 237 bfd.SessionType 239 The type of this session as defined in [RFC7880]. Newly added 240 values are: 242 PointToPoint: Classic point-to-point BFD, as described in 243 [RFC5880]. 245 MultipointHead: A session on the head responsible for the 246 periodic transmission of multipoint BFD Control packets 247 along the multipoint path. 249 MultipointTail: A multipoint session on a tail. 251 This variable MUST be initialized to the appropriate type when 252 the session is created. 254 5.4.2. State Variable Initialization and Maintenance 256 Some state variables defined in section 6.8.1 of [RFC5880] need to be 257 initialized or manipulated differently depending on the session type. 259 bfd.RequiredMinRxInterval 261 This variable MUST be initialized to 0 for session type 262 MultipointHead. 264 bfd.DemandMode 266 This variable MUST be initialized to 1 for session type 267 MultipointHead and MUST be initialized to 0 for session type 268 MultipointTail. 270 5.5. State Machine 272 The BFD state machine works slightly differently in the multipoint 273 application. In particular, since there is a many-to-one mapping, 274 three-way handshakes for session establishment and teardown are 275 neither possible nor appropriate. As such, there is no Init state. 276 Sessions of type MultipointHead MUST NOT send BFD control packets 277 with the State field being set to INIT, and those packets MUST be 278 ignored on receipt. 280 The following diagram provides an overview of the state machine for 281 session type MultipointTail. The notation on each arc represents the 282 state of the remote system (as received in the State field in the BFD 283 Control packet) or indicates the expiration of the Detection Timer. 285 DOWN, ADMIN DOWN, 286 +------+ TIMER +------+ 287 +----| |<---------------------| |----+ 288 DOWN,| | DOWN | | UP | |UP 289 ADMIN DOWN,+--->| |--------------------->| |<---+ 290 TIMER +------+ UP +------+ 292 Sessions of type MultipointHead never receive packets and have no 293 Detection Timer, and as such all state transitions are 294 administratively driven. 296 5.6. Session Establishment 298 Unlike point-to-point BFD, Multipoint BFD provides a form of the 299 discovery mechanism for tails to discover the head. The minimum 300 amount of a priori information required both on the head and tails is 301 the binding to the multipoint path over which BFD is running. The 302 head transmits Multipoint BFD packets on that path, and the tails 303 listen for BFD packets on that path. All other information can be 304 determined dynamically. 306 A session of type MultipointHead is created for each multipoint path 307 over which the head wishes to run BFD. This session runs in the 308 Active role, per section 6.1 [RFC5880]. Except when administratively 309 terminating BFD service, this session is always in state Up and 310 always operates in Demand mode. No received packets are ever 311 demultiplexed to the MultipointHead session. In this sense, it is a 312 degenerate form of a session. 314 Sessions on the tail MAY be established dynamically, based on the 315 receipt of a Multipoint BFD Control packet from the head, and are of 316 type MultipointTail. Tail sessions always take the Passive role, per 317 section 6.1 [RFC5880]. 319 5.7. Discriminators and Packet Demultiplexing 321 The use of Discriminators is somewhat different in Multipoint BFD 322 than in Point-to-point BFD. 324 The head sends Multipoint BFD Control packets over the multipoint 325 path via the MultipointHead session with My Discriminator set to a 326 value bound to the multipoint path, and with Your Discriminator set 327 to zero. 329 IP and MPLS multipoint tails MUST demultiplex BFD packets based on a 330 combination of the source address, My Discriminator and the identity 331 of the multipoint path which the Multipoint BFD Control packet was 332 received from. Together they uniquely identify the head of the 333 multipoint path. Bootstrapping a BFD session to multipoint MPLS LSP 334 may use the control plane, e.g., as described in 335 [I-D.ietf-bess-mvpn-fast-failover], and is outside the scope of this 336 document. 338 Note that, unlike point-to-point sessions, the My Discriminator value 339 on MultipointHead session MUST NOT be changed during the life of a 340 session. This is a side effect of the more complex demultiplexing 341 scheme. 343 5.8. Packet consumption on tails 345 BFD packets received on tails for an IP multicast group MUST be 346 consumed by tails and MUST NOT be forwarded to receivers. Nodes with 347 the BFD session of type MultipointTail MUST identify packets received 348 on an IP multipoint path as BFD control packet if the destination UDP 349 port value equals 3784. 351 For multipoint LSPs, when IP/UDP encapsulation of BFD control packets 352 is used, MultipointTail MUST expect destination UDP port 3784. 353 Destination IP address of BFD control packet MUST be in 127.0.0.0/8 354 range for IPv4 or in 0:0:0:0:0:FFFF:7F00:0/104 range for IPv6. The 355 use of these destination addresses is consistent with the 356 explanations and usage in [RFC8029]. Packets identified as BFD 357 packets MUST be consumed by MultipointTail and demultiplexed as 358 described in Section 5.13.2. Use of other types of encapsulation of 359 the BFD control message over multipoint LSP is outside the scope of 360 this document. 362 5.9. Bringing Up and Shutting Down Multipoint BFD Service 364 Because there is no three-way handshake in Multipoint BFD, a newly 365 started head (that does not have any previous state information 366 available) SHOULD start with bfd.SessionState set to Down and 367 bfd.RequiredMinRxInterval MUST be set to zero in the MultipointHead 368 session. The session SHOULD remain in this state for a time equal to 369 (bfd.DesiredMinTxInterval * bfd.DetectMult). This will ensure that 370 all MultipointTail sessions are reset (so long as the restarted head 371 is using the same or a larger value of bfd.DesiredMinTxInterval than 372 it did previously). 374 Multipoint BFD service is brought up by administratively setting 375 bfd.SessionState to Up in the MultipointHead session. 377 The head of a multipoint BFD session may wish to shut down its BFD 378 service in a controlled fashion. This is desirable because the tails 379 need not wait a detection time prior to declaring the multipoint 380 session to be down (and taking whatever action is necessary in that 381 case). 383 To shut down a multipoint session in a controlled fashion the head 384 MUST administratively set bfd.SessionState in the MultipointHead 385 session to either Down or AdminDown and SHOULD set 386 bfd.RequiredMinRxInterval to zero. The session SHOULD send BFD 387 Control packets in this state for a period equal to 388 (bfd.DesiredMinTxInterval * bfd.DetectMult). Alternatively, the head 389 MAY stop transmitting BFD Control packets and not send any more BFD 390 Control packets with the new state (Down or AdminDown). Tails will 391 declare the multipoint session down only after the detection time 392 interval runs out. 394 5.10. Timer Manipulation 396 Because of the one-to-many mapping, a session of type MultipointHead 397 SHOULD NOT initiate a Poll Sequence in conjunction with timer value 398 changes. However, to indicate a change in the packets, 399 MultipointHead session MUST send packets with the P bit set. 400 MultipointTail session MUST NOT reply if the packet has M and P bits 401 set and bfd.RequiredMinRxInterval set to 0. Because the Poll 402 Sequence is not used, the tail cannot negotiate down MultpointHead's 403 transmit interval. If the value of Desired Min TX Interval in the 404 BFD Control packet received by MultipointTail is too high (that 405 determination may change in time based on the current environment) it 406 must be handled by the implementation and may be controlled by local 407 policy, e.g., close the MultipointTail session. 409 The MultipointHead, when changing the transmit interval to a higher 410 value, MUST send BFD control packets with P bit set at the old 411 transmit interval before using the higher value in order to avoid 412 false detection timeouts at the tails. MultipointHead session MAY 413 also wait some amount of time before making the changes to the 414 transmit interval (through configuration). 416 Change in the value of bfd.RequiredMinRxInterval is outside the scope 417 of this document and is discussed in 418 [I-D.ietf-bfd-multipoint-active-tail]. 420 5.11. Detection Times 422 Multipoint BFD is inherently asymmetric. As such, each session type 423 has a different approach to detection times. 425 Since MultipointHead sessions never receive packets, they do not 426 calculate a detection time. 428 MultipointTail sessions cannot influence the transmission rate of the 429 MultipointHead session using the Required Min Rx Interval field 430 because of its one-to-many nature. As such, the detection time 431 calculation for a MultipointTail session does not use 432 bfd.RequiredMinRxInterval. The detection time is calculated as the 433 product of the last received values of Desired Min TX Interval and 434 Detect Mult. 436 The value of bfd.DetectMult may be changed at any time on any session 437 type. 439 5.12. State Maintenance for Down/AdminDown Sessions 441 The length of time session state is kept after the session goes down 442 determines how long the session will continue to send BFD Control 443 packets (since no packets can be sent after the session is 444 destroyed). 446 5.12.1. MultipointHead Sessions 448 When a MultipointHead session transitions to states Down or 449 AdminDown, the state SHOULD be maintained for a period equal to 450 (bfd.DesiredMinTxInterval * bfd.DetectMult) to ensure that the tails 451 more quickly detect the session going down (by continuing to transmit 452 BFD Control packets with the new state). 454 5.12.2. MultipointTail Sessions 456 MultipointTail sessions MAY be destroyed immediately upon leaving Up 457 state, since tail will transmit no packets. 459 Otherwise, MultipointTail sessions SHOULD be maintained as long as 460 BFD Control packets are being received by it (which by definition 461 will indicate that the head is not Up). 463 5.13. Base Specification Text Replacement 465 The following sections are meant to replace the corresponding 466 sections in the base specification [RFC5880] in support of BFD for 467 multipoint networks while not changing processing for point-to-point 468 BFD. 470 5.13.1. Reception of BFD Control Packets 472 The following procedure replaces the entire section 6.8.6 of 473 [RFC5880]. 475 When a BFD Control packet is received, the following procedure MUST 476 be followed, in the order specified. If the packet is discarded 477 according to these rules, processing of the packet MUST cease at that 478 point. 480 If the version number is not correct (1), the packet MUST be 481 discarded. 483 If the Length field is less than the minimum correct value (24 if 484 the A bit is clear, or 26 if the A bit is set), the packet MUST be 485 discarded. 487 If the Length field is greater than the payload of the 488 encapsulating protocol, the packet MUST be discarded. 490 If the Detect Mult field is zero, the packet MUST be discarded. 492 If the My Discriminator field is zero, the packet MUST be 493 discarded. 495 Demultiplex the packet to a session according to Section 5.13.2 496 below. The result is either a session of the proper type, or the 497 packet is discarded (and packet processing MUST cease). 499 If the A bit is set and no authentication is in use (bfd.AuthType 500 is zero), the packet MUST be discarded. 502 If the A bit is clear and authentication is in use (bfd.AuthType 503 is nonzero), the packet MUST be discarded. 505 If the A bit is set, the packet MUST be authenticated under the 506 rules of [RFC5880] section 6.7, based on the authentication type 507 in use (bfd.AuthType). This may cause the packet to be discarded. 509 Set bfd.RemoteDiscr to the value of My Discriminator. 511 Set bfd.RemoteState to the value of the State (Sta) field. 513 Set bfd.RemoteDemandMode to the value of the Demand (D) bit. 515 Set bfd.RemoteMinRxInterval to the value of Required Min RX 516 Interval. 518 If the Required Min Echo RX Interval field is zero, the 519 transmission of Echo packets, if any, MUST cease. 521 If a Poll Sequence is being transmitted by the local system and 522 the Final (F) bit in the received packet is set, the Poll Sequence 523 MUST be terminated. 525 If bfd.SessionType is PointToPoint, update the transmit interval 526 as described in [RFC5880] section 6.8.2. 528 If bfd.SessionType is PointToPoint, update the Detection Time as 529 described in section 6.8.4 of [RFC5880]. 531 Else 533 If bfd.SessionType is MultipointTail, then update the Detection 534 Time as the product of the last received values of Desired Min 535 TX Interval and Detect Mult, as described in Section 5.11 of 536 this specification. 538 If bfd.SessionState is AdminDown 540 Discard the packet 542 If the received state is AdminDown 544 If bfd.SessionState is not Down 546 Set bfd.LocalDiag to 3 (Neighbor signaled session down) 548 Set bfd.SessionState to Down 550 Else 552 If bfd.SessionState is Down 554 If bfd.SessionType is PointToPoint 556 If received State is Down 558 Set bfd.SessionState to Init 560 Else if received State is Init 562 Set bfd.SessionState to Up 564 Else (bfd.SessionType is not PointToPoint) 566 If received State is Up 568 Set bfd.SessionState to Up 570 Else if bfd.SessionState is Init 572 If received State is Init or Up 574 Set bfd.SessionState to Up 576 Else (bfd.SessionState is Up) 578 If received State is Down 580 Set bfd.LocalDiag to 3 (Neighbor signaled session down) 582 Set bfd.SessionState to Down 584 Check to see if Demand mode should become active or not (see 585 [RFC5880] section 6.6). 587 If bfd.RemoteDemandMode is 1, bfd.SessionState is Up and 588 bfd.RemoteSessionState is Up, Demand mode is active on the remote 589 system and the local system MUST cease the periodic transmission 590 of BFD Control packets (see Section 5.13.3). 592 If bfd.RemoteDemandMode is 0, or bfd.SessionState is not Up, or 593 bfd.RemoteSessionState is not Up, Demand mode is not active on the 594 remote system and the local system MUST send periodic BFD Control 595 packets (see Section 5.13.3). 597 If the Poll (P) bit is set, and bfd.SessionType is PointToPoint, 598 send a BFD Control packet to the remote system with the Poll (P) 599 bit clear, and the Final (F) bit set (see Section 5.13.3). 601 If the packet was not discarded, it has been received for purposes 602 of the Detection Time expiration rules in [RFC5880] section 6.8.4. 604 5.13.2. Demultiplexing BFD Control Packets 606 This section is part of the replacement for [RFC5880] section 6.8.6, 607 separated for clarity. 609 If the Multipoint (M) bit is set 610 If the Your Discriminator field is nonzero, the packet MUST be 611 discarded. 613 Select a session as based on source address, My Discriminator 614 and the identity of the multipoint path which the Multipoint 615 BFD Control packet was received. 617 If a session is found, and bfd.SessionType is not 618 MultipointTail, the packet MUST be discarded. 620 Else 622 If a session is not found, a new session of type 623 MultipointTail MAY be created, or the packet MAY be 624 discarded. This choice can be controlled by the local 625 policy, e.g., by settinga maximum number of MultipointTail 626 sessions. Use of the local policy and the exact mechanism 627 of it are outside the scope of this specification. 629 Else (Multipoint bit is clear) 631 If the Your Discriminator field is nonzero 633 Select a session based on the value of Your Discriminator. 634 If no session is found, the packet MUST be discarded. 636 Else (Your Discriminator is zero) 638 If the State field is not Down or AdminDown, the packet MUST 639 be discarded. 641 Otherwise, the session MUST be selected based on some 642 combination of other fields, possibly including source 643 addressing information, the My Discriminator field, and the 644 interface over which the packet was received. The exact 645 method of selection is application-specific and is thus 646 outside the scope of this specification. 648 If a matching session is found, and bfd.SessionType is not 649 PointToPoint, the packet MUST be discarded. 651 If a matching session is not found, a new session of type 652 PointToPoint MAY be created, or the packet MAY be discarded. 653 This choice MAY be controlled by a local policy and is 654 outside the scope of this specification. 656 If the State field is Init and bfd.SessionType is not 657 PointToPoint, the packet MUST be discarded. 659 5.13.3. Transmitting BFD Control Packets 661 The following procedure replaces the entire section 6.8.7 of 662 [RFC5880]. 664 With the exceptions listed in the remainder of this section, a system 665 MUST NOT transmit BFD Control packets at an interval less than the 666 larger of bfd.DesiredMinTxInterval and bfd.RemoteMinRxInterval, less 667 applied jitter (see below). In other words, the system reporting the 668 slower rate determines the transmission rate. 670 The periodic transmission of BFD Control packets MUST be jittered on 671 a per-packet basis by up to 25%, that is, the interval MUST be 672 reduced by a random value of 0 to 25%, in order to avoid self- 673 synchronization with other systems on the same subnetwork. Thus, the 674 average interval between packets will be roughly 12.5% less than that 675 negotiated. 677 If bfd.DetectMult is equal to 1, the interval between transmitted BFD 678 Control packets MUST be no more than 90% of the negotiated 679 transmission interval, and MUST be no less than 75% of the negotiated 680 transmission interval. This is to ensure that, on the remote system, 681 the calculated Detection Time does not pass prior to the receipt of 682 the next BFD Control packet. 684 A system MUST NOT transmit any BFD Control packets if bfd.RemoteDiscr 685 is zero and the system is taking the Passive role. 687 A system MUST NOT transmit any BFD Control packets if bfd.SessionType 688 is MultipointTail. 690 A system MUST NOT periodically transmit BFD Control packets if Demand 691 mode is active on the remote system (bfd.RemoteDemandMode is 1, 692 bfd.SessionState is Up, and bfd.RemoteSessionState is Up) and a Poll 693 Sequence is not being transmitted. 695 A system MUST NOT periodically transmit BFD Control packets if 696 bfd.RemoteMinRxInterval is zero. 698 If bfd.SessionType is MultipointHead, the transmit interval MUST be 699 set to bfd.DesiredMinTxInterval (this should happen automatically, as 700 bfd.RemoteMinRxInterval will be zero). 702 If bfd.SessionType is not MultipointHead, the transmit interval MUST 703 be recalculated whenever bfd.DesiredMinTxInterval changes, or 704 whenever bfd.RemoteMinRxInterval changes, and is equal to the greater 705 of those two values. See [RFC5880] sections 6.8.2 and 6.8.3 for 706 details on transmit timers. 708 A system MUST NOT set the Demand (D) bit if bfd.SessionType is 709 MultipointTail. 711 A system MUST NOT set the Demand (D) bit if bfd.SessionType 712 PointToPoint unless bfd.DemandMode is 1, bfd.SessionState is Up, and 713 bfd.RemoteSessionState is Up. 715 If bfd.SessionType is PointToPoint or MultipointHead, a BFD Control 716 packet SHOULD be transmitted during the interval between periodic 717 Control packet transmissions when the contents of that packet would 718 differ from that in the previously transmitted packet (other than the 719 Poll and Final bits) in order to more rapidly communicate a change in 720 state. 722 The contents of transmitted BFD Control packets MUST be set as 723 follows: 725 Version 727 Set to the current version number (1). 729 Diagnostic (Diag) 731 Set to bfd.LocalDiag. 733 State (Sta) 735 Set to the value indicated by bfd.SessionState. 737 Poll (P) 739 Set to 1 if the local system is sending a Poll Sequence or is a 740 session of type MultipointHead soliciting the identities of the 741 tails, or 0 if not. 743 Final (F) 745 Set to 1 if the local system is responding to a Control packet 746 received with the Poll (P) bit set, or 0 if not. 748 Control Plane Independent (C) 750 Set to 1 if the local system's BFD implementation is 751 independent of the control plane (it can continue to function 752 through a disruption of the control plane). 754 Authentication Present (A) 755 Set to 1 if authentication is in use in this session 756 (bfd.AuthType is nonzero), or 0 if not. 758 Demand (D) 760 Set to bfd.DemandMode if bfd.SessionState is Up and 761 bfd.RemoteSessionState is Up. Set to 1 if bfd.SessionType is 762 MultipointHead. Otherwise it is set to 0. 764 Multipoint (M) 766 Set to 1 if bfd.SessionType is MultipointHead. Otherwise, it 767 is set to 0. 769 Detect Mult 771 Set to bfd.DetectMult. 773 Length 775 Set to the appropriate length, based on the fixed header length 776 (24) plus any Authentication Section. 778 My Discriminator 780 Set to bfd.LocalDiscr. 782 Your Discriminator 784 Set to bfd.RemoteDiscr. 786 Desired Min TX Interval 788 Set to bfd.DesiredMinTxInterval. 790 Required Min RX Interval 792 Set to bfd.RequiredMinRxInterval. 794 Required Min Echo RX Interval 796 Set to 0 if bfd.SessionType is MultipointHead or 797 MultipointTail. Otherwise, set to the minimum required Echo 798 packet receive interval for this session. If this field is set 799 to zero, the local system is unwilling or unable to loop back 800 BFD Echo packets to the remote system, and the remote system 801 will not send Echo packets. 803 Authentication Section 805 Included and set according to the rules in [RFC5880] section 806 6.7 if authentication is in use (bfd.AuthType is nonzero). 807 Otherwise, this section is not present. 809 6. Congestion Considerations 811 As a foreword, although congestion can occur because of a number of 812 factors, it should be noted that high transmission rates are by 813 themselves subject to creating congestion either along the path or at 814 the tail end(s). As such, as stated in [RFC5883]: 816 "it is required that the operator correctly provision the rates at 817 which BFD is transmitted to avoid congestion (e.g link, I/O, CPU) 818 and false failure detection." 820 Use of BFD in multipoint networks, as specified in this document, 821 over multiple hops requires consideration of the mechanisms to react 822 to network congestion. Requirements stated in Section 7 of the BFD 823 base specification [RFC5880] equally apply to BFD in multipoint 824 networks and are repeated here: 826 "When BFD is used across multiple hops, a congestion control 827 mechanism MUST be implemented, and when congestion is detected, 828 the BFD implementation MUST reduce the amount of traffic it 829 generates." 831 The mechanism to control the load of BFD traffic MAY use BFD's 832 configuration interface to control BFD state variable 833 bfd.DesiredMinTxInterval. However, such a control loop do not form 834 part of the BFD protocol itself and its specification is thus outside 835 the scope of this document. 837 Additional considerations apply to BFD in multipoint networks, as 838 specified in this document. Indeed, because a tail does not transmit 839 any BFD Control packets to the head of the BFD session, such head 840 node has no BFD based mechanism to be aware of the state of the 841 session at the tail. In the absence of any other mechanism, the head 842 of the session could thus continue to send packets towards the 843 tail(s) even though a link failure has happened. In such a scenario 844 when it is required for the head of the session to be aware of the 845 state of the tail of the session, it is RECOMMENDED to implement 846 [I-D.ietf-bfd-multipoint-active-tail]. 848 7. IANA Considerations 850 This document has no actions for IANA. 852 8. Security Considerations 854 The same security considerations as those described in [RFC5880] 855 apply to this document. Additionally, implementations that create 856 MultpointTail sessions dynamically upon receipt of Multipoint BFD 857 Control packets MUST implement protective measures to prevent an 858 infinite number of MultipointTail sessions being created. Below are 859 listed some points to be considered in such implementations. 861 If a Multipoint BFD Control packet did not arrive on a multicast 862 path (e.g., on the expected interface, with expected MPLS label, 863 etc), then a MultipointTail session should not be created. 865 If redundant streams are expected for a given multicast stream, 866 then the implementations should not create more MultipointTail 867 sessions than the number of streams. Additionally, when the 868 number of MultipointTail sessions exceeds the number of expected 869 streams, then the implementation should generate an alarm to users 870 to indicate the anomaly. 872 The implementation should have a reasonable upper bound on the 873 number of MultipointHead sessions that can be created, with the 874 upper bound potentially being computed based on the load these 875 would generate. 877 The implementation should have a reasonable upper bound on the 878 number of MultipointTail sessions that can be created, with the 879 upper bound potentially being computed based on the number of 880 multicast streams that the system is expecting. 882 If authentication is in use, the head and all tails may be configured 883 to have a common authentication key in order for the tails to 884 validate multipoint BFD Control packets. 886 Shared keys in multipoint scenarios allow any tail to spoof the head 887 from the viewpoint of any other tail. For this reason, using shared 888 keys to authenticate BFD Control packets in multipoint scenarios is a 889 significant security exposure unless all tails can be trusted not to 890 spoof the head. Otherwise, asymmetric message authentication would 891 be needed, e.g., protocols that use Timed Efficient Stream Loss- 892 Tolerant Authentication (TESLA) as described in [RFC4082]. 893 Applicability of the assymetric message authentication to BFD for 894 multipoint networks is ouside the scope of this specification and is 895 for further study. 897 9. Contributors 899 Rahul Aggarwal of Juniper Networks and George Swallow of Cisco 900 Systems provided the initial idea for this specification and 901 contributed to its development. 903 10. Acknowledgments 905 Authors would also like to thank Nobo Akiya, Vengada Prasad Govindan, 906 Jeff Haas, Wim Henderickx, Gregory Mirsky and Mingui Zhang who have 907 greatly contributed to this document. 909 11. References 911 11.1. Normative References 913 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 914 Requirement Levels", BCP 14, RFC 2119, 915 DOI 10.17487/RFC2119, March 1997, 916 . 918 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 919 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 920 . 922 [RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. 923 Pallagatti, "Seamless Bidirectional Forwarding Detection 924 (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, 925 . 927 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 928 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 929 Switched (MPLS) Data-Plane Failures", RFC 8029, 930 DOI 10.17487/RFC8029, March 2017, 931 . 933 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 934 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 935 May 2017, . 937 11.2. Informational References 939 [I-D.ietf-bess-mvpn-fast-failover] 940 Morin, T., Kebler, R., and G. Mirsky, "Multicast VPN fast 941 upstream failover", draft-ietf-bess-mvpn-fast-failover-04 942 (work in progress), November 2018. 944 [I-D.ietf-bfd-multipoint-active-tail] 945 Katz, D., Ward, D., Networks, J., and G. Mirsky, "BFD 946 Multipoint Active Tails.", draft-ietf-bfd-multipoint- 947 active-tail-10 (work in progress), November 2018. 949 [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. 950 Briscoe, "Timed Efficient Stream Loss-Tolerant 951 Authentication (TESLA): Multicast Source Authentication 952 Transform Introduction", RFC 4082, DOI 10.17487/RFC4082, 953 June 2005, . 955 [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 956 (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, 957 June 2010, . 959 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 960 and A. Bierman, Ed., "Network Configuration Protocol 961 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 962 . 964 Authors' Addresses 966 Dave Katz 967 Juniper Networks 968 1194 N. Mathilda Ave. 969 Sunnyvale, California 94089-1206 970 USA 972 Email: dkatz@juniper.net 974 Dave Ward 975 Cisco Systems 976 170 West Tasman Dr. 977 San Jose, California 95134 978 USA 980 Email: wardd@cisco.com 982 Santosh Pallagatti (editor) 983 Rtbrick 985 Email: santosh.pallagatti@gmail.com 986 Greg Mirsky (editor) 987 ZTE Corp. 989 Email: gregimirsky@gmail.com