idnits 2.17.1 draft-ietf-bfd-seamless-base-08.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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? 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 (February 23, 2016) is 2985 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 (-08) exists of draft-ietf-bfd-seamless-use-case-03 -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 4 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: August 26, 2016 Cisco Systems 7 M. Bhatia 8 Ionos Networks 9 S. Pallagatti 10 February 23, 2016 12 Seamless Bidirectional Forwarding Detection (S-BFD) 13 draft-ietf-bfd-seamless-base-08 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 August 26, 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 toby 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. How such S-BFD control packets reach an appropriate reflector 323 BFD session is also a local matter, and is outside the scope of this 324 document. 326 6. State Variables 328 S-BFD introduces new state variables, and modifies the usage of 329 existing ones. 331 6.1. New State Variables 333 A new state variable is added to the base specification in support of 334 S-BFD. 336 o bfd.SessionType: This is a new state variable that describes the 337 type of this session. Allowable values for S-BFD sessions are: 339 * SBFDInitiator - an S-BFD session on a network node that 340 performs a continuity test to a target entity by sending S-BFD 341 packets. 343 * SBFDReflector - an S-BFD session on a network node that listens 344 for incoming S-BFD control packets to local entities and 345 generates response S-BFD control packets. 347 bfd.SessionType variable MUST be initialized to the appropriate type 348 when an S-BFD session is created. 350 6.2. State Variable Initialization and Maintenance 352 A state variable defined in Section 6.8.1 of [RFC5880] need to be 353 initialized or manipulated differently depending on the session type. 355 o bfd.DemandMode: This variable MUST be initialized to 1 for session 356 type SBFDInitiator, and MUST be initialized to 0 for session type 357 SBFDReflector. 359 7. S-BFD Procedures 361 7.1. Demultiplexing of S-BFD Control Packet 363 S-BFD packet MUST be demultiplexed with lower layer information 364 (e.g., dedicated destination UDP port, associated channel type). 365 Following procedure SHOULD be executed on both initiator and 366 reflector. 368 If S-BFD packet 370 If S-BFD packet is for SBFDReflector 372 Packet MUST be looked up to locate a corresponding 373 SBFDReflector session based on the value from the "your 374 discriminator" field in the table describing S-BFD 375 discriminators. 377 Else 379 Packet MUST be looked up to locate a corresponding 380 SBFDInitiator session or classical BFD session based on the 381 value from the "your discriminator" field in the table 382 describing BFD discriminators. If no match then received 383 packet MUST be discarded. 385 If session is SBFDInitiator 387 Destination of the packet (i.e., destination IP address) 388 SHOULD be validated to be for self. 390 Else 392 Packet MUST be discarded 394 Else 396 Procedure described in [RFC5880] MUST be applied. 398 More details on S-BFD control packet demultiplexing are described in 399 relevant S-BFD data plane documents. 401 7.2. Responder Procedures 403 A network node which receives S-BFD control packets transmitted by an 404 initiator is referred as responder. The responder, upon reception of 405 S-BFD control packets, is to perform necessary relevant validations 406 described in [RFC5880]. 408 7.2.1. Responder Demultiplexing 410 S-BFD packet MUST be demultiplexed with lower layer information 411 (e.g., dedicated destination UDP port, associated channel type). 412 Following procedure SHOULD be executed by responder: 414 If "your discriminator" not one of the entry allocated for local 415 entities 417 Packet MUST be discarded. 419 Else 421 Packet is determined to be handled by a reflector BFD session 422 responsible for that S-BFD discriminator. 424 If local policy allows (e.g., administrative, security, rate- 425 limiter, etc) 427 Chosen reflector BFD session SHOULD transmit a response BFD 428 control packet using procedures described in Section 7.3.2. 430 7.2.2. Transmission of S-BFD Control Packet by SBFDReflector 432 Contents of S-BFD control packets sent by an SBFDReflector MUST be 433 set as per Section 6.8.7 of [RFC5880]. There are few fields which 434 needs to be set differently from [RFC5880] as follows: 436 State (Sta) 438 Set to bfd.SessionState (either UP or ADMINDOWN only). 439 Clarification of reflector BFD session state is described in 440 Section 7.2.3. 442 Demand (D) 444 Set to 0. 446 Detect Mult 447 Value to be copied from "Detection Multiplier" filed of 448 received BFD packet. 450 My Discriminator 452 Value be copied from "your discriminator" filed of received BFD 453 packet. 455 Your Discriminator 457 Value be copied from "my discriminator" filed of received BFD 458 packet. 460 Desired Min TX Interval 462 Value be copied from "Desired Min TX Interval" filed of 463 received BFD packet. 465 Required Min RX Interval 467 Set to a bfd.RequiredMinRxInterval, value describing minimum 468 interval, in microseconds between received SBFD Control 469 packets. Further details are described in Section 7.2.3. 471 Required Min Echo RX Interval 473 If device supports looping back S-BFD echo packets 475 Set to the minimum required Echo packet receive interval for 476 this session. 478 Else 480 Set to 0. 482 7.2.3. Additional SBFDReflector Behaviors 484 o S-BFD control packets transmitted by the SBFDReflector MUST have 485 "Required Min RX Interval" set to a value which expresses, in 486 microseconds, the minimum interval between incoming S-BFD control 487 packets this SBFDReflector can handle. The SBFDReflector can 488 control how fast SBFInitiators will be sending S-BFD control 489 packets to self by ensuring "Required Min RX Interval" indicates a 490 value based on the current load. 492 o If the SBFDReflector wishes to communicate to some or all 493 SBFDInitiators that monitored local entity is "temporarily out of 494 service", then S-BFD control packets with "state" set to ADMINDOWN 495 are sent to those SBFDInitiators. The SBFDInitiators, upon 496 reception of such packets, MUST NOT conclude loss of reachability 497 to corresponding remote entity, and MUST back off packet 498 transmission interval for the remote entity to an interval no 499 faster than 1 second. If the SBFDReflector is generating a 500 response S-BFD control packet for a local entity that is in 501 service, then "state" in response BFD control packets MUST be set 502 to UP. 504 o If an SBFDReflector receives an S-BFD control packet with Demand 505 (D) bit cleared, the packet MUST be discarded. 507 7.3. Initiator Procedures 509 S-BFD control packets transmitted by an SBFDInitiator MUST set "your 510 discriminator" field to an S-BFD discriminator corresponding to the 511 remote entity. 513 Every SBFDInitiator MUST have a locally unique "my discriminator" 514 allocated from the BFD discriminator pool. 516 Below Figure 3 art describes high level concept of continuity test 517 using S-BFD. R2 allocates XX as the S-BFD discriminator for its 518 network reachability purpose, and advertises XX to neighbors. ASCII 519 art shows R1 and R4 performing a continuity test to R2. 521 +--- md=50/yd=XX (ping) ----+ 522 | | 523 |+-- md=XX/yd=50 (pong) --+ | 524 || | | 525 |v | v 526 R1 ==================== R2[*] ========= R3 ========= R4 527 | ^ |^ 528 | | || 529 | +-- md=60/yd=XX (ping) --+| 530 | | 531 +---- md=XX/yd=60 (pong) ---+ 533 [*] Reflector BFD session on R2. 534 === Links connecting network nodes. 535 --- S-BFD control packet traversal. 537 Figure 3: S-BFD Continuity Test 539 7.3.1. SBFDInitiator State Machine 541 An SBFDInitiator may be a persistent session on the initiator with a 542 timer for S-BFD control packet transmissions (stateful 543 SBFDInitiator). An SBFDInitiator may also be a module, a script or a 544 tool on the initiator that transmits one or more S-BFD control 545 packets "when needed" (stateless SBFDInitiator). For stateless 546 SBFDInitiators, a complete BFD state machine may not be applicable. 547 For stateful SBFDInitiators, the states and the state machine 548 described in [RFC5880] will not function due to SBFDReflector session 549 only sending UP and ADMINDOWN states (i.e., SBFDReflector session 550 does not send INIT state). The following diagram provides the 551 RECOMMENDED state machine for stateful SBFDInitiators. The notation 552 on each arc represents the state of the SBFDInitiator (as received in 553 the State field in the S-BFD control packet) or indicates the 554 expiration of the Detection Timer. 556 +--+ 557 ADMIN DOWN, | | 558 TIMER | V 559 +------+ UP +------+ 560 | |-------------------->| |----+ 561 | DOWN | | UP | | UP 562 | |<--------------------| |<---+ 563 +------+ ADMIN DOWN, +------+ 564 TIMER 566 Figure 4: SBFDInitiator FSM 568 Note that the above state machine is different from the base BFD 569 specification[RFC5880]. This is because the INIT state is no longer 570 applicable for the SBFDInitiator. Another important difference is 571 the transition of the state machine from the DOWN state to the UP 572 state when a packet with State UP is received by the SBFDInitiator. 573 The definitions of the states and the events have the same meaning as 574 in the base BFD specification [RFC5880]. 576 7.3.2. Transmission of S-BFD Control Packet by SBFDInitiator 578 Contents of S-BFD control packets sent by an SBFDInitiator MUST be 579 set as per Section 6.8.7 of [RFC5880]. There are few fields which 580 needs to be set differently from [RFC5880] as follows: 582 Demand (D) 584 D bit is used to identify S-BFD packet originated from 585 SBFDInitiator and is always set to 1. 587 Your Discriminator 589 Set to bfd.RemoteDiscr. bfd.RemoteDiscr is set to discriminator 590 value of remote entity. It MAY be learnt from routing 591 protocols or configured locally. 593 Required Min RX Interval 595 Set to 0. 597 Required Min Echo RX Interval 599 Set to 0. 601 7.3.3. Additional SBFDInitiator Behaviors 603 o If the SBFDInitiator receives a valid S-BFD control packet in 604 response to transmitted S-BFD control packet to a remote entity, 605 then the SBFDInitiator SHOULD conclude that S-BFD control packet 606 reached the intended remote entity. 608 o When a sufficient number of S-BFD packets have not arrived as they 609 should, the SBFDInitiator SHOULD declare loss of reachability to 610 the remote entity. The criteria for declaring loss of 611 reachability and the action that would be triggered as a result 612 are outside the scope of this document. 614 o Relating to above bullet item, it is critical for an 615 implementation to understand the latency to/from the reflector BFD 616 session on the responder. In other words, for very first S-BFD 617 packet transmitted by the SBFDInitiator, an implementation MUST 618 NOT expect response S-BFD packet to be received for time 619 equivalent to sum of latencies: initiator to responder and 620 responder back to initiator. 622 o If the SBFDInitiator receives an S-BFD control packet with Demand 623 (D) bit set, the packet MUST be discarded. 625 7.4. Diagnostic Values 627 Diagnostic value in both directions MAY be set to a certain value, to 628 attempt to communicate further information to both ends. 629 Implementation MAY use already existing diagnostic values defined in 630 Section 4.1 of [RFC5880]. However, details of such are outside the 631 scope of this specification. 633 7.5. The Poll Sequence 635 Poll sequence MAY be used in both directions. The Poll sequence MUST 636 operate in accordance with [RFC5880]. An SBFDReflector MAY use the 637 Poll sequence to slow down that rate at which S-BFD control packets 638 are generated from an SBFDInitiator. This is done by the 639 SBFDReflector using procedures described in Section 7.2.3 and setting 640 the Poll (P) bit in the reflected S-BFD control packet. The 641 SBFDInitiator is to then send the next S-BFD control packet with the 642 Final (F) bit set. If an SBFDReflector receives an S-BFD control 643 packet with Poll (P) bit set, then the SBFDReflector MUST respond 644 with an S-BFD control packet with Poll (P) bit cleared and Final (F) 645 bit set. 647 8. Operational Considerations 649 S-BFD provides a smooth and continuous operational experience as a 650 failure detection mechanism. This is achieved by providing a 651 simplified mechanism with large portions of negotiation aspects 652 eliminated, resulting in a faster and simpler provisioning. 654 8.1. Scaling Aspect 656 This mechanism brings forth one noticeable difference in terms of 657 scaling aspect: number of SBFDReflector. This specification 658 eliminates the need for egress nodes to have fully active BFD 659 sessions when only one side desires to perform continuity tests. 660 With introduction of reflector BFD concept, egress no longer is 661 required to create any active BFD session per path/LSP/function 662 basis. Due to this, total number of BFD sessions in a network is 663 reduced. 665 8.2. Congestion Considerations 667 S-BFD performs failure detection by consuming resources, including 668 bandwidth and CPU processing. It is therefore imperative that 669 operators correctly provision the rates at which S-BFD is transmitted 670 to avoid congestion. When BFD is used across multiple hops, a 671 congestion control mechanism MUST be implemented, and when congestion 672 is detected, the BFD implementation MUST reduce the amount of traffic 673 it generates. The exact mechanism used to detect congestion is 674 outside the scope of this specification, but may include detection of 675 lost BFD control packets or other means. The SBFDReflector can limit 676 the rate at which an SBFInitiators will be sending S-BFD control 677 packets utilizing the "Required Min RX Interval", at the expense of 678 increasing the detection time. 680 9. Co-existence with Classical BFD Sessions 682 Initial packet demultiplexing requirement is described in 683 Section 7.1. Because of this, S-BFD mechanism can co-exist with 684 classical BFD sessions. 686 10. S-BFD Echo Function 688 The concept of the S-BFD Echo function is similar to the BFD Echo 689 function described in [RFC5880]. S-BFD echo packets have the 690 destination of self, thus S-BFD echo packets are self-generated and 691 self-terminated after traversing a link/path. S-BFD echo packets are 692 expected to u-turn on the target node in the data plane and MUST NOT 693 be processed by any reflector BFD sessions on the target node. 695 When using the S-BFD Echo function, it is RECOMMENDED that: 697 o Both S-BFD control packets and S-BFD echo packets be sent. 699 o Both S-BFD control packets and S-BFD echo packets have the same 700 semantics in the forward direction to reach the target node. 702 In other words, it is not preferable to send just S-BFD echo packets 703 without also sending S-BFD control packets. There are two reasons 704 behind this suggestion: 706 o S-BFD control packets can verify the reachability to intended 707 target node, which allows one to have confidence that S-BFD echo 708 packets are u-turning on the expected target node. 710 o S-BFD control packets can detect when the target node is going out 711 of service (i.e., via receiving back ADMINDOWN state). 713 S-BFD Echo packets can be spoofed, and can u-turn in a transit node 714 before reaching the expected target node. When the S-BFD Echo 715 function is used, it is RECOMMENDED in this specification that both 716 S-BFD control packets and S-BFD echo packets be sent. While the 717 additional use of S-BFD control packets alleviates these two 718 concerns, some form of authentication MAY still be included. 720 The usage of the "Required Min Echo RX Interval" field is described 721 in Section 7.3.2 and Section 7.2.2. Because of the stateless nature 722 of SBFDReflector sessions, a value specified the "Required Min Echo 723 RX Interval" field is not very meaningful at SBFDReflector. Thus it 724 is RECOMMENDED that the "Required Min Echo RX Interval" field simply 725 be set to zero from SBFDInitiator. SBFDReflector MAY set to 726 appropriate value to control the rate at which it wants to receives 727 SBFD echo packets. 729 Following aspects of S-BFD Echo functions are left as implementation 730 details, and are outside the scope of this document: 732 o Format of the S-BFD echo packet (e.g., data beyond UDP header). 734 o Procedures on when and how to use the S-BFD Echo function. 736 11. Security Considerations 738 Same security considerations as [RFC5880] apply to this document. 739 Additionally, implementing the following measures will strengthen 740 security aspects of the mechanism described by this document: 742 o SBFDInitiator MAY pick a sequence number to be set in "sequence 743 Number" in authentication section based on authentication mode 744 configured. 746 o SBFDReflector MUST NOT look at the crypto sequence number before 747 accepting the packet. 749 o SBFDReflector MAY look at the Auth Key ID in the incoming packet 750 and verify the authentication data. 752 o SBFDReflector MUST accept the packet if authentication is 753 successful. 755 o SBFDReflector MUST compute the Authentication data and MUST use 756 the same sequence number that it received in the S-BFD control 757 packet that it is responding to. 759 o SBFDInitiator SHOULD accept S-BFD control packet with sequence 760 number within permissible window. One potential approach is the 761 procedure explained in [I-D.ietf-bfd-generic-crypto-auth]. 763 Using the above method, 765 o SBFDReflector continue to remain stateless despite using security. 767 o SBFDReflector are not susceptible to replay attacks as they always 768 respond to S-BFD control packets irrespective of the sequence 769 number carried. 771 o An attacker cannot impersonate the responder since the 772 SBFDInitiator will only accept S-BFD control packets that come 773 with the sequence number that it had originally used when sending 774 the S-BFD control packet. 776 Considerations about loop problems are covered in Appendix A. 778 12. IANA Considerations 780 No action is required by IANA for this document. 782 13. Acknowledgements 784 Authors would like to thank Jeffrey Haas, Greg Mirsky, Marc 785 Binderberger, and Alvaro Retana for performing thorough reviews and 786 providing number of suggestions. Authors would like to thank Girija 787 Raghavendra Rao, Les Ginsberg, Srihari Raghavan, Vanitha Neelamegam 788 and Vengada Prasad Govindan from Cisco Systems for providing valuable 789 comments. Authors would also like to thank John E. Drake and Pablo 790 Frank for providing comments and suggestions. 792 14. Contributing Authors 794 Tarek Saad 795 Cisco Systems 796 Email: tsaad@cisco.com 798 Siva Sivabalan 799 Cisco Systems 800 Email: msiva@cisco.com 802 Nagendra Kumar 803 Cisco Systems 804 Email: naikumar@cisco.com 806 Mallik Mudigonda 807 Cisco Systems 808 Email: mmudigon@cisco.com 810 Sam Aldrin 811 Google 812 Email: aldrin.ietf@gmail.com 814 15. References 816 15.1. Normative References 818 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 819 Requirement Levels", BCP 14, RFC 2119, 820 DOI 10.17487/RFC2119, March 1997, 821 . 823 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 824 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 825 . 827 15.2. Informative References 829 [I-D.ietf-bfd-generic-crypto-auth] 830 Bhatia, M., Manral, V., Zhang, D., and M. Jethanandani, 831 "BFD Generic Cryptographic Authentication", draft-ietf- 832 bfd-generic-crypto-auth-06 (work in progress), April 2014. 834 [I-D.ietf-bfd-seamless-use-case] 835 Aldrin, S., Bhatia, M., Matsushima, S., Mirsky, G., and N. 836 Kumar, "Seamless Bidirectional Forwarding Detection (BFD) 837 Use Case", draft-ietf-bfd-seamless-use-case-03 (work in 838 progress), July 2015. 840 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 841 DOI 10.17487/RFC0791, September 1981, 842 . 844 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 845 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 846 December 1998, . 848 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 849 Label Switching Architecture", RFC 3031, 850 DOI 10.17487/RFC3031, January 2001, 851 . 853 Appendix A. Loop Problem 855 Consider a scenario where we have two nodes and both are S-BFD 856 capable. 858 Node A (IP 192.0.2.1) ----------------- Node B (IP 192.0.2.2) 859 | 860 | 861 Man in the Middle (MiM) 863 Assume node A reserved a discriminator 0x01010101 for target 864 identifier 192.0.2.1 and has a reflector session in listening mode. 865 Similarly node B reserved a discriminator 0x02020202 for its target 866 identifier 192.0.2.2 and also has a reflector session in listening 867 mode. 869 Suppose MiM sends a spoofed packet with MyDisc = 0x01010101, YourDisc 870 = 0x02020202, source IP as 192.0.2.1 and dest IP as 192.0.2.2. When 871 this packet reaches Node B, the reflector session on Node B will swap 872 the discriminators and IP addresses of the received packet and 873 reflect it back, since YourDisc of the received packet matched with 874 reserved discriminator of Node B. The reflected packet that reached 875 Node A will have MyDdisc=0x02020202 and YourDisc=0x01010101. Since 876 YourDisc of the received packet matched the reserved discriminator of 877 Node A, Node A will swap the discriminators and reflects the packet 878 back to Node B. Since reflectors must set the TTL of the reflected 879 packets to 255, the above scenario will result in an infinite loop 880 with just one malicious packet injected from MiM. 882 FYI: Packet fields do not carry any direction information, i.e., if 883 this is Ping packet or reply packet. 885 Solutions 887 The current proposals to avoid the loop problem are: 889 o Overload "D" bit (Demand mode bit): Initiator always sets the 'D' 890 bit and reflector clears it. This way we can identify if a 891 received packet was a reflected packet and avoid reflecting it 892 back. However this changes the interpretation of 'D' bit. 894 o Use of State field in the BFD control packets: Initiator will 895 always send packets with State set to DOWN and reflector will send 896 back packets with state field set to UP. Reflectors will never 897 reflect any received packets with state as UP. However the only 898 issue is the use of state field differently i.e., state in the 899 S-BFD control packet from initiator does not reflect the local 900 state which is anyway not significant at reflector. 902 o Use of local discriminator as My Disc at reflector: Reflector will 903 always fill in My Discriminator with a locally allocated 904 discriminator value (not reserved discriminators) and will not 905 copy it from the received packet. 907 Authors' Addresses 909 Nobo Akiya 910 Big Switch Networks 912 Email: nobo.akiya.dev@gmail.com 914 Carlos Pignataro 915 Cisco Systems 917 Email: cpignata@cisco.com 918 Dave Ward 919 Cisco Systems 921 Email: wardd@cisco.com 923 Manav Bhatia 924 Ionos Networks 926 Email: manav@ionosnetworks.com 928 Santosh Pallagatti 930 Email: santosh.pallagatti@gmail.com