idnits 2.17.1 draft-ietf-bfd-seamless-use-case-04.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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages 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 (March 21, 2016) is 2957 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) == Outdated reference: A later version (-10) exists of draft-ietf-spring-oam-usecase-01 == 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 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). 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 M. Bhatia 5 Expires: September 22, 2016 Ionos Networks 6 S. Matsushima 7 Softbank 8 G. Mirsky 9 Ericsson 10 N. Kumar 11 Cisco 12 March 21, 2016 14 Seamless Bidirectional Forwarding Detection (BFD) Use Case 15 draft-ietf-bfd-seamless-use-case-04 17 Abstract 19 This document provides various use cases for Bidirectional Forwarding 20 Detection (BFD) and various requirements such that extensions could 21 be developed to allow for simplified detection of forwarding 22 failures. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 22, 2016. 41 Copyright Notice 43 Copyright (c) 2016 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 61 2. Introduction to Seamless BFD . . . . . . . . . . . . . . . . 3 62 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3.1. Unidirectional Forwarding Path Validation . . . . . . . . 4 64 3.2. Validation of forwarding path prior to traffic switching 5 65 3.3. Centralized Traffic Engineering . . . . . . . . . . . . . 6 66 3.4. BFD in Centralized Segment Routing . . . . . . . . . . . 6 67 3.5. Efficient BFD Operation Under Resource Constraints . . . 7 68 3.6. BFD for Anycast Address . . . . . . . . . . . . . . . . . 7 69 3.7. BFD Fault Isolation . . . . . . . . . . . . . . . . . . . 7 70 3.8. Multiple BFD Sessions to Same Target . . . . . . . . . . 8 71 3.9. MPLS BFD Session Per ECMP Path . . . . . . . . . . . . . 8 72 4. Detailed Requirements . . . . . . . . . . . . . . . . . . . . 9 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 75 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 76 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 79 9.2. Informative References . . . . . . . . . . . . . . . . . 11 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 82 1. Introduction 84 Bidirectional Forwarding Detection (BFD) is a lightweight protocol, 85 as defined in [RFC5880], used to detect forwarding failures. Various 86 protocols and applications rely on BFD for failure detection. Even 87 though the protocol is simple, there are certain use cases, where 88 faster setting up of sessions and continuity check of the data 89 forwarding paths is necessary. This document identifies various use 90 cases and requirements related to those, such that necessary 91 enhancements could be made to BFD protocol. 93 BFD is a simple lightweight "Hello" protocol to detect data plane 94 failures. With dynamic provisioning of forwarding paths on a large 95 scale, establishing BFD sessions for each of those paths creates 96 complexity, not only from an operations point of view, but also in 97 terms of the speed at which these sessions could be established or 98 deleted. The existing session establishment mechanism of the BFD 99 protocol has to be enhanced in order to minimize the time for the 100 session to come up to validate the forwarding path. 102 This document specifically identifies various use cases and 103 corresponding requirements in order to enhance BFD and other 104 supporting protocols. While the identified requirements could meet 105 various use cases , it is outside the scope of this document to 106 identify all of the possible and necessary requirements. Solutions 107 to the identified uses cases and protocol specific enhancements or 108 proposals are outside the scope of this document as well. 110 1.1. Terminology 112 The reader is expected to be familiar with the BFD, IP, MPLS and 113 Segment Routing (SR) [I-D.ietf-spring-segment-routing] terminology 114 and protocol constructs. This section identifies only the new 115 terminology introduced. 117 1.2. Requirements Language 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 121 "OPTIONAL" in this document are to be interpreted as described in 122 [RFC2119]. 124 2. Introduction to Seamless BFD 126 BFD, as defined in [RFC5880], requires two network nodes, to exchange 127 locally allocated discriminators. The discriminator enables 128 identification of the sender and receiver of BFD packets of the 129 particular session and perform proactive continuity monitoring of the 130 forwarding path between the two. [RFC5881] defines single hop BFD 131 whereas [RFC5883] defines multi-hop BFD, [RFC5884] BFD for MPLS 132 LSPs, and [RFC5885] - BFD for PWs. 134 Currently, BFD is best suited to verify that two end points are 135 reachable or that an existing connection continues to be up and 136 alive. In order for BFD to be able to initially verify that a 137 connection is valid and that it connects the expected set of end 138 points, it is necessary to provide the node information associated 139 with the connection at each end point prior to initiating BFD 140 sessions, such that this information can be used to verify that the 141 connection is up and verifiable. 143 If this information is already known to the end-points of a potential 144 BFD session, the initial handshake including an exchange of this 145 node-specific information is unnecessary and it is possible for the 146 end points to begin BFD messaging seamlessly. In fact, the initial 147 exchange of discriminator information is an unnecessary extra step 148 that may be avoided for these cases. 150 In a given scenario, where an entity (such as an operator, or 151 centralized controller) determines a set of network entities to which 152 BFD sessions might need to be established. Each of those network 153 entities is assigned a BFD discriminator, to establish a BFD session. 154 These network entities will create a BFD session instance that 155 listens for incoming BFD control packets. Mappings between selected 156 network entities and corresponding BFD discriminators are known to 157 other network nodes belonging in the same network by some means. A 158 network entity in this network is then able to send a BFD control 159 packet to a particular target with the corresponding BFD 160 discriminator. Target network node, upon reception of such BFD 161 control packet, will transmit a response BFD control packet back to 162 the sender. 164 3. Use Cases 166 As per the BFD protocol [RFC5880], BFD sessions are established using 167 handshake mechanism prior to validating the forwarding path. This 168 section outlines some use cases where the existing mechanism may not 169 be able to satisfy the requirements identified. In addition, some of 170 the use cases also stress the need for expedited BFD session 171 establishment while preserving benefits of forwarding failure 172 detection using existing BFD specifications. 174 3.1. Unidirectional Forwarding Path Validation 176 Even though bidirectional verification of forwarding path is useful, 177 there are scenarios where verification is only required in one 178 direction between a pair of nodes. One such case is, when a static 179 route uses BFD to validate reachability to the next-hop IP router. 180 In this case, the static route is established from one network entity 181 to another. The requirement in this case is only to validate the 182 forwarding path for that statically established path. Validation of 183 the forwarding path in the direction of the target entity to the 184 originating entity is not required, in this scenario. Many LSPs have 185 the same unidirectional characteristics and unidirectional validation 186 requirements. Such LSPs are common in Segment Routing and LDP based 187 networks. Another example is when a unidirectional tunnel uses BFD 188 to validate reachability of an egress node. 190 If the traditional BFD is to be used, the target network entity has 191 to be provisioned as well, even though the reverse path validation 192 with BFD session is not required. However, in the case of 193 unidirectional BFD, there is no need for provisioning on the target 194 network entity . Once the mechanism within the BFD protocol is in 195 place, session could be established in a single direction. When the 196 targeted network entity receives the packet, it knows that BFD 197 packet, based on the discriminator and processes it. This does not 198 necessitates the requirement for establishment of a bi-directional 199 session, hence the two way handshake to exchange discriminators is 200 not needed. 202 Thus the requirement for BFD for this use case is to enable session 203 establishment from source network entity to target network entity 204 without the need to have a session in the reverse direction. This 205 requires to ensure that the target network entity (for the BFD 206 session), upon receipt of BFD packet, MUST start processing for the 207 discriminator received in the BFD packet. The source network entity 208 MUST be able to establish a unidirectional BFD session without the 209 bidirectional handshake of discriminators for session establishment. 211 3.2. Validation of forwarding path prior to traffic switching 213 BFD provides data delivery confidence when reachability validation is 214 performed prior to traffic utilizing specific paths/LSPs. However 215 this comes with a cost, where, traffic is prevented to use such 216 paths/LSPs until BFD is able to validate the reachability, which 217 could take seconds due to BFD session bring-up sequences [RFC5880], 218 LSP ping bootstrapping [RFC5884], etc. This use case could be well 219 supported by eliminating the need for session negotiation and 220 discriminator exchanges in order to establish the BFD session. 222 All it takes is for the network entities to know what the 223 discriminator values to be used for the session. The same is the 224 case for S-BFD, i.e., the three-way handshake mechanism is eliminated 225 during bootstrap of BFD sessions. However, this information is 226 required at each entity to verify that BFD messages are being 227 received from the expected end-points, hence the handshake mechanism 228 serves no purpose. Elimination of the unnecessary handshake 229 mechanism allows for faster reachability validation of BFD 230 provisioned paths/LSPs. 232 In addition, it is expected that some MPLS technologies will require 233 traffic engineered LSPs to be created dynamically, perhaps driven by 234 external applications, e.g. in Software Defined Networks (SDN). It 235 will be desirable to perform BFD validation as soon as the LSP?s are 236 created, in order to use them. 238 In order to support this use case, the BFD session MUST be able to be 239 established without the need for session negotiation and exchange of 240 discriminators. 242 3.3. Centralized Traffic Engineering 244 Various technologies in the SDN domain that involve controller based 245 networks have evolved where intelligence, traditionally placed in a 246 distributed and dynamic control plane, is separated from the 247 networking entities along the data path, instead resides in a 248 logically centralized place. There are various controllers that 249 perform this exact function in establishment of forwarding paths for 250 the data flow. Traffic engineering is one important function, where 251 the traffic flow is engineered, depending upon various attributes and 252 constraints of the traffic paths as well as the network state. 254 When the intelligence of the network resides in a centralized entity, 255 ability to manage and maintain the dynamic network becomes a 256 challenge. One way to ensure the forwarding paths are valid, and 257 working, is done by validation of the network using BFD. When 258 traffic engineered tunnels are created, it is operationally critical 259 to ensure that the forwarding paths are working, prior to switching 260 the traffic onto the engineered tunnels. In the absence of control 261 plane protocols, it may be desirable to verify, not only the 262 forwarding path but also of any arbitrary path in the network. With 263 tunnels being engineered by a centralized entity, when the network 264 state changes, traffic has to be switched with minimum latency and 265 without black holing of the data. 267 Traditional BFD session establishment and validation of the 268 forwarding path must not become a bottleneck in the case of 269 centralized traffic engineering. If the controller or other 270 centralized entity is able to instantly verify a forwarding path of 271 the TE tunnel , it could steer the traffic onto the traffic 272 engineered tunnel very quickly thus minimizing adverse effect on a 273 service. This is especially useful and needed when the scale of the 274 network and number of TE tunnels is very high. 276 The cost associated with BFD session negotiation and establishment of 277 BFD sessions to identify valid paths is very high and providing 278 network redundancy becomes a critical issue. 280 3.4. BFD in Centralized Segment Routing 282 A monitoring technique of a Segment Routing network based on a 283 centralized controller is described in [I-D.ietf-spring-oam-usecase]. 284 Various OAM requirements for Segment Routing were captured in 285 [I-D.ietf-spring-sr-oam-requirement]. In validating this use case, 286 one of the requirements is to ensure the BFD packet's behavior is 287 according to the requirement and monitoring of the segment, where the 288 packet is U-turned at the expected node. One of the criterion is to 289 ensure the continuity check to the adjacent segment-id. 291 To support this use case, BFD MUST be able to perform liveness 292 detection initated from centralized controller for any given segment 293 under its domain. 295 3.5. Efficient BFD Operation Under Resource Constraints 297 When BFD sessions are being setup, torn down or modified (i.e. 298 parameters ? such as interval, multiplier, etc are being modified), 299 BFD requires additional packets other than scheduled packet 300 transmissions to complete the negotiation procedures (i.e. P/F 301 bits). There are scenarios where network resources are constrained: 302 a node may require BFD to monitor very large number of paths, or BFD 303 may need to operate in low powered and traffic sensitive networks, 304 i.e. microwave, low powered nano-cells, etc. In these scenarios, it 305 is desirable for BFD to slow down, speed up, stop or resume at will 306 witho minimal additional BFD packets exchanged to establish a new or 307 modified session. 309 The established BFD session parameters and attributes like 310 transmission interval, receiver interval, etc., MUST be modifiable 311 without changing the state of the session. 313 3.6. BFD for Anycast Address 315 BFD protocol requires two endpoints to host BFD sessions, both 316 sending packets to each other. This BFD model does not fit well with 317 anycast address monitoring, as BFD packets transmitted from a network 318 node to an anycast address will reach only one of potentially many 319 network nodes hosting the anycast address. 321 To support this use case, the BFD MUST be able to send packets in 322 order to be received by any of nodes hosting anycast address to which 323 the BFD packets being sent and to respond. This requirement does not 324 require BFD session establishment with every node hosting the anycast 325 address. 327 3.7. BFD Fault Isolation 329 BFD multi-hop [RFC5883]and BFD MPLS [RFC5884] traverse multiple 330 network nodes. BFD has been designed to declare failure upon lack of 331 consecutive packet reception, which can be caused by a fault anywhere 332 along the path. Fast failure detection allows for rapid path 333 recovery procedures. However, operators often have to follow up, 334 manually or automatically, to attempt to identify and localize the 335 fault that caused BFD sessions to fail. Usage of other tools to 336 isolate the fault may cause the packets to traverse a different path 337 through the network (e.g. if ECMP is used). In addition, the longer 338 it takes from BFD session failure to fault isolation attempt, more 339 likely that the fault cannot be isolated, e.g. a fault can get 340 corrected or routed around. If BFD had built-in fault isolation 341 capability, fault isolation can get triggered at the earliest sign of 342 fault and such packets will get load balanced in very similar way, if 343 not the same, as BFD packets that went missing. 345 To support this requirement, BFD SHOULD support fault isolation 346 capability using status indicating fields, when encountered. 348 3.8. Multiple BFD Sessions to Same Target 350 BFD is capable of providing very fast failure detection, as relevant 351 network nodes continuously transmit BFD packets at negotiated rate. 352 If BFD packet transmission is interrupted, even for a very short 353 period of time, that can result in BFD to declare failure 354 irrespective of path liveliness. It is possible, on a system where 355 BFD is running, for certain events, intentionally or unintentionally, 356 to cause a short interruption of BFD packet transmissions. With 357 distributed architectures of BFD implementations, this can be 358 protected, if a node was to run multiple BFD sessions to targets, 359 hosted on different parts of the system (ex: different CPU 360 instances). This can reduce BFD false failures, resulting in more 361 stable network. 363 3.9. MPLS BFD Session Per ECMP Path 365 BFD for MPLS, defined in [RFC5884], describes procedures to run BFD 366 as LSP in-band continuity check mechanism, through usage of MPLS echo 367 request [RFC4379] to bootstrap the BFD session on the egress node. 368 Section 4 of [RFC5884] also describes a possibility of running 369 multiple BFD sessions per alternative paths of LSP. However, details 370 on how to bootstrap and maintain correct set of BFD sessions on the 371 egress node is absent. 373 When an LSP has ECMP segment, it may be desirable to run in-band 374 monitoring that exercises every path of ECMP. Otherwise there will 375 be scenarios where in-band BFD session remains up through one path 376 but traffic is black-holing over another path. BFD session per ECMP 377 path of LSP requires definition of procedures that update [RFC5884] 378 in terms of how to bootstrap and maintain correct set of BFD sessions 379 on the egress node. However, that may require constant use of MPLS 380 Echo Request messages to create and delete BFD sessions on the egress 381 node, when ECMP paths and/or corresponding load balance hash keys 382 change. If a BFD session over any paths of the LSP can be 383 instantiated, stopped and resumed without requiring additional 384 procedures of bootstrapping via MPLS echo request, it would simplify 385 implementations and operations, and benefits network devices as less 386 processing are required by them. 388 To support this requirement, multiple BFD sessions MUST be able to be 389 established over different ECMP paths from the same source to target 390 node. 392 4. Detailed Requirements 394 REQ#1- A target network entity (for the BFD session), upon receipt of 395 BFD packet, MUST start processing for the discriminator received in 396 the BFD packet. 398 REQ#2- The source network entity MUST be able to establish a 399 unidirectional BFD session without the bidirectional handshake of 400 discriminators for session establishment. 402 REQ#3 - The BFD session MUST be able to be established without the 403 need for session negotiation and exchange of discriminators. 405 REQ#4 - BFD MUST be able to perform liveness detection initated from 406 centralized controller for any given segment under its domain. 408 REQ#5 - The established BFD session parameters and attributes like 409 transmission interval, receiver interval, etc., MUST be modifiable 410 without changing the state of the session. 412 REQ#6 - The BFD MUST be able to send and receive response to control 413 packets addressed to an anycast address to be received by any of 414 nodes hosting that address. This requirement does not require BFD 415 session establishment with every node hosting the anycast address. 417 REQ#7 - BFD SHOULD support fault isolation capability and to indicate 418 the same, when fault is encountered. 420 REQ#8 - BFD MUST be able to establish multiple sessions between the 421 same pair of source and target nodes. This requirement enables but 422 does not guarantee ability to monitor diverge paths in ECMP 423 environment. The mapping between BFD session and particular ECMP 424 path is out the scope of BFD specification. 426 5. Security Considerations 428 This document details the use cases and identifies various 429 requirements for the same. As this document do not propose any new 430 protocol or changes to the existing ones, no new security 431 considerations have been identified with this draft. 433 6. IANA Considerations 435 There are no IANA considerations introduced by this draft 437 7. Contributors 439 Carlos Pignataro 441 Cisco Systems 443 Email: cpignata@cisco.com 445 Glenn Hayden 447 ATT 449 Email: gh1691@att.com 451 Santosh P K 453 Juniper 455 Email: santoshpk@juniper.net 457 Mach Chen 459 Huawei 461 Email: mach.chen@huawei.com 463 Nobo Akiya 465 Cisco Systems 467 Email: nobo@cisco.com 469 8. Acknowledgements 471 The authors would like to thank Eric Gray for his useful comments. 473 9. References 475 9.1. Normative References 477 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 478 Requirement Levels", BCP 14, RFC 2119, 479 DOI 10.17487/RFC2119, March 1997, 480 . 482 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 483 Label Switched (MPLS) Data Plane Failures", RFC 4379, 484 DOI 10.17487/RFC4379, February 2006, 485 . 487 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 488 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 489 . 491 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 492 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 493 DOI 10.17487/RFC5881, June 2010, 494 . 496 [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 497 (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, 498 June 2010, . 500 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 501 "Bidirectional Forwarding Detection (BFD) for MPLS Label 502 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 503 June 2010, . 505 [RFC5885] Nadeau, T., Ed. and C. Pignataro, Ed., "Bidirectional 506 Forwarding Detection (BFD) for the Pseudowire Virtual 507 Circuit Connectivity Verification (VCCV)", RFC 5885, 508 DOI 10.17487/RFC5885, June 2010, 509 . 511 9.2. Informative References 513 [I-D.ietf-spring-oam-usecase] 514 Geib, R., Filsfils, C., Pignataro, C., and N. Kumar, "Use 515 Case for a Scalable and Topology-Aware Segment Routing 516 MPLS Data Plane Monitoring System", draft-ietf-spring-oam- 517 usecase-01 (work in progress), October 2015. 519 [I-D.ietf-spring-segment-routing] 520 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 521 and R. Shakir, "Segment Routing Architecture", draft-ietf- 522 spring-segment-routing-07 (work in progress), December 523 2015. 525 [I-D.ietf-spring-sr-oam-requirement] 526 Kumar, N., Pignataro, C., Akiya, N., Geib, R., Mirsky, G., 527 and S. Litkowski, "OAM Requirements for Segment Routing 528 Network", draft-ietf-spring-sr-oam-requirement-01 (work in 529 progress), December 2015. 531 Authors' Addresses 533 Sam Aldrin 534 Google, Inc 535 1600 Amphitheatre Parkway 536 Mountain View, CA 538 Email: aldrin.ietf@gmail.com 540 Manav Bhatia 541 Ionos Networks 543 Email: manav@ionosnetworks.com 545 Satoru Matsushima 546 Softbank 548 Email: satoru.matsushima@g.softbank.co.jp 550 Greg Mirsky 551 Ericsson 553 Email: gregory.mirsky@ericsson.com 555 Nagendra Kumar 556 Cisco 558 Email: naikumar@cisco.com