idnits 2.17.1 draft-liu-pim-mofrr-tilfa-02.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC7431]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 30, 2020) is 1394 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) == Unused Reference: 'RFC5286' is defined on line 507, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 7431 == Outdated reference: A later version (-13) exists of draft-ietf-rtgwg-segment-routing-ti-lfa-03 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PIM Working Group Yisong Liu 2 Internet Draft China Mobile 3 Intended status: Standards Track M. McBride 4 Expires: Dec 30, 2020 Futurewei 5 Z. Zhang 6 ZTE 7 June 30, 2020 9 Multicast-only Fast Reroute Based on Topology Independent Loop-free 10 Alternate Fast Reroute 11 draft-liu-pim-mofrr-tilfa-02 13 Status of this Memo 15 This Internet-Draft is submitted in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on December 30, 2020. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with 46 respect to this document. Code Components extracted from this 47 document must include Simplified BSD License text as described in 48 Section 4.e of the Trust Legal Provisions and are provided without 49 warranty as described in the Simplified BSD License. 51 Abstract 53 Multicast-only Fast Reroute (MoFRR) has been defined in [RFC7431], 54 but the selection of the secondary multicast next hop only according 55 to the loop-free alternate fast reroute, which has restrictions in 56 multicast deployments. This document describes a mechanism for 57 Multicast-only Fast Reroute by using Topology Independent Loop-free 58 Alternate fast reroute, which is independent of network topology and 59 can achieve covering more network environments. 61 Table of Contents 63 1. Introduction ................................................ 2 64 1.1. Requirements Language .................................. 3 65 1.2. Terminology ............................................ 3 66 2. Problem Statement ........................................... 3 67 3. Solution .................................................... 5 68 3.1. Secondary UMH Selection in PIM ......................... 5 69 3.2. Secondary UMH Selection in MLDP ........................ 6 70 3.3. Extension Protocol Fields Conflict ..................... 6 71 4. Packet Format ............................................... 7 72 4.1. PIM Join Message Extension ............................. 7 73 4.2. MLDP Label Mapping Message Extension ................... 8 74 5. IANA Considerations ........................................ 11 75 6. Security Considerations .................................... 12 76 7. References ................................................. 12 77 7.1. Normative References .................................. 12 78 7.2. Informative References ................................ 13 79 8. Acknowledgments ............................................ 13 80 Authors' Addresses ............................................ 14 82 1. Introduction 84 As the deployment of video services, operators are paying more and 85 more attention to solutions that minimize the service disruption due 86 to faults in the IP network carrying the packets for these services. 87 Multicast-only Fast Reroute (MoFRR) has been defined in [RFC7431], 88 which can minimize multicast packet loss in a network when node or 89 link failures occur by making simple enhancements to multicast 90 routing protocols such as Protocol Independent Multicast (PIM) and 91 Multipoint LDP (mLDP). But the selection of the secondary multicast 92 next hop only according to the loop-free alternate fast reroute in 94 [RFC7431], and there are limitations in multicast deployments for 95 this mechanism. This document describes a new mechanism for 96 Multicast-only Fast Reroute using Topology Independent Loop-free 97 Alternate (TILFA) fast reroute, which is independent of network 98 topology and can achieve covering more network environments. 100 1.1. Requirements Language 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 104 "OPTIONAL" in this document are to be interpreted as described in 105 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 106 capitals, as shown here. 108 1.2. Terminology 110 This document use the terms defined in [RFC7431], and also use the 111 concepts defined in [RFC7490]. The specific content of each term is 112 not described in this document. 114 2. Problem Statement 116 In [RFC7431] section 3, the secondary Upstream Multicast Hop (UMH) 117 of PIM and mLDP for MoFRR is a loop-free alternate (LFA). However, 118 the traditional LFA mechanism needs to satisfy at least one neighbor 119 whose next hop to the destination node is an acyclic next hop, 120 existing limitations in network deployments, and can only cover part 121 of the network topology environments. In some network topology, the 122 corresponding secondary UMH cannot be calculated, so PIM and MLDP 123 cannot establish a standby multicast tree and cannot implement MoFRR 124 protection. Therefore, the current MoFRR of PIM and MLDP is only 125 available in the network topology applicable to LFA. 127 The remote loop-free alternate (RLFA) defined in [RFC7490] is 128 extended from the LFA and can cover more network deployment 129 scenarios through the tunnel as an alternate path. The RLFA 130 mechanism needs to satisfy at least one node assumed to be N in the 131 network that the fault node is neither on the path from the source 132 node to the N node, nor on the path from the N node to the 133 destination node. RLFA only has enhancement compared to LFA but 134 still has limitations in network deployments. 136 [I-D.ietf-rtgwg-segment-routing-ti-lfa] defined a unicast FRR 137 solution based on the TILFA mechanism. The TILFA mechanism can 138 express the backup path with an explicit path, and has no constraint 139 on the topology, providing a more reliable FRR mechanism. The 140 unicast traffic can be forwarded according to the explicit path list 141 as an alternate path to implement unicast traffic protection, and 142 can achieve full coverage of various networking environments. 144 The alternate path provided by the TILFA mechanism is actually a 145 Segment List, including one or more Adjacency SIDs of one or more 146 links between the P space and the Q space, and the NodeSID of P 147 space node. PIM and MLDP can look up the corresponding node IP 148 address in the unicast route according to the NodeSID, and the IP 149 addresses of the two endpoints of the corresponding link in the 150 unicast route according to the Adjacency SIDs, but the multicast 151 protocol packets cannot be directly sent along the path of the 152 Segment List. 154 Both the PIM join message and the MLDP Label Mapping message need to 155 be sent hop-by-hop to establish a standby multicast tree. However, 156 not all of the nodes and links on the unicast alternate path are 157 included in the Segment List. If the PIM and MLDP protocol packets 158 are transmitted only in unicast mode, then equivalently the PIM and 159 MLDP packets are transmitted through the unicast tunnel like unicast 160 traffic, and cannot pass through the intermediate nodes of the 161 tunnel. The intermediate nodes of the alternate path cannot forward 162 multicast traffic because there are no PIM or MLDP state entries on 163 the nodes. PIM needs to create entries on the device hop-by-hop and 164 generate an incoming interface and an outgoing interface list. MLDP 165 needs to create entries on the device hop-by-hop and generate an 166 incoming label and an outgoing label list. So it can form an end-to- 167 end complete multicast tree for forwarding multicast traffic. 168 Therefore, it is not possible to send PIM and MLDP packets like 169 unicast traffic according to the Segment List path and establish a 170 standby multicast tree. 172 It is available in principle that the path information of the 173 Segment List is added to the PIM and MLDP packets to guide the hop- 174 by-hop RPF selection. The IP address of the node corresponding to 175 the NodeSID can be used as the segmented root node, and the IP 176 addresses of the interfaces at both endpoints of the link 177 corresponding to the Adjacency SID can be used directly as the local 178 upstream interface and upstream neighbor, but there is currently no 179 field in protocol packet to carry the explicit path specified by the 180 Segment List. For the PIM protocol, the PIM RPF Vector attribute was 181 defined in [RFC5496], which can carry the node IP address 182 corresponding to the NodeSID. The Explicit RPF Vector was defined in 183 [RFC7891], which can carry the peer IP address corresponding to the 184 Adjacency SID, but if there are multiple same peer IP addresses 185 corresponding to the Adjacency SID (i.e. anycast IP address), the 186 upstream neighbor of RPF selection may be different from the actual 187 upstream link corresponding to the Adjacency SID, which can make the 188 PIM join path and the TILFA calculation path inconsistent. For the 189 MLDP protocol, there is also no field defined in the MLDP protocol 190 Label Mapping message that can carry the explicit path of the 191 Segment List. 193 3. Solution 195 An Upstream Multicast Hop (UMH) is a candidate next-hop that can be 196 used to reach the root of the tree. In This document the secondary 197 UMH is based on unicast routing to find Segment List calculated by 198 TILFA. With MoFRR, The procedures for determining the secondary UMH 199 and establishing standby multicast tree are different for PIM and 200 mLDP. 202 This document extends the PIM and mLDP protocol, to establish the 203 standby multicast tree according to the Segment List calculated by 204 TILFA, and can achieve full coverage of various networking 205 environments for MoFRR protection of multicast services. 207 Assume that the Segment List calculated by TILFA is (NodeSID(A), 208 AdjSID(A-B)). Node A belongs to the P Space, and node B belongs to 209 the Q space. The IP address corresponding to NodeSID(A) can be 210 looked up in the local link state database of the IGP protocol, and 211 can be assumed to be IP-a. The IP addresses of the two endpoints of 212 the link corresponding to AdjSID(A-B) can also be looked up in the 213 local link state database of the IGP protocol, and can be assumed to 214 be IP-La and IP-Lb. 216 3.1. Secondary UMH Selection in PIM 218 In the procedure of PIM, IP-a can be looked as the normal RPF vector 219 attribute and added to the PIM join packet. IP-La and IP-Lb can be 220 looked as the RPF Vector attribute of the adjacency relationship, 221 called Adjacency RPF Vector, which is a new type of PIM join 222 attributes, and added to the PIM join packet too. 224 The PIM protocol firstly can select the RPF incoming interface and 225 upstream towards IP-a, and can join hop-by-hop to establish the PIM 226 standby multicast tree until the node A. On the node A, IP-Lb can be 227 looked as one PIM neighbor. If there are multiple PIM neighbors with 228 the same address IP-Lb, all of the corresponding local interfaces on 229 the node A need to be checked. The interface that is the only one 230 with the IP address IP-La can be looked as the RPF incoming 231 interface. The node A can send the PIM join packet to the node B on 232 the interface of IP-La, and IP-Lb is used as the RPF upstream 233 address of the PIM join. 235 After the PIM join packet is received on the node B, the PIM 236 protocol can find no more join attributes and select the RPF 237 incoming interface and upstream towards the multicast source 238 directly, and then can continue to join hop-by-hop to establish the 239 PIM standby multicast tree until the router directly connected the 240 source. 242 3.2. Secondary UMH Selection in MLDP 244 In the procedure of MLDP, Explicit path TLV is newly defined in MLDP 245 Label Mapping message to carry IP-a, IP-La and IP-Lb, which is 246 contained in the field of Optional Parameters. IP-a can be looked as 247 the segmented root node address and is added as the Node Address Sub 248 TLV in the Explicit path TLV. IP-La and IP-Lb are added as the 249 Adjacency Address Sub TLV in the Explicit Path TLV. 251 The MLDP protocol can look up the upstream interface and the 252 upstream LSR in the unicast route to IP-a, and can send the Label 253 Mapping message hop-by-hop to establish the standby MPLS multicast 254 tree to the node A. After the message is received on the node A, the 255 Node Address Sub TLV corresponding to the IP-a can be deleted from 256 the Label Mapping message. 258 On the node A IP-Lb can be looked as one MLDP neighbor. If there are 259 multiple MLDP neighbors with the same address IP-Lb, all of the 260 corresponding local interfaces on the node A need to be checked. The 261 interface that is the only one with the IP address IP-La can be 262 looked as the upstream interface. The node A can send MLDP Label 263 mapping message to the node B, and IP-Lb is used as the upstream LSR 264 address. 266 After the message is received on the node B, the Adjacency Address 267 Sub TLV corresponding to the IP-La and IP-Lb is deleted from the 268 Label Mapping message and if there is no more any sub TLV in the 269 Explicit Path TLV then the TLV should be deleted. The MLDP protocol 270 can select the upstream interface and the upstream LSR in the 271 unicast route to the original root node directly, and can continue 272 to send the Label Mapping message to establish the standby MPLS 273 multicast tree to the original root node. 275 3.3. Extension Protocol Fields Conflict 277 PIM Adjacency RPF Vector attribute is newly defined in join 278 attributes. If there are conflicts from multiple downstream PIM 279 neighbors, the mechanism in [RFC5384] Section 3.3.3 can be used to 280 select a PIM downstream neighbor with a numerically smallest IP 281 address. If at least two neighbors have the same IP address, the 282 interface index MUST be used as a tie breaker. 284 In the Explicit Path TLV newly defined in MLDP Label Mapping 285 message, if there are conflicts from multiple downstream MLDP 286 neighbors, including the inconsistency of the Sub TLV types, and the 287 inconsistency of the Sub TLV contents, and the inconsistency of the 288 Sub TLV sequences, it is also recommended to use the mechanism in 289 [RFC5384] Section 3.3.3. 291 4. Packet Format 293 This section describes the format of PIM and mLDP protocol packet 294 extension introduced by this document. 296 4.1. PIM Join Message Extension 298 0 1 2 3 299 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 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Addr Family | Encoding Type | Rsrvd |S|W|R| Mask Len | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Source Address 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+..... 305 |F|E| Attr_Type | Length | Value 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+..... 307 |F|E| Attr_Type | Length | Value 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+..... 309 . . . 310 . . . 312 The original PIM join attribute already has been defined in 313 [RFC5384] 315 Attr_Type: 317 0- Vector ; 319 4- Explicit RPF Vector ; 321 Other existing definitions are not related to RPF Vector Attribute. 323 0 1 2 3 324 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 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 |F|E| Type | Length | Value 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-....... 329 The definition of Adjacency RPF Vector attribute 331 F bit: 0, indicating that the unrecognized device does not forward 332 the attribute 334 E bit: indicates the last join attribute 336 Type: TBD 338 Length: depends on the address family of Encoded-Unicast address, 339 including the length of 2 addresses. 341 Value: Encoded-Unicast Address format defined in [RFC7761] Section 342 4.9.1, including 2 addresses. The first one indicates the address of 343 the local interface, and the second one indicates the address of the 344 peer interface. Only the case of the same address family is 345 supported. 347 4.2. MLDP Label Mapping Message Extension 349 0 1 2 3 350 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 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 |0| Label Mapping (0x0400) | Message Length | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | Message ID | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | FEC TLV | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Label TLV | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Optional Parameters | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 The LDP Label Mapping message format is defined in [RFC5036] Section 364 3.5.7. The MLDP P2MP protocol uses the message to establish a P2MP 365 multicast tree. The Optional Parameters field can be extended to 366 carry the node or link IP address list specified by the Segment 367 List. 369 0 1 2 3 370 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 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 |U|F| Type | Length | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | | 375 | Value | 376 ~ ~ 377 | | 378 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 The TLV format definition in [RFC5036] Section 3.3 can be used for 383 the Explicit Path TLV carrying the specified path of the Segment 384 List. 386 0 1 2 3 387 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 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 |1|0| TBD1 | Length | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | | 392 | Node Address Sub TLV | 393 | Adjacency Address Sub TLV | 394 ~ ~ 395 | | 396 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 The definition of Explicit Path TLV: 402 U bit: Unknown TLV bit. 1 indicates the unknown TLV MUST be silently 403 ignored and the rest of the message processed as if the unknown TLV 404 did not exist. 406 F bit: Forward unknown TLV bit. 0 indicates the unknown TLV is not 407 forwarded with the containing message. 409 Type: TBD1 411 Length: contains all Sub-TLV lengths 413 Value: Contains one or more Sub-TLVs, which are recorded in the 414 order of TILFA's Segment List. There are two types of Sub TLVs now. 415 One of the two types is called Node Address Sub TLV which carries 416 the node IP address corresponding to the NodeSID, and the other is 417 called Adjacency Address Sub TLV which carries the local interface 418 address and the peer interface address corresponding to the 419 Adjacency SID. 421 0 1 2 3 422 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 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 |1|0|E| Type = TBD2 | Length | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | | 427 | Node Address | 428 ~ ~ 429 | | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 Node Address Sub TLV carrying the node IP address corresponding to 433 the NodeSID 435 U bit: 1 indicates the unknown TLV MUST be silently ignored and the 436 rest of the message processed as if the unknown TLV did not exist. 437 F bit: 0 indicates the unknown TLV is not forwarded with the 438 containing message. 440 E bit: 1 indicates the last Sub TLV. 442 Type: TBD2 444 Length: IPv4 address 4 octet, IPv6 address 16 octet 445 Value: The IP address of the node corresponding to the NodeSID in 446 the Segment List generated by TILFA 448 0 1 2 3 449 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 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 |1|0|E| Type = TBD3 | Length | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | | 454 | Local Interface Address | 455 | Remote Interface Address | 456 ~ ~ 457 | | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 Adjacency Address Sub TLV carrying the local interface address and 461 the peer interface address corresponding to the Adjacency SID 463 U bit: 1 indicates the unknown TLV MUST be silently ignored and the 464 rest of the message processed as if the unknown TLV did not exist. 465 F bit: 0 indicates the unknown TLV is not forwarded with the 466 containing message. 468 E bit: 1 indicates the last Sub TLV. 470 Type: TBD3 472 Length: IPv4 address 8 octet, IPv6 address 32 octet 474 Value: The IP address of the local interface and the IP address of 475 the peer interface corresponding to the Adjacency SID in the Segment 476 List generated by TILFA must be recorded in order, and MUST be the 477 same address family. 479 5. IANA Considerations 481 This document requests IANA to assign a registry for Adjacency RPF 482 Vector in PIM Join Attribute and the Explicit Path TLV Node Address 483 Sub TLV, Adjacency Address Sub TLV in the Optional Parameters field 484 of MLDP P2MP Label Mapping message. The assignment is requested 485 permanent for IANA when this document is published as an RFC. The 486 string TBD, TBD1, TBD2 and TBD3 should all be replaced by the 487 assigned values accordingly. 489 6. Security Considerations 491 For general PIM-SM protocol Security Considerations, see [RFC7761]. 493 For general MLDP protocol Security Considerations, see [RFC6388] 495 TBD 497 7. References 499 7.1. Normative References 501 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 502 Requirement Levels", BCP 14, RFC 2119, March 1997. 504 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 505 "LDP Specification", RFC 5036, October 2007 507 [RFC5286] Atlas, A., Ed., and A. Zinin, Ed., "Basic Specification 508 for IP Fast Reroute: Loop-Free Alternates", RFC 5286, 509 September 2008 511 [RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol 512 Independent Multicast (PIM) Join Attribute Format", 513 RFC 5384, November 2008 515 [RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path 516 Forwarding (RPF) Vector TLV", RFC 5496, March 2009 518 [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. 519 Thomas, "Label Distribution Protocol Extensions for Point- 520 to-Multipoint and Multipoint-to-Multipoint Label Switched 521 Paths", RFC 6388, November 2011 523 [RFC7431] Karan, A., Filsfils, C., Wijnands, IJ., Ed., and B. 524 Decraene, "Multicast-Only Fast Reroute", RFC 7431, August 525 2015 527 [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. 528 So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", 529 RFC 7490, April 2015 531 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, 532 I.,Parekh, R., Zhang, Z., and L. Zheng, "Protocol 533 IndependentMulticast - Sparse Mode (PIM-SM): Protocol 534 Specification(Revised)", RFC 7761, March 2016 536 [RFC7891] Asghar, J., Wijnands, IJ., Ed., Krishnaswamy, S., Karan, 537 A., and V. Arya, "Explicit Reverse Path Forwarding (RPF) 538 Vector", RFC 7891, June 2016 540 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 541 2119 Key Words", BCP 14, RFC 8174, May 2017 543 [I-D.ietf-rtgwg-segment-routing-ti-lfa] Litkowski, S., Bashandy, A., 544 Filsfils, C., Decraene, B., Francois, P., Voyer, D., Clad, 545 F., and P. Camarillo, "Topology Independent Fast Reroute 546 using Segment Routing", draft-ietf-rtgwg-segment-routing- 547 ti-lfa-03, work-in-progress, March 2020 549 7.2. Informative References 551 TBD 553 8. Acknowledgments 555 The authors would like to thank the following for their valuable 556 contributions of this document: 558 TBD 560 Authors' Addresses 562 Yisong Liu 563 China Mobile 564 China 565 Email: liuyisong@chinamobile.com 567 Mike McBride 568 Futurewei Inc. 569 USA 570 Email: michael.mcbride@futurewei.com 572 Zheng(Sandy) Zhang 573 ZTE Corporation 574 China 575 Email: zzhang_ietf@hotmail.com