idnits 2.17.1 draft-ietf-bfd-seamless-base-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (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 (April 13, 2016) is 2935 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-03 == Outdated reference: A later version (-08) exists of draft-ietf-bfd-seamless-use-case-04 -- 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 N. Akiya 3 Internet-Draft Big Switch Networks 4 Updates: 5880 (if approved) C. Pignataro 5 Intended status: Standards Track D. Ward 6 Expires: October 15, 2016 Cisco Systems 7 M. Bhatia 8 Ionos Networks 9 S. Pallagatti 10 April 13, 2016 12 Seamless Bidirectional Forwarding Detection (S-BFD) 13 draft-ietf-bfd-seamless-base-09 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 October 15, 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 . . . . . . 8 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 . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . 15 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. Contributing Authors . . . . . . . . . . . . . . . . . . . . 18 96 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 97 15.1. Normative References . . . . . . . . . . . . . . . . . . 18 98 15.2. Informative References . . . . . . . . . . . . . . . . . 19 99 Appendix A. Loop Problem . . . . . . . . . . . . . . . . . . . . 19 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 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 which 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 Below figure 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 above setup is complete, any network node, having the knowledge 207 of the S-BFD discriminator allocated to by a remote node to remote 208 entity/entities, it 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 For example: 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 will advertises the S-BFD 231 discriminator 123 in an IS-IS TLV. S-BFD module in a system with IS- 232 IS SystemID yyy (node D) allocates an S-BFD discriminator 456, and 233 IS-IS advertises the S-BFD discriminator 456 in an IS-IS TLV. A 234 reflector BFD session is created on both network nodes (node A and 235 node D). When network node A wants to check the reachability to 236 network node D, node A can send an S-BFD control packet, destined to 237 node D, with "your discriminator" field set to 456. When the 238 reflector BFD session on node D receives this S-BFD control packet, 239 then response S-BFD control packet is sent back to node A, which 240 allows node A to 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 characteristics of an S-BFD discriminator is that it 253 MUST be unique within an administrative domain. If multiple network 254 nodes allocated a same S-BFD discriminator value, then S-BFD control 255 packets falsely terminating on a wrong network node can result in a 256 reflector BFD session to generate a response back, due to "your 257 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 Remainder of this subsection describes the reasons for above 276 suggestions. 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 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 a same purpose (e.g., network reachability), then the 292 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. How such collisions are addressed is 295 outside the scope of this document. 297 5. Reflector BFD Session 299 Each network node creates one or more reflector BFD sessions. This 300 reflector BFD session is a session which transmits S-BFD control 301 packets in response to received S-BFD control packets with "your 302 discriminator" having S-BFD discriminators allocated for local 303 entities. Specifically, this reflector BFD session is to have 304 following characteristics: 306 o MUST NOT transmit any S-BFD packets based on local timer expiry. 308 o MUST transmit an S-BFD control packet in response to a received 309 S-BFD control packet having a valid S-BFD discriminator in the 310 "your discriminator" field, unless prohibited by local policies 311 (e.g., administrative, security, rate-limiter, etc). 313 o MUST be capable of sending only two states: UP and ADMINDOWN. 315 One reflector BFD session may be responsible for handling received 316 S-BFD control packets targeted to all locally allocated S-BFD 317 discriminators, or few reflector BFD sessions may each be responsible 318 for subset of locally allocated S-BFD discriminators. This policy is 319 a local matter, and is outside the scope of this document. 321 Note that incoming S-BFD control packets may be IPv4, IPv6 or MPLS 322 based [I-D.ietf-bfd-seamless-ip], and other options are possible and 323 can be defined in future documents. How such S-BFD control packets 324 reach an appropriate reflector BFD session is also a local matter, 325 and is outside the scope of this document. 327 6. State Variables 329 S-BFD introduces new state variables, and modifies the usage of 330 existing ones. 332 6.1. New State Variables 334 A new state variable is added to the base specification in support of 335 S-BFD. 337 o bfd.SessionType: This is a new state variable that describes the 338 type of this session. Allowable values for S-BFD sessions are: 340 * SBFDInitiator - an S-BFD session on a network node that 341 performs a continuity test to a target entity by sending S-BFD 342 packets. 344 * SBFDReflector - an S-BFD session on a network node that listens 345 for incoming S-BFD control packets to local entities and 346 generates response S-BFD control packets. 348 bfd.SessionType variable MUST be initialized to the appropriate type 349 when an S-BFD session is created. 351 6.2. State Variable Initialization and Maintenance 353 A state variable defined in Section 6.8.1 of [RFC5880] need to be 354 initialized or manipulated differently depending on the session type. 356 o bfd.DemandMode: This variable MUST be initialized to 1 for session 357 type SBFDInitiator, and MUST be initialized to 0 for session type 358 SBFDReflector. 360 7. S-BFD Procedures 362 7.1. Demultiplexing of S-BFD Control Packet 364 S-BFD packet MUST be demultiplexed with lower layer information 365 (e.g., dedicated destination UDP port, associated channel type). 366 Following procedure SHOULD be executed on both initiator and 367 reflector. 369 If S-BFD packet 371 If S-BFD packet is for SBFDReflector 373 Packet MUST be looked up to locate a corresponding 374 SBFDReflector session based on the value from the "your 375 discriminator" field in the table describing S-BFD 376 discriminators. 378 Else 380 Packet MUST be looked up to locate a corresponding 381 SBFDInitiator session or classical BFD session based on the 382 value from the "your discriminator" field in the table 383 describing BFD discriminators. If no match then received 384 packet MUST be discarded. 386 If session is SBFDInitiator 388 Destination of the packet (i.e., destination IP address) 389 SHOULD be validated to be for self. 391 Else 393 Packet MUST be discarded 395 Else 397 Procedure described in [RFC5880] MUST be applied. 399 More details on S-BFD control packet demultiplexing are described in 400 relevant S-BFD data plane documents. 402 7.2. Responder Procedures 404 A network node which receives S-BFD control packets transmitted by an 405 initiator is referred as responder. The responder, upon reception of 406 S-BFD control packets, is to perform necessary relevant validations 407 described in [RFC5880]. 409 7.2.1. Responder Demultiplexing 411 S-BFD packet MUST be demultiplexed with lower layer information 412 (e.g., dedicated destination UDP port, associated channel type). 413 Following procedure SHOULD be executed by responder: 415 If "your discriminator" not one of the entry allocated for local 416 entities 418 Packet MUST be discarded. 420 Else 422 Packet is determined to be handled by a reflector BFD session 423 responsible for that S-BFD discriminator. 425 If local policy allows (e.g., administrative, security, rate- 426 limiter, etc) 428 Chosen reflector BFD session SHOULD transmit a response BFD 429 control packet using procedures described in Section 7.3.2. 431 7.2.2. Transmission of S-BFD Control Packet by SBFDReflector 433 Contents of S-BFD control packets sent by an SBFDReflector MUST be 434 set as per Section 6.8.7 of [RFC5880]. There are few fields which 435 needs to be set differently from [RFC5880] as follows: 437 State (Sta) 439 Set to bfd.SessionState (either UP or ADMINDOWN only). 440 Clarification of reflector BFD session state is described in 441 Section 7.2.3. 443 Demand (D) 445 Set to 0. 447 Detect Mult 448 Value to be copied from "Detection Multiplier" filed of 449 received BFD packet. 451 My Discriminator 453 Value be copied from "your discriminator" filed of received BFD 454 packet. 456 Your Discriminator 458 Value be copied from "my discriminator" filed of received BFD 459 packet. 461 Desired Min TX Interval 463 Value be copied from "Desired Min TX Interval" filed of 464 received BFD packet. 466 Required Min RX Interval 468 Set to a bfd.RequiredMinRxInterval, value describing minimum 469 interval, in microseconds between received SBFD Control 470 packets. Further details are described in Section 7.2.3. 472 Required Min Echo RX Interval 474 If device supports looping back S-BFD echo packets 476 Set to the minimum required Echo packet receive interval for 477 this session. 479 Else 481 Set to 0. 483 7.2.3. Additional SBFDReflector Behaviors 485 o S-BFD control packets transmitted by the SBFDReflector MUST have 486 "Required Min RX Interval" set to a value which expresses, in 487 microseconds, the minimum interval between incoming S-BFD control 488 packets this SBFDReflector can handle. The SBFDReflector can 489 control how fast SBFInitiators will be sending S-BFD control 490 packets to self by ensuring "Required Min RX Interval" indicates a 491 value based on the current load. 493 o If the SBFDReflector wishes to communicate to some or all 494 SBFDInitiators that monitored local entity is "temporarily out of 495 service", then S-BFD control packets with "state" set to ADMINDOWN 496 are sent to those SBFDInitiators. The SBFDInitiators, upon 497 reception of such packets, MUST NOT conclude loss of reachability 498 to corresponding remote entity, and MUST back off packet 499 transmission interval for the remote entity to an interval no 500 faster than 1 second. If the SBFDReflector is generating a 501 response S-BFD control packet for a local entity that is in 502 service, then "state" in response BFD control packets MUST be set 503 to UP. 505 o If an SBFDReflector receives an S-BFD control packet with Demand 506 (D) bit cleared, the packet MUST be discarded. 508 7.3. Initiator Procedures 510 S-BFD control packets transmitted by an SBFDInitiator MUST set "your 511 discriminator" field to an S-BFD discriminator corresponding to the 512 remote entity. 514 Every SBFDInitiator MUST have a locally unique "my discriminator" 515 allocated from the BFD discriminator pool. 517 Below Figure 3 art describes high level concept of continuity test 518 using S-BFD. R2 allocates XX as the S-BFD discriminator for its 519 network reachability purpose, and advertises XX to neighbors. ASCII 520 art shows R1 and R4 performing a continuity test to R2. 522 +--- md=50/yd=XX (ping) ----+ 523 | | 524 |+-- md=XX/yd=50 (pong) --+ | 525 || | | 526 |v | v 527 R1 ==================== R2[*] ========= R3 ========= R4 528 | ^ |^ 529 | | || 530 | +-- md=60/yd=XX (ping) --+| 531 | | 532 +---- md=XX/yd=60 (pong) ---+ 534 [*] Reflector BFD session on R2. 535 === Links connecting network nodes. 536 --- S-BFD control packet traversal. 538 Figure 3: S-BFD Continuity Test 540 7.3.1. SBFDInitiator State Machine 542 An SBFDInitiator may be a persistent session on the initiator with a 543 timer for S-BFD control packet transmissions (stateful 544 SBFDInitiator). An SBFDInitiator may also be a module, a script or a 545 tool on the initiator that transmits one or more S-BFD control 546 packets "when needed" (stateless SBFDInitiator). For stateless 547 SBFDInitiators, a complete BFD state machine may not be applicable. 548 For stateful SBFDInitiators, the states and the state machine 549 described in [RFC5880] will not function due to SBFDReflector session 550 only sending UP and ADMINDOWN states (i.e., SBFDReflector session 551 does not send INIT state). The following diagram provides the 552 RECOMMENDED state machine for stateful SBFDInitiators. The notation 553 on each arc represents the state of the SBFDInitiator (as received in 554 the State field in the S-BFD control packet) or indicates the 555 expiration of the Detection Timer. 557 +--+ 558 ADMIN DOWN, | | 559 TIMER | V 560 +------+ UP +------+ 561 | |-------------------->| |----+ 562 | DOWN | | UP | | UP 563 | |<--------------------| |<---+ 564 +------+ ADMIN DOWN, +------+ 565 TIMER 567 Figure 4: SBFDInitiator FSM 569 Note that the above state machine is different from the base BFD 570 specification[RFC5880]. This is because the INIT state is no longer 571 applicable for the SBFDInitiator. Another important difference is 572 the transition of the state machine from the DOWN state to the UP 573 state when a packet with State UP is received by the SBFDInitiator. 574 The definitions of the states and the events have the same meaning as 575 in the base BFD specification [RFC5880]. 577 7.3.2. Transmission of S-BFD Control Packet by SBFDInitiator 579 Contents of S-BFD control packets sent by an SBFDInitiator MUST be 580 set as per Section 6.8.7 of [RFC5880]. There are few fields which 581 needs to be set differently from [RFC5880] as follows: 583 Demand (D) 585 D bit is used to identify S-BFD packet originated from 586 SBFDInitiator and is always set to 1. 588 Your Discriminator 590 Set to bfd.RemoteDiscr. bfd.RemoteDiscr is set to discriminator 591 value of remote entity. It MAY be learnt from routing 592 protocols or configured locally. 594 Required Min RX Interval 596 Set to 0. 598 Required Min Echo RX Interval 600 Set to 0. 602 7.3.3. Additional SBFDInitiator Behaviors 604 o If the SBFDInitiator receives a valid S-BFD control packet in 605 response to transmitted S-BFD control packet to a remote entity, 606 then the SBFDInitiator SHOULD conclude that S-BFD control packet 607 reached the intended remote entity. 609 o When a sufficient number of S-BFD packets have not arrived as they 610 should, the SBFDInitiator SHOULD declare loss of reachability to 611 the remote entity. The criteria for declaring loss of 612 reachability and the action that would be triggered as a result 613 are outside the scope of this document. 615 o Relating to above bullet item, it is critical for an 616 implementation to understand the latency to/from the reflector BFD 617 session on the responder. In other words, for very first S-BFD 618 packet transmitted by the SBFDInitiator, an implementation MUST 619 NOT expect response S-BFD packet to be received for time 620 equivalent to sum of latencies: initiator to responder and 621 responder back to initiator. 623 o If the SBFDInitiator receives an S-BFD control packet with Demand 624 (D) bit set, the packet MUST be discarded. 626 7.4. Diagnostic Values 628 Diagnostic value in both directions MAY be set to a certain value, to 629 attempt to communicate further information to both ends. 630 Implementation MAY use already existing diagnostic values defined in 631 Section 4.1 of [RFC5880]. However, details of such are outside the 632 scope of this specification. 634 7.5. The Poll Sequence 636 Poll sequence MAY be used in both directions. The Poll sequence MUST 637 operate in accordance with [RFC5880]. An SBFDReflector MAY use the 638 Poll sequence to slow down that rate at which S-BFD control packets 639 are generated from an SBFDInitiator. This is done by the 640 SBFDReflector using procedures described in Section 7.2.3 and setting 641 the Poll (P) bit in the reflected S-BFD control packet. The 642 SBFDInitiator is to then send the next S-BFD control packet with the 643 Final (F) bit set. If an SBFDReflector receives an S-BFD control 644 packet with Poll (P) bit set, then the SBFDReflector MUST respond 645 with an S-BFD control packet with Poll (P) bit cleared and Final (F) 646 bit set. 648 8. Operational Considerations 650 S-BFD provides a smooth and continuous operational experience as a 651 failure detection mechanism. This is achieved by providing a 652 simplified mechanism with large portions of negotiation aspects 653 eliminated, resulting in a faster and simpler provisioning. 655 8.1. Scaling Aspect 657 This mechanism brings forth one noticeable difference in terms of 658 scaling aspect: number of SBFDReflector. This specification 659 eliminates the need for egress nodes to have fully active BFD 660 sessions when only one side desires to perform continuity tests. 661 With introduction of reflector BFD concept, egress no longer is 662 required to create any active BFD session per path/LSP/function 663 basis. Due to this, total number of BFD sessions in a network is 664 reduced. 666 8.2. Congestion Considerations 668 S-BFD performs failure detection by consuming resources, including 669 bandwidth and CPU processing. It is therefore imperative that 670 operators correctly provision the rates at which S-BFD is transmitted 671 to avoid congestion. When BFD is used across multiple hops, a 672 congestion control mechanism MUST be implemented, and when congestion 673 is detected, the BFD implementation MUST reduce the amount of traffic 674 it generates. The exact mechanism used to detect congestion is 675 outside the scope of this specification, but may include detection of 676 lost BFD control packets or other means. The SBFDReflector can limit 677 the rate at which an SBFInitiators will be sending S-BFD control 678 packets utilizing the "Required Min RX Interval", at the expense of 679 increasing the detection time. 681 9. Co-existence with Classical BFD Sessions 683 Initial packet demultiplexing requirement is described in 684 Section 7.1. Because of this, S-BFD mechanism can co-exist with 685 classical BFD sessions. 687 10. S-BFD Echo Function 689 The concept of the S-BFD Echo function is similar to the BFD Echo 690 function described in [RFC5880]. S-BFD echo packets have the 691 destination of self, thus S-BFD echo packets are self-generated and 692 self-terminated after traversing a link/path. S-BFD echo packets are 693 expected to u-turn on the target node in the data plane and MUST NOT 694 be processed by any reflector BFD sessions on the target node. 696 When using the S-BFD Echo function, it is RECOMMENDED that: 698 o Both S-BFD control packets and S-BFD echo packets be sent. 700 o Both S-BFD control packets and S-BFD echo packets have the same 701 semantics in the forward direction to reach the target node. 703 In other words, it is not preferable to send just S-BFD echo packets 704 without also sending S-BFD control packets. There are two reasons 705 behind this suggestion: 707 o S-BFD control packets can verify the reachability to intended 708 target node, which allows one to have confidence that S-BFD echo 709 packets are u-turning on the expected target node. 711 o S-BFD control packets can detect when the target node is going out 712 of service (i.e., via receiving back ADMINDOWN state). 714 S-BFD Echo packets can be spoofed, and can u-turn in a transit node 715 before reaching the expected target node. When the S-BFD Echo 716 function is used, it is RECOMMENDED in this specification that both 717 S-BFD control packets and S-BFD echo packets be sent. While the 718 additional use of S-BFD control packets alleviates these two 719 concerns, some form of authentication MAY still be included. 721 The usage of the "Required Min Echo RX Interval" field is described 722 in Section 7.3.2 and Section 7.2.2. Because of the stateless nature 723 of SBFDReflector sessions, a value specified the "Required Min Echo 724 RX Interval" field is not very meaningful at SBFDReflector. Thus it 725 is RECOMMENDED that the "Required Min Echo RX Interval" field simply 726 be set to zero from SBFDInitiator. SBFDReflector MAY set to 727 appropriate value to control the rate at which it wants to receives 728 SBFD echo packets. 730 Following aspects of S-BFD Echo functions are left as implementation 731 details, and are outside the scope of this document: 733 o Format of the S-BFD echo packet (e.g., data beyond UDP header). 735 o Procedures on when and how to use the S-BFD Echo function. 737 11. Security Considerations 739 Same security considerations as [RFC5880] apply to this document. 740 Additionally, implementing the following measures will strengthen 741 security aspects of the mechanism described by this document: 743 o SBFDInitiator MAY pick a sequence number to be set in "sequence 744 Number" in authentication section based on authentication mode 745 configured. 747 o SBFDReflector MUST NOT look at the crypto sequence number before 748 accepting the packet. 750 o SBFDReflector MAY look at the Auth Key ID in the incoming packet 751 and verify the authentication data. 753 o SBFDReflector MUST accept the packet if authentication is 754 successful. 756 o SBFDReflector MUST compute the Authentication data and MUST use 757 the same sequence number that it received in the S-BFD control 758 packet that it is responding to. 760 o SBFDInitiator SHOULD accept S-BFD control packet with sequence 761 number within permissible window. One potential approach is the 762 procedure explained in [I-D.ietf-bfd-generic-crypto-auth]. 764 Using the above method, 766 o SBFDReflector continue to remain stateless despite using security. 768 o SBFDReflector are not susceptible to replay attacks as they always 769 respond to S-BFD control packets irrespective of the sequence 770 number carried. 772 o An attacker cannot impersonate the responder since the 773 SBFDInitiator will only accept S-BFD control packets that come 774 with the sequence number that it had originally used when sending 775 the S-BFD control packet. 777 Considerations about loop problems are covered in Appendix A. 779 12. IANA Considerations 781 No action is required by IANA for this document. 783 13. Acknowledgements 785 Authors would like to thank Jeffrey Haas, Greg Mirsky, Marc 786 Binderberger, and Alvaro Retana for performing thorough reviews and 787 providing number of suggestions. Authors would like to thank Girija 788 Raghavendra Rao, Les Ginsberg, Srihari Raghavan, Vanitha Neelamegam 789 and Vengada Prasad Govindan from Cisco Systems for providing valuable 790 comments. Authors would also like to thank John E. Drake and Pablo 791 Frank for providing comments and suggestions. 793 14. Contributing Authors 795 Tarek Saad 796 Cisco Systems 797 Email: tsaad@cisco.com 799 Siva Sivabalan 800 Cisco Systems 801 Email: msiva@cisco.com 803 Nagendra Kumar 804 Cisco Systems 805 Email: naikumar@cisco.com 807 Mallik Mudigonda 808 Cisco Systems 809 Email: mmudigon@cisco.com 811 Sam Aldrin 812 Google 813 Email: aldrin.ietf@gmail.com 815 15. References 817 15.1. Normative References 819 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 820 Requirement Levels", BCP 14, RFC 2119, 821 DOI 10.17487/RFC2119, March 1997, 822 . 824 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 825 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 826 . 828 15.2. Informative References 830 [I-D.ietf-bfd-generic-crypto-auth] 831 Bhatia, M., Manral, V., Zhang, D., and M. Jethanandani, 832 "BFD Generic Cryptographic Authentication", draft-ietf- 833 bfd-generic-crypto-auth-06 (work in progress), April 2014. 835 [I-D.ietf-bfd-seamless-ip] 836 Akiya, N., Pignataro, C., and D. Ward, "Seamless 837 Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6 838 and MPLS", draft-ietf-bfd-seamless-ip-03 (work in 839 progress), February 2016. 841 [I-D.ietf-bfd-seamless-use-case] 842 Aldrin, S., Bhatia, M., Matsushima, S., Mirsky, G., and N. 843 Kumar, "Seamless Bidirectional Forwarding Detection (BFD) 844 Use Case", draft-ietf-bfd-seamless-use-case-04 (work in 845 progress), March 2016. 847 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 848 DOI 10.17487/RFC0791, September 1981, 849 . 851 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 852 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 853 December 1998, . 855 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 856 Label Switching Architecture", RFC 3031, 857 DOI 10.17487/RFC3031, January 2001, 858 . 860 Appendix A. Loop Problem 862 Consider a scenario where we have two nodes and both are S-BFD 863 capable. 865 Node A (IP 2001:db8::1) ----------------- Node B (IP 2001:db8::2) 866 | 867 | 868 Man in the Middle (MiM) 870 Assume node A reserved a discriminator 0x01010101 for target 871 identifier 2001:db8::1 and has a reflector session in listening mode. 872 Similarly node B reserved a discriminator 0x02020202 for its target 873 identifier 2001:db8::2 and also has a reflector session in listening 874 mode. 876 Suppose MiM sends a spoofed packet with MyDisc = 0x01010101, YourDisc 877 = 0x02020202, source IP as 2001:db8::1 and dest IP as 2001:db8::2. 878 When this packet reaches Node B, the reflector session on Node B will 879 swap the discriminators and IP addresses of the received packet and 880 reflect it back, since YourDisc of the received packet matched with 881 reserved discriminator of Node B. The reflected packet that reached 882 Node A will have MyDdisc=0x02020202 and YourDisc=0x01010101. Since 883 YourDisc of the received packet matched the reserved discriminator of 884 Node A, Node A will swap the discriminators and reflects the packet 885 back to Node B. Since reflectors must set the TTL of the reflected 886 packets to 255, the above scenario will result in an infinite loop 887 with just one malicious packet injected from MiM. 889 FYI: Packet fields do not carry any direction information, i.e., if 890 this is Ping packet or reply packet. 892 Solutions 894 The current proposals to avoid the loop problem are: 896 o Overload "D" bit (Demand mode bit): Initiator always sets the 'D' 897 bit and reflector clears it. This way we can identify if a 898 received packet was a reflected packet and avoid reflecting it 899 back. However this changes the interpretation of 'D' bit. 901 o Use of State field in the BFD control packets: Initiator will 902 always send packets with State set to DOWN and reflector will send 903 back packets with state field set to UP. Reflectors will never 904 reflect any received packets with state as UP. However the only 905 issue is the use of state field differently i.e., state in the 906 S-BFD control packet from initiator does not reflect the local 907 state which is anyway not significant at reflector. 909 o Use of local discriminator as My Disc at reflector: Reflector will 910 always fill in My Discriminator with a locally allocated 911 discriminator value (not reserved discriminators) and will not 912 copy it from the received packet. 914 Authors' Addresses 916 Nobo Akiya 917 Big Switch Networks 919 Email: nobo.akiya.dev@gmail.com 920 Carlos Pignataro 921 Cisco Systems 923 Email: cpignata@cisco.com 925 Dave Ward 926 Cisco Systems 928 Email: wardd@cisco.com 930 Manav Bhatia 931 Ionos Networks 933 Email: manav@ionosnetworks.com 935 Santosh Pallagatti 937 Email: santosh.pallagatti@gmail.com