idnits 2.17.1 draft-ietf-bfd-seamless-use-case-03.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 10 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 (July 31, 2015) is 3163 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) Summary: 1 error (**), 0 flaws (~~), 2 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: February 1, 2016 Ionos Networks 6 S. Matsushima 7 Softbank 8 G. Mirsky 9 Ericsson 10 N. Kumar 11 Cisco 12 July 31, 2015 14 Seamless Bidirectional Forwarding Detection (BFD) Use Case 15 draft-ietf-bfd-seamless-use-case-03 17 Abstract 19 This document provides various use cases for Bidirectional Forwarding 20 Detection (BFD) such that extensions could be developed to allow for 21 simplified detection of forwarding failures. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on February 1, 2016. 40 Copyright Notice 42 Copyright (c) 2015 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Introduction to Seamless BFD . . . . . . . . . . . . . . . . 3 60 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.1. Unidirectional Forwarding Path Validation . . . . . . . . 4 62 3.2. Validation of forwarding path prior to traffic switching 5 63 3.3. Centralized Traffic Engineering . . . . . . . . . . . . . 5 64 3.4. BFD in Centralized Segment Routing . . . . . . . . . . . 6 65 3.5. BFD Efficient Operation Under Resource Constraints . . . 6 66 3.6. BFD for Anycast Address . . . . . . . . . . . . . . . . . 7 67 3.7. BFD Fault Isolation . . . . . . . . . . . . . . . . . . . 7 68 3.8. Multiple BFD Sessions to Same Target . . . . . . . . . . 7 69 3.9. MPLS BFD Session Per ECMP Path . . . . . . . . . . . . . 7 70 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 72 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 73 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 76 8.2. Informative References . . . . . . . . . . . . . . . . . 10 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 79 1. Introduction 81 Bidirectional Forwarding Detection (BFD) is a lightweight protocol, 82 as defined in [RFC5880], used to detect forwarding failures. Various 83 protocols and applications rely on BFD for failure detection. Even 84 though the protocol is simple and lightweight, there are certain use 85 cases, where faster setting up of sessions and continuity check of 86 the data forwarding paths is necessary. This document identifies use 87 cases such that necessary enhancements could be made to BFD protocol 88 to meet those requirements. 90 BFD was designed to be a lightweight "Hello" protocol to detect data 91 plane failures. With dynamic provisioning of forwarding paths on a 92 large scale, establishing BFD sessions for each of those paths 93 creates complexity, not only from an operations point of view, but 94 also in terms of the speed at which these sessions could be 95 established or deleted. The existing session establishment mechanism 96 of the BFD protocol need to be enhanced in order to minimize the time 97 for the session to come up and validate the forwarding path. 99 This document specifically identifies those cases where certain 100 requirements could be derived to be used as reference, so that, 101 protocol enhancements could be developed to address them. While the 102 use cases could be used as reference for certain requirements, it is 103 outside the scope of this document to identify all of the 104 requirements for all possible enhancements. Specific solutions and 105 enhancement proposals are outside the scope of this document as well. 107 1.1. Terminology 109 The reader is expected to be familiar with the BFD, IP, MPLS and 110 Segment Routing (SR) terminology and protocol constructs. This 111 section identifies only the new terminology introduced. 113 2. Introduction to Seamless BFD 115 BFD, as defined in [RFC5880], requires two network nodes, to exchange 116 locally allocated discriminators. The discriminator enables 117 identification of the sender and receiver of BFD packets of the 118 particular session and proactive continuity monitoring of the 119 forwarding path between the two. [RFC5881] defines single hop BFD 120 whereas [RFC5883] defines multi-hop BFD, [RFC5884] BFD for MPLS 121 LSPs, and [RFC5885] - BFD for PWs. 123 Currently, BFD is best suited to verify that two end points are 124 reachable or that an existing connection continues to be valid. In 125 order for BFD to be able to initially verify that a connection is 126 valid and that it connects the expected set of end points, it is 127 necessary to provide the node information associated with the 128 connection at each end point prior to initiating BFD sessions, such 129 that this information can be used to verify that the connection is 130 valid. 132 If this information is already known to the end-points of a potential 133 BFD session, the initial handshake including an exchange of this 134 node-specific information is unnecessary and it is possible for the 135 end points to begin BFD messaging seamlessly. In fact, the initial 136 exchange of discriminator information is an unnecessary extra step 137 that may be avoided for these cases. 139 As an example of how Seamless BFD (S-BFD) might work, an entity (such 140 as an operator, or centralized controller) determines a set of 141 network entities to which BFD sessions might need to be established. 142 Each of those network entities is assigned a BFD discriminator, to 143 establish a BFD session. These network entities will create a BFD 144 session instance that listens for incoming BFD control packets. 145 Mappings between selected network entities and corresponding BFD 146 discriminators are known to other network nodes belonging in the same 147 network by some means. A network entity in this network is then able 148 to send a BFD control packet to a particular target with the 149 corresponding BFD discriminator. Target network node, upon reception 150 of such BFD control packet, will transmit a response BFD control 151 packet back to the sender. 153 3. Use Cases 155 As per the BFD protocol [RFC5880], BFD sessions are established using 156 handshake mechanism prior to validating the forwarding path. This 157 section outlines some use cases where the existing mechanism may not 158 be able to satisfy the requirements. In addition, some of the use 159 cases also be identify the need for expedited BFD session 160 establishment while preserving benefits of forwarding failure 161 detection using existing BFD specifications. 163 3.1. Unidirectional Forwarding Path Validation 165 Even though bidirectional verification of forwarding path is useful, 166 there are scenarios when verification is only required in one 167 direction between a pair of nodes. One such case is when a static 168 route uses BFD to validate reachability to the next-hop IP router. 169 In this case, the static route is established from one network entity 170 to another. The requirement in this case is only to validate the 171 forwarding path for that statically established path, and validation 172 by the target entity to the originating entity is not required. Many 173 LSPs have the same unidirectional characteristics and unidirectional 174 validation requirements. Such LSPs are common in Segment Routing and 175 LDP based networks. Another example is when a unidirectional tunnel 176 uses BFD to validate reachability of an egress node. 178 If the traditional BFD is to be used, the target network entity has 179 to be provisioned as well, even though the reverse path validation 180 with BFD session is not required. But with unidirectional BFD, the 181 need to provision on the target network entity is not needed. Once 182 the mechanism within the BFD protocol is in place, where the source 183 network entity knows the target network entity's discriminator, it 184 starts the session right away. When the targeted network entity 185 receives the packet, it knows that BFD packet, based on the 186 discriminator and processes it. That does not require establishment 187 of a bi-directional session, hence the two way handshake to exchange 188 discriminators is not needed as well. 190 The primary requirement in this use case is to enable session 191 establishment from source network entity to target network entity. 193 This translates to a need for the target network entity (for the BFD 194 session), should start processing for the discriminator received in 195 the BFD packet. This will enable the source network entity to 196 establish a unidirectional BFD session without the bidirectional 197 handshake of discriminators for session establishment. 199 3.2. Validation of forwarding path prior to traffic switching 201 BFD provides data delivery confidence when reachability validation is 202 performed prior to traffic utilizing specific paths/LSPs. However 203 this comes with a cost, where, traffic is prevented to use such 204 paths/LSPs until BFD is able to validate the reachability, which 205 could take seconds due to BFD session bring-up sequences [RFC5880], 206 LSP ping bootstrapping [RFC5884], etc. This use case does not 207 require to have sequences for session negotiation and discriminator 208 exchanges in order to establish the BFD session. 210 When these sequences for handshake are eliminated, the network 211 entities need to know what the discriminator values to be used for 212 the session. The same is the case for S-BFD, i.e., when the three- 213 way handshake mechanism is eliminated during bootstrap of BFD 214 sessions. However, this information is required at each entity to 215 verify that BFD messages are being received from the expected end- 216 points, hence the handshake mechanism serves no purpose. Elimination 217 of the unnecessary handshake mechanism allows for faster reachability 218 validation of BFD provisioned paths/LSPs. 220 In addition, it is expected that some MPLS technologies will require 221 traffic engineered LSPs to be created dynamically, perhaps driven by 222 external applications, e.g. in Software Defined Networks (SDN). It 223 will be desirable to perform BFD validation very quickly to allow 224 applications to utilize dynamically created LSPs in a timely manner. 226 3.3. Centralized Traffic Engineering 228 Various technologies in the SDN domain that involve controller based 229 networks have evolved where intelligence, traditionally placed in a 230 distributed and dynamic control plane, is separated from the data 231 plane and resides in a logically centralized place. There are 232 various controllers that perform this exact function in establishing 233 forwarding paths for the data flow. Traffic engineering is one 234 important function, where the traffic flow is engineered depending 235 upon various attributes of the traffic as well as the network state. 237 When the intelligence of the network resides in a centralized entity, 238 ability to manage and maintain the dynamic network becomes a 239 challenge. One way to ensure the forwarding paths are valid, and 240 working, is to establish BFD sessions within the network. When 241 traffic engineered tunnels are created, it is operationally critical 242 to ensure that the forwarding paths are working prior to switching 243 the traffic onto the engineered tunnels. In the absence of control 244 plane protocols, it may be desirable to verify the forwarding path 245 but also of any arbitrary path in the network. With tunnels being 246 engineered by a centralized entity, when the network state changes, 247 traffic has to be switched with minimum latency and black holing of 248 the data. 250 Traditional BFD session establishment and validation of the 251 forwarding path must not become a bottleneck in the case of 252 centralized traffic engineering. If the controller or other 253 centralized entity is able to instantly verify a forwarding path of 254 the TE tunnel , it could steer the traffic onto the traffic 255 engineered tunnel very quickly thus minimizing adverse effect on a 256 service. This is especially useful and needed when the scale of the 257 network and number of TE tunnels is very high. 259 The cost associated with BFD session negotiation and establishment of 260 BFD sessions to identify valid paths is very high and providing 261 network redundancy becomes a critical issue. 263 3.4. BFD in Centralized Segment Routing 265 A centralized controller based Segment Routing network monitoring 266 technique is described in [I-D.geib-spring-oam-usecase]. In 267 validating this use case, one of the requirements is to ensure the 268 BFD packet's behavior is according to the requirement and monitoring 269 of the segment, where the packet is U-turned at the expected node. 270 One of the criterion is to ensure the continuity check to the 271 adjacent segment-id. 273 3.5. BFD Efficient Operation Under Resource Constraints 275 When BFD sessions are being setup, torn down or modified (i.e. 276 parameters ? such as interval, multiplier, etc are being modified), 277 BFD requires additional packets other than scheduled packet 278 transmissions to complete the negotiation procedures (i.e. P/F 279 bits). There are scenarios where network resources are constrained: 280 a node may require BFD to monitor very large number of paths, or BFD 281 may need to operate in low powered and traffic sensitive networks, 282 i.e. microwave, low powered nano-cells, etc. In these scenarios, it 283 is desirable for BFD to slow down, speed up, stop or resume at will 284 witho minimal additional BFD packets exchanged to establish a new or 285 modified session. 287 3.6. BFD for Anycast Address 289 BFD protocol requires two endpoints to host BFD sessions, both 290 sending packets to each other. This BFD model does not fit well with 291 anycast address monitoring, as BFD packets transmitted from a network 292 node to an anycast address will reach only one of potentially many 293 network nodes hosting the anycast address. 295 3.7. BFD Fault Isolation 297 BFD multi-hop and BFD MPLS traverse multiple network nodes. BFD has 298 been designed to declare failure upon lack of consecutive packet 299 reception, which can be caused by a fault anywhere along the path. 300 Fast failure detection allows for rapid path recovery procedures. 301 However, operators often have to follow up, manually or 302 automatically, to attempt to identify and localize the fault that 303 caused BFD sessions to fail. Usage of other tools to isolate the 304 fault may cause the packets to traverse a different path through the 305 network (e.g. if ECMP is used). In addition, the longer it takes 306 from BFD session failure to fault isolation attempt, more likely that 307 the fault cannot be isolated, e.g. a fault can get corrected or 308 routed around. If BFD had built-in fault isolation capability, fault 309 isolation can get triggered at the earliest sign of fault and such 310 packets will get load balanced in very similar way, if not the same, 311 as BFD packets that went missing. 313 3.8. Multiple BFD Sessions to Same Target 315 BFD is capable of providing very fast failure detection, as relevant 316 network nodes continuously transmitting BFD packets at negotiated 317 rate. If BFD packet transmission is interrupted, even for a very 318 short period of time, that can result in BFD to declare failure 319 irrespective of path liveliness. It is possible, on a system where 320 BFD is running, for certain events, intentionally or unintentionally, 321 to cause a short interruption of BFD packet transmissions. With 322 distributed architectures of BFD implementations, this can be 323 protected, if a node was to run multiple BFD sessions to targets, 324 hosted on different parts of the system (ex: different CPU 325 instances). This can reduce BFD false failures, resulting in more 326 stable network. 328 3.9. MPLS BFD Session Per ECMP Path 330 BFD for MPLS, defined in [RFC5884], describes procedures to run BFD 331 as LSP in-band continuity check mechanism, through usage of MPLS echo 332 request [RFC4379] to bootstrap the BFD session on the egress node. 333 Section 4 of [RFC5884] also describes a possibility of running 334 multiple BFD sessions per alternative paths of LSP. However, details 335 on how to bootstrap and maintain correct set of BFD sessions on the 336 egress node is absent. 338 When an LSP has ECMP segment, it may be desirable to run in-band 339 monitoring that exercises every path of ECMP. Otherwise there will 340 be scenarios where in-band BFD session remains up through one path 341 but traffic is black-holing over another path. One way to achieve 342 BFD session per ECMP path of LSP is to define procedures that update 343 [RFC5884] in terms of how to bootstrap and maintain correct set of 344 BFD sessions on the egress node. However, that may require constant 345 use of MPLS Echo Request messages to create and delete BFD sessions 346 on the egress node, when ECMP paths and/or corresponding load balance 347 hash keys change. If a BFD session over any paths of the LSP can be 348 instantiated, stopped and resumed without requiring additional 349 procedures of bootstrapping via MPLS echo request, it would simplify 350 implementations and operations, and benefits network devices as less 351 processing are required by them. 353 4. Security Considerations 355 There are no new security considerations associated with this draft. 357 5. IANA Considerations 359 There are no IANA considerations introduced by this draft 361 6. Contributors 363 Carlos Pignataro 365 Cisco Systems 367 Email: cpignata@cisco.com 369 Glenn Hayden 371 ATT 373 Email: gh1691@att.com 375 Santosh P K 377 Juniper 379 Email: santoshpk@juniper.net 381 Mach Chen 382 Huawei 384 Email: mach.chen@huawei.com 386 Nobo Akiya 388 Cisco Systems 390 Email: nobo@cisco.com 392 7. Acknowledgements 394 The authors would like to thank Eric Gray for his useful comments. 396 8. References 398 8.1. Normative References 400 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 401 Label Switched (MPLS) Data Plane Failures", RFC 4379, 402 DOI 10.17487/RFC4379, February 2006, 403 . 405 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 406 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 407 . 409 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 410 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 411 DOI 10.17487/RFC5881, June 2010, 412 . 414 [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 415 (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, 416 June 2010, . 418 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 419 "Bidirectional Forwarding Detection (BFD) for MPLS Label 420 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 421 June 2010, . 423 [RFC5885] Nadeau, T., Ed. and C. Pignataro, Ed., "Bidirectional 424 Forwarding Detection (BFD) for the Pseudowire Virtual 425 Circuit Connectivity Verification (VCCV)", RFC 5885, 426 DOI 10.17487/RFC5885, June 2010, 427 . 429 8.2. Informative References 431 [I-D.geib-spring-oam-usecase] 432 Geib, R., Filsfils, C., Pignataro, C., and N. Kumar, "Use 433 case for a scalable and topology aware MPLS data plane 434 monitoring system", draft-geib-spring-oam-usecase-06 (work 435 in progress), July 2015. 437 Authors' Addresses 439 Sam Aldrin 440 Google, Inc 441 1600 Amphitheatre Parkway 442 Mountain View, CA 444 Email: aldrin.ietf@gmail.com 446 Manav Bhatia 447 Ionos Networks 449 Email: manav@ionosnetworks.com 451 Satoru Matsushima 452 Softbank 454 Email: satoru.matsushima@g.softbank.co.jp 456 Greg Mirsky 457 Ericsson 459 Email: gregory.mirsky@ericsson.com 461 Nagendra Kumar 462 Cisco 464 Email: naikumar@cisco.com