idnits 2.17.1 draft-ietf-bfd-seamless-base-11.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 (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 (May 6, 2016) is 2910 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 (-06) exists of draft-ietf-bfd-seamless-ip-04 == Outdated reference: A later version (-08) exists of draft-ietf-bfd-seamless-use-case-06 -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force C. Pignataro 3 Internet-Draft D. Ward 4 Updates: 5880 (if approved) Cisco 5 Intended status: Standards Track N. Akiya 6 Expires: November 7, 2016 Big Switch Networks 7 M. Bhatia 8 Ionos Networks 9 S. Pallagatti 10 May 6, 2016 12 Seamless Bidirectional Forwarding Detection (S-BFD) 13 draft-ietf-bfd-seamless-base-11 15 Abstract 17 This document defines a simplified mechanism to use Bidirectional 18 Forwarding Detection (BFD) with large portions of negotiation aspects 19 eliminated, thus providing benefits such as quick provisioning as 20 well as improved control and flexibility to network nodes initiating 21 the path monitoring. 23 This document updates RFC5880. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on November 7, 2016. 48 Copyright Notice 50 Copyright (c) 2016 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Seamless BFD Overview . . . . . . . . . . . . . . . . . . . . 5 68 4. S-BFD Discriminators . . . . . . . . . . . . . . . . . . . . 6 69 4.1. S-BFD Discriminator Uniqueness . . . . . . . . . . . . . 6 70 4.2. Discriminator Pools . . . . . . . . . . . . . . . . . . . 7 71 5. Reflector BFD Session . . . . . . . . . . . . . . . . . . . . 7 72 6. State Variables . . . . . . . . . . . . . . . . . . . . . . . 8 73 6.1. New State Variables . . . . . . . . . . . . . . . . . . . 8 74 6.2. State Variable Initialization and Maintenance . . . . . . 9 75 7. S-BFD Procedures . . . . . . . . . . . . . . . . . . . . . . 9 76 7.1. Demultiplexing of S-BFD Control Packet . . . . . . . . . 9 77 7.2. Responder Procedures . . . . . . . . . . . . . . . . . . 10 78 7.2.1. Responder Demultiplexing . . . . . . . . . . . . . . 10 79 7.2.2. Transmission of S-BFD Control Packet by SBFDReflector 10 80 7.2.3. Additional SBFDReflector Behaviors . . . . . . . . . 11 81 7.3. Initiator Procedures . . . . . . . . . . . . . . . . . . 12 82 7.3.1. SBFDInitiator State Machine . . . . . . . . . . . . . 12 83 7.3.2. Transmission of S-BFD Control Packet by SBFDInitiator 13 84 7.3.3. Additional SBFDInitiator Behaviors . . . . . . . . . 14 85 7.4. Diagnostic Values . . . . . . . . . . . . . . . . . . . . 14 86 7.5. The Poll Sequence . . . . . . . . . . . . . . . . . . . . 15 87 8. Operational Considerations . . . . . . . . . . . . . . . . . 15 88 8.1. Scaling Aspect . . . . . . . . . . . . . . . . . . . . . 15 89 8.2. Congestion Considerations . . . . . . . . . . . . . . . . 16 90 9. Co-existence with Classical BFD Sessions . . . . . . . . . . 16 91 10. S-BFD Echo Function . . . . . . . . . . . . . . . . . . . . . 16 92 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 93 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 94 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 95 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 96 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 97 15.1. Normative References . . . . . . . . . . . . . . . . . . 19 98 15.2. Informative References . . . . . . . . . . . . . . . . . 19 99 Appendix A. Loop Problem and Solution . . . . . . . . . . . . . 20 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 102 1. Introduction 104 Bidirectional Forwarding Detection (BFD), [RFC5880] and related 105 documents, has efficiently generalized the failure detection 106 mechanism for multiple protocols and applications. There are some 107 improvements that can be made to better fit existing technologies. 108 There is a possibility of evolving BFD to better fit new 109 technologies. This document focuses on several aspects of BFD in 110 order to further improve efficiency, to expand failure detection 111 coverage and to allow BFD usage for wider scenarios. Additional use 112 cases are listed in [I-D.ietf-bfd-seamless-use-case]. 114 Specifically, this document defines Seamless Bidirectional Forwarding 115 Detection (S-BFD) a simplified mechanism to use Bidirectional 116 Forwarding Detection (BFD) with large portions of negotiation aspects 117 eliminated, thus providing benefits such as quick provisioning as 118 well as improved control and flexibility to network nodes initiating 119 the path monitoring. S-BFD enables cases benefiting from the use of 120 core BFD technologies in a fashion that leverages existing 121 implementations and protocol machinery while providing a rather 122 simplified and largely stateless infrastructure for continuity 123 testing. 125 One key aspect of the mechanism described in this document eliminates 126 the time between a network node wanting to perform a continuity test 127 and completing the continuity test. In traditional BFD terms, the 128 initial state changes from DOWN to UP are virtually nonexistent. 129 Removal of this seam (i.e., time delay) in BFD provides applications 130 a smooth and continuous operational experience. Therefore, "Seamless 131 BFD" (S-BFD) has been chosen as the name for this mechanism. 133 2. Terminology 135 The reader is expected to be familiar with the BFD [RFC5880], IP 136 [RFC0791] [RFC2460] and MPLS [RFC3031] terminologies and protocol 137 constructs. This section describes several new terminologies 138 introduced by S-BFD. 140 o Classical BFD - BFD session types based on [RFC5880]. 142 o S-BFD - Seamless BFD. 144 o S-BFD control packet - a BFD control packet for the S-BFD 145 mechanism. 147 o S-BFD echo packet - a BFD echo packet for the S-BFD mechanism. 149 o S-BFD packet - a BFD control packet or a BFD echo packet. 151 o Entity - a function on a network node that S-BFD mechanism allows 152 remote network nodes to perform continuity test to. An entity can 153 be abstract (e.g., reachability) or specific (e.g., IP addresses, 154 router-IDs, functions). 156 o SBFDInitiator - an S-BFD session on a network node that performs a 157 continuity test to a remote entity by sending S-BFD packets. 159 o SBFDReflector - an S-BFD session on a network node that listens 160 for incoming S-BFD control packets to local entities and generates 161 response S-BFD control packets. 163 o Reflector BFD session - synonymous with SBFDReflector. 165 o S-BFD discriminator - a BFD discriminator allocated for a local 166 entity and is being listened by an SBFDReflector. 168 o BFD discriminator - a BFD discriminator allocated for an 169 SBFDInitiator. 171 o Initiator - a network node hosting an SBFDInitiator. 173 o Responder - a network node hosting an SBFDReflector. 175 Figure 1 describes the relationship between S-BFD terminologies. 177 +---------------------+ +------------------------+ 178 | Initiator | | Responder | 179 | +-----------------+ | | +-----------------+ | 180 | | SBFDInitiator |---S-BFD ctrl pkt----->| SBFDReflector | | 181 | | +-------------+ |<--S-BFD ctrl pkt------| +-------------+ | | 182 | | | BFD discrim | | | | | |S-BFD discrim| | | 183 | | | | |---S-BFD echo pkt---+ | | | | | 184 | | +-------------+ | | | | | +----------^--+ | | 185 | +-----------------+<-------------------+ +------------|----+ | 186 | | | | | 187 | | | +---v----+ | 188 | | | | Entity | | 189 | | | +--------+ | 190 +---------------------+ +------------------------+ 192 Figure 1: S-BFD Terminology Relationship 194 3. Seamless BFD Overview 196 An S-BFD module on each network node allocates one or more S-BFD 197 discriminators for local entities, and creates a reflector BFD 198 session. Allocated S-BFD discriminators may be advertised by 199 applications (e.g., OSPF/IS-IS). Required result is that 200 applications, on other network nodes, possess the knowledge of the 201 S-BFD discriminators allocated by a remote node to remote entities. 202 The reflector BFD session is to, upon receiving an S-BFD control 203 packet targeted to one of local S-BFD discriminator values, transmit 204 a response S-BFD control packet back to the initiator. 206 Once the above setup is complete, any network node, having the 207 knowledge of the S-BFD discriminator allocated by a remote node to 208 remote entity/entities, can quickly perform a continuity test to the 209 remote entity by simply sending S-BFD control packets with 210 corresponding S-BFD discriminator value in the "your discriminator" 211 field. 213 This is exemplified in Figure 2. 215 <------- IS-IS Network -------> 217 +---------+ 218 | | 219 A---------B---------C---------D 220 ^ ^ 221 | | 222 SystemID SystemID 223 xxx yyy 224 BFD Discrim BFD Discrim 225 123 456 227 Figure 2: S-BFD for IS-IS Network 229 S-BFD module in a system IS-IS SystemID xxx (node A) allocates an 230 S-BFD discriminator 123, and IS-IS advertises the S-BFD discriminator 231 123 in an IS-IS TLV. S-BFD module in a system with IS-IS SystemID 232 yyy (node D) allocates an S-BFD discriminator 456, and IS-IS 233 advertises the S-BFD discriminator 456 in an IS-IS TLV. A reflector 234 BFD session is created on both network nodes (node A and node D). 235 When network node A wants to check the reachability to network node 236 D, node A can send an S-BFD control packet, destined to node D, with 237 "your discriminator" field set to 456. When the reflector BFD 238 session on node D receives this S-BFD control packet, then a response 239 S-BFD control packet is sent back to node A, which allows node A to 240 complete the continuity test. 242 When a node allocates multiple S-BFD discriminators, how remote nodes 243 determine which of the discriminators is associated with a specific 244 entity is currently unspecified. The use of multiple S-BFD 245 discriminators by a single network node is therefore discouraged 246 until a means of learning the mapping is defined. 248 4. S-BFD Discriminators 250 4.1. S-BFD Discriminator Uniqueness 252 One important characteristic of an S-BFD discriminator is that it 253 MUST be unique within an administrative domain. If multiple network 254 nodes allocated the same S-BFD discriminator value, then S-BFD 255 control packets falsely terminating on a wrong network node can 256 result in a reflector BFD session to generate a response back, due to 257 "your discriminator" matching. This is clearly not desirable. 259 4.2. Discriminator Pools 261 This subsection describes a discriminator pool implementation 262 technique to minimize S-BFD discriminator collisions. The result 263 will allow an implementation to better satisfy the S-BFD 264 discriminator uniqueness requirement defined in Section 4.1. 266 o SBFDInitiator is to allocate a discriminator from the BFD 267 discriminator pool. If the system also supports classical BFD 268 that runs on [RFC5880], then the BFD discriminator pool SHOULD be 269 shared by SBFDInitiator sessions and classical BFD sessions. 271 o SBFDReflector is to allocate a discriminator from the S-BFD 272 discriminator pool. The S-BFD discriminator pool SHOULD be a 273 separate pool than the BFD discriminator pool. 275 The remainder of this subsection describes the reasons for the 276 suggestions above. 278 Locally allocated S-BFD discriminator values for entities, listened 279 by SBFDReflector sessions, may be arbitrary allocated or derived from 280 values provided by applications. These values may be protocol IDs 281 (e.g., System-ID, Router-ID) or network targets (e.g., IP address). 282 To avoid derived S-BFD discriminator values already being assigned to 283 other BFD sessions (i.e., SBFDInitiator sessions and classical BFD 284 sessions), it is RECOMMENDED that the discriminator pool for 285 SBFDReflector sessions be separate from other BFD sessions. 287 Even when following the separate discriminator pool approach, 288 collision is still possible between one S-BFD application to another 289 S-BFD application, that may be using different values and algorithms 290 to derive S-BFD discriminator values. If the two applications are 291 using S-BFD for the same purpose (e.g., network reachability), then 292 the colliding S-BFD discriminator value can be shared. If the two 293 applications are using S-BFD for a different purpose, then the 294 collision must be addressed. The use of multiple S-BFD 295 discriminators by a single network node, however, is discouraged (see 296 Section 3). 298 5. Reflector BFD Session 300 Each network node creates one or more reflector BFD sessions. This 301 reflector BFD session is a session that transmits S-BFD control 302 packets in response to received S-BFD control packets with "your 303 discriminator" having S-BFD discriminators allocated for local 304 entities. Specifically, this reflector BFD session has the following 305 characteristics: 307 o MUST NOT transmit any S-BFD packets based on local timer expiry. 309 o MUST transmit an S-BFD control packet in response to a received 310 S-BFD control packet having a valid S-BFD discriminator in the 311 "your discriminator" field, unless prohibited by local policies 312 (e.g., administrative, security, rate-limiter, etc.) 314 o MUST be capable of sending only two states: UP and ADMINDOWN. 316 One reflector BFD session may be responsible for handling received 317 S-BFD control packets targeted to all locally allocated S-BFD 318 discriminators, or few reflector BFD sessions may each be responsible 319 for subset of locally allocated S-BFD discriminators. This policy is 320 a local matter, and is outside the scope of this document. 322 Note that incoming S-BFD control packets may be IPv4, IPv6 or MPLS 323 based [I-D.ietf-bfd-seamless-ip], and other options are possible and 324 can be defined in future documents. How such S-BFD control packets 325 reach an appropriate reflector BFD session is also a local matter, 326 and is outside the scope of this document. 328 6. State Variables 330 S-BFD introduces new state variables, and modifies the usage of 331 existing ones. 333 6.1. New State Variables 335 A new state variable is added to the base specification in support of 336 S-BFD. 338 o bfd.SessionType: This is a new state variable that describes the 339 type of this session. Allowable values for S-BFD sessions are: 341 * SBFDInitiator - an S-BFD session on a network node that 342 performs a continuity test to a target entity by sending S-BFD 343 packets. 345 * SBFDReflector - an S-BFD session on a network node that listens 346 for incoming S-BFD control packets to local entities and 347 generates response S-BFD control packets. 349 bfd.SessionType variable MUST be initialized to the appropriate type 350 when an S-BFD session is created. 352 6.2. State Variable Initialization and Maintenance 354 A state variable defined in Section 6.8.1 of [RFC5880] need to be 355 initialized or manipulated differently depending on the session type. 357 o bfd.DemandMode: This variable MUST be initialized to 1 for session 358 type SBFDInitiator, and MUST be initialized to 0 for session type 359 SBFDReflector. This is done to prevent loops (see Appendix A). 361 7. S-BFD Procedures 363 7.1. Demultiplexing of S-BFD Control Packet 365 S-BFD packet MUST be demultiplexed with lower layer information 366 (e.g., dedicated destination UDP port [I-D.ietf-bfd-seamless-ip], 367 associated channel type [I-D.ietf-pals-seamless-vccv]). The 368 following procedure SHOULD be executed on both initiator and 369 reflector. 371 If S-BFD packet 373 If S-BFD packet is for SBFDReflector 375 Packet MUST be looked up to locate a corresponding 376 SBFDReflector session based on the value from the "your 377 discriminator" field in the table describing S-BFD 378 discriminators. 380 Else 382 Packet MUST be looked up to locate a corresponding 383 SBFDInitiator session or classical BFD session based on the 384 value from the "your discriminator" field in the table 385 describing BFD discriminators. If no match then received 386 packet MUST be discarded. 388 If session is SBFDInitiator 390 Destination of the packet (i.e., destination IP address) 391 SHOULD be validated to be for self. 393 Else 395 Packet MUST be discarded 397 Else 399 Procedure described in [RFC5880] MUST be applied. 401 More details on S-BFD control packet demultiplexing are described in 402 relevant S-BFD data plane documents. 404 7.2. Responder Procedures 406 A network node that receives S-BFD control packets transmitted by an 407 initiator is referred as responder. The responder, upon reception of 408 S-BFD control packets, is to perform necessary relevant validations 409 described in [RFC5880]. 411 7.2.1. Responder Demultiplexing 413 S-BFD packet MUST be demultiplexed with lower layer information. The 414 following procedure SHOULD be executed by the responder: 416 If "your discriminator" not one of the entry allocated for local 417 entities 419 Packet MUST be discarded. 421 Else 423 Packet is determined to be handled by a reflector BFD session 424 responsible for that S-BFD discriminator. 426 If local policy allows (e.g., administrative, security, rate- 427 limiter, etc.) 429 Chosen reflector BFD session SHOULD transmit a response BFD 430 control packet using procedures described in Section 7.2.2. 432 7.2.2. Transmission of S-BFD Control Packet by SBFDReflector 434 Contents of S-BFD control packets sent by an SBFDReflector MUST be 435 set as per Section 6.8.7 of [RFC5880]. There are a few fields that 436 needs to be set differently from [RFC5880] as follows: 438 State (Sta) 440 Set to bfd.SessionState (either UP or ADMINDOWN only). 441 Clarification of reflector BFD session state is described in 442 Section 7.2.3. 444 Demand (D) 446 Set to 0, to identify the S-BFD packet is sent by the 447 SBFDReflector. 449 Detect Mult 451 Value to be copied from "Detection Multiplier" filed of 452 received BFD packet. 454 My Discriminator 456 Value be copied from "your discriminator" filed of received BFD 457 packet. 459 Your Discriminator 461 Value be copied from "my discriminator" filed of received BFD 462 packet. 464 Desired Min TX Interval 466 Value be copied from "Desired Min TX Interval" filed of 467 received BFD packet. 469 Required Min RX Interval 471 Set to a bfd.RequiredMinRxInterval, value describing minimum 472 interval, in microseconds between received SBFD Control 473 packets. Further details are described in Section 7.2.3. 475 Required Min Echo RX Interval 477 If device supports looping back S-BFD echo packets 479 Set to the minimum required Echo packet receive interval for 480 this session. 482 Else 484 Set to 0. 486 7.2.3. Additional SBFDReflector Behaviors 488 o S-BFD control packets transmitted by the SBFDReflector MUST have 489 "Required Min RX Interval" set to a value that expresses, in 490 microseconds, the minimum interval between incoming S-BFD control 491 packets this SBFDReflector can handle. The SBFDReflector can 492 control how fast SBFInitiators will be sending S-BFD control 493 packets to self by ensuring "Required Min RX Interval" indicates a 494 value based on the current load. 496 o When the SBFDReflector receives an S-BFD control packet from an 497 SBFDInitiator, then the SBFDReflector needs to determine what 498 "state" to send in the response S-BFD control packet. If the 499 monitored local entity is in service, then the "state" MUST be set 500 to UP. If the monitored local entity is "temporarily out of 501 service", then the "state" SHOULD be set to ADMINDOWN. 503 o If an SBFDReflector receives an S-BFD control packet with Demand 504 (D) bit cleared, the packet MUST be discarded (see Appendix A). 506 7.3. Initiator Procedures 508 S-BFD control packets transmitted by an SBFDInitiator MUST set "your 509 discriminator" field to an S-BFD discriminator corresponding to the 510 remote entity. 512 Every SBFDInitiator MUST have a locally unique "my discriminator" 513 allocated from the BFD discriminator pool. 515 Figure 3 describes the high-level concept of continuity test using 516 S-BFD. R2 allocates XX as the S-BFD discriminator for its network 517 reachability purpose, and advertises XX to neighbors. ASCII art 518 shows R1 and R4 performing a continuity test to R2. 520 +--- md=50/yd=XX (ping) ----+ 521 | | 522 |+-- md=XX/yd=50 (pong) --+ | 523 || | | 524 |v | v 525 R1 ==================== R2[*] ========= R3 ========= R4 526 | ^ |^ 527 | | || 528 | +-- md=60/yd=XX (ping) --+| 529 | | 530 +---- md=XX/yd=60 (pong) ---+ 532 [*] Reflector BFD session on R2. 533 === Links connecting network nodes. 534 --- S-BFD control packet traversal. 536 Figure 3: S-BFD Continuity Test 538 7.3.1. SBFDInitiator State Machine 540 An SBFDInitiator may be a persistent session on the initiator with a 541 timer for S-BFD control packet transmissions (stateful 542 SBFDInitiator). An SBFDInitiator may also be a module, a script or a 543 tool on the initiator that transmits one or more S-BFD control 544 packets "when needed" (stateless SBFDInitiator). For stateless 545 SBFDInitiators, a complete BFD state machine may not be applicable. 546 For stateful SBFDInitiators, the states and the state machine 547 described in [RFC5880] will not function due to SBFDReflector session 548 only sending UP and ADMINDOWN states (i.e., SBFDReflector session 549 does not send INIT state). The following diagram provides the 550 RECOMMENDED state machine for stateful SBFDInitiators. The notation 551 on each arc represents the state of the SBFDInitiator (as received in 552 the State field in the S-BFD control packet) or indicates the 553 expiration of the Detection Timer. See Figure 4. 555 +--+ 556 ADMIN DOWN, | | 557 TIMER | V 558 +------+ UP +------+ 559 | |-------------------->| |----+ 560 | DOWN | | UP | | UP 561 | |<--------------------| |<---+ 562 +------+ ADMIN DOWN, +------+ 563 TIMER 565 Figure 4: SBFDInitiator FSM 567 Note that the above state machine is different from the base BFD 568 specification [RFC5880]. This is because the INIT state is no longer 569 applicable for the SBFDInitiator. Another important difference is 570 the transition of the state machine from the DOWN state to the UP 571 state when a packet with State UP is received by the SBFDInitiator. 572 The definitions of the states and the events have the same meaning as 573 in the base BFD specification [RFC5880]. 575 7.3.2. Transmission of S-BFD Control Packet by SBFDInitiator 577 Contents of S-BFD control packets sent by an SBFDInitiator MUST be 578 set as per Section 6.8.7 of [RFC5880]. There are few fields which 579 needs to be set differently from [RFC5880] as follows: 581 Demand (D) 583 D bit is used to identify S-BFD packet originated from 584 SBFDInitiator and is always set to 1. 586 Your Discriminator 588 Set to bfd.RemoteDiscr. bfd.RemoteDiscr is set to discriminator 589 value of remote entity. It MAY be learnt from routing 590 protocols or configured locally. 592 Required Min RX Interval 594 Set to 0. 596 Required Min Echo RX Interval 598 Set to 0. 600 7.3.3. Additional SBFDInitiator Behaviors 602 o If the SBFDInitiator receives a valid S-BFD control packet in 603 response to transmitted S-BFD control packet to a remote entity, 604 then the SBFDInitiator SHOULD conclude that S-BFD control packet 605 reached the intended remote entity. 607 o When an SBFDInitiator receives a response S-BFD control packet, if 608 the state specified is ADMINDOWN, the SBFDInitiator MUST NOT 609 conclude loss of reachability to the corresponding remote entity, 610 and MUST back off packet transmission interval for the remote 611 entity to an interval no faster than 1 second. 613 o When a sufficient number of S-BFD packets have not arrived as they 614 should, the SBFDInitiator SHOULD declare loss of reachability to 615 the remote entity. The criteria for declaring loss of 616 reachability and the action that would be triggered as a result 617 are outside the scope of this document; the action MAY include 618 logging an error. 620 o Relating to above bullet item, it is critical for an 621 implementation to understand the latency to/from the reflector BFD 622 session on the responder. In other words, for very first S-BFD 623 packet transmitted by the SBFDInitiator, an implementation MUST 624 NOT expect response S-BFD packet to be received for time 625 equivalent to sum of latencies: initiator to responder and 626 responder back to initiator. 628 o If the SBFDInitiator receives an S-BFD control packet with Demand 629 (D) bit set, the packet MUST be discarded (see Appendix A). 631 7.4. Diagnostic Values 633 Diagnostic value in both directions MAY be set to a certain value, to 634 attempt to communicate further information to both ends. 635 Implementation MAY use already existing diagnostic values defined in 636 Section 4.1 of [RFC5880]. However, details of such are outside the 637 scope of this specification. 639 7.5. The Poll Sequence 641 Poll sequence MAY be used in both directions. The Poll sequence MUST 642 operate in accordance with [RFC5880]. An SBFDReflector MAY use the 643 Poll sequence to slow down that rate at which S-BFD control packets 644 are generated from an SBFDInitiator. This is done by the 645 SBFDReflector using procedures described in Section 7.2.3 and setting 646 the Poll (P) bit in the reflected S-BFD control packet. The 647 SBFDInitiator is to then send the next S-BFD control packet with the 648 Final (F) bit set. If an SBFDReflector receives an S-BFD control 649 packet with Poll (P) bit set, then the SBFDReflector MUST respond 650 with an S-BFD control packet with Poll (P) bit cleared and Final (F) 651 bit set. 653 8. Operational Considerations 655 S-BFD provides a smooth and continuous (i.e., seamless) operational 656 experience as an Operations, Administration, and Maintenance (OAM) 657 mechanism for connectivity check and connection verification. This 658 is achieved by providing a simplified mechanism with large portions 659 of negotiation aspects eliminated, resulting in a faster and simpler 660 provisioning. 662 Because of this simplified mechanism, due to a misconfiguration, an 663 SBFDInitiator could send S-BFD control packets to a target that does 664 not exist or that is outside the S-BFD administrative domain. As 665 explained in Section 7.3.1, an SBFDInitiator can be a "persistent" 666 initiator or a "when needed" one. When an S-BFD "persistent" 667 SBFDInitiator is used, it SHOULD be controlled that S-BFD control 668 packet do not propagate for an extended period of time outside of the 669 administrative domain that uses it. Further, operational measures 670 SHOULD be taken to identify if S-BFD packets are not responded to for 671 an extended period of time, and remediate the situation. These 672 potential concerns are largely mitigated by dynamic advertisement 673 mechanisms for S-BFD, and with automation checks before applying 674 configurations. 676 8.1. Scaling Aspect 678 This mechanism brings forth one noticeable difference in terms of 679 scaling aspect: number of SBFDReflector. This specification 680 eliminates the need for egress nodes to have fully active BFD 681 sessions when only one side desires to perform continuity tests. 682 With introduction of reflector BFD concept, egress no longer is 683 required to create any active BFD session per path/LSP/function 684 basis. Due to this, total number of BFD sessions in a network is 685 reduced. 687 8.2. Congestion Considerations 689 S-BFD performs failure detection by consuming resources, including 690 bandwidth and CPU processing. It is therefore imperative that 691 operators correctly provision the rates at which S-BFD is transmitted 692 to avoid congestion. When BFD is used across multiple hops, a 693 congestion control mechanism MUST be implemented, and when congestion 694 is detected, the BFD implementation MUST reduce the amount of traffic 695 it generates. The exact mechanism used to detect congestion is 696 outside the scope of this specification, but may include detection of 697 lost BFD control packets or other means. The SBFDReflector can limit 698 the rate at which an SBFInitiators will be sending S-BFD control 699 packets utilizing the "Required Min RX Interval", at the expense of 700 increasing the detection time. 702 9. Co-existence with Classical BFD Sessions 704 Initial packet demultiplexing requirement is described in 705 Section 7.1. Because of this, S-BFD mechanism can co-exist with 706 classical BFD sessions. 708 10. S-BFD Echo Function 710 The concept of the S-BFD Echo function is similar to the BFD Echo 711 function described in [RFC5880]. S-BFD echo packets have the 712 destination of self, thus S-BFD echo packets are self-generated and 713 self-terminated after traversing a link/path. S-BFD echo packets are 714 expected to u-turn on the target node in the data plane and MUST NOT 715 be processed by any reflector BFD sessions on the target node. 717 When using the S-BFD Echo function, it is RECOMMENDED that: 719 o Both S-BFD control packets and S-BFD echo packets be sent. 721 o Both S-BFD control packets and S-BFD echo packets have the same 722 semantics in the forward direction to reach the target node. 724 In other words, it is not preferable to send just S-BFD echo packets 725 without also sending S-BFD control packets. There are two reasons 726 behind this suggestion: 728 o S-BFD control packets can verify the reachability to intended 729 target node, which allows one to have confidence that S-BFD echo 730 packets are u-turning on the expected target node. 732 o S-BFD control packets can detect when the target node is going out 733 of service (i.e., via receiving back ADMINDOWN state). 735 S-BFD Echo packets can be spoofed, and can u-turn in a transit node 736 before reaching the expected target node. When the S-BFD Echo 737 function is used, it is RECOMMENDED in this specification that both 738 S-BFD control packets and S-BFD echo packets be sent. While the 739 additional use of S-BFD control packets alleviates these two 740 concerns, some form of authentication MAY still be included. 742 The usage of the "Required Min Echo RX Interval" field is described 743 in Section 7.3.2 and Section 7.2.2. Because of the stateless nature 744 of SBFDReflector sessions, a value specified the "Required Min Echo 745 RX Interval" field is not very meaningful at SBFDReflector. Thus it 746 is RECOMMENDED that the "Required Min Echo RX Interval" field simply 747 be set to zero from SBFDInitiator. SBFDReflector MAY set to 748 appropriate value to control the rate at which it wants to receives 749 SBFD echo packets. 751 The following aspects of S-BFD Echo functions are left as 752 implementation details, and are outside the scope of this document: 754 o Format of the S-BFD echo packet (e.g., data beyond UDP header). 756 o Procedures on when and how to use the S-BFD Echo function. 758 11. Security Considerations 760 Same security considerations as [RFC5880] apply to this document. 761 Additionally, implementing the following measures will strengthen 762 security aspects of the mechanism described by this document: 764 o SBFDInitiator MAY pick a sequence number to be set in "sequence 765 Number" in authentication section based on authentication mode 766 configured. 768 o SBFDReflector MUST NOT use the crypto sequence number to make a 769 decision about accepting the packet. This is because the 770 SBFDReflector does not maintain S-BFD peer state, and because the 771 SBFDReflector can receive S-BFD packets from multiple 772 SBFDInitiators. Consequently, BFD authentication can be used but 773 not the sequence number. 775 o SBFDReflector MAY use the Auth Key ID in the incoming packet to 776 verify the authentication data. 778 o SBFDReflector MUST accept the packet if authentication is 779 successful. 781 o SBFDReflector MUST compute the Authentication data and MUST use 782 the same sequence number that it received in the S-BFD control 783 packet that it is responding to. 785 o SBFDInitiator SHOULD accept S-BFD control packet with sequence 786 number within permissible window. One potential approach is the 787 procedure explained in [I-D.ietf-bfd-generic-crypto-auth]. 789 Using the above method, 791 o SBFDReflector continue to remain stateless despite using security. 793 o SBFDReflector are not susceptible to replay attacks as they always 794 respond to S-BFD control packets irrespective of the sequence 795 number carried. 797 o An attacker cannot impersonate the responder since the 798 SBFDInitiator will only accept S-BFD control packets that come 799 with the sequence number that it had originally used when sending 800 the S-BFD control packet. 802 Additionally, the use of strong forms of authentication is strongly 803 encouraged for S-BFD. The use of Simple Password authentication 804 potentially puts other services at risk, if S-BFD packets can be 805 intercepted and if those password values are reused for other 806 services. 808 Considerations about loop problems are covered in Appendix A. 810 12. IANA Considerations 812 No action is required by IANA for this document. 814 13. Acknowledgements 816 The authors would like to thank Jeffrey Haas, Greg Mirsky, Marc 817 Binderberger, and Alvaro Retana for performing thorough reviews and 818 providing number of suggestions. The authors would also like to 819 thank Girija Raghavendra Rao, Les Ginsberg, Srihari Raghavan, Vanitha 820 Neelamegam, and Vengada Prasad Govindan from Cisco Systems for 821 providing valuable comments. Finally, the authors would also like to 822 thank John E. Drake and Pablo Frank for providing comments and 823 suggestions. 825 14. Contributors 827 The following are key contributors to this document: 829 Tarek Saad, Cisco Systems, Inc. 830 Siva Sivabalan, Cisco Systems, Inc. 831 Nagendra Kumar, Cisco Systems, Inc. 832 Mallik Mudigonda, Cisco Systems, Inc. 833 Sam Aldrin, Google 835 15. References 837 15.1. Normative References 839 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 840 Requirement Levels", BCP 14, RFC 2119, 841 DOI 10.17487/RFC2119, March 1997, 842 . 844 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 845 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 846 . 848 15.2. Informative References 850 [I-D.ietf-bfd-generic-crypto-auth] 851 Bhatia, M., Manral, V., Zhang, D., and M. Jethanandani, 852 "BFD Generic Cryptographic Authentication", draft-ietf- 853 bfd-generic-crypto-auth-06 (work in progress), April 2014. 855 [I-D.ietf-bfd-seamless-ip] 856 Akiya, N., Pignataro, C., and D. Ward, "Seamless 857 Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6 858 and MPLS", draft-ietf-bfd-seamless-ip-04 (work in 859 progress), April 2016. 861 [I-D.ietf-bfd-seamless-use-case] 862 Aldrin, S., Pignataro, C., Mirsky, G., and N. Kumar, 863 "Seamless Bidirectional Forwarding Detection (S-BFD) Use 864 Cases", draft-ietf-bfd-seamless-use-case-06 (work in 865 progress), April 2016. 867 [I-D.ietf-pals-seamless-vccv] 868 Govindan, V. and C. Pignataro, "Seamless BFD for VCCV", 869 draft-ietf-pals-seamless-vccv-03 (work in progress), April 870 2016. 872 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 873 DOI 10.17487/RFC0791, September 1981, 874 . 876 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 877 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 878 December 1998, . 880 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 881 Label Switching Architecture", RFC 3031, 882 DOI 10.17487/RFC3031, January 2001, 883 . 885 Appendix A. Loop Problem and Solution 887 Consider a scenario where we have two nodes and both are S-BFD 888 capable. 890 Node A (IP 2001:db8::1) ----------------- Node B (IP 2001:db8::2) 891 | 892 | 893 Man in the Middle (MiM) 895 Assume node A reserved a discriminator 0x01010101 for target 896 identifier 2001:db8::1 and has a reflector session in listening mode. 897 Similarly node B reserved a discriminator 0x02020202 for its target 898 identifier 2001:db8::2 and also has a reflector session in listening 899 mode. 901 Suppose MiM sends a spoofed packet with MyDisc = 0x01010101, YourDisc 902 = 0x02020202, source IP as 2001:db8::1 and dest IP as 2001:db8::2. 903 When this packet reaches Node B, the reflector session on Node B will 904 swap the discriminators and IP addresses of the received packet and 905 reflect it back, since YourDisc of the received packet matched with 906 reserved discriminator of Node B. The reflected packet that reached 907 Node A will have MyDdisc=0x02020202 and YourDisc=0x01010101. Since 908 YourDisc of the received packet matched the reserved discriminator of 909 Node A, Node A will swap the discriminators and reflects the packet 910 back to Node B. Since reflectors must set the TTL of the reflected 911 packets to 255, the above scenario will result in an infinite loop 912 with just one malicious packet injected from MiM. 914 The solution to avoid the loop problem uses the "D" bit (Demand mode 915 bit). The Initiator always sets the 'D' bit and the reflector always 916 clears it. This way we can identify if a received packet was a 917 reflected packet and avoid reflecting it back. 919 Authors' Addresses 921 Carlos Pignataro 922 Cisco Systems, Inc. 924 Email: cpignata@cisco.com 926 Dave Ward 927 Cisco Systems, Inc. 929 Email: wardd@cisco.com 931 Nobo Akiya 932 Big Switch Networks 934 Email: nobo.akiya.dev@gmail.com 936 Manav Bhatia 937 Ionos Networks 939 Email: manav@ionosnetworks.com 941 Santosh Pallagatti 943 Email: santosh.pallagatti@gmail.com