idnits 2.17.1 draft-ietf-bfd-seamless-use-case-07.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 -- The document date (May 4, 2016) is 2913 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-ietf-bfd-seamless-base-09 == Outdated reference: A later version (-06) exists of draft-ietf-bfd-seamless-ip-04 == Outdated reference: A later version (-10) exists of draft-ietf-spring-oam-usecase-03 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-07 == Outdated reference: A later version (-03) exists of draft-ietf-spring-sr-oam-requirement-01 -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 4379 (Obsoleted by RFC 8029) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Aldrin 3 Internet-Draft Google, Inc 4 Intended status: Informational C. Pignataro 5 Expires: November 5, 2016 Cisco 6 G. Mirsky 7 Ericsson 8 N. Kumar 9 Cisco 10 May 4, 2016 12 Seamless Bidirectional Forwarding Detection (S-BFD) Use Cases 13 draft-ietf-bfd-seamless-use-case-07 15 Abstract 17 This document describes various use cases for a Seamless 18 Bidirectional Forwarding Detection (S-BFD), and provides requirements 19 such that protocol mechanisms allow for a simplified detection of 20 forwarding failures. 22 These use cases support S-BFD, as a simplified mechanism to use 23 Bidirectional Forwarding Detection (BFD) with large portions of 24 negotiation aspects eliminated, accelerating the establishment of a 25 BFD session. S-BFD benefits include quick provisioning as well as 26 improved control and flexibility to network nodes initiating the path 27 monitoring. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on November 5, 2016. 46 Copyright Notice 48 Copyright (c) 2016 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 66 2. Introduction to Seamless BFD . . . . . . . . . . . . . . . . 4 67 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3.1. Unidirectional Forwarding Path Validation . . . . . . . . 5 69 3.2. Validation of the Forwarding Path Prior to Switching 70 Traffic . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 3.3. Centralized Traffic Engineering . . . . . . . . . . . . . 7 72 3.4. BFD in Centralized Segment Routing . . . . . . . . . . . 8 73 3.5. Efficient BFD Operation under Resource Constraints . . . 8 74 3.6. BFD for Anycast Addresses . . . . . . . . . . . . . . . . 8 75 3.7. BFD Fault Isolation . . . . . . . . . . . . . . . . . . . 9 76 3.8. Multiple BFD Sessions to the Same Target Node . . . . . . 9 77 3.9. An MPLS BFD Session Per ECMP Path . . . . . . . . . . . . 10 78 4. Detailed Requirements for a Seamless BFD . . . . . . . . . . 10 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 81 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 82 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 85 9.2. Informative References . . . . . . . . . . . . . . . . . 13 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 88 1. Introduction 90 Bidirectional Forwarding Detection (BFD) is a lightweight protocol, 91 as defined in [RFC5880], used to detect forwarding failures. Various 92 protocols and applications rely on BFD as its clients for failure 93 detection. Even though the protocol is lightweight and simple, there 94 are certain use cases where faster setting up of sessions and faster 95 continuity check of the data forwarding paths is necessary. This 96 document identifies these use cases and consequent requirements, such 97 that enhancements and extensions result in a Seamless BFD (S-BFD) 98 protocol. 100 BFD is a simple lightweight "Hello" protocol to detect data plane 101 failures. With dynamic provisioning of forwarding paths on a large 102 scale, establishing BFD sessions for each of those paths not only 103 creates operational complexity, but also causes undesirable delay in 104 establishing or deleting sessions. The existing session 105 establishment mechanism of the BFD protocol has to be enhanced in 106 order to minimize the time for the session to come up to validate the 107 forwarding path. 109 This document specifically identifies various use cases and 110 corresponding requirements in order to enhance BFD and other 111 supporting protocols. Specifically, one key goal is removing the 112 time delay (i.e., the "seam") between a network node wants to perform 113 a continuity test and the node completes that continuity test. 114 Consequently, "Seamless BFD" (S-BFD) has been chosen as the name for 115 this mechanism. 117 While the identified requirements could meet various use cases, it is 118 outside the scope of this document to identify all of the possible 119 and necessary requirements. Solutions to the identified uses cases 120 and protocol specific enhancements or proposals are outside the scope 121 of this document as well. Protocol definitions to support these use 122 cases can be found at [I-D.ietf-bfd-seamless-base] and 123 [I-D.ietf-bfd-seamless-ip]. 125 1.1. Terminology 127 The reader is expected to be familiar with the BFD [RFC5880], IP 128 [RFC0791] [RFC2460], MPLS [RFC3031], and Segment Routing (SR) 129 [I-D.ietf-spring-segment-routing] terminologies and protocol 130 constructs. 132 1.2. Requirements Language 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 136 "OPTIONAL" in this document are to be interpreted as described in 137 [RFC2119]. 139 2. Introduction to Seamless BFD 141 BFD, as defined in [RFC5880], requires two network nodes to exchange 142 locally allocated discriminators. These discriminators enable the 143 identification of the sender and the receiver of BFD packets over the 144 particular session. Subsequently, BFD performs proactive continuity 145 monitoring of the forwarding path between the two. Several 146 specifications describe BFD's multiple deployment uses: 148 [RFC5881] defines BFD over IPv4 and IPv6 for single IP hops 150 [RFC5883] defines BFD over multihop paths 152 [RFC5884] defines BFD for MPLS Label Switched Paths (LSPs) 154 [RFC5885] defines BFD for MPLS Pseudowires (PWs) 156 Currently, BFD is best suited to verify that two endpoints are 157 mutually reachable or that an existing connection continues to be up 158 and alive. In order for BFD to be able to initially verify that a 159 connection is valid and that it connects the expected set of 160 endpoints, it is necessary to provide each endpoint with the 161 discriminators associated with the connection at each endpoint prior 162 to initiating BFD sessions. The discriminators are used to verify 163 that the connection is up and verifiable. Currently, the exchange of 164 discriminators and the demultiplexing of the initial BFD packets is 165 application dependent. 167 If this information is already known to the end-points of a potential 168 BFD session, the initial handshake including an exchange of 169 discriminators is unnecessary and it is possible for the endpoints to 170 begin BFD messaging seamlessly. A key objective of the S-BFD use 171 cases described in this document is to avoid needing to exchange the 172 initial packets before the BFD session can be established, with the 173 goal of getting to the established state more quickly; in other 174 words, the initial exchange of discriminator information is an 175 unnecessary extra step that may be avoided for these cases. 177 In a given scenario, an entity (such as an operator, or a centralized 178 controller) determines a set of network entities to which BFD 179 sessions might need to be established. In traditional BFD, each of 180 those network entities chooses a BFD discriminator for each BFD 181 session that the entity will participate in (see Section 6.3 of 182 [RFC5880]). However, a key goal of a Seamless BFD is to provide 183 operational simplification. In this context, for S-BFD, each of 184 those network entities is assigned one or more BFD discriminators, 185 and allowing those network entities to use one discriminator value 186 for multiple sessions. Therefore, there may be only one or a few 187 discriminators assigned to a node. These network entities will 188 create an S-BFD listener session instance that listens for incoming 189 BFD control packets. When the mappings between specific network 190 entities and their corresponding BFD discriminators are known to 191 other network nodes belonging to the same administrative domain, 192 then, without having received any BFD packet from a particular 193 target, a network entity in this network is able to send a BFD 194 control packet to the target's assigned discriminator in the Your 195 Discriminator field. The target network node, upon reception of such 196 BFD control packet, will transmit a response BFD control packet back 197 to the sender. 199 3. Use Cases 201 As per the BFD protocol [RFC5880], BFD sessions are established using 202 handshake mechanism prior to validating the forwarding path. This 203 section outlines some use cases where the existing mechanism may not 204 be able to satisfy the requirements identified. In addition, some of 205 the use cases also stress the need for expedited BFD session 206 establishment while preserving benefits of forwarding failure 207 detection using existing BFD mechanics. Both these high-level goals 208 result in the S-BFD use cases. 210 3.1. Unidirectional Forwarding Path Validation 212 Even though bidirectional verification of forwarding path is useful, 213 there are scenarios where verification is only required in one 214 direction between a pair of nodes. One such case is, when a static 215 route uses BFD to validate reachability to the next-hop IP router. 216 In this case, the static route is established from one network entity 217 to another. The requirement in this case is only to validate the 218 forwarding path for that statically established unidirectional path. 219 Validation of the forwarding path in the direction of the target 220 entity to the originating entity is not required, in this scenario. 221 Many LSPs have the same unidirectional characteristics and 222 unidirectional validation requirements. Such LSPs are common in 223 Segment Routing and LDP based MPLS networks. A final example is when 224 a unidirectional tunnel uses BFD to validate reachability of an 225 egress node. 227 Additionally, there are operational implications to the 228 unidirectional path validation. If the traditional BFD is to be 229 used, the target network entity has to be provisioned as well as an 230 initiator, even though the reverse path validation with the BFD 231 session is not required. However, in the case of unidirectional BFD, 232 there is no need for provisioning on the target network entity, only 233 the source one. 235 In this use case, a BFD session could be established in a single 236 direction. When the targeted network entity receives the packet, it 237 identities the packet as BFD in an application-specific manner (for 238 example, a destination UDP port number). Subsequently, the BFD 239 module processes the packet, using the Your Discriminator value as 240 context. Then, the network entity sends a response to the 241 originator. This does not necessitate the requirement for 242 establishment of a bi-directional session, hence the two way 243 handshake to exchange discriminators is not needed. The target node 244 does not need to know the My Discriminator of the source node. 246 Thus, a requirement for BFD for this use case is to enable session 247 establishment from source network entity to target network entity 248 without the need to have a session (and state) for the reverse 249 direction. Further, another requirement is that the BFD response 250 from target back to sender can take any (in-band or out-of-band) 251 path. The BFD module in the target network entity (for the BFD 252 session), upon receipt of BFD packet, starts processing the BFD 253 packet based on the discriminator received. The source network 254 entity can therefore establish a unidirectional BFD session without 255 the bidirectional handshake and exchange of discriminators for 256 session establishment. 258 3.2. Validation of the Forwarding Path Prior to Switching Traffic 260 This use case is when BFD is used to verify reachability before 261 sending traffic via a path/LSP. This comes with a cost, which is 262 that traffic is prevented to use the path/LSP until BFD is able to 263 validate the reachability, which could take seconds due to BFD 264 session bring-up sequences [RFC5880], LSP ping bootstrapping 265 [RFC5884], etc. This use case would be better supported by 266 eliminating the need for the initial BFD session negotiation. 268 All it takes to be able to send BFD packets to a target, and the 269 target properly demultiplexing these, is for the source network 270 entities to know what the discriminator values to be used for the 271 session. The same is the case for S-BFD: the three-way handshake 272 mechanism is eliminated during the bootstrap of BFD sessions. 273 However, this information is required at each entity to verify that 274 BFD messages are being received from the expected end-points, hence 275 the handshake mechanism serves no purpose. Elimination of the 276 unnecessary handshake mechanism allows for faster reachability 277 validation of BFD provisioned paths/LSPs. 279 In addition, it is expected that some MPLS technologies will require 280 traffic engineered LSPs to be created dynamically, perhaps driven by 281 external applications, as e.g. in Software Defined Networks (SDN). 283 It will be desirable to perform BFD validation as soon as the LSPs 284 are created, so as to use them. 286 In order to support this use case, an S-BFD session is established 287 without the need for session negotiation and exchange of 288 discriminators. 290 3.3. Centralized Traffic Engineering 292 Various technologies in the SDN domain that involve controller-based 293 networks have evolved such that the intelligence, traditionally 294 placed in a distributed and dynamic control plane, is separated from 295 the networking entities themselves; instead, it resides in a 296 (logically) centralized place. There are various controllers that 297 perform the function in establishment of forwarding paths for the 298 data flow. Traffic engineering (TE) is one important function, where 299 the path of the traffic flow is engineered, depending upon various 300 attributes and constraints of the traffic paths as well as the 301 network state. 303 When the intelligence of the network resides in a centralized entity, 304 the ability to manage and maintain the dynamic network and its 305 multiple data paths and node reachability becomes a challenge. One 306 way to ensure the forwarding paths are valid and working is done by 307 validation using BFD. When traffic engineered tunnels are created, 308 it is operationally critical to ensure that the forwarding paths are 309 working, prior to switching the traffic onto the engineered tunnels. 310 In the absence of distributed control plane protocols, it may be 311 desirable to verify any arbitrary forwarding path in the network. 312 With tunnels being engineered by a centralized entity, when the 313 network state changes, traffic has to be switched with minimum 314 latency and without black-holing of the data. 316 It is highly desirable in this centralized traffic engineering use 317 case that the traditional BFD session establishment and validation of 318 the forwarding path does not become a bottleneck. If the controller 319 or other centralized entity is able to very rapidly verify the 320 forwarding path of a traffic engineered tunnel, it could steer the 321 traffic onto the traffic engineered tunnel very quickly thus 322 minimizing adverse effect on a service. This is even more useful and 323 necessary when the scale of the network and number of traffic 324 engineered tunnels grows. 326 The cost associated with the time required for BFD session 327 negotiation and establishment of BFD sessions to identify valid paths 328 is very high when providing network redundancy is a critical issue. 330 3.4. BFD in Centralized Segment Routing 332 A monitoring technique of a Segment Routing network based on a 333 centralized controller is described in [I-D.ietf-spring-oam-usecase]. 334 Specific OAM requirements for Segment Routing are captured in 335 [I-D.ietf-spring-sr-oam-requirement]. In validating this use case, 336 one of the requirements is to ensure that the BFD packet's behavior 337 is according to the monitoring specified for the segment, and that 338 the packet is U-turned at the expected node. This criteria ensures 339 the continuity check to the adjacent segment-id. 341 To support this use case, the operational requirement is for BFD, 342 initiated from a centralized controller, to perform liveness 343 detection for any given segment under its domain. 345 3.5. Efficient BFD Operation under Resource Constraints 347 When BFD sessions are being setup, torn down or modified (i.e., when 348 parameters such as interval and multiplier are being modified), BFD 349 requires additional packets other than scheduled packet transmissions 350 to complete the negotiation procedures (i.e., P/F bits). There are 351 scenarios where network resources are constrained: a node may require 352 BFD to monitor very large number of paths, or BFD may need to operate 353 in low powered and traffic sensitive networks; these include 354 microwave, low powered nano-cells, and others. In these scenarios, 355 it is desirable for BFD to slow down, speed up, stop, or resume at- 356 will and with minimal number of additional BFD packets exchanged to 357 modify the session or establish a new one. 359 The established BFD session parameters and attributes like 360 transmission interval, receiver interval, etc., need to be modifiable 361 without changing the state of the session. 363 3.6. BFD for Anycast Addresses 365 The BFD protocol requires two endpoints to host BFD sessions, both 366 sending packets to each other. This BFD model does not fit well with 367 anycast address monitoring, as BFD packets transmitted from a network 368 node to an anycast address will reach only one of potentially many 369 network nodes hosting the anycast address. 371 This use case verifies that a source node can send a packet to an 372 anycast address, and that the target node to which the packet is 373 delivered can send a response packet to the source node. Traditional 374 BFD cannot fulfill this requirement, since it does not provide for a 375 set of BFD agents to collectively form one endpoint of a BFD session. 376 The concept of a Target Listener in S-BFD solves this requirement. 378 To support this use case, the BFD sender transmits BFD packets, which 379 are received by any of the nodes hosting the anycast address to which 380 the BFD packets being sent. The anycast target that receives the BFD 381 packet, responds. This use case does not imply the BFD session 382 establishment with every node hosting the anycast address. 383 Consequently, in this any cast use case, target nodes that do not 384 happen to receive any of the BFD packets do not need to maintain any 385 state, and the source node does not need to maintain separate state 386 for each target node. 388 3.7. BFD Fault Isolation 390 BFD for multihop paths [RFC5883] and BFD for MPLS LSPs [RFC5884] 391 perform end-to-end validation, traversing multiple network nodes. 392 BFD has been designed to declare failure upon lack of consecutive 393 packet reception, which can be caused by a fault anywhere along these 394 path. Fast failure detection allows for rapid fault detection and 395 consequent rapid path recovery procedures. However, operators often 396 have to follow up, manually or automatically, to attempt to identify 397 and localize the fault that caused BFD sessions to fail (i.e., fault 398 isolation). The usage of other tools to isolate the fault (e.g., 399 traceroute) may cause the packets to traverse a different path 400 through the network, if Equal-Cost Multipath (ECMP) is used. In 401 addition, the longer it takes from BFD session failure to starting 402 fault isolation, the more likely that the fault will not be able to 403 be isolated (e.g., a fault can get corrected or routed around). If 404 BFD had built-in fault isolation capability, fault isolation can get 405 triggered at the earliest sign of fault detection. This embedded 406 fault isolation will be more effective when those BFD fault isolation 407 packets are load balanced in the same way as the BFD packets that 408 were dropped, detecting the fault. 410 This use case describes S-BFD fault isolation capabilities, utilizing 411 a TTL field (e.g., as in Section 5.1.1 of [I-D.ietf-bfd-seamless-ip]) 412 or using status indicating fields. 414 3.8. Multiple BFD Sessions to the Same Target Node 416 BFD is capable of providing very fast failure detection, as relevant 417 network nodes continuously transmit BFD packets at the negotiated 418 rate. If BFD packet transmission is interrupted, even for a very 419 short period of time, BFD can declare a failure irrespective of path 420 liveliness. It is possible, on a system where BFD is running, for 421 certain events (intentionally or unintentionally) to cause a short 422 interruption of BFD packet transmissions. With distributed 423 architectures of BFD implementations, this case can be protected. In 424 this case, the use case of an S-BFD node running multiple BFD 425 sessions to a targets, with those sessions hosted on different system 426 modules (e.g., in different CPU instances). This can reduce BFD 427 false failures, resulting in more stable network. 429 To support this use case, a mapping between the multiple 430 discriminators on a single system, and the specific entity within the 431 system is required. 433 3.9. An MPLS BFD Session Per ECMP Path 435 BFD for MPLS LSPs, defined in [RFC5884], describes procedures to run 436 BFD as LSP in-band continuity check mechanism, through usage of MPLS 437 echo request [RFC4379] to bootstrap the BFD session on the target 438 (i.e., egress) node. Section 4 of [RFC5884] also describes a 439 possibility of running multiple BFD sessions per alternative paths of 440 LSP. [RFC7726] further clarified the procedures, both for ingress 441 and egress nodes, of how to bootstrap, maintain, and remove multiple 442 BFD sessions for the same tuple. However, this 443 mechanism still requires the use of MPLS LSP Ping for bootstrapping, 444 round-trips for initialization, and keeping state at the receiver. 446 In the presence of ECMP within an MPLS LSP, it may be desirable to 447 run in-band monitoring that exercises every path of this ECMP. 448 Otherwise there will be scenarios where in-band BFD session remains 449 up through one path but traffic is black-holing over another path. A 450 BFD session per ECMP path of an LSP requires the definition of 451 procedures that update [RFC5884] in terms of how to bootstrap and 452 maintain the correct set of BFD sessions on the egress node. 453 However, for traditional BFD, that requires the constant use of MPLS 454 Echo Request messages to create and delete BFD sessions on the egress 455 node, when ECMP paths and/or corresponding load balance hash keys 456 change. If a BFD session over any paths of the LSP can be 457 instantiated, stopped and resumed without requiring additional 458 procedures of bootstrapping via an MPLS echo request message, it 459 would greatly simplify both implementations and operations, and 460 benefits network devices as less processing are required by them. 462 To support this requirement, multiple S-BFD sessions need to be 463 established over different ECMP paths from the same source to target 464 node. 466 4. Detailed Requirements for a Seamless BFD 468 REQ#1: A target network entity (for the S-BFD session), upon 469 receipt of the S-BFD packet, MUST process the packet based 470 on the discriminator received in the BFD packet. If the 471 S-BFD context is found, the target network entity MUST be 472 able to send a response. 474 REQ#2: The source network entity MUST be able to establish a 475 unidirectional S-BFD session without the bidirectional 476 handshake of discriminators for session establishment. 478 REQ#3: The S-BFD session MUST be able to be established without the 479 need for exchange of discriminators in session negotiation. 481 REQ#4: In a Segment Routed network, S-BFD MUST be able to perform 482 liveness detection initiated from a centralized controller 483 for any given segment under its domain. 485 REQ#5: The established S-BFD session parameters and attributes, 486 such as transmission interval, reception interval, etc., 487 MUST be modifiable without changing the state of the 488 session. 490 REQ#6: An S-BFD source network entity MUST be able to send S-BFD 491 control packets to an anycast address which are received by 492 any node hosting that address, and must be able to receive 493 responses from any of these anycast nodes, without 494 establishing a separate BFD session with every node hosing 495 the anycast address. 497 REQ#7: S-BFD SHOULD support fault isolation capability, which MAY 498 be triggered when a fault is encountered. 500 REQ#8: S-BFD SHOULD be able to establish multiple sessions between 501 the same pair of source and target nodes. This requirement 502 enables but does not guarantee the ability to monitor 503 diverge paths in ECMP environments. It also provides 504 resiliency in distributed router architectures. The mapping 505 between BFD discriminators and particular entities (e.g., 506 ECMP paths, or Line Cards) is out the scope of the S-BFD 507 specification. 509 REQ#9: The S-BFD protocol MUST provide mechanisms for loop 510 detection and prevention, protecting against malicious 511 attacks attempting to create packet loops. 513 REQ#10: S-BFD MUST incorporate robust security protections against 514 impersonators, malicions actors, and various attacks. The 515 simple and accelerated establishment of an S-BFD session 516 should not negatively affect security. 518 5. Security Considerations 520 This document details the use cases and identifies various associated 521 requirements. Some of these requirements are security related. The 522 use cases herein described do not expose a system to abuse or to 523 additional security risks. Since some negotiation aspects are 524 eliminated, a misconfiguration can result in S-BFD packets being sent 525 to an incorrect node. If this receiving node runs S-BFD, the packet 526 will be discarted because of the discriminator mismatch. If the node 527 does not run S-BFD, the packet will be naturally discarded. 529 The proposed new protocols, extensions, and enhancements for a 530 Seamless BFD supporting these use cases and realizing these 531 requirements will address the associated security considerations. A 532 Seamless BFD should not have reduced security capabilities as 533 compared to traditional BFD. 535 6. IANA Considerations 537 There are no IANA considerations introduced by this document. 539 7. Acknowledgements 541 The authors would like to thank Tobias Gondrom and Eric Gray, for 542 their insightful and useful comments. The authors appreciate the 543 thorough review and comments provided by Dale R. Worley. 545 8. Contributors 547 The following are key contributors to this document: 549 Manav Bhatia, Ionos Networks 550 Satoru Matsushima, Softbank 551 Glenn Hayden, ATT 552 Santosh P K 553 Mach Chen, Huawei 554 Nobo Akiya, Big Switch Networks 556 9. References 558 9.1. Normative References 560 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 561 Requirement Levels", BCP 14, RFC 2119, 562 DOI 10.17487/RFC2119, March 1997, 563 . 565 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 566 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 567 . 569 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 570 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 571 DOI 10.17487/RFC5881, June 2010, 572 . 574 [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 575 (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, 576 June 2010, . 578 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 579 "Bidirectional Forwarding Detection (BFD) for MPLS Label 580 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 581 June 2010, . 583 [RFC5885] Nadeau, T., Ed. and C. Pignataro, Ed., "Bidirectional 584 Forwarding Detection (BFD) for the Pseudowire Virtual 585 Circuit Connectivity Verification (VCCV)", RFC 5885, 586 DOI 10.17487/RFC5885, June 2010, 587 . 589 9.2. Informative References 591 [I-D.ietf-bfd-seamless-base] 592 Akiya, N., Pignataro, C., Ward, D., Bhatia, M., and J. 593 Networks, "Seamless Bidirectional Forwarding Detection 594 (S-BFD)", draft-ietf-bfd-seamless-base-09 (work in 595 progress), April 2016. 597 [I-D.ietf-bfd-seamless-ip] 598 Akiya, N., Pignataro, C., and D. Ward, "Seamless 599 Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6 600 and MPLS", draft-ietf-bfd-seamless-ip-04 (work in 601 progress), April 2016. 603 [I-D.ietf-spring-oam-usecase] 604 Geib, R., Filsfils, C., Pignataro, C., and N. Kumar, "A 605 Scalable and Topology-Aware MPLS Dataplane Monitoring 606 System", draft-ietf-spring-oam-usecase-03 (work in 607 progress), April 2016. 609 [I-D.ietf-spring-segment-routing] 610 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 611 and R. Shakir, "Segment Routing Architecture", draft-ietf- 612 spring-segment-routing-07 (work in progress), December 613 2015. 615 [I-D.ietf-spring-sr-oam-requirement] 616 Kumar, N., Pignataro, C., Akiya, N., Geib, R., Mirsky, G., 617 and S. Litkowski, "OAM Requirements for Segment Routing 618 Network", draft-ietf-spring-sr-oam-requirement-01 (work in 619 progress), December 2015. 621 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 622 DOI 10.17487/RFC0791, September 1981, 623 . 625 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 626 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 627 December 1998, . 629 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 630 Label Switching Architecture", RFC 3031, 631 DOI 10.17487/RFC3031, January 2001, 632 . 634 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 635 Label Switched (MPLS) Data Plane Failures", RFC 4379, 636 DOI 10.17487/RFC4379, February 2006, 637 . 639 [RFC7726] Govindan, V., Rajaraman, K., Mirsky, G., Akiya, N., and S. 640 Aldrin, "Clarifying Procedures for Establishing BFD 641 Sessions for MPLS Label Switched Paths (LSPs)", RFC 7726, 642 DOI 10.17487/RFC7726, January 2016, 643 . 645 Authors' Addresses 647 Sam Aldrin 648 Google, Inc 650 Email: aldrin.ietf@gmail.com 652 Carlos Pignataro 653 Cisco Systems, Inc. 655 Email: cpignata@cisco.com 656 Greg Mirsky 657 Ericsson 659 Email: gregory.mirsky@ericsson.com 661 Nagendra Kumar 662 Cisco Systems, Inc. 664 Email: naikumar@cisco.com