idnits 2.17.1 draft-aldrin-bfd-seamless-use-case-01.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 (March 28, 2014) is 3680 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '5880' on line 184 == Missing Reference: 'TBD' is mentioned on line 203, but not defined == Missing Reference: 'I-D.geib-spring-oam-usecase' is mentioned on line 288, but not defined == Missing Reference: 'RFC4379' is mentioned on line 353, but not defined ** Obsolete undefined reference: RFC 4379 (Obsoleted by RFC 8029) == Unused Reference: 'KEYWORDS' is defined on line 386, but no explicit reference was found in the text == Unused Reference: 'EVILBIT' is defined on line 404, but no explicit reference was found in the text == Unused Reference: 'RFC5513' is defined on line 407, but no explicit reference was found in the text == Unused Reference: 'RFC5514' is defined on line 410, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Sam Aldrin 3 Intended Status: Informational (Huawei) 4 Expires: September 29, 2014 Manav Bhatia 5 (Alcatel-Lucent) 6 Greg Mirsky 7 (Ericsson) 8 Nagendra Kumar 9 (Cisco) 10 Satoru Matsushima 11 (Softbank) 13 March 28, 2014 15 Seamless Bidirectional Forwarding Detection (BFD) Use Case 16 draft-aldrin-bfd-seamless-use-case-01 18 Abstract 20 This document provides various use cases for Bidirectional Forwarding 21 Detection (BFD) such that simplified solution and extensions could be 22 developed for detecting forwarding failures. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that 31 other groups may also distribute working documents as 32 Internet-Drafts. 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 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/1id-abstracts.html 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html 45 Copyright and License Notice 46 Copyright (c) 2014 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.2 Contributors . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Introduction to Seamless BFD . . . . . . . . . . . . . . . . . 4 65 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.1. Unidirectional Forwarding Path Validation . . . . . . . . . 5 67 3.2. Validation of forwarding path prior to traffic switching . 6 68 3.3. Centralized Traffic Engineering . . . . . . . . . . . . . . 6 69 3.4. BFD in Centralized Segment Routing . . . . . . . . . . . . 7 70 3.5. BFD to Efficiently Operate under Resource Constraints . . . 7 71 3.6. BFD for Anycast Address . . . . . . . . . . . . . . . . . . 7 72 3.7. BFD Fault Isolation . . . . . . . . . . . . . . . . . . . . 7 73 3.8. Multiple BFD Sessions to Same Target . . . . . . . . . . . 8 74 3.9. MPLS BFD Session Per ECMP Path . . . . . . . . . . . . . . 8 75 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 10 76 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 77 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 6.1 Normative References . . . . . . . . . . . . . . . . . . . 10 79 6.2 Informative References . . . . . . . . . . . . . . . . . . 10 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 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 and lightweight, there are certain use 88 cases, where a much faster setting up of sessions and continuity 89 check of the data forwarding paths is necessary. This document 90 identifies those use cases such that necessary enhancements could be 91 made to BFD protocol to meet those requirements. 93 There are various ways to detecting faults and BFD protocol was 94 designed to be a lightweight "Hello" protocol to detect data plane 95 failures. With dynamic provisioning of forwarding paths at a large 96 scale, establishing BFD sessions for each of those paths creates 97 complexity, not only from operations point of view, but also the 98 speed at which these sessions could be established or deleted. The 99 existing session establishment mechanism of the BFD protocol need to 100 be enhanced in order to minimize the time for the session to come up 101 and validate the forwarding path. 103 This document specifically identifies those cases where certain 104 requirements could be derived to be used as reference, so that, 105 protocol enhancements could be developed to address them. Whilst the 106 use cases could be used as reference for certain requirements, it is 107 outside the scope of this document to identify all of the 108 requirements for all possible enhancements. Specific solutions and 109 enhancement proposals are outside the scope of this document as well. 111 1.1 Terminology 113 The reader is expected to be familiar with the BFD, IP, MPLS and SR 114 terminology and protocol constructs. This section identifies only 115 the new terminology introduced. 117 1.2 Contributors 119 Carlos Pignataro 120 Cisco Systems 122 Email: cpignata@cisco.com 124 Glenn Hayden 125 ATT 127 Email: gh1691@att.com 129 Santosh P K 130 Juniper 132 Email: santoshpk@juniper.net 134 Mach Chen 135 Huawei 137 Email: mach.chen@huawei.com 139 Nobo Akiya 140 Cisco Systems 142 Email: nobo@cisco.com 144 2. Introduction to Seamless BFD 146 BFD as defined in standard [RFC5880] requires two network nodes, as 147 part of handshake, exchange discriminators. This will enable the 148 sender and receiver of BFD packets of a session to be identified and 149 check the continuity of the forwarding path. [RFC5881] defines single 150 hop BFD whereas [RFC5883] and [RFC5884] defines multi-hop BFD. 152 In order to establish BFD sessions between network entities and 153 seamlessly be able to have the session up and running, BFD protocol 154 should be capable of doing that. These sessions have to be 155 established a priori to traffic flow and ensure the forwarding path 156 is available and connectivity is present. With handshake mechanism 157 within BFD protocol, establishing sessions at a rapid rate and 158 ensuring the validity or existence of working forwarding path, prior 159 to the session being up and running, becomes complex and time 160 consuming. In order to achieve seamless BFD sessions, it requires a 161 mechanism where the ability to specify the discriminators and the 162 ability to respond to the BFD control packets by the network node, 163 should already be negotiated ahead of the session becoming active. 164 Seamless BFD by definition will be able to provide those mechanisms 165 within the BFD protocol in order to meet the requirements and 166 establish BFD sessions seamlessly, with minimal overhead, in order to 167 detect forwarding failures. 169 As an example of how Seamless BFD (S-BFD) works, a set of network 170 entities are first identified, to which BFD sessions have to be 171 established. Each of those network nodes, will be assigned a special 172 BFD discriminator, to establish a BFD session. These network nodes 173 will also create a BFD session instance that listens for incoming BFD 174 control packets. Mappings between selected network entities and 175 corresponding special BFD discriminators are known to other network 176 nodes belonging in the same network. A network node in such network 177 is then able to send a BFD control packet to a particular target with 178 corresponding special BFD discriminator. Target network node, upon 179 reception of such BFD control packet, will transmit a response BFD 180 control packet back to the sender. 182 3. Use Cases 184 As per the BFD protocol RFC[5880], BFD sessions are established using 185 handshake mechanism prior to validating the forwarding path. This 186 section outlines some of the use cases where the existing mechanism 187 may not be able to satisfy the requirements. In addition, some of the 188 use cases will also be identifying the need for expedited BFD session 189 establishment with preserving benefits of forwarding failure 190 detection using existing BFD specifications. 192 3.1. Unidirectional Forwarding Path Validation 194 Even though bidirectional verification of forwarding path is useful, 195 there are scenarios when only one side of the BFD, not both, is 196 interested in verifying continuity of the data plane between a pair 197 of nodes. One such case is, when a static route uses BFD to validate 198 reachability to the next-hop IP router. In this case, the static 199 route is established from one network entity to another. The 200 requirement in this case is only to validate the forwarding path for 201 that statically established path. Validating the reverse direction is 202 not required in this case. Many of these network scenarios are being 203 proposed as part of segment routing [TBD]. Another example is when a 204 unidirectional tunnel uses BFD to validate reachability to the egress 205 node. 207 If the traditional BFD is to be used, the target network entity has 208 to be provisioned as well, even though the reverse path validation 209 with BFD session is not required. But with unidirectional BFD, the 210 need to provision on the target network entity is not needed. Once 211 the mechanism within the BFD protocol is in place, where the source 212 network entity knows the target network entity's discriminator, it 213 starts the session right away. When the targeted network entity 214 receives the packet, it knows that BFD packet, based on the 215 discriminator and processes it. That do not require to have a bi- 216 directional session establishment, hence the two way handshake to 217 exchange discriminators is not needed as well. 219 The primary requirement in this use case is to enable session 220 establishment from source network entity to target network entity. 221 This translates to, the target network entity for the BFD session, 222 upon receiving the BFD packet, should start processing for the 223 discriminator received. This will enable the source network entity to 224 establish a unidirectional BFD session without bidirectional 225 handshake of discriminators for session establishment. 227 3.2. Validation of forwarding path prior to traffic switching 229 BFD provides data delivery confidence when reachability validation is 230 performed prior to traffic utilizing specific paths/LSPs. However 231 this comes with a cost, where, traffic is prevented to use such 232 paths/LSPs until BFD is able to validate the reachability, which 233 could take seconds due to BFD session bring-up sequences [RFC5880], 234 LSP ping bootstrapping [RFC5884], etc. This use case does not 235 require to have sequences for session negotiation and discriminator 236 exchanges in order to establish the BFD session. 238 When these sequences for handshake are eliminated, the network 239 entities need to know what the discriminator values to be used for 240 the session. The same is the case for S-BFD, i.e., when the three-way 241 handshake mechanism is eliminated during bootstrap of BFD sessions. 242 Due to this faster reachability validation of BFD provisioned 243 paths/LSPs could be achieved. In addition, it is expected that some 244 MPLS technologies will require traffic engineered LSPs to get created 245 dynamically, driven by external applications, e.g. in Software 246 Defined Networks (SDN). It would be desirable to perform BFD 247 validation very quickly to allow applications to utilize dynamically 248 created LSPs in timely manner. 250 3.3. Centralized Traffic Engineering 252 Various technologies in the SDN domain have evolved which involves 253 controller based networks, where the intelligence, traditionally 254 placed in the distributed and dynamic control plane, is separated 255 from the data plane and resides in a logically centralized place. 256 There are various controllers which perform this exact function in 257 establishing forwarding paths for the data flow. Traffic engineering 258 is one important function, where the traffic is engineered depending 259 upon various attributes of the traffic as well as the network state. 261 When the intelligence of the network resides in the centralized 262 entity, ability to manage and maintain the dynamic network becomes a 263 challenge. One way to ensure the forwarding paths are valid and 264 working is to establish BFD sessions within the network. When traffic 265 engineering tunnels are created, it is operationally critical to 266 ensure that the forwarding paths are working prior to switching the 267 traffic onto the engineered tunnels. In the absence of control plane 268 protocols, it is not only the desire to verify the forwarding path 269 but also an arbitrary path in the network. With tunnels being 270 engineered from the centralized entity, when the network state 271 changes, traffic has to be switched without much latency and black 272 holing of the data. 274 Traditional BFD session establishment and validation of the 275 forwarding path must not become bottleneck in the case of centralized 276 traffic engineering. If the controller or other centralized entity is 277 able to instantly verify a forwarding path of the TE tunnel , it 278 could steer the traffic onto the traffic engineered tunnel very 279 quickly thus minimizing adverse effect on a service. This is 280 especially useful and needed when the scale of the network and number 281 of TE tunnels is too high. Session negotiation and establishment of 282 BFD sessions to identify valid paths is way to high in terms of time 283 and providing network redundancy becomes a critical issue. 285 3.4. BFD in Centralized Segment Routing 287 Centralized controller based Segment Routing network monitoring 288 technique, is described in [I-D.geib-spring-oam-usecase]. In 289 validating this use case, one of the requirements is to ensure the 290 BFD packet's behavior is according to the requirement and monitoring 291 of the segment, where the packet is U-turned at the expected node. 292 One of the criterion is to ensure the continuity check to the 293 adjacent segment-id. 295 3.5. BFD to Efficiently Operate under Resource Constraints 297 When BFD sessions are being setup, torn down or parameters (i.e. 298 interval, multiplier, etc) are being modified, BFD protocol requires 299 additional packets outside of scheduled packet transmissions to 300 complete the negotiation procedures (i.e. P/F bits). There are 301 scenarios where network resources are constrained: a node may require 302 BFD to monitor very large number of paths, or BFD may need to operate 303 in low powered and traffic sensitive networks, i.e. microwave, low 304 powered nano-cells, etc. In these scenarios, it is desirable for BFD 305 to slow down, speed up, stop or resume at will without requiring 306 additional BFD packets to be exchanged. 308 3.6. BFD for Anycast Address 310 BFD protocol requires the two endpoints to host BFD sessions, both 311 sending packets to each other. This BFD model does not fit well with 312 anycast address monitoring, as BFD packets transmitted from a network 313 node to an anycast address will reach only one of potentially many 314 network nodes hosting the anycast address. 316 3.7. BFD Fault Isolation 318 BFD multi-hop and BFD MPLS traverse multiple network nodes. BFD has 319 been designed to declare failure upon lack of consecutive packet 320 reception, which can be caused by any fault anywhere along the path. 321 Fast failure detection provides great benefits, as it can trigger 322 recovery procedures rapidly. However, operators often have to follow 323 up, manually or automatically, to attempt to identify and localize 324 the fault which caused the BFD sessions to fail. Usage of other tools 325 to isolate the fault may cause the packets to traverse differently 326 throughout the network (i.e. ECMP). In addition, longer it takes from 327 BFD session failure to fault isolation attempt, more likely that 328 fault cannot be isolated, i.e. fault can get corrected or routed 329 around. If BFD had built-in fault isolation capability, fault 330 isolation can get triggered at the earliest sign of fault and such 331 packets will get load balanced in very similar way, if not the same, 332 as BFD packets which went missing. 334 3.8. Multiple BFD Sessions to Same Target 336 BFD is capable of providing very fast failure detection, as relevant 337 network nodes continuously transmitting BFD packets at negotiated 338 rate. If BFD packet transmission is interrupted, even for a very 339 short period of time, that can result in BFD to declare failure 340 irrespective of path liveliness. It is possible, on a system where 341 BFD is running, for certain events, intentionally or unintentionally, 342 to cause a short interruption of BFD packet transmissions. With 343 distributed architectures of BFD implementations, this can be 344 protected, if a node was to run multiple BFD sessions to targets, 345 hosted on different parts of the system (ex: different CPU 346 instances). This can reduce BFD false failures, resulting in more 347 stable network. 349 3.9. MPLS BFD Session Per ECMP Path 351 BFD for MPLS, defined in [RFC5884], describes procedures to run BFD 352 as LSP in-band continuity check mechanism, through usage of MPLS echo 353 request [RFC4379] to bootstrap the BFD session on the egress node. 354 Section 4 of [RFC5884] also describes a possibility of running 355 multiple BFD sessions per alternative paths of LSP. However, details 356 on how to bootstrap and maintain correct set of BFD sessions on the 357 egress node is absent. 359 When an LSP has ECMP segment, it may be desirable to run in-band 360 monitoring that exercises every path of ECMP. Otherwise there will 361 be scenarios where in-band BFD session remains up through one path 362 but traffic is black-holing over another path. One way to achieve 363 BFD session per ECMP path of LSP is to define procedures that update 364 [RFC5884] in terms of how to bootstrap and maintain correct set of 365 BFD sessions on the egress node. However, that may require constant 366 use of MPLS Echo Request messages to create and delete BFD sessions 367 on the egress node, when ECMP paths and/or corresponding load balance 368 hash keys change. If a BFD session over any paths of the LSP can be 369 instantiated, stopped and resumed without requiring additional 370 procedures of bootstrapping via MPLS echo request, it would simplify 371 implementations and operations, and benefits network devices as less 372 processing are required by them. 374 4 Security Considerations 376 There are no new security considerations introduced by this draft. 378 5 IANA Considerations 380 There are no new IANA considerations introduced by this draft 382 6 References 384 6.1 Normative References 386 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 387 Requirement Levels", BCP 14, RFC 2119, March 1997. 389 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 390 (BFD)", RFC5880, June 2010. 392 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 393 (BFD)", RFC5881, June 2010. 395 [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 396 (BFD) for Multihop Paths", RFC5883, June 2010. 398 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 399 "Bidirectional Forwarding Detection (BFD) for MPLS Label 400 Switched Paths (LSPs)", RFC5884, June 2010. 402 6.2 Informative References 404 [EVILBIT] Bellovin, S., "The Security Flag in the IPv4 Header", 405 RFC 3514, April 1 2003. 407 [RFC5513] Farrel, A., "IANA Considerations for Three Letter 408 Acronyms", RFC 5513, April 1 2009. 410 [RFC5514] Vyncke, E., "IPv6 over Social Networks", RFC 5514, April 1 411 2009. 413 Authors' Addresses 415 Sam Aldrin 416 Huawei Technologies 417 2330 Central Expressway 418 Santa Clara, CA 95051 419 EMail: aldrin.ietf@gmail.com 421 Manav Bhatia 422 Alcatel-Lucent 424 EMail: manav.bhatia@alcatel-lucent.com 426 Satoru Matsushima 427 Softbank 429 EMail: satoru.matsushima@g.softbank.co.jp 431 Greg Mirsky 432 Ericsson 434 EMail: gregory.mirsky@ericsson.com 436 Nagendra Kumar 437 Cisco 439 EMail: naikumar@cisco.com