idnits 2.17.1 draft-ietf-bfd-multipoint-18.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. -- The draft header indicates that this document updates RFC5880, 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 (June 18, 2018) is 2138 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-03 == Outdated reference: A later version (-10) exists of draft-ietf-bfd-multipoint-active-tail-08 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 3 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: December 20, 2018 S. Pallagatti, Ed. 7 Individual contributor 8 G. Mirsky, Ed. 9 ZTE Corp. 10 June 18, 2018 12 BFD for Multipoint Networks 13 draft-ietf-bfd-multipoint-18 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 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 5 60 5.1. Multipoint BFD Control Packets . . . . . . . . . . . . . 5 61 5.2. Session Model . . . . . . . . . . . . . . . . . . . . . . 5 62 5.3. Session Failure Semantics . . . . . . . . . . . . . . . . 5 63 5.4. State Variables . . . . . . . . . . . . . . . . . . . . . 5 64 5.4.1. New State Variable Values . . . . . . . . . . . . . . 6 65 5.4.2. State Variable Initialization and Maintenance . . . . 6 66 5.5. State Machine . . . . . . . . . . . . . . . . . . . . . . 6 67 5.6. Session Establishment . . . . . . . . . . . . . . . . . . 7 68 5.7. Discriminators and Packet Demultiplexing . . . . . . . . 7 69 5.8. Packet consumption on tails . . . . . . . . . . . . . . . 8 70 5.9. Bringing Up and Shutting Down Multipoint BFD Service . . 8 71 5.10. Timer Manipulation . . . . . . . . . . . . . . . . . . . 9 72 5.11. Detection Times . . . . . . . . . . . . . . . . . . . . . 9 73 5.12. State Maintenance for Down/AdminDown Sessions . . . . . . 10 74 5.12.1. MultipointHead Sessions . . . . . . . . . . . . . . 10 75 5.12.2. MultipointTail Sessions . . . . . . . . . . . . . . 10 76 5.13. Base Specification Text Replacement . . . . . . . . . . . 10 77 5.13.1. Reception of BFD Control Packets . . . . . . . . . . 11 78 5.13.2. Demultiplexing BFD Control Packets . . . . . . . . . 13 79 5.13.3. Transmitting BFD Control Packets . . . . . . . . . . 14 80 6. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 17 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 82 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 83 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 84 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 85 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 86 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 87 11.2. Informational References . . . . . . . . . . . . . . . . 19 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 90 1. Introduction 92 The Bidirectional Forwarding Detection protocol [RFC5880] specifies a 93 method for verifying unicast connectivity between a pair of systems. 94 This document defines a method for using BFD to provide verification 95 of multipoint or multicast connectivity between a multipoint sender 96 (the "head") and a set of one or more multipoint receivers (the 97 "tails"). 99 As multipoint transmissions are inherently unidirectional, this 100 mechanism purports only to verify this unidirectional connectivity. 101 Although this seems in conflict with the "Bidirectional" in BFD, the 102 protocol is capable of supporting this use case. Use of BFD in 103 Demand mode enables a tail monitor availability of a multipoint path 104 even without the existence of some kind of a return path to the head. 105 As an option, if a return path from a tail to the head exists, the 106 tail may notify the head of the lack of multipoint connectivity. 107 Details of tail notification to the head are outside the scope of 108 this document and are discussed in 109 [I-D.ietf-bfd-multipoint-active-tail]. 111 This application of BFD allows for the tails to detect a lack of 112 connectivity from the head. For some applications such detection of 113 the failure at the tail is useful. For example, use of multipoint 114 BFD to enable fast failure detection and faster failover in multicast 115 VPN described in [I-D.ietf-bess-mvpn-fast-failover]. Due to 116 unidirectional nature, virtually all options and timing parameters 117 are controlled by the head. 119 Throughout this document, the term "multipoint" is defined as a 120 mechanism by which one or more systems receive packets sent by a 121 single sender. This specifically includes such things as IP 122 multicast and point-to-multipoint MPLS. 124 Term "connectivity" in this document is not being used in the context 125 of connectivity verification in transport network but as an 126 alternative to "continuity", i.e., the existence of a forwarding path 127 between the sender and the receiver. 129 This document effectively updates and extends the base BFD 130 specification [RFC5880]. 132 2. Keywords 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 136 "OPTIONAL" in this document are to be interpreted as described in BCP 137 14 [RFC2119] [RFC8174] when, and only when, they appear in all 138 capitals, as shown here. 140 3. Goals 142 The primary goal of this mechanism is to allow tails to rapidly 143 detect the fact that multipoint connectivity from the head has 144 failed. 146 Another goal is for the mechanism to work on any multicast 147 technology. 149 A further goal is to support multiple, overlapping point-to- 150 multipoint paths, as well as multipoint-to-multipoint paths, and to 151 allow point-to-point BFD sessions to operate simultaneously among the 152 systems participating in Multipoint BFD. 154 It is not a goal for this protocol to verify point-to-point bi- 155 directional connectivity between the head and any tail. This can be 156 done independently (and with no penalty in protocol overhead) by 157 using point-to-point BFD. 159 4. Overview 161 The heart of this protocol is the periodic transmission of BFD 162 Control packets along a multipoint path, from the head to all tails 163 on the path. The contents of the BFD packets provide the means for 164 the tails to calculate the detection time for path failure. If no 165 BFD Control packets are received by a tail for a detection time, the 166 tail declares the path to having failed. For some applications this 167 is the only mechanism necessary; the head can remain ignorant of the 168 tails. 170 The head of a multipoint BFD session may wish to be alerted to the 171 tails' connectivity (or lack thereof). Details of how the head keeps 172 track of tails and how tails alert their connectivity to the head are 173 outside scope of this document and are discussed in 174 [I-D.ietf-bfd-multipoint-active-tail]. 176 Although this document describes a single head and a set of tails 177 spanned by a single multipoint path, the protocol is capable of 178 supporting (and discriminating between) more than one multipoint path 179 at both heads and tails, as described in Section 5.7 and 180 Section 5.13.2. Furthermore, the same head and tail may share 181 multiple multipoint paths, and a multipoint path may have multiple 182 heads. 184 5. Protocol Details 186 This section describes the operation of Multipoint BFD in detail. 188 5.1. Multipoint BFD Control Packets 190 Multipoint BFD Control packets (packets sent by the head over a 191 multipoint path) are explicitly marked as such, via the setting of 192 the M bit [RFC5880]. This means that Multipoint BFD does not depend 193 on the recipient of a packet to know whether the packet was received 194 over a multipoint path. This can be useful in scenarios where this 195 information may not be available to the recipient. 197 5.2. Session Model 199 Multipoint BFD is modeled as a set of sessions of different types. 200 The elements of procedure differ slightly for each type. 202 The head has a session of type MultipointHead, as defined in 203 Section 5.4.1, that is bound to a multipoint path. Multipoint BFD 204 Control packets are sent by this session over the multipoint path, 205 and no BFD Control packets are received by it. 207 Each tail has a session of type MultipointTail, as defined in 208 Section 5.4.1, associated with a multipoint path. These sessions 209 receive BFD Control packets from the head over the multipoint path. 211 5.3. Session Failure Semantics 213 The semantics of session failure is subtle enough to warrant further 214 explanation. 216 MultipointHead sessions cannot fail (since they are controlled 217 administratively). 219 If a MultipointTail session fails, it means that the tail definitely 220 has lost contact with the head (or the head has been administratively 221 disabled) and the tail should take appropriate action. 223 5.4. State Variables 225 Multipoint BFD introduces some new state variables and modifies the 226 usage of a few existing ones. 228 5.4.1. New State Variable Values 230 A number of new values of the state variable bfd.SessionType are 231 added to the base BFD [RFC5880] and base S-BFD [RFC7880] 232 specifications in support of Multipoint BFD. 234 bfd.SessionType 236 The type of this session as defined in [RFC7880]. Newly added 237 values are: 239 PointToPoint: Classic point-to-point BFD, as described in 240 [RFC5880]. 242 MultipointHead: A session on the head responsible for the 243 periodic transmission of multipoint BFD Control packets 244 along the multipoint path. 246 MultipointTail: A multipoint session on a tail. 248 This variable MUST be initialized to the appropriate type when 249 the session is created. 251 5.4.2. State Variable Initialization and Maintenance 253 Some state variables defined in section 6.8.1 of [RFC5880] need to be 254 initialized or manipulated differently depending on the session type. 256 bfd.RequiredMinRxInterval 258 This variable MUST be initialized to 0 for session type 259 MultipointHead. 261 bfd.DemandMode 263 This variable MUST be initialized to 1 for session type 264 MultipointHead and MUST be initialized to 0 for session type 265 MultipointTail. 267 5.5. State Machine 269 The BFD state machine works slightly differently in the multipoint 270 application. In particular, since there is a many-to-one mapping, 271 three-way handshakes for session establishment and teardown are 272 neither possible nor appropriate. As such, there is no Init state. 273 Sessions of type MultipointHead MUST NOT send BFD control packets 274 with the State field being set to INIT, and those packets MUST be 275 ignored on receipt. 277 The following diagram provides an overview of the state machine for 278 session type MultipointTail. The notation on each arc represents the 279 state of the remote system (as received in the State field in the BFD 280 Control packet) or indicates the expiration of the Detection Timer. 282 DOWN, ADMIN DOWN, 283 +------+ TIMER +------+ 284 +----| |<---------------------| |----+ 285 DOWN,| | DOWN | | UP | |UP 286 ADMIN DOWN,+--->| |--------------------->| |<---+ 287 TIMER +------+ UP +------+ 289 Sessions of type MultipointHead never receive packets and have no 290 Detection Timer, and as such all state transitions are 291 administratively driven. 293 5.6. Session Establishment 295 Unlike point-to-point BFD, Multipoint BFD provides a form of the 296 discovery mechanism for tails to discover the head. The minimum 297 amount of a priori information required both on the head and tails is 298 the binding to the multipoint path over which BFD is running. The 299 head transmits Multipoint BFD packets on that path, and the tails 300 listen for BFD packets on that path. All other information MAY be 301 determined dynamically. 303 A session of type MultipointHead is created for each multipoint path 304 over which the head wishes to run BFD. This session runs in the 305 Active role , per section 6.1 [RFC5880]. Except when 306 administratively terminating BFD service, this session is always in 307 state Up and always operates in Demand mode. No received packets are 308 ever demultiplexed to the MultipointHead session. In this sense, it 309 is a degenerate form of a session. 311 Sessions on the tail MAY be established dynamically, based on the 312 receipt of a Multipoint BFD Control packet from the head, and are of 313 type MultipointTail. Tail sessions always take the Passive role, per 314 section 6.1 [RFC5880]. 316 5.7. Discriminators and Packet Demultiplexing 318 The use of Discriminators is somewhat different in Multipoint BFD 319 than in Point-to-point BFD. 321 The head sends Multipoint BFD Control packets over the multipoint 322 path via the MultipointHead session with My Discr set to a value 323 bound to the multipoint path, and with Your Discr set to zero. 325 IP and MPLS multipoint tails MUST demultiplex BFD packets based on a 326 combination of the source address, My Discriminator and the identity 327 of the multipoint path which the Multipoint BFD Control packet was 328 received from. Together they uniquely identify the head of the 329 multipoint path. Bootstrapping BFD session to multipoint MPLS LSP in 330 case of penultimate hop popping may use control plane, e.g., as 331 described in [I-D.ietf-bess-mvpn-fast-failover], and is outside the 332 scope of this document. 334 Note that, unlike point-to-point sessions, the My Discriminator value 335 on MultipointHead session MUST NOT be changed during the life of a 336 session. This is a side effect of the more complex demultiplexing 337 scheme. 339 5.8. Packet consumption on tails 341 BFD packets received on tails for an IP multicast group MUST be 342 consumed by tails and MUST NOT be forwarded to receivers. Nodes with 343 the BFD session of type MultipointTail MUST identify packets received 344 on an IP multipoint path as BFD control packet if the destination UDP 345 port value equals 3784. 347 For multipoint LSPs, when IP/UDP encapsulation of BFD control packets 348 is used, MultipointTail MUST expect destination UDP port 3784. 349 Destination IP address of BFD control packet MUST be in 127.0.0.0/8 350 range for IPv4 or in 0:0:0:0:0:FFFF:7F00:0/104 range for IPv6. The 351 use of these destination addresses is consistent with the 352 explanations and usage in [RFC8029]. Packets identified as BFD 353 packets MUST be consumed by MultipointTail and demultiplexed as 354 described in Section 5.13.2. Use of other types of encapsulation of 355 the BFD control message over multipoint LSP is outside the scope of 356 this document. 358 5.9. Bringing Up and Shutting Down Multipoint BFD Service 360 Because there is no three-way handshake in Multipoint BFD, a newly 361 started head (that does not have any previous state information 362 available) SHOULD start with bfd.SessionState set to Down and 363 bfd.RequiredMinRxInterval MUST be set to zero in the MultipointHead 364 session. The session SHOULD remain in this state for a time equal to 365 (bfd.DesiredMinTxInterval * bfd.DetectMult). This will ensure that 366 all MultipointTail sessions are reset (so long as the restarted head 367 is using the same or a larger value of bfd.DesiredMinTxInterval than 368 it did previously). 370 Multipoint BFD service is brought up by administratively setting 371 bfd.SessionState to Up in the MultipointHead session. 373 The head of a multipoint BFD session may wish to shut down its BFD 374 service in a controlled fashion. This is desirable because the tails 375 need not wait a detection time prior to declaring the multipoint 376 session to be down (and taking whatever action is necessary in that 377 case). 379 To shut down a multipoint session in a controlled fashion the head 380 MUST administratively set bfd.SessionState in the MultipointHead 381 session to either Down or AdminDown and SHOULD set 382 bfd.RequiredMinRxInterval to zero. The session SHOULD send BFD 383 Control packets in this state for a period equal to 384 (bfd.DesiredMinTxInterval * bfd.DetectMult). Alternatively, the head 385 MAY stop transmitting BFD Control packets and not send any more BFD 386 Control packets with the new state (Down or AdminDown). Tails will 387 declare the multipoint session down only after the detection time 388 interval runs out. 390 5.10. Timer Manipulation 392 Because of the one-to-many mapping, a session of type MultipointHead 393 SHOULD NOT initiate a Poll Sequence in conjunction with timer value 394 changes. However, to indicate a change in the packets, 395 MultipointHead session MUST send packets with the P bit set. 396 MultipointTail session MUST NOT reply if the packet has M and P bits 397 set and bfd.RequiredMinRxInterval set to 0. Because the Poll 398 Sequence is not used, the tail cannot negotiate down MultpointHead's 399 transmit interval. If the value of Desired Min TX Interval in the 400 BFD Control packet received by MultipointTail is too high (that 401 determination may change in time based on the current environment) it 402 must be handled by the implementation and may be controlled by local 403 policy, e.g., close the MultipointTail session. 405 The MultipointHead, when changing the transmit interval to a higher 406 value, MUST send BFD control packets with P bit set at the old 407 transmit interval before using the higher value in order to avoid 408 false detection timeouts at the tails. MultipointHead session MAY 409 also wait some amount of time before making the changes to the 410 transmit interval (through configuration). 412 Change in the value of bfd.RequiredMinRxInterval is outside the scope 413 of this document and is discussed in 414 [I-D.ietf-bfd-multipoint-active-tail]. 416 5.11. Detection Times 418 Multipoint BFD is inherently asymmetric. As such, each session type 419 has a different approach to detection times. 421 Since MultipointHead sessions never receive packets, they do not 422 calculate a detection time. 424 MultipointTail sessions cannot influence the transmission rate of the 425 MultipointHead session using the Required Min Rx Interval field 426 because of its one-to-many nature. As such, the detection time 427 calculation for a MultipointTail session does not use 428 bfd.RequiredMinRxInterval. The detection time is calculated as the 429 product of the last received values of Desired Min TX Interval and 430 Detect Mult. 432 The value of bfd.DetectMult may be changed at any time on any session 433 type. 435 5.12. State Maintenance for Down/AdminDown Sessions 437 The length of time session state is kept after the session goes down 438 determines how long the session will continue to send BFD Control 439 packets (since no packets can be sent after the session is 440 destroyed). 442 5.12.1. MultipointHead Sessions 444 When a MultipointHead session transitions to states Down or 445 AdminDown, the state SHOULD be maintained for a period equal to 446 (bfd.DesiredMinTxInterval * bfd.DetectMult) to ensure that the tails 447 more quickly detect the session going down (by continuing to transmit 448 BFD Control packets with the new state). 450 5.12.2. MultipointTail Sessions 452 MultipointTail sessions MAY be destroyed immediately upon leaving Up 453 state, since tail will transmit no packets. 455 Otherwise, MultipointTail sessions SHOULD be maintained as long as 456 BFD Control packets are being received by it (which by definition 457 will indicate that the head is not Up). 459 5.13. Base Specification Text Replacement 461 The following sections are meant to replace the corresponding 462 sections in the base specification [RFC5880] in support of BFD for 463 multipoint networks while not changing processing for point-to-point 464 BFD. 466 5.13.1. Reception of BFD Control Packets 468 The following procedure replaces the entire section 6.8.6 of 469 [RFC5880]. 471 When a BFD Control packet is received, the following procedure MUST 472 be followed, in the order specified. If the packet is discarded 473 according to these rules, processing of the packet MUST cease at that 474 point. 476 If the version number is not correct (1), the packet MUST be 477 discarded. 479 If the Length field is less than the minimum correct value (24 if 480 the A bit is clear, or 26 if the A bit is set), the packet MUST be 481 discarded. 483 If the Length field is greater than the payload of the 484 encapsulating protocol, the packet MUST be discarded. 486 If the Detect Mult field is zero, the packet MUST be discarded. 488 If the My Discriminator field is zero, the packet MUST be 489 discarded. 491 Demultiplex the packet to a session according to Section 5.13.2 492 below. The result is either a session of the proper type, or the 493 packet is discarded (and packet processing MUST cease). 495 If the A bit is set and no authentication is in use (bfd.AuthType 496 is zero), the packet MUST be discarded. 498 If the A bit is clear and authentication is in use (bfd.AuthType 499 is nonzero), the packet MUST be discarded. 501 If the A bit is set, the packet MUST be authenticated under the 502 rules of [RFC5880] section 6.7, based on the authentication type 503 in use (bfd.AuthType). This may cause the packet to be discarded. 505 Set bfd.RemoteDiscr to the value of My Discriminator. 507 Set bfd.RemoteState to the value of the State (Sta) field. 509 Set bfd.RemoteDemandMode to the value of the Demand (D) bit. 511 Set bfd.RemoteMinRxInterval to the value of Required Min RX 512 Interval. 514 If the Required Min Echo RX Interval field is zero, the 515 transmission of Echo packets, if any, MUST cease. 517 If a Poll Sequence is being transmitted by the local system and 518 the Final (F) bit in the received packet is set, the Poll Sequence 519 MUST be terminated. 521 If bfd.SessionType is PointToPoint, update the transmit interval 522 as described in [RFC5880] section 6.8.2. 524 If bfd.SessionType is PointToPoint, update the Detection Time as 525 described in section 6.8.4 of [RFC5880]. 527 Else 529 If bfd.SessionType is MultipointTail, then update the Detection 530 Time as the product of the last received values of Desired Min 531 TX Interval and Detect Mult, as described in Section 5.11 of 532 this specification. 534 If bfd.SessionState is AdminDown 536 Discard the packet 538 If the received state is AdminDown 540 If bfd.SessionState is not Down 542 Set bfd.LocalDiag to 3 (Neighbor signaled session down) 544 Set bfd.SessionState to Down 546 Else 548 If bfd.SessionState is Down 550 If bfd.SessionType is PointToPoint 552 If received State is Down 554 Set bfd.SessionState to Init 556 Else if received State is Init 558 Set bfd.SessionState to Up 560 Else (bfd.SessionType is not PointToPoint) 561 If received State is Up 563 Set bfd.SessionState to Up 565 Else if bfd.SessionState is Init 567 If received State is Init or Up 569 Set bfd.SessionState to Up 571 Else (bfd.SessionState is Up) 573 If received State is Down 575 Set bfd.LocalDiag to 3 (Neighbor signaled session down) 577 Set bfd.SessionState to Down 579 Check to see if Demand mode should become active or not (see 580 [RFC5880] section 6.6). 582 If bfd.RemoteDemandMode is 1, bfd.SessionState is Up and 583 bfd.RemoteSessionState is Up, Demand mode is active on the remote 584 system and the local system MUST cease the periodic transmission 585 of BFD Control packets (see Section 5.13.3). 587 If bfd.RemoteDemandMode is 0, or bfd.SessionState is not Up, or 588 bfd.RemoteSessionState is not Up, Demand mode is not active on the 589 remote system and the local system MUST send periodic BFD Control 590 packets (see Section 5.13.3). 592 If the packet was not discarded, it has been received for purposes 593 of the Detection Time expiration rules in [RFC5880] section 6.8.4. 595 5.13.2. Demultiplexing BFD Control Packets 597 This section is part of the replacement for [RFC5880] section 6.8.6, 598 separated for clarity. 600 If the Multipoint (M) bit is set 602 If the Your Discriminator field is nonzero, the packet MUST be 603 discarded. 605 Select a session as based on source address, My Discriminator 606 and the identity of the multipoint path which the Multipoint 607 BFD Control packet was received. 609 If a session is found, and bfd.SessionType is not 610 MultipointTail, the packet MUST be discarded. 612 Else 614 If a session is not found, a new session of type 615 MultipointTail MAY be created, or the packet MAY be 616 discarded. This choice MAY be controlled by the local 617 policy, e.g. a maximum number of MultipointTail sessions and 618 number of active MultipointTail sessions, and is outside the 619 scope of this specification. 621 Else (Multipoint bit is clear) 623 If the Your Discriminator field is nonzero 625 Select a session based on the value of Your Discriminator. 626 If no session is found, the packet MUST be discarded. 628 Else (Your Discriminator is zero) 630 If the State field is not Down or AdminDown, the packet MUST 631 be discarded. 633 Otherwise, the session MUST be selected based on some 634 combination of other fields, possibly including source 635 addressing information, the My Discriminator field, and the 636 interface over which the packet was received. The exact 637 method of selection is application-specific and is thus 638 outside the scope of this specification. 640 If a matching session is found, and bfd.SessionType is not 641 PointToPoint, the packet MUST be discarded. 643 If a matching session is not found, a new session of type 644 PointToPoint MAY be created, or the packet MAY be discarded. 645 This choice MAY be controlled by a local policy and is 646 outside the scope of this specification. 648 If the State field is Init and bfd.SessionType is not 649 PointToPoint, the packet MUST be discarded. 651 5.13.3. Transmitting BFD Control Packets 653 The following procedure replaces the entire section 6.8.7 of 654 [RFC5880]. 656 BFD Control packets MUST be transmitted periodically at the rate 657 determined according to [RFC5880] section 6.8.2, except as specified 658 in this section. 660 A system MUST NOT transmit any BFD Control packets if bfd.RemoteDiscr 661 is zero and the system is taking the Passive role. 663 A system MUST NOT transmit any BFD Control packets if bfd.SessionType 664 is MultipointTail. 666 A system MUST NOT periodically transmit BFD Control packets if Demand 667 mode is active on the remote system (bfd.RemoteDemandMode is 1, 668 bfd.SessionState is Up, and bfd.RemoteSessionState is Up) and a Poll 669 Sequence is not being transmitted. 671 A system MUST NOT periodically transmit BFD Control packets if 672 bfd.RemoteMinRxInterval is zero. 674 If bfd.SessionType is MultipointHead, the transmit interval MUST be 675 set to bfd.DesiredMinTxInterval (this should happen automatically, as 676 bfd.RemoteMinRxInterval will be zero). 678 If bfd.SessionType is not MultipointHead, the transmit interval MUST 679 be recalculated whenever bfd.DesiredMinTxInterval changes, or 680 whenever bfd.RemoteMinRxInterval changes, and is equal to the greater 681 of those two values. See [RFC5880] sections 6.8.2 and 6.8.3 for 682 details on transmit timers. 684 A system MUST NOT set the Demand (D) bit if bfd.SessionType is 685 MultipointTail. 687 A system MUST NOT set the Demand (D) bit if bfd.SessionType 688 PointToPoint unless bfd.DemandMode is 1, bfd.SessionState is Up, and 689 bfd.RemoteSessionState is Up. 691 If bfd.SessionType is PointToPoint or MultipointHead, a BFD Control 692 packet SHOULD be transmitted during the interval between periodic 693 Control packet transmissions when the contents of that packet would 694 differ from that in the previously transmitted packet (other than the 695 Poll and Final bits) in order to more rapidly communicate a change in 696 state. 698 The contents of transmitted BFD Control packets MUST be set as 699 follows: 701 Version 703 Set to the current version number (1). 705 Diagnostic (Diag) 707 Set to bfd.LocalDiag. 709 State (Sta) 711 Set to the value indicated by bfd.SessionState. 713 Poll (P) 715 Set to 1 if the local system is sending a Poll Sequence or is a 716 session of type MultipointHead soliciting the identities of the 717 tails, or 0 if not. 719 Final (F) 721 Set to 1 if the local system is responding to a Control packet 722 received with the Poll (P) bit set, or 0 if not. 724 Control Plane Independent (C) 726 Set to 1 if the local system's BFD implementation is 727 independent of the control plane (it can continue to function 728 through a disruption of the control plane). 730 Authentication Present (A) 732 Set to 1 if authentication is in use in this session 733 (bfd.AuthType is nonzero), or 0 if not. 735 Demand (D) 737 Set to bfd.DemandMode if bfd.SessionState is Up and 738 bfd.RemoteSessionState is Up. Set to 1 if bfd.SessionType is 739 MultipointHead. Otherwise it is set to 0. 741 Multipoint (M) 743 Set to 1 if bfd.SessionType is MultipointHead. Otherwise, it 744 is set to 0. 746 Detect Mult 748 Set to bfd.DetectMult. 750 Length 751 Set to the appropriate length, based on the fixed header length 752 (24) plus any Authentication Section. 754 My Discriminator 756 Set to bfd.LocalDiscr. 758 Your Discriminator 760 Set to bfd.RemoteDiscr. 762 Desired Min TX Interval 764 Set to bfd.DesiredMinTxInterval. 766 Required Min RX Interval 768 Set to bfd.RequiredMinRxInterval. 770 Required Min Echo RX Interval 772 Set to 0 if bfd.SessionType is MultipointHead or 773 MultipointTail. 775 Authentication Section 777 Included and set according to the rules in [RFC5880] section 778 6.7 if authentication is in use (bfd.AuthType is nonzero). 779 Otherwise, this section is not present. 781 6. Assumptions 783 If authentication is in use, the head and all tails may be configured 784 to have a common authentication key in order for the tails to 785 validate multipoint BFD Control packets. 787 Shared keys in multipoint scenarios allow any tail to spoof the head 788 from the viewpoint of any other tail. For this reason, using shared 789 keys to authenticate BFD Control packets in multipoint scenarios is a 790 significant security exposure unless all tails can be trusted not to 791 spoof the head. Otherwise, asymmetric message authentication would 792 be needed, e.g., protocols that use Timed Efficient Stream Loss- 793 Tolerant Authentication (TESLA) as described in [RFC4082]. 795 7. IANA Considerations 797 This document has no actions for IANA. 799 8. Security Considerations 801 The same security considerations as those described in [RFC5880] 802 apply to this document. Additionally, implementations that create 803 MultpointTail sessions dynamically upon receipt of Multipoint BFD 804 Control packets MUST implement protective measures to prevent an 805 infinite number of MultipointTail sessions being created. Below are 806 listed some points to be considered in such implementations. 808 If a Multipoint BFD Control packet did not arrive on a multicast 809 path (e.g., on the expected interface, with expected MPLS label, 810 etc), then a MultipointTail session should not be created. 812 If redundant streams are expected for a given multicast stream, 813 then the implementations should not create more MultipointTail 814 sessions than the number of streams. Additionally, when the 815 number of MultipointTail sessions exceeds the number of expected 816 streams, then the implementation should generate an alarm to users 817 to indicate the anomaly. 819 The implementation should have a reasonable upper bound on the 820 number of MultipointTail sessions that can be created, with the 821 upper bound potentially being computed based on the number of 822 multicast streams that the system is expecting. 824 9. Contributors 826 Rahul Aggarwal of Juniper Networks and George Swallow of Cisco 827 Systems provided the initial idea for this specification and 828 contributed to its development. 830 10. Acknowledgments 832 Authors would also like to thank Nobo Akiya, Vengada Prasad Govindan, 833 Jeff Haas, Wim Henderickx, Gregory Mirsky and Mingui Zhang who have 834 greatly contributed to this document. 836 11. References 838 11.1. Normative References 840 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 841 Requirement Levels", BCP 14, RFC 2119, 842 DOI 10.17487/RFC2119, March 1997, 843 . 845 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 846 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 847 . 849 [RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. 850 Pallagatti, "Seamless Bidirectional Forwarding Detection 851 (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, 852 . 854 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 855 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 856 Switched (MPLS) Data-Plane Failures", RFC 8029, 857 DOI 10.17487/RFC8029, March 2017, 858 . 860 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 861 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 862 May 2017, . 864 11.2. Informational References 866 [I-D.ietf-bess-mvpn-fast-failover] 867 Morin, T., Kebler, R., and G. Mirsky, "Multicast VPN fast 868 upstream failover", draft-ietf-bess-mvpn-fast-failover-03 869 (work in progress), May 2018. 871 [I-D.ietf-bfd-multipoint-active-tail] 872 Katz, D., Ward, D., Networks, J., and G. Mirsky, "BFD 873 Multipoint Active Tails.", draft-ietf-bfd-multipoint- 874 active-tail-08 (work in progress), June 2018. 876 [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. 877 Briscoe, "Timed Efficient Stream Loss-Tolerant 878 Authentication (TESLA): Multicast Source Authentication 879 Transform Introduction", RFC 4082, DOI 10.17487/RFC4082, 880 June 2005, . 882 Authors' Addresses 883 Dave Katz 884 Juniper Networks 885 1194 N. Mathilda Ave. 886 Sunnyvale, California 94089-1206 887 USA 889 Email: dkatz@juniper.net 891 Dave Ward 892 Cisco Systems 893 170 West Tasman Dr. 894 San Jose, California 95134 895 USA 897 Email: wardd@cisco.com 899 Santosh Pallagatti (editor) 900 Individual contributor 902 Email: santosh.pallagatti@gmail.com 904 Greg Mirsky (editor) 905 ZTE Corp. 907 Email: gregimirsky@gmail.com