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