idnits 2.17.00 (12 Aug 2021) /tmp/idnits44582/draft-liu-pim-mofrr-tilfa-05.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. == There are 11 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 211 has weird spacing: '... Lb and IP-...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (Mar 4, 2022) is 71 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5384' is defined on line 350, but no explicit reference was found in the text Summary: 1 error (**), 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 China Mobile 3 Intended status: Informational M. McBride 4 Expires: September 4, 2022 Futurewei 5 Z. Zhang 6 ZTE 7 J. Xie 8 Huawei 9 C. Lin 10 New H3C Technologies 11 Mar 4, 2022 13 Multicast-only Fast Reroute Based on Topology Independent Loop-free 14 Alternate Fast Reroute 15 draft-liu-pim-mofrr-tilfa-05 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other documents 29 at any time. It is inappropriate to use Internet-Drafts as 30 reference material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 This Internet-Draft will expire on September 4, 2022. 40 Copyright Notice 42 Copyright (c) 2022 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with 50 respect to this document. Code Components extracted from this 51 document must include Simplified BSD License text as described in 52 Section 4.e of the Trust Legal Provisions and are provided without 53 warranty as described in the Simplified BSD License. 55 Abstract 57 Multicast-only Fast Reroute (MoFRR) has been defined in [RFC7431], 58 but the selection of the secondary multicast next hop only according 59 to the loop-free alternate fast reroute, which has restrictions in 60 multicast deployments. This document describes a mechanism for 61 Multicast-only Fast Reroute by using Topology Independent Loop-free 62 Alternate fast reroute, which is independent of network topology and 63 can achieve covering more network environments. 65 Table of Contents 67 1. Introduction...................................................2 68 1.1. Requirements Language.....................................3 69 1.2. Terminology...............................................3 70 2. Problem Statement..............................................3 71 3. Solution.......................................................4 72 4. IANA Considerations............................................8 73 5. Security Considerations........................................8 74 6. References.....................................................8 75 6.1. Normative References......................................8 76 6.2. Informative References....................................9 77 7. Acknowledgments................................................9 78 Authors' Addresses...............................................10 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). But 89 the selection of the secondary multicast next hop only according to 90 the loop-free alternate fast reroute in [RFC7431], and there are 91 limitations in multicast deployments for this mechanism. This 92 document describes a new mechanism for Multicast-only Fast Reroute 93 using Topology Independent Loop-free Alternate (TILFA) fast reroute, 94 which is independent of network topology and can achieve covering 95 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 for MoFRR is a loop-free alternate (LFA). However, the 115 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 cannot 120 establish a standby multicast tree and cannot implement MoFRR 121 protection. Therefore, the current MoFRR of PIM is only available in 122 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 can look up the corresponding node IP address in the 145 unicast route according to the NodeSID, and the IP addresses of the 146 two endpoints of the corresponding link in the unicast route 147 according to the Adjacency SIDs, but the multicast protocol packets 148 cannot be directly sent along the path of the Segment List. 150 PIM join message need to be sent hop-by-hop to establish a standby 151 multicast tree. However, not all of the nodes and links on the 152 unicast alternate path are included in the Segment List. If the PIM 153 protocol packets are transmitted only in unicast mode, then 154 equivalently the PIM packets are transmitted through the unicast 155 tunnel like unicast traffic, and cannot pass through the 156 intermediate nodes of the tunnel. The intermediate nodes of the 157 alternate path cannot forward multicast traffic because there are no 158 PIM state entries on the nodes. PIM needs to create entries on the 159 device hop-by-hop and generate an incoming interface and an outgoing 160 interface list. So it can form an end-to-end complete multicast tree 161 for forwarding multicast traffic. Therefore, it is not possible to 162 send PIM packets like unicast traffic according to the Segment List 163 path and can only establish a standby multicast tree. 165 3. Solution 167 A secondary Upstream Multicast Hop (UMH) is a candidate next-hop 168 that can be used to reach the root of the tree. In This document 169 the secondary UMH is based on unicast routing to find the Segment 170 List calculated by TILFA. 172 It is available in principle that the path information of the 173 Segment List is added to the PIM packets to guide the hop-by-hop RPF 174 selection. The IP address of the node corresponding to the NodeSID 175 can be used as the segmented root node, and the IP addresses of the 176 interfaces at both endpoints of the link corresponding to the 177 Adjacency SID can be used directly as the local upstream interface 178 and upstream neighbor. 180 For the PIM protocol, the PIM RPF Vector attribute was defined in 181 [RFC5496], which can carry the node IP address corresponding to the 182 NodeSID. The explicit RPF Vector was defined in [RFC7891], which can 183 carry the peer IP address corresponding to the Adjacency SID. 185 This document can use the above two RPF Vector standards and does 186 not need to extend the PIM protocol, to establish the standby 187 multicast tree according to the Segment List calculated by TILFA, 188 and can achieve full coverage of various networking environments for 189 MoFRR protection of multicast services. 191 Assume that the Segment List calculated by TILFA is (NodeSID(A), 192 AdjSID(A-B)). Node A belongs to the P Space, and node B belongs to 193 the Q space. The IP address corresponding to NodeSID(A) can be 194 looked up in the local link state database of the IGP protocol, and 195 can be assumed to be IP-a. The IP addresses of the two endpoints of 196 the link corresponding to AdjSID(A-B) can also be looked up in the 197 local link state database of the IGP protocol, and can be assumed to 198 be IP-La and IP-Lb. 200 In the procedure of PIM, IP-a can be looked as the normal RPF vector 201 attribute and added to the PIM join packet. IP-La can be looked as 202 the local address of the incoming interface, and IP-Lb can be 203 looked as the address of the upstream neighbor. So IP-Lb can be 204 added to the PIM join packet as the explicit RPF Vector attribute. 206 The PIM protocol firstly can select the RPF incoming interface and 207 upstream towards IP-a, and can join hop-by-hop to establish the PIM 208 standby multicast tree until the node A. On the node A, IP-Lb can be 209 looked as the PIM upstream neighbor. The node A can find the 210 incoming interface in the unicast routing table according to the IP- 211 Lb and IP-Lb is used as the RPF upstream address of the PIM join 212 packet to the node B. 214 After the PIM join packet is received on the node B, the PIM 215 protocol can find no more RPF Vector attributes and select the RPF 216 incoming interface and upstream towards the multicast source 217 directly, and then can continue to join hop-by-hop to establish the 218 PIM standby multicast tree until the router directly connected the 219 source. 221 4. Illustration 223 This section provides an illustration of MoFRR based on TI-LFA. The 224 example topology is shown in Figure 1. The metric of R3-R4 link is 225 100, and the metrics of other links are 10. All the link metrics are 226 bidirectional. 228 <-----Priamry Path--- (S,G) Join 230 [S]---(R1)---(R2)******(R6)-------[R] 231 | | 232 <--- | | | 233 | | | | 234 | | (R5) | 235 | | | | 236 | | | | 237 | | | | 238 | (R3)------(R4) | 239 | | 240 --Secondary Path-- 242 Figure 1: Sample Topology 244 The IP addresses and MPLS SIDs, which may be involved in the MoFRR 245 calculation, are configured as following: 247 Node IP Address Node SID 248 R4 4.4.4.4/32 16004 250 Link IP Address Adjacency SID 251 R3->R4 14.0.0.1/24 24001 252 R4->R3 14.0.0.2/24 24002 254 The primary path of the PIM join packet is R6->R2->R1, and the 255 secondary path is R6->R5->R4->R3->R2->R1. However, the traditional 256 LFA does not work properly for the secondary path, because the 257 shortest path to R2 from R5 (or from R4) still goes through R6-R2 258 link. In this case, R6 needs to calculate the secondary UMH using 259 the proposed MoFRR method based on TI-LFA. 261 According to the TI-LFA algorithm, P-Space and Q-Space are shown in 262 Figure 2. The TI-LFA repair path consists of the Node SID of R4 and 263 the Adjacency SID of R4->R3. The repair segment list is (16004, 264 24002). 266 ........ 267 . . 268 [S]---(R1)---(R2)******(R6)---[R] 269 . | . | 270 . | . +++|++++ 271 . | . + | + 272 . | . + (R5) + 273 . | . + | + 274 . | . + | + 275 . | . + | + 276 . (R3)------(R4) + 277 . . + + 278 ........ ++++++++ 279 Q-Space P-Space 281 Figure 2: P-Space and Q-Space 282 In the procedure of PIM, the IP addresses associated with the repair 283 segment list are looked up in the IGP link state database. The Node 284 SID 16004 corresponds to 4.4.4.4, which will be carried in the RPF 285 Vector Attribute. The Adjacency SID 24002 corresponds to local 286 address 14.0.0.2 and remote peer address 14.0.0.1, and 14.0.0.1 will 287 be carried in the Explicit RPF Vector Attribute. Therefore, R6 288 installs the secondary UMH with these RPF Vectors. 290 The forwarding of PIM join packet along the secondary path is shown 291 in Figure 3. 293 +--------+ 294 |Type = 0| 295 |4.4.4.4 | 296 +--------+ +--------+ 297 |Type = 4| |Type = 4| 298 |14.0.0.1| |14.0.0.1| 299 +--------+ +--------+ No RPF Vector 301 R6----->R5---->R4------------>R3----->R2---->R1 303 Figure 3: Forwarding PIM Join Packet along Secondary Path 305 R6 inserts two RPF Vector Attributes in the PIM join packet, which 306 are 4.4.4.4 of Type 0 (RPF Vector Attribute) and 14.0.0.1 of Type 4 307 (Explicit RPF Vector Attribute). Then R6 forwards the packet along 308 the secondary path. 310 When R5 receives the packet, R5 performs a unicast route lookup of 311 the first RPF Vector 4.4.4.4 and sends the packet to R4. 313 R4 is the owner of 4.4.4.4, so it removes the first RPF Vector from 314 the packet and forwards according to the following RPF Vector. R4 315 sends the packet to R3 according to the next RPF Vector 14.0.0.1, 316 since its PIM neighbor R3 corresponds to 14.0.0.1. 318 When R3 receives the packet, as the owner of 14.0.0.1, it removes 319 the RPF Vector. Then the packet has no RPF Vector, and will be 320 forwarded to the source through R3->R2->R1 according to unicast 321 routes. 323 After the PIM join packet reaches R1, a secondary multicast tree, 324 R1->R2->R3->R4->R5->R6, is established hop-by-hop for (S, G) by 325 MoFRR based on TI-LFA. 327 The above procedures can also work in IPv6 data plane. The TI-LFA 328 path computation algorithm in the SRv6 data plane is the same as in 329 the SR-MPLS data plane. Instead of MPLS labels, SRv6 SIDs are used 330 to build repair list. Similarly, the RPF Vector Attributes and the 331 Explicit RPF Vector Attributes will contain IPv6 addresses instead 332 of IPv4 addresses. 334 5. IANA Considerations 336 No IANA actions are required for this document. 338 6. Security Considerations 340 This document does not change the security properties of PIM. For 341 general PIM-SM protocol Security Considerations, see [RFC7761]. 343 7. References 345 7.1. Normative References 347 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 348 Requirement Levels", BCP 14, RFC 2119, March 1997. 350 [RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol 351 Independent Multicast (PIM) Join Attribute Format", 352 RFC 5384, November 2008 354 [RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path 355 Forwarding (RPF) Vector TLV", RFC 5496, March 2009 357 [RFC7431] Karan, A., Filsfils, C., Wijnands, IJ., Ed., and B. 358 Decraene, "Multicast-Only Fast Reroute", RFC 7431, August 359 2015 361 [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. 362 So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", 363 RFC 7490, April 2015 365 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, 366 I.,Parekh, R., Zhang, Z., and L. Zheng, "Protocol 367 IndependentMulticast - Sparse Mode (PIM-SM): Protocol 368 Specification(Revised)", RFC 7761, March 2016 370 [RFC7891] Asghar, J., Wijnands, IJ., Ed., Krishnaswamy, S., Karan, 371 A., and V. Arya, "Explicit Reverse Path Forwarding (RPF) 372 Vector", RFC 7891, June 2016 374 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 375 2119 Key Words", BCP 14, RFC 8174, May 2017 377 [I-D.ietf-rtgwg-segment-routing-ti-lfa] Litkowski, S., Bashandy, A., 378 Filsfils, C., Francois, P., Decraene, B., and D. Voyer, 379 "Topology Independent Fast Reroute using Segment Routing", 380 draft-ietf-rtgwg-segment-routing-ti-lfa-08, work-in- 381 progress, January 2022 383 7.2. Informative References 385 TBD 387 8. Acknowledgments 389 The authors would like to thank the following for their valuable 390 contributions of this document: 392 TBD 394 Authors' Addresses 396 Yisong Liu 397 China Mobile 398 China 399 Email: liuyisong@chinamobile.com 401 Mike McBride 402 Futurewei Inc. 403 USA 404 Email: michael.mcbride@futurewei.com 406 Zheng(Sandy) Zhang 407 ZTE Corporation 408 China 409 Email: zzhang_ietf@hotmail.com 411 Jingrong Xie 412 Huawei Technologies 413 China 414 Email: xiejingrong@huawei.com 416 Changwang Lin 417 New H3C Technologies 418 China 419 Email: linchangwang.04414@h3c.com