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