idnits 2.17.1 draft-ietf-mpls-bfd-directed-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: ---------------------------------------------------------------------------- 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 (September 14, 2016) is 2752 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-13) exists of draft-ietf-mpls-spring-lsp-ping-00 ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) ** Obsolete normative reference: RFC 6424 (Obsoleted by RFC 8029) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group G. Mirsky 3 Internet-Draft Ericsson 4 Intended status: Standards Track J. Tantsura 5 Expires: March 18, 2017 Individual 6 I. Varlashkin 7 Google 8 M. Chen 9 Huawei 10 September 14, 2016 12 Bidirectional Forwarding Detection (BFD) Directed Return Path 13 draft-ietf-mpls-bfd-directed-04 15 Abstract 17 Bidirectional Forwarding Detection (BFD) is expected to be able to 18 monitor wide variety of encapsulations of paths between systems. 19 When a BFD session monitors an explicitly routed unidirectional path 20 there may be a need to direct egress BFD peer to use specific path 21 for the reverse direction of the BFD session. 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 March 18, 2017. 40 Copyright Notice 42 Copyright (c) 2016 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. Conventions used in this document . . . . . . . . . . . . 3 59 1.1.1. Requirements Language . . . . . . . . . . . . . . . . 3 60 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Direct Reverse BFD Path . . . . . . . . . . . . . . . . . . . 3 62 3.1. Case of MPLS Data Plane . . . . . . . . . . . . . . . . . 3 63 3.1.1. BFD Reverse Path TLV . . . . . . . . . . . . . . . . 4 64 3.1.2. Static and RSVP-TE sub-TLVs . . . . . . . . . . . . . 5 65 3.1.3. Segment Routing: MPLS Data Plane Case . . . . . . . . 5 66 3.2. Bootstrapping BFD session with BFD Reverse Path over 67 Segment Routed tunnel . . . . . . . . . . . . . . . . . . 5 68 3.3. Return Codes . . . . . . . . . . . . . . . . . . . . . . 6 69 4. Use Case Scenario . . . . . . . . . . . . . . . . . . . . . . 6 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 71 5.1. TLV . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 5.2. Sub-TLV . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 5.3. Return Codes . . . . . . . . . . . . . . . . . . . . . . 8 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 75 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 78 8.2. Informative References . . . . . . . . . . . . . . . . . 10 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 81 1. Introduction 83 RFC 5880 [RFC5880], RFC 5881 [RFC5881], and RFC 5883 [RFC5883] 84 established the BFD protocol for IP networks and RFC 5884 [RFC5884] 85 set rules of using BFD asynchronous mode over IP/MPLS LSPs. These 86 standards implicitly assume that the egress BFD peer will use the 87 shortest path route regardless of route being used to send BFD 88 control packets towards it. 90 For the case where a LSP is explicitly routed it is likely that the 91 shortest return path to the ingress BFD peer would not follow the 92 same path as the LSP in the forward direction. The fact that BFD 93 control packets are not guaranteed to follow the same links and nodes 94 in both forward and reverse directions is a significant factor in 95 producing false positive defect notifications, i.e. false alarms, if 96 used by the ingress BFD peer to deduce the state of the forward 97 direction. 99 This document defines the BFD Reverse Path TLV as an extension to LSP 100 Ping [RFC4379] and proposes that it is to be used to instruct the 101 egress BFD peer to use explicit path for its BFD control packets 102 associated with a particular BFD session. The TLV will be allocated 103 from the TLV and sub-TLV registry defined by RFC 4379 [RFC4379]. As 104 a special case, forward and reverse directions of the BFD session can 105 form a bi-directional co-routed associated channel. 107 1.1. Conventions used in this document 109 1.1.1. Requirements Language 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 113 "OPTIONAL" in this document are to be interpreted as described in 114 [RFC2119]. 116 2. Problem Statement 118 When BFD is used to monitor unidirectional explicitly routed path, 119 e.g. MPLS-TE LSP, BFD control packets in forward direction would be 120 in-band using the mechanism defined in [RFC5884] and [RFC5586]. But 121 the reverse direction of the BFD session would follow the shortest 122 path route and that might lead to the problem in detecting failures 123 on a unidirectional explicit path as described below: 125 o a failure detection by ingress node on the reverse path cannot be 126 interpreted as bi-directional failure unambiguously and thus 127 trigger, for example, protection switchover of the forward 128 direction without possibility of being a false positive. 130 To address this scenario the egress BFD peer would be instructed to 131 use a specific path for BFD control packets. 133 3. Direct Reverse BFD Path 135 3.1. Case of MPLS Data Plane 137 LSP ping, defined in [RFC4379], uses BFD Discriminator TLV [RFC5884] 138 to bootstrap a BFD session over an MPLS LSP. This document defines a 139 new TLV, BFD Reverse Path TLV, that MUST contain a single sub-TLV 140 that can be used to carry information about the reverse path for the 141 BFD session that is specified by value in BFD Discriminator TLV. 143 3.1.1. BFD Reverse Path TLV 145 The BFD Reverse Path TLV is an optional TLV within the LSP ping 146 [RFC4379], [RFC6424]. However, if used, the BFD Discriminator TLV 147 MUST be included in an Echo Request message as well. If the BFD 148 Discriminator TLV is not present when the BFD Reverse Path TLV is 149 included, then it MUST be treated as malformed Echo Request, as 150 described in [RFC4379]. 152 The BFD Reverse Path TLV carries information about the path onto 153 which the egress BFD peer of the BFD session referenced by the BFD 154 Discriminator TLV MUST transmit BFD control packets. The format of 155 the BFD Reverse Path TLV is as presented in Figure 1. 157 0 1 2 3 158 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | BFD Reverse Path TLV Type | Length | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Reverse Path | 163 ~ ~ 164 | | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 Figure 1: BFD Reverse Path TLV 169 BFD Reverse Path TLV Type is 2 octets in length and has a value of 170 TBD1 (to be assigned by IANA as requested in Section 5). 172 Length field is 2 octets long and defines the length in octets of the 173 Reverse Path field. 175 Reverse Path field contains a sub-TLV. Any Target FEC sub-TLV 176 (already defined, or to be defined in the future) for TLV Types 1, 177 16, and 21 of MPLS LSP Ping Parameters registry MAY be used in this 178 field. Exactly one sub-TLV MUST be included in the Reverse Path TLV. 179 If more than one sub-TLV is present in the Reverse Path TLV, then, in 180 order to avoid ambiguity of which of TLVs to use, the egress BFD peer 181 MUST send Echo Reply with the received Reverse Path TLVs and set the 182 Return Code to "Too Many TLVs Detected" Section 3.3. 184 If the egress LSR cannot find the path specified in the Reverse Path 185 TLV it MUST send Echo Reply with the received Reverse Path TLV and 186 set the Return Code to "Failed to establish the BFD session. The 187 specified reverse path was not found" Section 3.3. The egress BFD 188 peer MAY establish the BFD session over IP network as defined in 189 [RFC5884]. 191 3.1.2. Static and RSVP-TE sub-TLVs 193 When an explicit path on an MPLS data plane is set either as Static 194 or RSVP-TE LSP respective sub-TLVs defined in [RFC7110] MAY be used 195 to identify the explicit reverse path for the BFD session. 197 3.1.3. Segment Routing: MPLS Data Plane Case 199 In addition to Static and RSVP-TE, Segment Routing with MPLS data 200 plane can be used to set an explicit path. In this case a new sub- 201 TLV is defined in this document as presented in Figure 2. 203 0 1 2 3 204 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | SegRouting MPLS sub-TLV Type | Length | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Label Entry 1 | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Label Entry 2 | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 ~ ~ 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Label Entry N | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 Figure 2: Segment Routing MPLS Tunnel sub-TLV 219 The Segment Routing Tunnel sub-TLV Type is two octets in length, and 220 has a value of TBD2 (to be assigned by IANA as requested in 221 Section 5). 223 The egress LSR MUST use the Value field as label stack for BFD 224 control packets for the BFD session identified by the source IP 225 address of the MPLS LSP Ping packet and the value in the BFD 226 Discriminator TLV. Label Entries MUST be in network order. 228 The Segment Routing Tunnel sub-TLV MAY be used in Reply Path TLV 229 defined in [RFC7110] 231 3.2. Bootstrapping BFD session with BFD Reverse Path over Segment 232 Routed tunnel 234 As discussed in [I-D.ietf-mpls-spring-lsp-ping] introduction of 235 Segment Routing network domains with an MPLS data plane adds three 236 new sub-TLVs that MAY be used with Target FEC TLV. Section 6.1 237 addresses use of the new sub-TLVs in Target FEC TLV in LSP ping and 238 LSP traceroute. For the case of LSP ping the 239 [I-D.ietf-mpls-spring-lsp-ping] states that: 241 "Initiator MUST include FEC(s) corresponding to the destination 242 segment. " 244 "Initiator, i.e. ingress LSR, MAY include FECs corresponding to some 245 or all of segments imposed in the label stack by the ingress LSR to 246 communicate the segments traversed. " 248 When LSP ping is used to bootstrap BFD session this document updates 249 the statement and defines that LSP Ping MUST include the FEC 250 corresponding to the destination segment and SHOULD NOT include FECs 251 corresponding to some or all of other segments imposed by the ingress 252 LSR. Operationally such restriction would not cause any problem or 253 uncertainty as LSP ping with FECs corresponding to some or all 254 segments or traceroute that validate the segment route MAY precede 255 the LSP ping that bootstraps the BFD session. 257 3.3. Return Codes 259 This document defines the following Return Codes for MPLS LSP Echo 260 Reply: 262 o "Too Many TLVs Detected", (TBD3). When more than one Reverse Path 263 TLV found in the received Echo Request by the egress BFD peer, an 264 Echo Reply with the return code set to "Too Many TLVs Detected" 265 MUST be sent to the ingress BFD peer Section 3.1.1. 267 o "Failed to establish the BFD session. The specified reverse path 268 was not found", (TBD4). When a specified reverse path is not 269 available at the egress BFD peer, an Echo Reply with the return 270 code set to "Failed to establish the BFD session. The specified 271 reverse path was not found" MUST be sent back to the ingress BFD 272 peer Section 3.1.1. 274 4. Use Case Scenario 276 In the network presented in Figure 3 node A monitors two tunnels to 277 node H: A-B-C-D-G-H and A-B-E-F-G-H. To bootstrap a BFD session to 278 monitor the first tunnel, node A MUST include a BFD Discriminator TLV 279 with Discriminator value (e.g. foobar-1) and MAY include a BFD 280 Reverse Path TLV that references H-G-D-C-B-A tunnel. To bootstrap a 281 BFD session to monitor the second tunnel, node A MUST include a BFD 282 Discriminator TLV with a different Discriminator value (e.g. foobar- 283 2) [RFC7726] and MAY include a BFD Reverse Path TLV that references 284 H-G-F-E-B-A tunnel. 286 C---------D 287 | | 288 A-------B G-----H 289 | | 290 E---------F 292 Figure 3: Use Case for BFD Reverse Path TLV 294 If an operator needs node H to monitor a path to node A, e.g. 295 H-G-D-C-B-A tunnel, then by looking up list of known Reverse Paths it 296 MAY find and use the existing BFD session. 298 5. IANA Considerations 300 5.1. TLV 302 The IANA is requested to assign a new value for BFD Reverse Path TLV 303 from the "Multiprotocol Label Switching Architecture (MPLS) Label 304 Switched Paths (LSPs) Ping Parameters - TLVs" registry, "TLVs and 305 sub-TLVs" sub-registry. 307 +----------+----------------------+---------------+ 308 | Value | Description | Reference | 309 +----------+----------------------+---------------+ 310 | X (TBD1) | BFD Reverse Path TLV | This document | 311 +----------+----------------------+---------------+ 313 Table 1: New BFD Reverse Type TLV 315 5.2. Sub-TLV 317 The IANA is requested to create new sub-registry for sub-TLV types of 318 TLV TBD. All code points in the ranges 0 through 16383 and 32768 319 through 49161 in this registry shall be allocated according to the 320 "IETF Review" procedure as specified in [RFC5226] . Code points in 321 the ranges 16384 through 31743 and 49162 through 64511 in this 322 registry shall be allocated according to the "First Come First 323 Served" procedure as specified in [RFC5226]. Values in the range 324 31744 through 32767 and 64512 through 65534 are for Vendor or Private 325 Use, and MUST NOT be allocated. This document defines the following 326 new values of new sub-TLV type: 328 +-------------+-------------------------------------+---------------+ 329 | Value | Description | Reference | 330 +-------------+-------------------------------------+---------------+ 331 | 0 | Reserved | This document | 332 | X (TBD2) | Segment Routing MPLS Tunnel sub-TLV | This document | 333 | 2-31743 | Unassigned | | 334 | 31744-32767 | Reserved for Vendor or Private Use | | 335 | 32768-64511 | Unassigned | | 336 | 64512-65534 | Reserved for Vendor or Private Use | | 337 | 65535 | Reserved | This document | 338 +-------------+-------------------------------------+---------------+ 340 Table 2: New Segment Routing Tunnel sub-TLV 342 5.3. Return Codes 344 The IANA is requested to assign a new Return Code value from the 345 "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) 346 Ping Parameters" registry, "Return Codes" sub-registry, as follows 347 using a Standards Action value. 349 +----------+----------------------------------------+---------------+ 350 | Value | Description | Reference | 351 +----------+----------------------------------------+---------------+ 352 | X (TBD3) | Too Many TLVs Detected. | This document | 353 | X (TBD4) | Failed to establish the BFD session. | This document | 354 | | The specified reverse path was not | | 355 | | found. | | 356 +----------+----------------------------------------+---------------+ 358 Table 3: New Return Code 360 6. Security Considerations 362 Security considerations discussed in [RFC5880], [RFC5884], and 363 [RFC4379], apply to this document. 365 7. Acknowledgements 367 Authors greatly appreciate thorough review and the most helpful 368 comments from Eric Gray and Carlos Pignataro. 370 8. References 371 8.1. Normative References 373 [I-D.ietf-mpls-spring-lsp-ping] 374 Kumar, N., Swallow, G., Pignataro, C., Akiya, N., Kini, 375 S., Gredler, H., and M. Chen, "Label Switched Path (LSP) 376 Ping/Trace for Segment Routing Networks Using MPLS 377 Dataplane", draft-ietf-mpls-spring-lsp-ping-00 (work in 378 progress), May 2016. 380 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 381 Requirement Levels", BCP 14, RFC 2119, 382 DOI 10.17487/RFC2119, March 1997, 383 . 385 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 386 Label Switched (MPLS) Data Plane Failures", RFC 4379, 387 DOI 10.17487/RFC4379, February 2006, 388 . 390 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 391 "MPLS Generic Associated Channel", RFC 5586, 392 DOI 10.17487/RFC5586, June 2009, 393 . 395 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 396 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 397 . 399 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 400 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 401 DOI 10.17487/RFC5881, June 2010, 402 . 404 [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 405 (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, 406 June 2010, . 408 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 409 "Bidirectional Forwarding Detection (BFD) for MPLS Label 410 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 411 June 2010, . 413 [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for 414 Performing Label Switched Path Ping (LSP Ping) over MPLS 415 Tunnels", RFC 6424, DOI 10.17487/RFC6424, November 2011, 416 . 418 [RFC7110] Chen, M., Cao, W., Ning, S., Jounay, F., and S. Delord, 419 "Return Path Specified Label Switched Path (LSP) Ping", 420 RFC 7110, DOI 10.17487/RFC7110, January 2014, 421 . 423 [RFC7726] Govindan, V., Rajaraman, K., Mirsky, G., Akiya, N., and S. 424 Aldrin, "Clarifying Procedures for Establishing BFD 425 Sessions for MPLS Label Switched Paths (LSPs)", RFC 7726, 426 DOI 10.17487/RFC7726, January 2016, 427 . 429 8.2. Informative References 431 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 432 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 433 DOI 10.17487/RFC5226, May 2008, 434 . 436 Authors' Addresses 438 Greg Mirsky 439 Ericsson 441 Email: gregimirsky@gmail.com 443 Jeff Tantsura 444 Individual 446 Email: jefftant.ietf@gmail.com 448 Ilya Varlashkin 449 Google 451 Email: Ilya@nobulus.com 453 Mach(Guoyi) Chen 454 Huawei 456 Email: mach.chen@huawei.com