idnits 2.17.1 draft-mirsky-spring-bfd-08.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 (August 2, 2019) is 1728 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 (-30) exists of draft-ietf-mpls-bfd-directed-11 ** 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 (-14) exists of draft-ietf-mpls-static-yang-09 == Outdated reference: A later version (-03) exists of draft-ietf-spring-mpls-anycast-segments-02 == Outdated reference: A later version (-02) exists of draft-ninan-spring-mpls-inter-as-oam-01 Summary: 2 errors (**), 0 flaws (~~), 6 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: February 3, 2020 Apstra, Inc. 6 I. Varlashkin 7 Google 8 M. Chen 9 Huawei 10 August 2, 2019 12 Bidirectional Forwarding Detection (BFD) in Segment Routing Networks 13 Using MPLS Dataplane 14 draft-mirsky-spring-bfd-08 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 February 3, 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 . . . . . . . . . . . . . . . . . . . . . . . 3 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. Security Considerations . . . . . . . . . . . . . . . . . . . 10 78 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 79 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 81 11.2. Informative References . . . . . . . . . . . . . . . . . 12 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 84 1. Introduction 86 [RFC5880], [RFC5881], and [RFC5883] defined the operation of 87 Bidirectional Forwarding Detection (BFD) protocol between the two 88 systems over IP networks. [RFC5884] and [RFC7726] set rules for 89 using BFD Asynchronous mode over point-to-point (p2p) Multiprotocol 90 Label Switching (MPLS) Label Switched Path (LSP). These latter 91 standards implicitly assume that the remote BFD system, which is at 92 the egress Label Edge Router (LER), will use the shortest path route 93 regardless of the path the BFD system at the ingress LER uses to send 94 BFD Control packets towards it. Throughourt this document references 95 to ingress LER and egrees LER are used, respectively, as shortened 96 version of "BFD system at the ingress/egress LER". 98 This document defines the use of LSP Ping for Segment Routing 99 networks over MPLS data plane [RFC8287] to bootstrap and control path 100 of a BFD session from the egress to ingress LER using Segment Routing 101 tunnel with MPLS data plane (SR-MPLS). 103 1.1. Conventions 105 1.1.1. Terminology 107 BFD: Bidirectional Forwarding Detection 109 FEC: Forwarding Equivalence Class 111 MPLS: Multiprotocol Label Switching 113 SR-MPLS Segment Routing with MPLS data plane 115 LSP: Label Switched Path 117 LER Label Edge Router 119 p2p Point-to-point 121 p2mp Point-to-multipoint 123 SID Segment Identifier 125 SR Segment Routing 127 1.1.2. Requirements Language 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 131 "OPTIONAL" in this document are to be interpreted as described in BCP 132 14 [RFC2119] [RFC8174] when, and only when, they appear in all 133 capitals, as shown here. 135 2. Bootstrapping BFD Session over Segment Routed Tunnel with MPLS Data 136 Plane 138 Use of an LSP Ping to bootstrap BFD over MPLS LSP is required, as 139 documented in [RFC5884], to establish an association between a fault 140 detection message, i.e., BFD Control message, and the Forwarding 141 Equivalency Class (FEC) of a single label stack LSP in case of 142 Penultimate Hop Popping or when the egress LER distributes the 143 Explicit NULL label to the penultimate hop router. The Explicit NULL 144 label is not advertised as a Segment Identifier (SID) by an SR node 145 but, as demonstrated in section 3.1 146 [I-D.ietf-spring-segment-routing-mpls] 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." YANG Data 210 Model for MPLS Static LSPs [I-D.ietf-mpls-static-yang] models 211 outgoing MPLS labels to be imposed as leaf-list [RFC6020], i.e., as 212 array of rt-types:mpls-label [RFC8294]. 214 This document defines new optional Non-FEC Path TLV. The format of 215 the Non-FEC Path TLV is presented in Figure 1 217 0 1 2 3 218 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 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Non-FEC Path TLV Type | Length | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | | 223 ~ Non-FEC Path ~ 224 | | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 Figure 1: Non-FEC Path TLV Format 229 Non-FEC Path TLV Type is two octets in length and has a value of TBD1 230 (to be assigned by IANA as requested in Section 8.1). 232 Length field is two octets long and defines the length in octets of 233 the Non-FEC Path field. 235 Non-FEC Path field contains a sub-TLV. Any Non-FEC Path sub-TLV 236 (defined in this document or to be defined in the future) for Non-FEC 237 Path TLV type MAY be used in this field. None or one sub-TLV MAY be 238 included in the Non-FEC Path TLV. If no sub-TLV has been found in 239 the Non-FEC Path TLV, the egress LER MUST revert to using the reverse 240 path selected based on its local policy. If there is more than one 241 sub-TLV, then the Return Code in echo reply MUST be set to value TBD3 242 "Too Many TLVs Detected" (to be assigned by IANA as requested in 243 Table 4). 245 Non-FEC Path TLV MAY be used to specify the reverse path of the BFD 246 session identified in the BFD Discriminator TLV. If the Non-FEC Path 247 TLV is present in the echo request message the BFD Discriminator TLV 248 MUST be present as well. If the BFD Discriminator TLV is absent when 249 the Non-FEC Path TLV is included, then it MUST be treated as 250 malformed Echo Request, as described in [RFC8029]. 252 This document defines Static Routing MPLS Tunnel sub-TLV that MAY be 253 used with the Non-FEC Path TLV. The format of the sub-TLV is 254 presented in Figure 2. 256 0 1 2 3 257 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 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | SR MPLS Tunnel sub-TLV Type | Length | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Label Entry 1 (Top Label) | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Label Entry 2 | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 ~ ~ 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Label Entry N (Bottom Label) | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 Figure 2: Segment Routing MPLS Tunnel sub-TLV 272 The Segment Routing MPLS Tunnel sub-TLV Type is two octets in length, 273 and has a value of TBD2 (to be assigned by IANA as requested in 274 Section 8.1). 276 The egress LER MUST use the Value field as label stack for BFD 277 Control packets for the BFD session identified by the source IP 278 address of the MPLS LSP Ping packet and the value in the BFD 279 Discriminator TLV. Label Entries MUST be in network order. 281 The Non-FEC Path TLV and Segment Routing MPLS Tunnel sub-TLV MAY be 282 used in Reply Path TLV defined in [RFC7110], particularly to ensure 283 end-to-end veryfication of multi-AS SR tunnel, as described in 284 [I-D.ninan-spring-mpls-inter-as-oam]. 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 [I-D.mirsky-bfd-mpls-demand] defines how Demand mode of BFD, 296 specified in sections 6.6 and 6.18.4 of [RFC5880], can be used to 297 monitor uni-directional MPLS LSP. Similar procedures can be 298 following in SR-MPLS to monitor uni-directional SR tunnels: 300 o an ingress SR node bootstraps BFD session over SR-MPLS in Async 301 BFD mode; 303 o once BFD session is Up, the ingress SR node switches the egress 304 LER into the Demand mode by setting D field in BFD Control packet 305 it transmits; 307 o if the egress LER detects the failure of the BFD session, it sends 308 its BFD Control packet to the ingress SR node over the IP network 309 with a Poll sequence; 311 o if the ingress SR node receives a BFD Control packet from the 312 remote node in a Demand mode with Poll sequence and Diag field 313 indicating the failure, the ingress SR node transmits BFD Control 314 packet with Final over IP and switches the BFD over SR-MPLS back 315 into Async mode, sending BFD Control packets one per second. 317 7. Using BFD to Monitor Pont-to-Multipoint SR Policy 319 [I-D.voyer-spring-sr-p2mp-policy] defined variants of SR Policy to 320 deliver point-to-multipoint (p2mp) services. For the given P2MP 321 segment [RFC8562] can be used if, for example, leaves have an 322 alternative source of the multicast service flow to select. In such 323 a scenario, a leaf may switch to using the alternative flow after 324 p2mp BFD detects the failure in the working multicast path. For 325 scenarios where it is required for the root to monitor the state of 326 the multicast tree [RFC8563] can be used. The root may use the 327 detection of the failure of the multicast tree to the particular leaf 328 to restore the path for that leaf or re-instantiate the whole 329 multicast tree. 331 An essential part of using p2mp BFD is the bootstrapping the BFD 332 session at all the leaves. The root, acting as the MultipointHead, 333 MAY use LSP Ping with the BFD Discriminator TLV. Alternatively, 334 extensions to routing protocols, e.g., BGP, or management plane, 335 e.g., PCEP, MAY be used to associate the particular P2MP segment with 336 MultipointHead's Discriminator. Extensions for routing protocols and 337 management plane are for further study. 339 8. IANA Considerations 341 8.1. Non-FEC Path TLV 343 IANA is requested to assign new TLV type from the from Standards 344 Action range of the registry "Multiprotocol Label Switching 345 Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters - 346 TLVs" as defined in Table 1. 348 +-------+------------------+---------------+ 349 | Value | TLV Name | Reference | 350 +-------+------------------+---------------+ 351 | TBD1 | Non-FEC Path TLV | This document | 352 +-------+------------------+---------------+ 354 Table 1: New Non-FEC Path TLV 356 IANA is requested to create new Non-FEC Path sub-TLV registry for the 357 Non-FEC Path TLV, as described in Table 2. 359 +-------------+---------------+-------------------------------------+ 360 | Range | Registration | Note | 361 | | Procedures | | 362 +-------------+---------------+-------------------------------------+ 363 | 0-16383 | Standards | This range is for mandatory TLVs or | 364 | | Action | for optional TLVs that require an | 365 | | | error message if not recognized. | 366 | 16384-31743 | Specification | Experimental RFC needed | 367 | | Required | | 368 | 32768-49161 | Standards | This range is for optional TLVs | 369 | | Action | that can be silently dropped if not | 370 | | | recognized. | 371 | 49162-64511 | Specification | Experimental RFC needed | 372 | | Required | | 373 | 64512-65535 | Private Use | | 374 +-------------+---------------+-------------------------------------+ 376 Table 2: Non-FEC Path sub-TLV registry 378 IANA is requested to allocate the following values from the Non-FEC 379 Path sub-TLV registry as defined in Table 3. 381 +-------+-------------------------------------+---------------+ 382 | Value | Description | Reference | 383 +-------+-------------------------------------+---------------+ 384 | 0 | Reserved | This document | 385 | TBD2 | Segment Routing MPLS Tunnel sub-TLV | This document | 386 | 65535 | Reserved | This document | 387 +-------+-------------------------------------+---------------+ 389 Table 3: New Segment Routing Tunnel sub-TLV 391 8.2. Return Code 393 IANA is requested to create Non-FEC Path sub-TLV sub-registry for the 394 new Non-FEC Path TLV and assign a new Return Code value from the 395 "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) 396 Ping Parameters" registry, "Return Codes" sub-registry, as follows 397 using a Standards Action value. 399 +--------+-------------------------+---------------+ 400 | Value | Description | Reference | 401 +--------+-------------------------+---------------+ 402 | X TBD3 | Too Many TLVs Detected. | This document | 403 +--------+-------------------------+---------------+ 405 Table 4: New Return Code 407 9. Security Considerations 409 Security considerations discussed in [RFC5880], [RFC5884], [RFC7726], 410 and [RFC8029] apply to this document. 412 10. Acknowledgments 414 TBD 416 11. References 418 11.1. Normative References 420 [I-D.ietf-mpls-bfd-directed] 421 Mirsky, G., Tantsura, J., Varlashkin, I., and M. Chen, 422 "Bidirectional Forwarding Detection (BFD) Directed Return 423 Path", draft-ietf-mpls-bfd-directed-11 (work in progress), 424 April 2019. 426 [I-D.ietf-spring-segment-routing-mpls] 427 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 428 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 429 data plane", draft-ietf-spring-segment-routing-mpls-22 430 (work in progress), May 2019. 432 [I-D.mirsky-bfd-mpls-demand] 433 Mirsky, G., "BFD in Demand Mode over Point-to-Point MPLS 434 LSP", draft-mirsky-bfd-mpls-demand-05 (work in progress), 435 June 2019. 437 [I-D.voyer-spring-sr-p2mp-policy] 438 daniel.voyer@bell.ca, d., Filsfils, C., Parekh, R., 439 Bidgoli, H., and Z. Zhang, "SR Replication Policy for P2MP 440 Service Delivery", draft-voyer-spring-sr-p2mp-policy-03 441 (work in progress), July 2019. 443 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 444 Requirement Levels", BCP 14, RFC 2119, 445 DOI 10.17487/RFC2119, March 1997, 446 . 448 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 449 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 450 . 452 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 453 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 454 DOI 10.17487/RFC5881, June 2010, 455 . 457 [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 458 (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, 459 June 2010, . 461 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 462 "Bidirectional Forwarding Detection (BFD) for MPLS Label 463 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 464 June 2010, . 466 [RFC6428] Allan, D., Ed., Swallow, G., Ed., and J. Drake, Ed., 467 "Proactive Connectivity Verification, Continuity Check, 468 and Remote Defect Indication for the MPLS Transport 469 Profile", RFC 6428, DOI 10.17487/RFC6428, November 2011, 470 . 472 [RFC7726] Govindan, V., Rajaraman, K., Mirsky, G., Akiya, N., and S. 473 Aldrin, "Clarifying Procedures for Establishing BFD 474 Sessions for MPLS Label Switched Paths (LSPs)", RFC 7726, 475 DOI 10.17487/RFC7726, January 2016, 476 . 478 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 479 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 480 Switched (MPLS) Data-Plane Failures", RFC 8029, 481 DOI 10.17487/RFC8029, March 2017, 482 . 484 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 485 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 486 May 2017, . 488 [RFC8287] Kumar, N., Ed., Pignataro, C., Ed., Swallow, G., Akiya, 489 N., Kini, S., and M. Chen, "Label Switched Path (LSP) 490 Ping/Traceroute for Segment Routing (SR) IGP-Prefix and 491 IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data 492 Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017, 493 . 495 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 496 Decraene, B., Litkowski, S., and R. Shakir, "Segment 497 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 498 July 2018, . 500 [RFC8562] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, 501 Ed., "Bidirectional Forwarding Detection (BFD) for 502 Multipoint Networks", RFC 8562, DOI 10.17487/RFC8562, 503 April 2019, . 505 [RFC8563] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, 506 Ed., "Bidirectional Forwarding Detection (BFD) Multipoint 507 Active Tails", RFC 8563, DOI 10.17487/RFC8563, April 2019, 508 . 510 11.2. Informative References 512 [I-D.ietf-mpls-static-yang] 513 Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 514 "A YANG Data Model for MPLS Static LSPs", draft-ietf-mpls- 515 static-yang-09 (work in progress), March 2019. 517 [I-D.ietf-spring-mpls-anycast-segments] 518 Sarkar, P., Gredler, H., Filsfils, C., Previdi, S., 519 Decraene, B., and M. Horneffer, "Anycast Segments in MPLS 520 based Segment Routing", draft-ietf-spring-mpls-anycast- 521 segments-02 (work in progress), January 2018. 523 [I-D.ninan-spring-mpls-inter-as-oam] 524 Hegde, S., Arora, K., Ninan, S., and M. Srivastava, "PMS/ 525 Head-end based MPLS Ping and Traceroute in Inter-AS SR 526 Networks", draft-ninan-spring-mpls-inter-as-oam-01 (work 527 in progress), July 2019. 529 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 530 the Network Configuration Protocol (NETCONF)", RFC 6020, 531 DOI 10.17487/RFC6020, October 2010, 532 . 534 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 535 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 536 RFC 6790, DOI 10.17487/RFC6790, November 2012, 537 . 539 [RFC7110] Chen, M., Cao, W., Ning, S., Jounay, F., and S. Delord, 540 "Return Path Specified Label Switched Path (LSP) Ping", 541 RFC 7110, DOI 10.17487/RFC7110, January 2014, 542 . 544 [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, 545 "Common YANG Data Types for the Routing Area", RFC 8294, 546 DOI 10.17487/RFC8294, December 2017, 547 . 549 Authors' Addresses 551 Greg Mirsky 552 ZTE Corp. 554 Email: gregimirsky@gmail.com 556 Jeff Tantsura 557 Apstra, Inc. 559 Email: jefftant.ietf@gmail.com 561 Ilya Varlashkin 562 Google 564 Email: Ilya@nobulus.com 566 Mach(Guoyi) Chen 567 Huawei 569 Email: mach.chen@huawei.com