idnits 2.17.1 draft-ietf-spring-bfd-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (22 March 2021) is 1125 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-17 ** 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-08 ** Downref: Normative reference to an Informational draft: draft-mirsky-bfd-mpls-demand (ref. 'I-D.mirsky-bfd-mpls-demand') == Outdated reference: A later version (-10) exists of draft-ietf-pim-bfd-p2mp-use-case-05 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: 23 September 2021 Juniper Networks 6 I. Varlashkin 7 Google 8 M. Chen 9 Huawei 10 J. Wenying 11 CMCC 12 22 March 2021 14 Bidirectional Forwarding Detection (BFD) in Segment Routing Networks 15 Using MPLS Dataplane 16 draft-ietf-spring-bfd-01 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 23 September 2021. 49 Copyright Notice 51 Copyright (c) 2021 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 Simplified BSD License text 60 as described in Section 4.e of the Trust Legal Provisions and are 61 provided without warranty as described in the Simplified 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 . . . . . . . . . . . . . . . . . . . . 11 82 11. Security Considerations . . . . . . . . . . . . . . . . . . . 11 83 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 84 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 85 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 86 14.1. Normative References . . . . . . . . . . . . . . . . . . 12 87 14.2. Informative References . . . . . . . . . . . . . . . . . 14 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 159 [I-D.ietf-bess-mvpn-fast-failover] and 160 [I-D.ietf-pim-bfd-p2mp-use-case]. 162 As demonstrated in [RFC8287], the introduction of Segment Routing 163 network domains with an MPLS data plane requires three new sub-TLVs 164 that MAY be used with Target FEC TLV. Section 6.1 addresses the use 165 of the new sub-TLVs in Target FEC TLV in LSP ping and LSP traceroute. 166 For the case of LSP ping, the [RFC8287] states that: 168 The initiator, i.e., ingress LER, MUST include FEC(s) 169 corresponding to the destination segment. 171 The initiator MAY include FECs corresponding to some or all of 172 segments imposed in the label stack by the ingress LER to 173 communicate the segments traversed. 175 It has been noted in [RFC5884] that a BFD session monitors for 176 defects particular tuple. [RFC7726] clarified how to 177 establish and operate multiple BFD sessions for the same tuple. Because only the ingress LER is aware of the SR-based 179 explicit route, the egress LER can associate the LSP ping with BFD 180 Discriminator TLV with only one of the FECs it advertised for the 181 particular segment. Thus this document clarifies that: 183 When LSP Ping is used to bootstrapping a BFD session for SR-MPLS 184 tunnel the FEC corresponding to the segment to be associated with 185 the BFD session MUST be as the very last sub-TLV in the Target FEC 186 TLV. 188 If the target segment is an anycast prefix segment 189 ([I-D.ietf-spring-mpls-anycast-segments]) the corresponding Anycast 190 SID MUST be included in the Target TLV as the very last sub-TLV. 191 Also, for BFD Control packet the ingress SR node MUST use precisely 192 the same label stack encapsulation, especially Entropy Label 193 ([RFC6790]), as for the LSP ping with the BFD Discriminator TLV that 194 bootstrapped the BFD session. Other operational aspects of using BFD 195 to monitor the continuity of the path to the particular Anycast SID, 196 advertised by a group of SR-MPLS capable nodes, will be considered in 197 the future versions of the document. 199 Encapsulation of a BFD Control packet in Segment Routing network with 200 MPLS data plane MUST follow Section 7 [RFC5884] when the IP/UDP 201 header used and MUST follow Section 3.4 [RFC6428] without IP/UDP 202 header being used. 204 3. Use BFD Reverse Path TLV over Segment Routed MPLS Tunnel 206 For BFD over MPLS LSP case, per [RFC5884], egress LER MAY send BFD 207 Control packet to the ingress LER either over IP network or an MPLS 208 LSP. Similarly, for the case of BFD over p2p SR-MPLS tunnel, the 209 egress LER MAY route BFD Control packet over the IP network, as 210 described in [RFC5883], or transmit over a segment tunnel, as 211 described in Section 7 [RFC5884]. In some cases, there may be a need 212 to direct egress LER to use a specific path for the reverse direction 213 of the BFD session by using the BFD Reverse Path TLV and following 214 all procedures as defined in [I-D.ietf-mpls-bfd-directed]. 216 4. Use Non-FEC Path TLV 218 For the case of MPLS data plane, Segment Routing Architecture 219 [RFC8402] explains that "a segment is encoded as an MPLS label. An 220 ordered list of segments is encoded as a stack of labels." 222 This document defines a new optional Non-FEC Path TLV. The format of 223 the Non-FEC Path TLV is presented in Figure 1 224 0 1 2 3 225 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 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Non-FEC Path TLV Type | Length | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | | 230 ~ Non-FEC Path ~ 231 | | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 Figure 1: Non-FEC Path TLV Format 236 Non-FEC Path TLV Type is two octets in length and has a value of TBD1 237 (to be assigned by IANA as requested in Section 9.1). 239 Length field is two octets long and defines the length in octets of 240 the Non-FEC Path field. 242 Non-FEC Path field contains a sub-TLV. Any Non-FEC Path sub-TLV 243 (defined in this document or to be defined in the future) for Non-FEC 244 Path TLV type MAY be used in this field. None or one sub-TLV MAY be 245 included in the Non-FEC Path TLV. If no sub-TLV has been found in 246 the Non-FEC Path TLV, the egress LER MUST revert to using the reverse 247 path selected based on its local policy. If there is more than one 248 sub-TLV, then the Return Code in echo reply MUST be set to value TBD3 249 "Too Many TLVs Detected" (to be assigned by IANA as requested in 250 Table 4). 252 Non-FEC Path TLV MAY be used to specify the reverse path of the BFD 253 session identified in the BFD Discriminator TLV. If the Non-FEC Path 254 TLV is present in the echo request message the BFD Discriminator TLV 255 MUST be present as well. If the BFD Discriminator TLV is absent when 256 the Non-FEC Path TLV is included, then it MUST be treated as 257 malformed Echo Request, as described in [RFC8029]. 259 This document defines the Segment Routing MPLS Tunnel sub-TLV that 260 MAY be used with the Non-FEC Path TLV. The format of the sub-TLV is 261 presented in Figure 2. 263 0 1 2 3 264 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 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | SR MPLS Tunnel sub-TLV Type | Length | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | SID Entry 1 (Top of Stack) | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | SID Entry 2 | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 ~ ~ 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | SID Entry N (Bottom of Stack) | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 Figure 2: Segment Routing MPLS Tunnel sub-TLV 279 The Segment Routing MPLS Tunnel sub-TLV Type is two octets in length, 280 and has a value of TBD2 (to be assigned by IANA as requested in 281 Section 9.1). 283 The egress LER MUST use the Value field as label stack for BFD 284 Control packets for the BFD session identified by the source IP 285 address of the MPLS LSP Ping packet and the value in the BFD 286 Discriminator TLV. Label Entries MUST be in network order. 288 5. BFD Reverse Path TLV over Segment Routed MPLS Tunnel with Dynamic 289 Control Plane 291 When Segment Routed domain with MPLS data plane uses distributed 292 tunnel computation BFD Reverse Path TLV MAY use Target FEC sub-TLVs 293 defined in [RFC8287]. 295 6. Applicability of BFD Demand Mode in SR-MPLS Domain 297 [I-D.mirsky-bfd-mpls-demand] defines how Demand mode of BFD, 298 specified in sections 6.6 and 6.18.4 of [RFC5880], can be used to 299 monitor uni-directional MPLS LSP. Similar procedures can be 300 following in SR-MPLS to monitor uni-directional SR tunnels: 302 * an ingress SR node bootstraps BFD session over SR-MPLS in Async 303 BFD mode; 305 * once BFD session is Up, the ingress SR node switches the egress 306 LER into the Demand mode by setting D field in BFD Control packet 307 it transmits; 309 * if the egress LER detects the failure of the BFD session, it sends 310 its BFD Control packet to the ingress SR node over the IP network 311 with a Poll sequence; 313 * if the ingress SR node receives a BFD Control packet from the 314 remote node in a Demand mode with Poll sequence and Diag field 315 indicating the failure, the ingress SR node transmits BFD Control 316 packet with Final over IP and switches the BFD over SR-MPLS back 317 into Async mode, sending BFD Control packets one per second. 319 7. Using BFD to Monitor Point-to-Multipoint SR Policy 321 [I-D.voyer-spring-sr-p2mp-policy] defined variants of SR Policy to 322 deliver point-to-multipoint (p2mp) services. For the given P2MP 323 segment [RFC8562] can be used if, for example, leaves have an 324 alternative source of the multicast service flow to select. In such 325 a scenario, a leaf may switch to using the alternative flow after 326 p2mp BFD detects the failure in the working multicast path. For 327 scenarios where it is required for the root to monitor the state of 328 the multicast tree [RFC8563] can be used. The root may use the 329 detection of the failure of the multicast tree to the particular leaf 330 to restore the path for that leaf or re-instantiate the whole 331 multicast tree. 333 An essential part of using p2mp BFD is the bootstrapping the BFD 334 session at all the leaves. The root, acting as the MultipointHead, 335 MAY use LSP Ping with the BFD Discriminator TLV. Alternatively, 336 extensions to routing protocols, e.g., BGP, or management plane, 337 e.g., PCEP, MAY be used to associate the particular P2MP segment with 338 MultipointHead's Discriminator. Extensions for routing protocols and 339 management plane are for further study. 341 8. Use of Echo BFD in SR-MPLS 343 Echo-BFD [RFC5880] can be used to monitor an SR Policy between the 344 local and the remote BFD peers. As defined in [RFC5880], the remote 345 BFD system does not process the payload of an Echo BFD. Thus it is 346 the local system that demultiplexes the Echo BFD packet matching it 347 to the appropriate BFD session and detects missing Echo BFD packets. 348 A BFD Control packet MAY be used as the payload of Echo BFD. This 349 specification defines the use of Echo BFD in SR-MPLS network with BFD 350 Control packet as the payload. The use of other types of Echo BFD 351 payload is outside the scope of this document. Because the remote 352 BFD system does not process Echo BFD, the value of the Your 353 Discriminator field MUST be set to the discriminator the local BFD 354 system assigned to the given BFD session. My Discriminator field 355 MUST be zeroed. Authentication MUST be set according to the 356 configuration of the BFD session. To ensure that the Echo BFD packet 357 is returned to the sender without being processed, the sender MAY use 358 a Binding SID (BSID) [RFC8402] that has been bound with the SR Policy 359 that ensures the return of a packet to that particular node. A BSID 360 MAY be associated with the SR Policy that is the reverse to the SR 361 Policy programmed onto the BFD Echo packet by the sender. 363 9. IANA Considerations 365 9.1. Non-FEC Path TLV 367 IANA is requested to assign new TLV type from the from Standards 368 Action range of the registry "Multiprotocol Label Switching 369 Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters - 370 TLVs" as defined in Table 1. 372 +=======+==================+===============+ 373 | Value | TLV Name | Reference | 374 +=======+==================+===============+ 375 | TBD1 | Non-FEC Path TLV | This document | 376 +-------+------------------+---------------+ 378 Table 1: New Non-FEC Path TLV 380 IANA is requested to create new Non-FEC Path sub-TLV registry for the 381 Non-FEC Path TLV, as described in Table 2. 383 +=============+===============+=====================================+ 384 | Range | Registration | Note | 385 | | Procedures | | 386 +=============+===============+=====================================+ 387 | 0-16383 | Standards | This range is for mandatory | 388 | | Action | TLVs or for optional TLVs | 389 | | | that require an error | 390 | | | message if not recognized. | 391 +-------------+---------------+-------------------------------------+ 392 | 16384-31743 | Specification | Experimental RFC needed | 393 | | Required | | 394 +-------------+---------------+-------------------------------------+ 395 | 32768-49161 | Standards | This range is for optional | 396 | | Action | TLVs that can be silently | 397 | | | dropped if not recognized. | 398 +-------------+---------------+-------------------------------------+ 399 | 49162-64511 | Specification | Experimental RFC needed | 400 | | Required | | 401 +-------------+---------------+-------------------------------------+ 402 | 64512-65535 | Private Use | | 403 +-------------+---------------+-------------------------------------+ 405 Table 2: Non-FEC Path sub-TLV registry 407 IANA is requested to allocate the following values from the Non-FEC 408 Path sub-TLV registry as defined in Table 3. 410 +=======+=====================================+===============+ 411 | Value | Description | Reference | 412 +=======+=====================================+===============+ 413 | 0 | Reserved | This document | 414 +-------+-------------------------------------+---------------+ 415 | TBD2 | Segment Routing MPLS Tunnel sub-TLV | This document | 416 +-------+-------------------------------------+---------------+ 417 | 65535 | Reserved | This document | 418 +-------+-------------------------------------+---------------+ 420 Table 3: New Segment Routing Tunnel sub-TLV 422 9.2. Return Code 424 IANA is requested to create Non-FEC Path sub-TLV sub-registry for the 425 new Non-FEC Path TLV and assign a new Return Code value from the 426 "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) 427 Ping Parameters" registry, "Return Codes" sub-registry, as follows 428 using a Standards Action value. 430 +========+=========================+===============+ 431 | Value | Description | Reference | 432 +========+=========================+===============+ 433 | X TBD3 | Too Many TLVs Detected. | This document | 434 +--------+-------------------------+---------------+ 436 Table 4: New Return Code 438 10. Implementation Status 440 - The organization responsible for the implementation: ZTE 441 Corporation. 443 - The implementation's name ROSng SW empowers traditional routers, 444 e.g., ZXCTN 6000. 446 - A brief general description: A list of SIDs can be specified as the 447 Return Path for an SR-MPLS tunnel. 449 - The implementation's level of maturity: production. 451 - Coverage: complete 453 - Version compatibility: draft-mirsky-spring-bfd-06. 455 - Licensing: proprietary. 457 - Implementation experience: Appreciate Early Allocation of values 458 for Non-FEC TLV and Segment Routing MPLS Tunnel sub-TLV (using 459 Private Use code points). 461 - Contact information: Qian Xin qian.xin2@zte.com.cn 463 - The date when information about this particular implementation was 464 last updated: 12/16/2019 466 Note to RFC Editor: This section MUST be removed before publication 467 of the document. 469 11. Security Considerations 471 Security considerations discussed in [RFC5880], [RFC5884], [RFC7726], 472 and [RFC8029] apply to this document. 474 12. Contributors 475 Xiao Min 476 ZTE Corp. 477 Email: xiao.min2@zte.com.cn 479 13. Acknowledgments 481 Authors greatly appreciate the help of Qian Xin, who provided the 482 information about the implementation of this specification. 484 14. References 486 14.1. Normative References 488 [I-D.ietf-mpls-bfd-directed] 489 Mirsky, G., Tantsura, J., Varlashkin, I., and M. Chen, 490 "Bidirectional Forwarding Detection (BFD) Directed Return 491 Path for MPLS Label Switched Paths (LSPs)", Work in 492 Progress, Internet-Draft, draft-ietf-mpls-bfd-directed-17, 493 16 February 2021, . 496 [I-D.mirsky-bfd-mpls-demand] 497 Mirsky, G., "BFD in Demand Mode over Point-to-Point MPLS 498 LSP", Work in Progress, Internet-Draft, draft-mirsky-bfd- 499 mpls-demand-08, 9 September 2020, 500 . 503 [I-D.voyer-spring-sr-p2mp-policy] 504 Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z. 505 Zhang, "SR Replication Policy for P2MP Service Delivery", 506 Work in Progress, Internet-Draft, draft-voyer-spring-sr- 507 p2mp-policy-03, 2 July 2019, . 510 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 511 Requirement Levels", BCP 14, RFC 2119, 512 DOI 10.17487/RFC2119, March 1997, 513 . 515 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 516 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 517 . 519 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 520 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 521 DOI 10.17487/RFC5881, June 2010, 522 . 524 [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 525 (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, 526 June 2010, . 528 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 529 "Bidirectional Forwarding Detection (BFD) for MPLS Label 530 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 531 June 2010, . 533 [RFC6428] Allan, D., Ed., Swallow, G., Ed., and J. Drake, Ed., 534 "Proactive Connectivity Verification, Continuity Check, 535 and Remote Defect Indication for the MPLS Transport 536 Profile", RFC 6428, DOI 10.17487/RFC6428, November 2011, 537 . 539 [RFC7726] Govindan, V., Rajaraman, K., Mirsky, G., Akiya, N., and S. 540 Aldrin, "Clarifying Procedures for Establishing BFD 541 Sessions for MPLS Label Switched Paths (LSPs)", RFC 7726, 542 DOI 10.17487/RFC7726, January 2016, 543 . 545 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 546 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 547 Switched (MPLS) Data-Plane Failures", RFC 8029, 548 DOI 10.17487/RFC8029, March 2017, 549 . 551 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 552 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 553 May 2017, . 555 [RFC8287] Kumar, N., Ed., Pignataro, C., Ed., Swallow, G., Akiya, 556 N., Kini, S., and M. Chen, "Label Switched Path (LSP) 557 Ping/Traceroute for Segment Routing (SR) IGP-Prefix and 558 IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data 559 Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017, 560 . 562 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 563 Decraene, B., Litkowski, S., and R. Shakir, "Segment 564 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 565 July 2018, . 567 [RFC8562] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, 568 Ed., "Bidirectional Forwarding Detection (BFD) for 569 Multipoint Networks", RFC 8562, DOI 10.17487/RFC8562, 570 April 2019, . 572 [RFC8563] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, 573 Ed., "Bidirectional Forwarding Detection (BFD) Multipoint 574 Active Tails", RFC 8563, DOI 10.17487/RFC8563, April 2019, 575 . 577 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 578 Decraene, B., Litkowski, S., and R. Shakir, "Segment 579 Routing with the MPLS Data Plane", RFC 8660, 580 DOI 10.17487/RFC8660, December 2019, 581 . 583 14.2. Informative References 585 [I-D.ietf-bess-mvpn-fast-failover] 586 Morin, T., Kebler, R., and G. Mirsky, "Multicast VPN Fast 587 Upstream Failover", Work in Progress, Internet-Draft, 588 draft-ietf-bess-mvpn-fast-failover-15, 21 January 2021, 589 . 592 [I-D.ietf-pim-bfd-p2mp-use-case] 593 Mirsky, G. and J. Xiaoli, "Bidirectional Forwarding 594 Detection (BFD) for Multi-point Networks and Protocol 595 Independent Multicast - Sparse Mode (PIM-SM) Use Case", 596 Work in Progress, Internet-Draft, draft-ietf-pim-bfd-p2mp- 597 use-case-05, 30 November 2020, 598 . 601 [I-D.ietf-spring-mpls-anycast-segments] 602 Sarkar, P., Gredler, H., Filsfils, C., Previdi, S., 603 Decraene, B., and M. Horneffer, "Anycast Segments in MPLS 604 based Segment Routing", Work in Progress, Internet-Draft, 605 draft-ietf-spring-mpls-anycast-segments-03, 27 April 2020, 606 . 609 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 610 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 611 RFC 6790, DOI 10.17487/RFC6790, November 2012, 612 . 614 Authors' Addresses 616 Greg Mirsky 617 ZTE Corp. 619 Email: gregimirsky@gmail.com, gregory.mirsky@ztetx.com 620 Jeff Tantsura 621 Juniper Networks 623 Email: jefftant.ietf@gmail.com 625 Ilya Varlashkin 626 Google 628 Email: Ilya@nobulus.com 630 Mach(Guoyi) Chen 631 Huawei 633 Email: mach.chen@huawei.com 635 Jiang Wenying 636 CMCC 638 Email: jiangwenying@chinamobile.com