idnits 2.17.1 draft-mirsky-spring-bfd-10.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 (April 26, 2020) is 1460 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-13 ** 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-06 ** Downref: Normative reference to an Informational draft: draft-mirsky-bfd-mpls-demand (ref. 'I-D.mirsky-bfd-mpls-demand') == Outdated reference: A later version (-15) exists of draft-ietf-bess-mvpn-fast-failover-10 == Outdated reference: A later version (-10) exists of draft-ietf-pim-bfd-p2mp-use-case-03 == Outdated reference: A later version (-03) exists of draft-ietf-spring-mpls-anycast-segments-02 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: October 28, 2020 Apstra, Inc. 6 I. Varlashkin 7 Google 8 M. Chen 9 Huawei 10 J. Wenying 11 CMCC 12 April 26, 2020 14 Bidirectional Forwarding Detection (BFD) in Segment Routing Networks 15 Using MPLS Dataplane 16 draft-mirsky-spring-bfd-10 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 October 28, 2020. 49 Copyright Notice 51 Copyright (c) 2020 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 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3 69 1.1.2. Requirements Language . . . . . . . . . . . . . . . . 3 70 2. Bootstrapping BFD Session over Segment Routed Tunnel with 71 MPLS Data Plane . . . . . . . . . . . . . . . . . . . . . . . 4 72 3. Use BFD Reverse Path TLV over Segment Routed MPLS Tunnel . . 5 73 4. Use Non-FEC Path TLV . . . . . . . . . . . . . . . . . . . . 5 74 5. BFD Reverse Path TLV over Segment Routed MPLS Tunnel with 75 Dynamic Control Plane . . . . . . . . . . . . . . . . . . . . 7 76 6. Applicability of BFD Demand Mode in SR-MPLS Domain . . . . . 7 77 7. Using BFD to Monitor Point-to-Multipoint SR Policy . . . . . 7 78 8. Use of Echo BFD in SR-MPLS . . . . . . . . . . . . . . . . . 8 79 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 80 9.1. Non-FEC Path TLV . . . . . . . . . . . . . . . . . . . . 8 81 9.2. Return Code . . . . . . . . . . . . . . . . . . . . . . . 9 82 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 10 83 11. Security Considerations . . . . . . . . . . . . . . . . . . . 10 84 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 85 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 86 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 87 14.1. Normative References . . . . . . . . . . . . . . . . . . 11 88 14.2. Informative References . . . . . . . . . . . . . . . . . 13 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 91 1. Introduction 93 [RFC5880], [RFC5881], and [RFC5883] defined the operation of 94 Bidirectional Forwarding Detection (BFD) protocol between the two 95 systems over IP networks. [RFC5884] and [RFC7726] set rules for 96 using BFD Asynchronous mode over point-to-point (p2p) Multiprotocol 97 Label Switching (MPLS) Label Switched Path (LSP). These latter 98 standards implicitly assume that the remote BFD system, which is at 99 the egress Label Edge Router (LER), will use the shortest path route 100 regardless of the path the BFD system at the ingress LER uses to send 101 BFD Control packets towards it. Throughout this document, references 102 to ingress LER and egress LER are used, respectively, as a shortened 103 version of the "BFD system at the ingress/egress LER". 105 This document defines the use of LSP Ping for Segment Routing 106 networks over MPLS data plane [RFC8287] to bootstrap and control path 107 of a BFD session from the egress to ingress LER using Segment Routing 108 tunnel with MPLS data plane (SR-MPLS). 110 1.1. Conventions 112 1.1.1. Terminology 114 BFD: Bidirectional Forwarding Detection 116 BSID: Binding Segment Identifier 118 FEC: Forwarding Equivalence Class 120 MPLS: Multiprotocol Label Switching 122 SR-MPLS Segment Routing with MPLS data plane 124 LSP: Label Switched Path 126 LER Label Edge Router 128 p2p Point-to-point 130 p2mp Point-to-multipoint 132 SID Segment Identifier 134 SR Segment Routing 136 1.1.2. Requirements Language 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 140 "OPTIONAL" in this document are to be interpreted as described in BCP 141 14 [RFC2119] [RFC8174] when, and only when, they appear in all 142 capitals, as shown here. 144 2. Bootstrapping BFD Session over Segment Routed Tunnel with MPLS Data 145 Plane 147 Use of an LSP Ping to bootstrap BFD over MPLS LSP is required, as 148 documented in [RFC5884], to establish an association between a fault 149 detection message, i.e., BFD Control message, and the Forwarding 150 Equivalency Class (FEC) of a single label stack LSP in case of 151 Penultimate Hop Popping or when the egress LER distributes the 152 Explicit NULL label to the penultimate hop router. The Explicit NULL 153 label is not advertised as a Segment Identifier (SID) by an SR node 154 but, as demonstrated in section 3.1 [RFC8660] if the operation at the 155 penultimate hop is NEXT; then the egress SR node will receive an IP 156 encapsulated packet. Thus the conclusion is that LSP Ping MUST be 157 used to bootstrap a BFD session in an SR-MPLS domain if there are no 158 other means to bootstrap the BFD session, e.g., using an extension to 159 a dynamic routing protocol as described in 160 [I-D.ietf-bess-mvpn-fast-failover] and 161 [I-D.ietf-pim-bfd-p2mp-use-case]. 163 As demonstrated in [RFC8287], the introduction of Segment Routing 164 network domains with an MPLS data plane requires three new sub-TLVs 165 that MAY be used with Target FEC TLV. Section 6.1 addresses the use 166 of the new sub-TLVs in Target FEC TLV in LSP ping and LSP traceroute. 167 For the case of LSP ping, the [RFC8287] states that: 169 The initiator, i.e., ingress LER, MUST include FEC(s) 170 corresponding to the destination segment. 172 The initiator MAY include FECs corresponding to some or all of 173 segments imposed in the label stack by the ingress LER to 174 communicate the segments traversed. 176 It has been noted in [RFC5884] that a BFD session monitors for 177 defects particular tuple. [RFC7726] clarified how to 178 establish and operate multiple BFD sessions for the same tuple. Because only the ingress LER is aware of the SR-based 180 explicit route, the egress LER can associate the LSP ping with BFD 181 Discriminator TLV with only one of the FECs it advertised for the 182 particular segment. Thus this document clarifies that: 184 When LSP Ping is used to bootstrapping a BFD session for SR-MPLS 185 tunnel the FEC corresponding to the segment to be associated with 186 the BFD session MUST be as the very last sub-TLV in the Target FEC 187 TLV. 189 If the target segment is an anycast prefix segment 190 ([I-D.ietf-spring-mpls-anycast-segments]) the corresponding Anycast 191 SID MUST be included in the Target TLV as the very last sub-TLV. 193 Also, for BFD Control packet the ingress SR node MUST use precisely 194 the same label stack encapsulation, especially Entropy Label 195 ([RFC6790]), as for the LSP ping with the BFD Discriminator TLV that 196 bootstrapped the BFD session. Other operational aspects of using BFD 197 to monitor the continuity of the path to the particular Anycast SID, 198 advertised by a group of SR-MPLS capable nodes, will be considered in 199 the future versions of the document. 201 Encapsulation of a BFD Control packet in Segment Routing network with 202 MPLS data plane MUST follow Section 7 [RFC5884] when the IP/UDP 203 header used and MUST follow Section 3.4 [RFC6428] without IP/UDP 204 header being used. 206 3. Use BFD Reverse Path TLV over Segment Routed MPLS Tunnel 208 For BFD over MPLS LSP case, per [RFC5884], egress LER MAY send BFD 209 Control packet to the ingress LER either over IP network or an MPLS 210 LSP. Similarly, for the case of BFD over p2p SR-MPLS tunnel, the 211 egress LER MAY route BFD Control packet over the IP network, as 212 described in [RFC5883], or transmit over a segment tunnel, as 213 described in Section 7 [RFC5884]. In some cases, there may be a need 214 to direct egress LER to use a specific path for the reverse direction 215 of the BFD session by using the BFD Reverse Path TLV and following 216 all procedures as defined in [I-D.ietf-mpls-bfd-directed]. 218 4. Use Non-FEC Path TLV 220 For the case of MPLS data plane, Segment Routing Architecture 221 [RFC8402] explains that "a segment is encoded as an MPLS label. An 222 ordered list of segments is encoded as a stack of labels." 224 This document defines a new optional Non-FEC Path TLV. The format of 225 the Non-FEC Path TLV is presented in Figure 1 227 0 1 2 3 228 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 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Non-FEC Path TLV Type | Length | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | | 233 ~ Non-FEC Path ~ 234 | | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 Figure 1: Non-FEC Path TLV Format 239 Non-FEC Path TLV Type is two octets in length and has a value of TBD1 240 (to be assigned by IANA as requested in Section 9.1). 242 Length field is two octets long and defines the length in octets of 243 the Non-FEC Path field. 245 Non-FEC Path field contains a sub-TLV. Any Non-FEC Path sub-TLV 246 (defined in this document or to be defined in the future) for Non-FEC 247 Path TLV type MAY be used in this field. None or one sub-TLV MAY be 248 included in the Non-FEC Path TLV. If no sub-TLV has been found in 249 the Non-FEC Path TLV, the egress LER MUST revert to using the reverse 250 path selected based on its local policy. If there is more than one 251 sub-TLV, then the Return Code in echo reply MUST be set to value TBD3 252 "Too Many TLVs Detected" (to be assigned by IANA as requested in 253 Table 4). 255 Non-FEC Path TLV MAY be used to specify the reverse path of the BFD 256 session identified in the BFD Discriminator TLV. If the Non-FEC Path 257 TLV is present in the echo request message the BFD Discriminator TLV 258 MUST be present as well. If the BFD Discriminator TLV is absent when 259 the Non-FEC Path TLV is included, then it MUST be treated as 260 malformed Echo Request, as described in [RFC8029]. 262 This document defines the Segment Routing MPLS Tunnel sub-TLV that 263 MAY be used with the Non-FEC Path TLV. The format of the sub-TLV is 264 presented in Figure 2. 266 0 1 2 3 267 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 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | SR MPLS Tunnel sub-TLV Type | Length | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | SID Entry 1 (Top of Stack) | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | SID Entry 2 | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 ~ ~ 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | SID Entry N (Bottom of Stack) | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 Figure 2: Segment Routing MPLS Tunnel sub-TLV 282 The Segment Routing MPLS Tunnel sub-TLV Type is two octets in length, 283 and has a value of TBD2 (to be assigned by IANA as requested in 284 Section 9.1). 286 The egress LER MUST use the Value field as label stack for BFD 287 Control packets for the BFD session identified by the source IP 288 address of the MPLS LSP Ping packet and the value in the BFD 289 Discriminator TLV. Label Entries MUST be in network order. 291 5. BFD Reverse Path TLV over Segment Routed MPLS Tunnel with Dynamic 292 Control Plane 294 When Segment Routed domain with MPLS data plane uses distributed 295 tunnel computation BFD Reverse Path TLV MAY use Target FEC sub-TLVs 296 defined in [RFC8287]. 298 6. Applicability of BFD Demand Mode in SR-MPLS Domain 300 [I-D.mirsky-bfd-mpls-demand] defines how Demand mode of BFD, 301 specified in sections 6.6 and 6.18.4 of [RFC5880], can be used to 302 monitor uni-directional MPLS LSP. Similar procedures can be 303 following in SR-MPLS to monitor uni-directional SR tunnels: 305 o an ingress SR node bootstraps BFD session over SR-MPLS in Async 306 BFD mode; 308 o once BFD session is Up, the ingress SR node switches the egress 309 LER into the Demand mode by setting D field in BFD Control packet 310 it transmits; 312 o if the egress LER detects the failure of the BFD session, it sends 313 its BFD Control packet to the ingress SR node over the IP network 314 with a Poll sequence; 316 o if the ingress SR node receives a BFD Control packet from the 317 remote node in a Demand mode with Poll sequence and Diag field 318 indicating the failure, the ingress SR node transmits BFD Control 319 packet with Final over IP and switches the BFD over SR-MPLS back 320 into Async mode, sending BFD Control packets one per second. 322 7. Using BFD to Monitor Point-to-Multipoint SR Policy 324 [I-D.voyer-spring-sr-p2mp-policy] defined variants of SR Policy to 325 deliver point-to-multipoint (p2mp) services. For the given P2MP 326 segment [RFC8562] can be used if, for example, leaves have an 327 alternative source of the multicast service flow to select. In such 328 a scenario, a leaf may switch to using the alternative flow after 329 p2mp BFD detects the failure in the working multicast path. For 330 scenarios where it is required for the root to monitor the state of 331 the multicast tree [RFC8563] can be used. The root may use the 332 detection of the failure of the multicast tree to the particular leaf 333 to restore the path for that leaf or re-instantiate the whole 334 multicast tree. 336 An essential part of using p2mp BFD is the bootstrapping the BFD 337 session at all the leaves. The root, acting as the MultipointHead, 338 MAY use LSP Ping with the BFD Discriminator TLV. Alternatively, 339 extensions to routing protocols, e.g., BGP, or management plane, 340 e.g., PCEP, MAY be used to associate the particular P2MP segment with 341 MultipointHead's Discriminator. Extensions for routing protocols and 342 management plane are for further study. 344 8. Use of Echo BFD in SR-MPLS 346 Echo-BFD [RFC5880] can be used to monitor an SR Policy between the 347 local and the remote BFD peers. As defined in [RFC5880], the remote 348 BFD system does not process the payload of an Echo BFD. Thus it is 349 the local system that demultiplexes the Echo BFD packet matching it 350 to the appropriate BFD session and detects missing Echo BFD packets. 351 A BFD Control packet MAY be used as the payload of Echo BFD. This 352 specification defines the use of Echo BFD in SR-MPLS network with BFD 353 Control packet as the payload. The use of other types of Echo BFD 354 payload is outside the scope of this document. Because the remote 355 BFD system does not process Echo BFD, the value of the Your 356 Discriminator field MUST be set to the discriminator the local BFD 357 system assigned to the given BFD session. My Discriminator field 358 MUST be zeroed. Authentication MUST be set according to the 359 configuration of the BFD session. To ensure that the Echo BFD packet 360 is returned to the sender without being processed, the sender MAY use 361 a Binding SID (BSID) [RFC8402] that has been bound with the SR Policy 362 that ensures the return of a packet to that particular node. A BSID 363 MAY be associated with the SR Policy that is the reverse to the SR 364 Policy programmed onto the BFD Echo packet by the sender. 366 9. IANA Considerations 368 9.1. Non-FEC Path TLV 370 IANA is requested to assign new TLV type from the from Standards 371 Action range of the registry "Multiprotocol Label Switching 372 Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters - 373 TLVs" as defined in Table 1. 375 +-------+------------------+---------------+ 376 | Value | TLV Name | Reference | 377 +-------+------------------+---------------+ 378 | TBD1 | Non-FEC Path TLV | This document | 379 +-------+------------------+---------------+ 381 Table 1: New Non-FEC Path TLV 383 IANA is requested to create new Non-FEC Path sub-TLV registry for the 384 Non-FEC Path TLV, as described in Table 2. 386 +-------------+---------------+-------------------------------------+ 387 | Range | Registration | Note | 388 | | Procedures | | 389 +-------------+---------------+-------------------------------------+ 390 | 0-16383 | Standards | This range is for mandatory TLVs or | 391 | | Action | for optional TLVs that require an | 392 | | | error message if not recognized. | 393 | 16384-31743 | Specification | Experimental RFC needed | 394 | | Required | | 395 | 32768-49161 | Standards | This range is for optional TLVs | 396 | | Action | that can be silently dropped if not | 397 | | | recognized. | 398 | 49162-64511 | Specification | Experimental RFC needed | 399 | | Required | | 400 | 64512-65535 | Private Use | | 401 +-------------+---------------+-------------------------------------+ 403 Table 2: Non-FEC Path sub-TLV registry 405 IANA is requested to allocate the following values from the Non-FEC 406 Path sub-TLV registry as defined in Table 3. 408 +-------+-------------------------------------+---------------+ 409 | Value | Description | Reference | 410 +-------+-------------------------------------+---------------+ 411 | 0 | Reserved | This document | 412 | TBD2 | Segment Routing MPLS Tunnel sub-TLV | This document | 413 | 65535 | Reserved | This document | 414 +-------+-------------------------------------+---------------+ 416 Table 3: New Segment Routing Tunnel sub-TLV 418 9.2. Return Code 420 IANA is requested to create Non-FEC Path sub-TLV sub-registry for the 421 new Non-FEC Path TLV and assign a new Return Code value from the 422 "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) 423 Ping Parameters" registry, "Return Codes" sub-registry, as follows 424 using a Standards Action value. 426 +--------+-------------------------+---------------+ 427 | Value | Description | Reference | 428 +--------+-------------------------+---------------+ 429 | X TBD3 | Too Many TLVs Detected. | This document | 430 +--------+-------------------------+---------------+ 432 Table 4: New Return Code 434 10. Implementation Status 436 - The organization responsible for the implementation: ZTE 437 Corporation. 439 - The implementation's name ROSng SW empowers traditional routers, 440 e.g., ZXCTN 6000. 442 - A brief general description: A list of SIDs can be specified as the 443 Return Path for an SR-MPLS tunnel. 445 - The implementation's level of maturity: production. 447 - Coverage: complete 449 - Version compatibility: draft-mirsky-spring-bfd-06. 451 - Licensing: proprietary. 453 - Implementation experience: Appreciate Early Allocation of values 454 for Non-FEC TLV and Segment Routing MPLS Tunnel sub-TLV (using 455 Private Use code points). 457 - Contact information: Qian Xin qian.xin2@zte.com.cn 459 - The date when information about this particular implementation was 460 last updated: 12/16/2019 462 Note to RFC Editor: This section MUST be removed before publication 463 of the document. 465 11. Security Considerations 467 Security considerations discussed in [RFC5880], [RFC5884], [RFC7726], 468 and [RFC8029] apply to this document. 470 12. Contributors 472 Xiao Min 473 ZTE Corp. 474 Email: xiao.min2@zte.com.cn 476 13. Acknowledgments 478 Authors greatly appreciate the help of Qian Xin, who provided the 479 information about the implementation of this specification. 481 14. References 483 14.1. Normative References 485 [I-D.ietf-mpls-bfd-directed] 486 Mirsky, G., Tantsura, J., Varlashkin, I., and M. Chen, 487 "Bidirectional Forwarding Detection (BFD) Directed Return 488 Path", draft-ietf-mpls-bfd-directed-13 (work in progress), 489 December 2019. 491 [I-D.mirsky-bfd-mpls-demand] 492 Mirsky, G., "BFD in Demand Mode over Point-to-Point MPLS 493 LSP", draft-mirsky-bfd-mpls-demand-06 (work in progress), 494 December 2019. 496 [I-D.voyer-spring-sr-p2mp-policy] 497 daniel.voyer@bell.ca, d., Filsfils, C., Parekh, R., 498 Bidgoli, H., and Z. Zhang, "SR Replication Policy for P2MP 499 Service Delivery", draft-voyer-spring-sr-p2mp-policy-03 500 (work in progress), July 2019. 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-bess-mvpn-fast-failover] 578 Morin, T., Kebler, R., and G. Mirsky, "Multicast VPN fast 579 upstream failover", draft-ietf-bess-mvpn-fast-failover-10 580 (work in progress), February 2020. 582 [I-D.ietf-pim-bfd-p2mp-use-case] 583 Mirsky, G. and J. Xiaoli, "Bidirectional Forwarding 584 Detection (BFD) for Multi-point Networks and Protocol 585 Independent Multicast - Sparse Mode (PIM-SM) Use Case", 586 draft-ietf-pim-bfd-p2mp-use-case-03 (work in progress), 587 January 2020. 589 [I-D.ietf-spring-mpls-anycast-segments] 590 Sarkar, P., Gredler, H., Filsfils, C., Previdi, S., 591 Decraene, B., and M. Horneffer, "Anycast Segments in MPLS 592 based Segment Routing", draft-ietf-spring-mpls-anycast- 593 segments-02 (work in progress), January 2018. 595 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 596 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 597 RFC 6790, DOI 10.17487/RFC6790, November 2012, 598 . 600 Authors' Addresses 602 Greg Mirsky 603 ZTE Corp. 605 Email: gregimirsky@gmail.com 607 Jeff Tantsura 608 Apstra, Inc. 610 Email: jefftant.ietf@gmail.com 611 Ilya Varlashkin 612 Google 614 Email: Ilya@nobulus.com 616 Mach(Guoyi) Chen 617 Huawei 619 Email: mach.chen@huawei.com 621 Jiang Wenying 622 CMCC 624 Email: jiangwenying@chinamobile.com