idnits 2.17.00 (12 Aug 2021) /tmp/idnits51495/draft-ietf-spring-bfd-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 document date (26 April 2022) is 18 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Working Group G. Mirsky 3 Internet-Draft Ericsson 4 Intended status: Standards Track J. Tantsura 5 Expires: 28 October 2022 Microsoft 6 I. Varlashkin 7 Google 8 M. Chen 9 Huawei 10 J. Wenying 11 CMCC 12 26 April 2022 14 Bidirectional Forwarding Detection (BFD) in Segment Routing Networks 15 Using MPLS Dataplane 16 draft-ietf-spring-bfd-04 18 Abstract 20 Segment Routing (SR) architecture leverages the paradigm of source 21 routing. It can be realized in the Multiprotocol Label Switching 22 (MPLS) network without any change to the data plane. A segment is 23 encoded as an MPLS label, and an ordered list of segments is encoded 24 as a stack of labels. Bidirectional Forwarding Detection (BFD) is 25 expected to monitor any existing path between systems. This document 26 defines how to use Label Switched Path Ping to bootstrap a BFD 27 session, control an SR Policy in the reverse direction of the SR-MPLS 28 tunnel, and applicability of BFD Demand mode in the SR-MPLS domain. 29 Also, the document describes the use of BFD Echo with BFD Control 30 packet payload. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on 28 October 2022. 49 Copyright Notice 51 Copyright (c) 2022 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 56 license-info) in effect on the date of publication of this document. 57 Please review these documents carefully, as they describe your rights 58 and restrictions with respect to this document. Code Components 59 extracted from this document must include Revised BSD License text as 60 described in Section 4.e of the Trust Legal Provisions and are 61 provided without warranty as described in the Revised BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3 68 1.1.2. Requirements Language . . . . . . . . . . . . . . . . 4 69 2. Bootstrapping BFD Session over Segment Routed Tunnel with MPLS 70 Data Plane . . . . . . . . . . . . . . . . . . . . . . . 4 71 3. Use BFD Reverse Path TLV over Segment Routed MPLS Tunnel . . 5 72 4. Use Non-FEC Path TLV . . . . . . . . . . . . . . . . . . . . 5 73 5. BFD Reverse Path TLV over Segment Routed MPLS Tunnel with 74 Dynamic Control Plane . . . . . . . . . . . . . . . . . . 7 75 6. Applicability of BFD Demand Mode in SR-MPLS Domain . . . . . 7 76 7. Using BFD to Monitor Point-to-Multipoint SR Policy . . . . . 8 77 8. Use of Echo BFD in SR-MPLS . . . . . . . . . . . . . . . . . 8 78 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 79 9.1. Non-FEC Path TLV . . . . . . . . . . . . . . . . . . . . 9 80 9.2. Return Code . . . . . . . . . . . . . . . . . . . . . . . 10 81 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 10 82 11. Security Considerations . . . . . . . . . . . . . . . . . . . 11 83 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 84 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 85 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 86 14.1. Normative References . . . . . . . . . . . . . . . . . . 11 87 14.2. Informative References . . . . . . . . . . . . . . . . . 13 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 90 1. Introduction 92 [RFC5880], [RFC5881], and [RFC5883] defined the operation of 93 Bidirectional Forwarding Detection (BFD) protocol between the two 94 systems over IP networks. [RFC5884] and [RFC7726] set rules for 95 using BFD Asynchronous mode over point-to-point (p2p) Multiprotocol 96 Label Switching (MPLS) Label Switched Path (LSP). These latter 97 standards implicitly assume that the remote BFD system, which is at 98 the egress Label Edge Router (LER), will use the shortest path route 99 regardless of the path the BFD system at the ingress LER uses to send 100 BFD Control packets towards it. Throughout this document, references 101 to ingress LER and egress LER are used, respectively, as a shortened 102 version of the "BFD system at the ingress/egress LER". 104 This document defines the use of LSP Ping for Segment Routing 105 networks over MPLS data plane [RFC8287] to bootstrap and control path 106 of a BFD session from the egress to ingress LER using Segment Routing 107 tunnel with MPLS data plane (SR-MPLS). 109 1.1. Conventions 111 1.1.1. Terminology 113 BFD: Bidirectional Forwarding Detection 115 BSID: Binding Segment Identifier 117 FEC: Forwarding Equivalence Class 119 MPLS: Multiprotocol Label Switching 121 SR-MPLS Segment Routing with MPLS data plane 123 LSP: Label Switched Path 125 LER Label Edge Router 127 p2p Point-to-point 129 p2mp Point-to-multipoint 131 SID Segment Identifier 133 SR Segment Routing 135 1.1.2. Requirements Language 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 139 "OPTIONAL" in this document are to be interpreted as described in BCP 140 14 [RFC2119] [RFC8174] when, and only when, they appear in all 141 capitals, as shown here. 143 2. Bootstrapping BFD Session over Segment Routed Tunnel with MPLS Data 144 Plane 146 Use of an LSP Ping to bootstrap BFD over MPLS LSP is required, as 147 documented in [RFC5884], to establish an association between a fault 148 detection message, i.e., BFD Control message, and the Forwarding 149 Equivalency Class (FEC) of a single label stack LSP in case of 150 Penultimate Hop Popping or when the egress LER distributes the 151 Explicit NULL label to the penultimate hop router. The Explicit NULL 152 label is not advertised as a Segment Identifier (SID) by an SR node 153 but, as demonstrated in section 3.1 [RFC8660] if the operation at the 154 penultimate hop is NEXT; then the egress SR node will receive an IP 155 encapsulated packet. Thus the conclusion is that LSP Ping MUST be 156 used to bootstrap a BFD session in an SR-MPLS domain if there are no 157 other means to bootstrap the BFD session, e.g., using an extension to 158 a dynamic routing protocol as described in [RFC9026] and [RFC9186]. 160 As demonstrated in [RFC8287], the introduction of Segment Routing 161 network domains with an MPLS data plane requires three new sub-TLVs 162 that MAY be used with Target FEC TLV. Section 6.1 addresses the use 163 of the new sub-TLVs in Target FEC TLV in LSP ping and LSP traceroute. 164 For the case of LSP ping, the [RFC8287] states that: 166 The initiator, i.e., ingress LER, MUST include FEC(s) 167 corresponding to the destination segment. 169 The initiator MAY include FECs corresponding to some or all of 170 segments imposed in the label stack by the ingress LER to 171 communicate the segments traversed. 173 It has been noted in [RFC5884] that a BFD session monitors for 174 defects particular tuple. [RFC7726] clarified how to 175 establish and operate multiple BFD sessions for the same tuple. Because only the ingress LER is aware of the SR-based 177 explicit route, the egress LER can associate the LSP ping with BFD 178 Discriminator TLV with only one of the FECs it advertised for the 179 particular segment. Thus this document clarifies that: 181 When LSP Ping is used to bootstrapping a BFD session for SR-MPLS 182 tunnel the FEC corresponding to the segment to be associated with 183 the BFD session MUST be as the very last sub-TLV in the Target FEC 184 TLV. 186 If the target segment is an anycast prefix segment 187 ([I-D.ietf-spring-mpls-anycast-segments]) the corresponding Anycast 188 SID MUST be included in the Target TLV as the very last sub-TLV. 189 Also, for BFD Control packet the ingress SR node MUST use precisely 190 the same label stack encapsulation, especially Entropy Label 191 ([RFC6790]), as for the LSP ping with the BFD Discriminator TLV that 192 bootstrapped the BFD session. Other operational aspects of using BFD 193 to monitor the continuity of the path to the particular Anycast SID, 194 advertised by a group of SR-MPLS capable nodes, will be considered in 195 the future versions of the document. 197 Encapsulation of a BFD Control packet in Segment Routing network with 198 MPLS data plane MUST follow Section 7 [RFC5884] when the IP/UDP 199 header used and MUST follow Section 3.4 [RFC6428] without IP/UDP 200 header being used. 202 3. Use BFD Reverse Path TLV over Segment Routed MPLS Tunnel 204 For BFD over MPLS LSP case, per [RFC5884], egress LER MAY send BFD 205 Control packet to the ingress LER either over IP network or an MPLS 206 LSP. Similarly, for the case of BFD over p2p SR-MPLS tunnel, the 207 egress LER MAY route BFD Control packet over the IP network, as 208 described in [RFC5883], or transmit over a segment tunnel, as 209 described in Section 7 [RFC5884]. In some cases, there may be a need 210 to direct egress LER to use a specific path for the reverse direction 211 of the BFD session by using the BFD Reverse Path TLV and following 212 all procedures as defined in [I-D.ietf-mpls-bfd-directed]. 214 4. Use Non-FEC Path TLV 216 For the case of MPLS data plane, Segment Routing Architecture 217 [RFC8402] explains that "a segment is encoded as an MPLS label. An 218 ordered list of segments is encoded as a stack of labels." 220 This document defines a new optional Non-FEC Path TLV. The format of 221 the Non-FEC Path TLV is presented in Figure 1 222 0 1 2 3 223 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 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Non-FEC Path TLV Type | Length | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | | 228 ~ Non-FEC Path ~ 229 | | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 Figure 1: Non-FEC Path TLV Format 234 Non-FEC Path TLV Type is two octets in length and has a value of TBD1 235 (to be assigned by IANA as requested in Section 9.1). 237 Length field is two octets long and defines the length in octets of 238 the Non-FEC Path field. 240 Non-FEC Path field contains a sub-TLV. Any Non-FEC Path sub-TLV 241 (defined in this document or to be defined in the future) for Non-FEC 242 Path TLV type MAY be used in this field. None or one sub-TLV MAY be 243 included in the Non-FEC Path TLV. If no sub-TLV has been found in 244 the Non-FEC Path TLV, the egress LER MUST revert to using the reverse 245 path selected based on its local policy. If there is more than one 246 sub-TLV, then the Return Code in echo reply MUST be set to value TBD3 247 "Too Many TLVs Detected" (to be assigned by IANA as requested in 248 Table 4). 250 Non-FEC Path TLV MAY be used to specify the reverse path of the BFD 251 session identified in the BFD Discriminator TLV. If the Non-FEC Path 252 TLV is present in the echo request message the BFD Discriminator TLV 253 MUST be present as well. If the BFD Discriminator TLV is absent when 254 the Non-FEC Path TLV is included, then it MUST be treated as 255 malformed Echo Request, as described in [RFC8029]. 257 This document defines the Segment Routing MPLS Tunnel sub-TLV that 258 MAY be used with the Non-FEC Path TLV. The format of the sub-TLV is 259 presented in Figure 2. 261 0 1 2 3 262 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 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | SR MPLS Tunnel sub-TLV Type | Length | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | SID Entry 1 (Top of Stack) | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | SID Entry 2 | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 ~ ~ 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | SID Entry N (Bottom of Stack) | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 Figure 2: Segment Routing MPLS Tunnel sub-TLV 277 The Segment Routing MPLS Tunnel sub-TLV Type is two octets in length, 278 and has a value of TBD2 (to be assigned by IANA as requested in 279 Section 9.1). 281 The egress LER MUST use the Value field as label stack for BFD 282 Control packets for the BFD session identified by the source IP 283 address of the MPLS LSP Ping packet and the value in the BFD 284 Discriminator TLV. Label Entries MUST be in network order. 286 5. BFD Reverse Path TLV over Segment Routed MPLS Tunnel with Dynamic 287 Control Plane 289 When Segment Routed domain with MPLS data plane uses distributed 290 tunnel computation BFD Reverse Path TLV MAY use Target FEC sub-TLVs 291 defined in [RFC8287]. 293 6. Applicability of BFD Demand Mode in SR-MPLS Domain 295 Sections 6.6 and 6.18.4 of [RFC5880] define how Demand mode of BFD 296 can be used to monitor uni-directional MPLS LSP. Similar procedures 297 can be following in SR-MPLS to monitor uni-directional SR tunnels: 299 * an ingress SR node bootstraps BFD session over SR-MPLS in Async 300 BFD mode; 302 * once BFD session is Up, the ingress SR node switches the egress 303 LER into the Demand mode by setting D field in BFD Control packet 304 it transmits; 306 * if the egress LER detects the failure of the BFD session, it sends 307 its BFD Control packet to the ingress SR node over the IP network 308 with a Poll sequence; 310 * if the ingress SR node receives a BFD Control packet from the 311 remote node in a Demand mode with Poll sequence and Diag field 312 indicating the failure, the ingress SR node transmits BFD Control 313 packet with Final over IP and switches the BFD over SR-MPLS back 314 into Async mode, sending BFD Control packets one per second. 316 7. Using BFD to Monitor Point-to-Multipoint SR Policy 318 [I-D.ietf-spring-sr-replication-segment] defined variants of SR 319 Policy to deliver point-to-multipoint (p2mp) services. For the given 320 P2MP segment [RFC8562] can be used if, for example, leaves have an 321 alternative source of the multicast service flow to select. In such 322 a scenario, a leaf may switch to using the alternative flow after 323 p2mp BFD detects the failure in the working multicast path. For 324 scenarios where it is required for the root to monitor the state of 325 the multicast tree [RFC8563] can be used. The root may use the 326 detection of the failure of the multicast tree to the particular leaf 327 to restore the path for that leaf or re-instantiate the whole 328 multicast tree. 330 An essential part of using p2mp BFD is the bootstrapping the BFD 331 session at all the leaves. The root, acting as the MultipointHead, 332 MAY use LSP Ping with the BFD Discriminator TLV. Alternatively, 333 extensions to routing protocols, e.g., BGP, or management plane, 334 e.g., PCEP, MAY be used to associate the particular P2MP segment with 335 MultipointHead's Discriminator. Extensions for routing protocols and 336 management plane are for further study. 338 8. Use of Echo BFD in SR-MPLS 340 Echo-BFD [RFC5880] can be used to monitor an SR Policy between the 341 local and the remote BFD peers. As defined in [RFC5880], the remote 342 BFD system does not process the payload of an Echo BFD. Thus it is 343 the local system that demultiplexes the Echo BFD packet matching it 344 to the appropriate BFD session and detects missing Echo BFD packets. 345 A BFD Control packet MAY be used as the payload of Echo BFD. This 346 specification defines the use of Echo BFD in SR-MPLS network with BFD 347 Control packet as the payload. The use of other types of Echo BFD 348 payload is outside the scope of this document. Because the remote 349 BFD system does not process Echo BFD, the value of the Your 350 Discriminator field MUST be set to the discriminator the local BFD 351 system assigned to the given BFD session. My Discriminator field 352 MUST be zeroed. Authentication MUST be set according to the 353 configuration of the BFD session. To ensure that the Echo BFD packet 354 is returned to the sender without being processed, the sender MAY use 355 a Binding SID (BSID) [RFC8402] that has been bound with the SR Policy 356 that ensures the return of a packet to that particular node. A BSID 357 MAY be associated with the SR Policy that is the reverse to the SR 358 Policy programmed onto the BFD Echo packet by the sender. 360 9. IANA Considerations 362 9.1. Non-FEC Path TLV 364 IANA is requested to assign new TLV type from the from Standards 365 Action range of the registry "Multiprotocol Label Switching 366 Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters - 367 TLVs" as defined in Table 1. 369 +=======+==================+===============+ 370 | Value | TLV Name | Reference | 371 +=======+==================+===============+ 372 | TBD1 | Non-FEC Path TLV | This document | 373 +-------+------------------+---------------+ 375 Table 1: New Non-FEC Path TLV 377 IANA is requested to create new Non-FEC Path sub-TLV registry for the 378 Non-FEC Path TLV, as described in Table 2. 380 +=============+===============+=====================================+ 381 | Range | Registration | Note | 382 | | Procedures | | 383 +=============+===============+=====================================+ 384 | 0-16383 | Standards | This range is for mandatory | 385 | | Action | TLVs or for optional TLVs | 386 | | | that require an error | 387 | | | message if not recognized. | 388 +-------------+---------------+-------------------------------------+ 389 | 16384-31743 | Specification | Experimental RFC needed | 390 | | Required | | 391 +-------------+---------------+-------------------------------------+ 392 | 32768-49161 | Standards | This range is for optional | 393 | | Action | TLVs that can be silently | 394 | | | dropped if not recognized. | 395 +-------------+---------------+-------------------------------------+ 396 | 49162-64511 | Specification | Experimental RFC needed | 397 | | Required | | 398 +-------------+---------------+-------------------------------------+ 399 | 64512-65535 | Private Use | | 400 +-------------+---------------+-------------------------------------+ 402 Table 2: Non-FEC Path sub-TLV registry 404 IANA is requested to allocate the following values from the Non-FEC 405 Path sub-TLV registry as defined in Table 3. 407 +=======+=====================================+===============+ 408 | Value | Description | Reference | 409 +=======+=====================================+===============+ 410 | 0 | Reserved | This document | 411 +-------+-------------------------------------+---------------+ 412 | TBD2 | Segment Routing MPLS Tunnel sub-TLV | This document | 413 +-------+-------------------------------------+---------------+ 414 | 65535 | Reserved | This document | 415 +-------+-------------------------------------+---------------+ 417 Table 3: New Segment Routing Tunnel sub-TLV 419 9.2. Return Code 421 IANA is requested to create Non-FEC Path sub-TLV sub-registry for the 422 new Non-FEC Path TLV and assign a new Return Code value from the 423 "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) 424 Ping Parameters" registry, "Return Codes" sub-registry, as follows 425 using a Standards Action value. 427 +========+=========================+===============+ 428 | Value | Description | Reference | 429 +========+=========================+===============+ 430 | X TBD3 | Too Many TLVs Detected. | This document | 431 +--------+-------------------------+---------------+ 433 Table 4: New Return Code 435 10. Implementation Status 437 - The organization responsible for the implementation: ZTE 438 Corporation. 440 - The implementation's name ROSng SW empowers traditional routers, 441 e.g., ZXCTN 6000. 443 - A brief general description: A list of SIDs can be specified as the 444 Return Path for an SR-MPLS tunnel. 446 - The implementation's level of maturity: production. 448 - Coverage: complete 450 - Version compatibility: draft-mirsky-spring-bfd-06. 452 - Licensing: proprietary. 454 - Implementation experience: Appreciate Early Allocation of values 455 for Non-FEC TLV and Segment Routing MPLS Tunnel sub-TLV (using 456 Private Use code points). 458 - Contact information: Qian Xin qian.xin2@zte.com.cn 460 - The date when information about this particular implementation was 461 last updated: 12/16/2019 463 Note to RFC Editor: This section MUST be removed before publication 464 of the document. 466 11. Security Considerations 468 Security considerations discussed in [RFC5880], [RFC5884], [RFC7726], 469 and [RFC8029] apply to this document. 471 12. Contributors 473 Xiao Min 474 ZTE Corp. 475 Email: xiao.min2@zte.com.cn 477 13. Acknowledgments 479 Authors greatly appreciate the help of Qian Xin, who provided the 480 information about the implementation of this specification. 482 14. References 484 14.1. Normative References 486 [I-D.ietf-mpls-bfd-directed] 487 Mirsky, G., Tantsura, J., Varlashkin, I., and M. Chen, 488 "Bidirectional Forwarding Detection (BFD) Directed Return 489 Path for MPLS Label Switched Paths (LSPs)", Work in 490 Progress, Internet-Draft, draft-ietf-mpls-bfd-directed-19, 491 14 February 2022, . 494 [I-D.ietf-spring-sr-replication-segment] 495 (editor), D. V., Filsfils, C., Parekh, R., Bidgoli, H., 496 and Z. Zhang, "SR Replication Segment for Multi-point 497 Service Delivery", Work in Progress, Internet-Draft, 498 draft-ietf-spring-sr-replication-segment-07, 7 March 2022, 499 . 502 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 503 Requirement Levels", BCP 14, RFC 2119, 504 DOI 10.17487/RFC2119, March 1997, 505 . 507 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 508 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 509 . 511 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 512 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 513 DOI 10.17487/RFC5881, June 2010, 514 . 516 [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 517 (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, 518 June 2010, . 520 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 521 "Bidirectional Forwarding Detection (BFD) for MPLS Label 522 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 523 June 2010, . 525 [RFC6428] Allan, D., Ed., Swallow, G., Ed., and J. Drake, Ed., 526 "Proactive Connectivity Verification, Continuity Check, 527 and Remote Defect Indication for the MPLS Transport 528 Profile", RFC 6428, DOI 10.17487/RFC6428, November 2011, 529 . 531 [RFC7726] Govindan, V., Rajaraman, K., Mirsky, G., Akiya, N., and S. 532 Aldrin, "Clarifying Procedures for Establishing BFD 533 Sessions for MPLS Label Switched Paths (LSPs)", RFC 7726, 534 DOI 10.17487/RFC7726, January 2016, 535 . 537 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 538 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 539 Switched (MPLS) Data-Plane Failures", RFC 8029, 540 DOI 10.17487/RFC8029, March 2017, 541 . 543 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 544 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 545 May 2017, . 547 [RFC8287] Kumar, N., Ed., Pignataro, C., Ed., Swallow, G., Akiya, 548 N., Kini, S., and M. Chen, "Label Switched Path (LSP) 549 Ping/Traceroute for Segment Routing (SR) IGP-Prefix and 550 IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data 551 Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017, 552 . 554 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 555 Decraene, B., Litkowski, S., and R. Shakir, "Segment 556 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 557 July 2018, . 559 [RFC8562] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, 560 Ed., "Bidirectional Forwarding Detection (BFD) for 561 Multipoint Networks", RFC 8562, DOI 10.17487/RFC8562, 562 April 2019, . 564 [RFC8563] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, 565 Ed., "Bidirectional Forwarding Detection (BFD) Multipoint 566 Active Tails", RFC 8563, DOI 10.17487/RFC8563, April 2019, 567 . 569 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 570 Decraene, B., Litkowski, S., and R. Shakir, "Segment 571 Routing with the MPLS Data Plane", RFC 8660, 572 DOI 10.17487/RFC8660, December 2019, 573 . 575 14.2. Informative References 577 [I-D.ietf-spring-mpls-anycast-segments] 578 Sarkar, P., Gredler, H., Filsfils, C., Previdi, S., 579 Decraene, B., and M. Horneffer, "Anycast Segments in MPLS 580 based Segment Routing", Work in Progress, Internet-Draft, 581 draft-ietf-spring-mpls-anycast-segments-03, 27 April 2020, 582 . 585 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 586 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 587 RFC 6790, DOI 10.17487/RFC6790, November 2012, 588 . 590 [RFC9026] Morin, T., Ed., Kebler, R., Ed., and G. Mirsky, Ed., 591 "Multicast VPN Fast Upstream Failover", RFC 9026, 592 DOI 10.17487/RFC9026, April 2021, 593 . 595 [RFC9186] Mirsky, G. and X. Ji, "Fast Failover in Protocol 596 Independent Multicast - Sparse Mode (PIM-SM) Using 597 Bidirectional Forwarding Detection (BFD) for Multipoint 598 Networks", RFC 9186, DOI 10.17487/RFC9186, January 2022, 599 . 601 Authors' Addresses 603 Greg Mirsky 604 Ericsson 605 Email: gregimirsky@gmail.com 607 Jeff Tantsura 608 Microsoft 609 Email: jefftant.ietf@gmail.com 611 Ilya Varlashkin 612 Google 613 Email: Ilya@nobulus.com 615 Mach(Guoyi) Chen 616 Huawei 617 Email: mach.chen@huawei.com 619 Jiang Wenying 620 CMCC 621 Email: jiangwenying@chinamobile.com