idnits 2.17.1 draft-mirsky-spring-bfd-09.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 (December 19, 2019) is 1580 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 (-27) exists of draft-ietf-mpls-bfd-directed-12 ** Downref: Normative reference to an Experimental draft: draft-ietf-mpls-bfd-directed (ref. 'I-D.ietf-mpls-bfd-directed') == Outdated reference: A later version (-15) exists of draft-mirsky-bfd-mpls-demand-05 ** Downref: Normative reference to an Informational draft: draft-mirsky-bfd-mpls-demand (ref. 'I-D.mirsky-bfd-mpls-demand') == Outdated reference: A later version (-03) exists of draft-ietf-spring-mpls-anycast-segments-02 Summary: 2 errors (**), 0 flaws (~~), 4 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 ZTE Corp. 4 Intended status: Standards Track J. Tantsura 5 Expires: June 21, 2020 Apstra, Inc. 6 I. Varlashkin 7 Google 8 M. Chen 9 Huawei 10 December 19, 2019 12 Bidirectional Forwarding Detection (BFD) in Segment Routing Networks 13 Using MPLS Dataplane 14 draft-mirsky-spring-bfd-09 16 Abstract 18 Segment Routing (SR) architecture leverages the paradigm of source 19 routing. It can be realized in the Multiprotocol Label Switching 20 (MPLS) network without any change to the data plane. A segment is 21 encoded as an MPLS label, and an ordered list of segments is encoded 22 as a stack of labels. Bidirectional Forwarding Detection (BFD) is 23 expected to monitor any existing path between systems. This document 24 defines how to use Label Switched Path Ping to bootstrap a BFD 25 session, control path in reverse direction of the SR-MPLS tunnel and 26 applicability of BFD Demand mode in the SR-MPLS domain. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on June 21, 2020. 45 Copyright Notice 47 Copyright (c) 2019 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3 65 1.1.2. Requirements Language . . . . . . . . . . . . . . . . 3 66 2. Bootstrapping BFD Session over Segment Routed Tunnel with 67 MPLS Data Plane . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Use BFD Reverse Path TLV over Segment Routed MPLS Tunnel . . 5 69 4. Use Non-FEC Path TLV . . . . . . . . . . . . . . . . . . . . 5 70 5. BFD Reverse Path TLV over Segment Routed MPLS Tunnel with 71 Dynamic Control Plane . . . . . . . . . . . . . . . . . . . . 7 72 6. Applicability of BFD Demand Mode in SR-MPLS Domain . . . . . 7 73 7. Using BFD to Monitor Pont-to-Multipoint SR Policy . . . . . . 7 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 75 8.1. Non-FEC Path TLV . . . . . . . . . . . . . . . . . . . . 8 76 8.2. Return Code . . . . . . . . . . . . . . . . . . . . . . . 9 77 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 9 78 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 79 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 80 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 81 12.1. Normative References . . . . . . . . . . . . . . . . . . 10 82 12.2. Informative References . . . . . . . . . . . . . . . . . 12 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 85 1. Introduction 87 [RFC5880], [RFC5881], and [RFC5883] defined the operation of 88 Bidirectional Forwarding Detection (BFD) protocol between the two 89 systems over IP networks. [RFC5884] and [RFC7726] set rules for 90 using BFD Asynchronous mode over point-to-point (p2p) Multiprotocol 91 Label Switching (MPLS) Label Switched Path (LSP). These latter 92 standards implicitly assume that the remote BFD system, which is at 93 the egress Label Edge Router (LER), will use the shortest path route 94 regardless of the path the BFD system at the ingress LER uses to send 95 BFD Control packets towards it. Throughourt this document references 96 to ingress LER and egrees LER are used, respectively, as shortened 97 version of "BFD system at the ingress/egress LER". 99 This document defines the use of LSP Ping for Segment Routing 100 networks over MPLS data plane [RFC8287] to bootstrap and control path 101 of a BFD session from the egress to ingress LER using Segment Routing 102 tunnel with MPLS data plane (SR-MPLS). 104 1.1. Conventions 106 1.1.1. Terminology 108 BFD: Bidirectional Forwarding Detection 110 FEC: Forwarding Equivalence Class 112 MPLS: Multiprotocol Label Switching 114 SR-MPLS Segment Routing with MPLS data plane 116 LSP: Label Switched Path 118 LER Label Edge Router 120 p2p Point-to-point 122 p2mp Point-to-multipoint 124 SID Segment Identifier 126 SR Segment Routing 128 1.1.2. Requirements Language 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 132 "OPTIONAL" in this document are to be interpreted as described in BCP 133 14 [RFC2119] [RFC8174] when, and only when, they appear in all 134 capitals, as shown here. 136 2. Bootstrapping BFD Session over Segment Routed Tunnel with MPLS Data 137 Plane 139 Use of an LSP Ping to bootstrap BFD over MPLS LSP is required, as 140 documented in [RFC5884], to establish an association between a fault 141 detection message, i.e., BFD Control message, and the Forwarding 142 Equivalency Class (FEC) of a single label stack LSP in case of 143 Penultimate Hop Popping or when the egress LER distributes the 144 Explicit NULL label to the penultimate hop router. The Explicit NULL 145 label is not advertised as a Segment Identifier (SID) by an SR node 146 but, as demonstrated in section 3.1 [RFC8660] if the operation at the 147 penultimate hop is NEXT; then the egress SR node will receive an IP 148 encapsulated packet. Thus the conclusion is that LSP Ping MUST be 149 used to bootstrap a BFD session in SR-MPLS domain. 151 As demonstrated in [RFC8287], the introduction of Segment Routing 152 network domains with an MPLS data plane requires three new sub-TLVs 153 that MAY be used with Target FEC TLV. Section 6.1 addresses use of 154 the new sub-TLVs in Target FEC TLV in LSP ping and LSP traceroute. 155 For the case of LSP ping, the [RFC8287] states that: 157 The initiator, i.e., ingress LER, MUST include FEC(s) 158 corresponding to the destination segment. 160 The initiator MAY include FECs corresponding to some or all of 161 segments imposed in the label stack by the ingress LER to 162 communicate the segments traversed. 164 It has been noted in [RFC5884] that a BFD session monitors for 165 defects particular tuple. [RFC7726] clarified how to 166 establish and operate multiple BFD sessions for the same tuple. Because only the ingress LER is aware of the SR-based 168 explicit route, the egress LER can associate the LSP ping with BFD 169 Discriminator TLV with only one of the FECs it advertised for the 170 particular segment. Thus this document clarifies that: 172 When LSP Ping is used to bootstrapping a BFD session for SR-MPLS 173 tunnel the FEC corresponding to the segment to be associated with 174 the BFD session MUST be as the very last sub-TLV in the Target FEC 175 TLV. 177 If the target segment is an anycast prefix segment 178 ([I-D.ietf-spring-mpls-anycast-segments]) the corresponding Anycast 179 SID MUST be included in the Target TLV as the very last sub-TLV. 180 Also, for BFD Control packet the ingress SR node MUST use precisely 181 the same label stack encapsulation, especially Entropy Label 182 ([RFC6790]), as for the LSP ping with the BFD Discriminator TLV that 183 bootstrapped the BFD session. Other operational aspects of using BFD 184 to monitor the continuity of the path to the particular Anycast SID, 185 advertised by a group of SR-MPLS capable nodes, will be considered in 186 the future versions of the document. 188 Encapsulation of a BFD Control packet in Segment Routing network with 189 MPLS data plane MUST follow Section 7 [RFC5884] when the IP/UDP 190 header used and MUST follow Section 3.4 [RFC6428] without IP/UDP 191 header being used. 193 3. Use BFD Reverse Path TLV over Segment Routed MPLS Tunnel 195 For BFD over MPLS LSP case, per [RFC5884], egress LER MAY send BFD 196 Control packet to the ingress LER either over IP network or an MPLS 197 LSP. Similarly, for the case of BFD over p2p SR-MPLS tunnel, the 198 egress LER MAY route BFD Control packet over the IP network, as 199 described in [RFC5883], or transmit over a segment tunnel, as 200 described in Section 7 [RFC5884]. In some cases, there may be a need 201 to direct egress LER to use a specific path for the reverse direction 202 of the BFD session by using the BFD Reverse Path TLV and following 203 all procedures as defined in [I-D.ietf-mpls-bfd-directed]. 205 4. Use Non-FEC Path TLV 207 For the case of MPLS data plane, Segment Routing Architecture 208 [RFC8402] explains that "a segment is encoded as an MPLS label. An 209 ordered list of segments is encoded as a stack of labels." 211 This document defines new optional Non-FEC Path TLV. The format of 212 the Non-FEC Path TLV is presented in Figure 1 214 0 1 2 3 215 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 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Non-FEC Path TLV Type | Length | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | | 220 ~ Non-FEC Path ~ 221 | | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 Figure 1: Non-FEC Path TLV Format 226 Non-FEC Path TLV Type is two octets in length and has a value of TBD1 227 (to be assigned by IANA as requested in Section 8.1). 229 Length field is two octets long and defines the length in octets of 230 the Non-FEC Path field. 232 Non-FEC Path field contains a sub-TLV. Any Non-FEC Path sub-TLV 233 (defined in this document or to be defined in the future) for Non-FEC 234 Path TLV type MAY be used in this field. None or one sub-TLV MAY be 235 included in the Non-FEC Path TLV. If no sub-TLV has been found in 236 the Non-FEC Path TLV, the egress LER MUST revert to using the reverse 237 path selected based on its local policy. If there is more than one 238 sub-TLV, then the Return Code in echo reply MUST be set to value TBD3 239 "Too Many TLVs Detected" (to be assigned by IANA as requested in 240 Table 4). 242 Non-FEC Path TLV MAY be used to specify the reverse path of the BFD 243 session identified in the BFD Discriminator TLV. If the Non-FEC Path 244 TLV is present in the echo request message the BFD Discriminator TLV 245 MUST be present as well. If the BFD Discriminator TLV is absent when 246 the Non-FEC Path TLV is included, then it MUST be treated as 247 malformed Echo Request, as described in [RFC8029]. 249 This document defines Segment Routing MPLS Tunnel sub-TLV that MAY be 250 used with the Non-FEC Path TLV. The format of the sub-TLV is 251 presented in Figure 2. 253 0 1 2 3 254 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 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | SR MPLS Tunnel sub-TLV Type | Length | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | SID Entry 1 (Top of Stack) | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | SID Entry 2 | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 ~ ~ 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | SID Entry N (Bottom of Stack) | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 Figure 2: Segment Routing MPLS Tunnel sub-TLV 269 The Segment Routing MPLS Tunnel sub-TLV Type is two octets in length, 270 and has a value of TBD2 (to be assigned by IANA as requested in 271 Section 8.1). 273 The egress LER MUST use the Value field as label stack for BFD 274 Control packets for the BFD session identified by the source IP 275 address of the MPLS LSP Ping packet and the value in the BFD 276 Discriminator TLV. Label Entries MUST be in network order. 278 5. BFD Reverse Path TLV over Segment Routed MPLS Tunnel with Dynamic 279 Control Plane 281 When Segment Routed domain with MPLS data plane uses distributed 282 tunnel computation BFD Reverse Path TLV MAY use Target FEC sub-TLVs 283 defined in [RFC8287]. 285 6. Applicability of BFD Demand Mode in SR-MPLS Domain 287 [I-D.mirsky-bfd-mpls-demand] defines how Demand mode of BFD, 288 specified in sections 6.6 and 6.18.4 of [RFC5880], can be used to 289 monitor uni-directional MPLS LSP. Similar procedures can be 290 following in SR-MPLS to monitor uni-directional SR tunnels: 292 o an ingress SR node bootstraps BFD session over SR-MPLS in Async 293 BFD mode; 295 o once BFD session is Up, the ingress SR node switches the egress 296 LER into the Demand mode by setting D field in BFD Control packet 297 it transmits; 299 o if the egress LER detects the failure of the BFD session, it sends 300 its BFD Control packet to the ingress SR node over the IP network 301 with a Poll sequence; 303 o if the ingress SR node receives a BFD Control packet from the 304 remote node in a Demand mode with Poll sequence and Diag field 305 indicating the failure, the ingress SR node transmits BFD Control 306 packet with Final over IP and switches the BFD over SR-MPLS back 307 into Async mode, sending BFD Control packets one per second. 309 7. Using BFD to Monitor Pont-to-Multipoint SR Policy 311 [I-D.voyer-spring-sr-p2mp-policy] defined variants of SR Policy to 312 deliver point-to-multipoint (p2mp) services. For the given P2MP 313 segment [RFC8562] can be used if, for example, leaves have an 314 alternative source of the multicast service flow to select. In such 315 a scenario, a leaf may switch to using the alternative flow after 316 p2mp BFD detects the failure in the working multicast path. For 317 scenarios where it is required for the root to monitor the state of 318 the multicast tree [RFC8563] can be used. The root may use the 319 detection of the failure of the multicast tree to the particular leaf 320 to restore the path for that leaf or re-instantiate the whole 321 multicast tree. 323 An essential part of using p2mp BFD is the bootstrapping the BFD 324 session at all the leaves. The root, acting as the MultipointHead, 325 MAY use LSP Ping with the BFD Discriminator TLV. Alternatively, 326 extensions to routing protocols, e.g., BGP, or management plane, 327 e.g., PCEP, MAY be used to associate the particular P2MP segment with 328 MultipointHead's Discriminator. Extensions for routing protocols and 329 management plane are for further study. 331 8. IANA Considerations 333 8.1. Non-FEC Path TLV 335 IANA is requested to assign new TLV type from the from Standards 336 Action range of the registry "Multiprotocol Label Switching 337 Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters - 338 TLVs" as defined in Table 1. 340 +-------+------------------+---------------+ 341 | Value | TLV Name | Reference | 342 +-------+------------------+---------------+ 343 | TBD1 | Non-FEC Path TLV | This document | 344 +-------+------------------+---------------+ 346 Table 1: New Non-FEC Path TLV 348 IANA is requested to create new Non-FEC Path sub-TLV registry for the 349 Non-FEC Path TLV, as described in Table 2. 351 +-------------+---------------+-------------------------------------+ 352 | Range | Registration | Note | 353 | | Procedures | | 354 +-------------+---------------+-------------------------------------+ 355 | 0-16383 | Standards | This range is for mandatory TLVs or | 356 | | Action | for optional TLVs that require an | 357 | | | error message if not recognized. | 358 | 16384-31743 | Specification | Experimental RFC needed | 359 | | Required | | 360 | 32768-49161 | Standards | This range is for optional TLVs | 361 | | Action | that can be silently dropped if not | 362 | | | recognized. | 363 | 49162-64511 | Specification | Experimental RFC needed | 364 | | Required | | 365 | 64512-65535 | Private Use | | 366 +-------------+---------------+-------------------------------------+ 368 Table 2: Non-FEC Path sub-TLV registry 370 IANA is requested to allocate the following values from the Non-FEC 371 Path sub-TLV registry as defined in Table 3. 373 +-------+-------------------------------------+---------------+ 374 | Value | Description | Reference | 375 +-------+-------------------------------------+---------------+ 376 | 0 | Reserved | This document | 377 | TBD2 | Segment Routing MPLS Tunnel sub-TLV | This document | 378 | 65535 | Reserved | This document | 379 +-------+-------------------------------------+---------------+ 381 Table 3: New Segment Routing Tunnel sub-TLV 383 8.2. Return Code 385 IANA is requested to create Non-FEC Path sub-TLV sub-registry for the 386 new Non-FEC Path TLV and assign a new Return Code value from the 387 "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) 388 Ping Parameters" registry, "Return Codes" sub-registry, as follows 389 using a Standards Action value. 391 +--------+-------------------------+---------------+ 392 | Value | Description | Reference | 393 +--------+-------------------------+---------------+ 394 | X TBD3 | Too Many TLVs Detected. | This document | 395 +--------+-------------------------+---------------+ 397 Table 4: New Return Code 399 9. Implementation Status 401 - The organization responsible for the implementation: ZTE 402 Corporation. 404 - The implementation's name ROSng SW empowers traditional routers, 405 e.g., ZXCTN 6000. 407 - A brief general description: A list of SIDs can be specified as the 408 Return Path for an SR-MPLS tunnel. 410 - The implementation's level of maturity: production. 412 - Coverage: complete 414 - Version compatibility: draft-mirsky-spring-bfd-06. 416 - Licensing: proprietary. 418 - Implementation experience: Appreciate Early Allocation of values 419 for Non-FEC TLV and Segment Routing MPLS Tunnel sub-TLV (using 420 Private Use code points). 422 - Contact information: Qian Xin qian.xin2@zte.com.cn 424 - The date when information about this particular implementation was 425 last updated: 12/16/2019 427 Note to RFC Editor: This section MUST be removed before publication 428 of the document. 430 10. Security Considerations 432 Security considerations discussed in [RFC5880], [RFC5884], [RFC7726], 433 and [RFC8029] apply to this document. 435 11. Acknowledgments 437 Authors greatly appreciate the help of Qian Xin, who provided the 438 information about the implementation of this specification. 440 12. References 442 12.1. Normative References 444 [I-D.ietf-mpls-bfd-directed] 445 Mirsky, G., Tantsura, J., Varlashkin, I., and M. Chen, 446 "Bidirectional Forwarding Detection (BFD) Directed Return 447 Path", draft-ietf-mpls-bfd-directed-12 (work in progress), 448 August 2019. 450 [I-D.mirsky-bfd-mpls-demand] 451 Mirsky, G., "BFD in Demand Mode over Point-to-Point MPLS 452 LSP", draft-mirsky-bfd-mpls-demand-05 (work in progress), 453 June 2019. 455 [I-D.voyer-spring-sr-p2mp-policy] 456 daniel.voyer@bell.ca, d., Filsfils, C., Parekh, R., 457 Bidgoli, H., and Z. Zhang, "SR Replication Policy for P2MP 458 Service Delivery", draft-voyer-spring-sr-p2mp-policy-03 459 (work in progress), July 2019. 461 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 462 Requirement Levels", BCP 14, RFC 2119, 463 DOI 10.17487/RFC2119, March 1997, 464 . 466 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 467 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 468 . 470 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 471 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 472 DOI 10.17487/RFC5881, June 2010, 473 . 475 [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 476 (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, 477 June 2010, . 479 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 480 "Bidirectional Forwarding Detection (BFD) for MPLS Label 481 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 482 June 2010, . 484 [RFC6428] Allan, D., Ed., Swallow, G., Ed., and J. Drake, Ed., 485 "Proactive Connectivity Verification, Continuity Check, 486 and Remote Defect Indication for the MPLS Transport 487 Profile", RFC 6428, DOI 10.17487/RFC6428, November 2011, 488 . 490 [RFC7726] Govindan, V., Rajaraman, K., Mirsky, G., Akiya, N., and S. 491 Aldrin, "Clarifying Procedures for Establishing BFD 492 Sessions for MPLS Label Switched Paths (LSPs)", RFC 7726, 493 DOI 10.17487/RFC7726, January 2016, 494 . 496 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 497 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 498 Switched (MPLS) Data-Plane Failures", RFC 8029, 499 DOI 10.17487/RFC8029, March 2017, 500 . 502 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 503 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 504 May 2017, . 506 [RFC8287] Kumar, N., Ed., Pignataro, C., Ed., Swallow, G., Akiya, 507 N., Kini, S., and M. Chen, "Label Switched Path (LSP) 508 Ping/Traceroute for Segment Routing (SR) IGP-Prefix and 509 IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data 510 Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017, 511 . 513 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 514 Decraene, B., Litkowski, S., and R. Shakir, "Segment 515 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 516 July 2018, . 518 [RFC8562] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, 519 Ed., "Bidirectional Forwarding Detection (BFD) for 520 Multipoint Networks", RFC 8562, DOI 10.17487/RFC8562, 521 April 2019, . 523 [RFC8563] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, 524 Ed., "Bidirectional Forwarding Detection (BFD) Multipoint 525 Active Tails", RFC 8563, DOI 10.17487/RFC8563, April 2019, 526 . 528 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 529 Decraene, B., Litkowski, S., and R. Shakir, "Segment 530 Routing with the MPLS Data Plane", RFC 8660, 531 DOI 10.17487/RFC8660, December 2019, 532 . 534 12.2. Informative References 536 [I-D.ietf-spring-mpls-anycast-segments] 537 Sarkar, P., Gredler, H., Filsfils, C., Previdi, S., 538 Decraene, B., and M. Horneffer, "Anycast Segments in MPLS 539 based Segment Routing", draft-ietf-spring-mpls-anycast- 540 segments-02 (work in progress), January 2018. 542 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 543 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 544 RFC 6790, DOI 10.17487/RFC6790, November 2012, 545 . 547 Authors' Addresses 549 Greg Mirsky 550 ZTE Corp. 552 Email: gregimirsky@gmail.com 554 Jeff Tantsura 555 Apstra, Inc. 557 Email: jefftant.ietf@gmail.com 559 Ilya Varlashkin 560 Google 562 Email: Ilya@nobulus.com 563 Mach(Guoyi) Chen 564 Huawei 566 Email: mach.chen@huawei.com