idnits 2.17.1 draft-chen-pim-srv6-p2mp-path-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 246 has weird spacing: '...xt-hops sub-...' == Line 269 has weird spacing: '...xt-hops sub-...' -- The document date (April 30, 2022) is 717 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'L1' is mentioned on line 173, but not defined == Missing Reference: 'R' is mentioned on line 181, but not defined == Missing Reference: 'P1' is mentioned on line 181, but not defined == Missing Reference: 'L3' is mentioned on line 181, but not defined == Unused Reference: 'I-D.ietf-6man-segment-routing-header' is defined on line 621, but no explicit reference was found in the text == Unused Reference: 'RFC8200' is defined on line 648, but no explicit reference was found in the text == Unused Reference: 'RFC8754' is defined on line 658, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-sr-replication-segment' is defined on line 677, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-rtgwg-segment-routing-ti-lfa-08 == Outdated reference: A later version (-16) exists of draft-ietf-rtgwg-srv6-egress-protection-05 == Outdated reference: A later version (-08) exists of draft-ietf-pim-sr-p2mp-policy-04 == Outdated reference: A later version (-19) exists of draft-ietf-spring-sr-replication-segment-07 Summary: 0 errors (**), 0 flaws (~~), 15 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Chen 3 Internet-Draft M. McBride 4 Intended status: Experimental Futurewei 5 Expires: November 1, 2022 Y. Fan 6 Casa Systems 7 Z. Li 8 X. Geng 9 Huawei 10 M. Toy 11 G. Mishra 12 Verizon 13 A. Wang 14 China Telecom 15 L. Liu 16 Fujitsu 17 X. Liu 18 Volta Networks 19 April 30, 2022 21 Stateless SRv6 Point-to-Multipoint Path 22 draft-chen-pim-srv6-p2mp-path-06 24 Abstract 26 This document describes a solution for a SRv6 Point-to-Multipoint 27 (P2MP) Path/Tree to deliver the traffic from the ingress of the path 28 to the multiple egresses/leaves of the path in a SR domain. There is 29 no state stored in the core of the network for a SR P2MP path like a 30 SR Point-to-Point (P2P) path in this solution. 32 Requirements Language 34 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 35 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 36 document are to be interpreted as described in [RFC2119] [RFC8174] 37 when, and only when, they appear in all capitals, as shown here. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at https://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on November 1, 2022. 56 Copyright Notice 58 Copyright (c) 2022 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (https://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 2. Overview of P2MP Multicast Tree . . . . . . . . . . . . . . . 3 75 3. Encoding P2MP Multicast Tree . . . . . . . . . . . . . . . . 5 76 4. Procedures/Behaviors . . . . . . . . . . . . . . . . . . . . 8 77 4.1. Procedure/Behavior on Ingress Node . . . . . . . . . . . 8 78 4.2. Procedure/Behavior on Transit Node . . . . . . . . . . . 9 79 4.3. Procedure/Behavior on Egress Node . . . . . . . . . . . . 11 80 5. Stateless SRv6 P2MP Path for Ingress . . . . . . . . . . . . 11 81 6. Protection . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 6.1. Global Protection . . . . . . . . . . . . . . . . . . . . 13 83 6.2. Local Protection . . . . . . . . . . . . . . . . . . . . 13 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 86 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 87 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 88 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 89 10.2. Informative References . . . . . . . . . . . . . . . . . 15 90 Appendix A. Example IPv6 Header using G-SRv6 . . . . . . . . . . 15 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 93 1. Introduction 95 The Segment Routing (SR) for unicast or Point-to-Point (P2P) path is 96 described in [RFC8402]. For SR multicast or Point-to-Multipoint 97 (P2MP) path/tree, it may be implemented through using multiple SR P2P 98 paths. The function of a SR P2MP path/tree from an ingress node to 99 multiple (say n) egress/leaf nodes is implemented by n SR P2P paths. 100 These n P2P paths are from the ingress to those n egress/leaf nodes 101 of the P2MP path/tree. This solution may waste some network 102 resources such as link bandwidth. 104 An alternative solution proposed in 105 [I-D.shen-spring-p2mp-transport-chain] uses a number of P2MP chain 106 tunnels to implement a P2MP path/tree from an ingress to n egress/ 107 leaf nodes. Each P2MP chain tunnel is a tunnel from the ingress to a 108 leaf node as its tail end and may have some leaf nodes as its bud 109 nodes along the tunnel. This alternative solution improves the usage 110 of network resources over the solution above using pure P2P paths. 111 However, these two solutions are based on SR P2P paths. 113 A solution for a SR P2MP path/tree using a P2MP multicast tree is 114 proposed in [I-D.ietf-pim-sr-p2mp-policy]. For a SR P2MP path/tree 115 from an ingress/root to multiple egress/leaf nodes, a multicast P2MP 116 tree is created to deliver the traffic from the ingress/root to the 117 egress/leaf nodes. The state of the tree is instantiated in the 118 forwarding plane by a controller such as PCE at Root node, 119 intermediate Replication nodes and Leaf nodes of the tree. This is 120 not consistent with the SR principles in which no state is stored at 121 the core of the network. 123 This document describes a new solution for a SRv6 Point-to-Multipoint 124 (P2MP) Path/Tree to deliver the traffic from the ingress of the path 125 to the multiple egresses/leaves of the path in a SR domain. This 126 solution uses a P2MP multicast tree without storing its state in the 127 core of the network for a SR P2MP path/tree like a SR P2P path. For 128 distinguishing a SRv6 P2MP path/tree used in the other solutions with 129 storing some states in the core, a new name, called stateless SRv6 130 P2MP path/tree, is used in the solution in this document. Even 131 though SRv6 P2MP path/tree and stateless SRv6 P2MP path/tree are used 132 interchangeably in the document, they both mean stateless SRv6 P2MP 133 path/tree. 135 2. Overview of P2MP Multicast Tree 137 For a SR P2P path from its ingress to its egress, a segment list for 138 the path is provided to the ingress. The ingress pushes the list 139 into a packet, and the packet is delivered to the egress according to 140 the segment list without any state in the core of the network. 142 For a SR P2MP path from its ingress to multiple egress/leaf nodes, a 143 segment list for the P2MP path is provided to the ingress. The 144 ingress pushes the list into a packet, and the packet is delivered to 145 the multiple egress/leaf nodes according to the segment list without 146 any state in the core of the network. 148 Figure 1 shows a SR P2MP path from ingress/root R to four egress/leaf 149 nodes L1, L2, L3 and L4. Nodes P1, P2, P3 and P4 are the transit 150 nodes of the P2MP path. 152 Suppose that X-m is the segment identifier (SID) of node X. X-m is 153 an adjacent SID or node SID. For simplicity, we assume X-m is a node 154 SID in the illustrations below. R-m, P1-m, P2-m, P3-m, P4-m, L1-m, 155 L2-m, L3-m and L4-m are the SIDs of the nodes on the SR P2MP path. 156 They are multicast SIDs or replication SIDs in general. 158 A multicast SID is a SID from a multicast SID block. In a SR domain 159 supporting SR multicast, each node has a multicast node SID, which is 160 globally significant. A multicast SID of a node on a SR P2MP path is 161 associated with the SIDs of its next hop (or say downstream) nodes. 162 When the node receives a packet with its multicast SID, it duplicates 163 and sends the packet to each of its next hop nodes according to their 164 SIDs. 166 If node P on a SR P2MP path has B (B > 1) next hop nodes along the 167 path, the SID of node P, P-m, MUST be a multicast SID when it is in 168 the segment list for the P2MP path. The SIDs of the B next hop nodes 169 just follow P-m in the segment list. When node P receives the packet 170 with P-m as destination address (DA), it duplicates and sends the 171 packet to each of the B next hop nodes along the P2MP path. 173 [L1] R Ingress/Root 174 / Li Egress/Leaf 175 / Pi Transit Node 176 / 177 [P2]------[L2] 178 / 179 / 180 / 181 [R]------[P1] [L3] 182 \ / 183 \ / 184 \ / 185 [P3]------[P4]------[L4] 187 Figure 1: SR P2MP Path from R to L1, L2, L3 and L4 189 is a segment list 190 for the SR P2MP path in Figure 1 to be pushed into a packet at 191 ingress/root R. Node P1 has 2 next hop nodes P2 and P3 along the 192 P2MP path. The next hop nodes' SIDs P2-m and P3-m follow P1-m, which 193 is P1's multicast SID. When P1 receives a packet with DA = P1-m 194 transported by the P2MP path, it duplicates and sends the packet to 195 its next hop nodes P2 and P3 according to P1-m, P2-m and P3-m. 197 The number of branches or next hops from node P1 is a value of one 198 argument in P1-m, called N-Branches. The value of N-Branches in P1-m 199 is 2. With this information, node P1 duplicates and sends the packet 200 to 2 next hop nodes P2 and P3, which are indicated by the 2 SIDs P2-m 201 and P3-m following P1-m. 203 The number of SIDs under node P1 is a value of another argument in 204 P1-m, called N-SIDs. It is the number of the SIDs encoding the sub- 205 trees from P1 and the SIDs following. The sub-trees are encoded by 7 206 SIDs following P1-m in the segment list. The value of N-SIDs in P1-m 207 is 7. 209 Since there are 2 branches or next hops (i.e., L1 and L2) from node 210 P2, the value of N-Branches in P2-m is 2. The two sub-trees from P2 211 are encoded by 2 SIDs (i.e., L1-m and L2-m) and there are 3 SIDs 212 (i.e., P4-m, L3-m, L4-m) following them. The value of N-SIDs in P2-m 213 is 5 (2 + 3). With this information, before sending the packet to 214 node P2, node P1 sets DA to P2-m, SL in SRH to 5 (the N-SIDs in DA = 215 P2-m), and sends the packet to DA (i.e., P2). 217 Since there are 1 branch or next hop (i.e., P4) from node P3, the 218 value of N-Branches in P3-m is 1. The sub-tree from P3 is encoded by 219 3 SIDs (i.e., P4-m, L3-m and L4-m) and no SIDs following them. The 220 value of N-SIDs in P3-m is 3. With this information, before sending 221 the packet to node P3, node P1 sets DA to P3-m, SL in SRH to 3 (the 222 N-SIDs in DA = P3-m), and sends the packet to DA (i.e., P3). 224 Each node on the SR P2MP path sends the packet to its next hop nodes 225 according to the segment list and no state is stored in any transit 226 node (i.e., the core of the network). The packet is delivered to the 227 egress/leaf nodes from the ingress. 229 3. Encoding P2MP Multicast Tree 231 For a sub-tree ST of a SR P2MP path from the ingress node of the P2MP 232 path, suppose that 234 o the multicast SID of the next hop node NH is mSID; 235 o there are B branches (i.e., outgoing interfaces) to the next hop 236 node BNH-j (j = 1, ..., B) from node NH along the sub-tree, the 237 multicast SID of BNH-j is mSID-j; 239 o SidSeq-j (j = 1, ..., B) is the SID sequence in the segment list 240 encoding the sub-trees from node BNH-j. 242 Sub-tree ST is encoded as segment list 244 < mSID, mSID-1, ..., mSID-B, SidSeq-1, ..., SidSeq-B > 245 \___/ \____________________/ \______/ \________/ 246 SIDs of NH B branches/next-hops sub-trees sub-trees 247 BNH-j of node NH from BNH-1 from BNH-B 249 where mSID contains the number of branches in its N-Branches field, 250 which is B, and the number of SIDs in its N-SIDs field, which is the 251 number of the SIDs encoding the sub-trees from NH and the SIDs 252 following (No SID following in this case). The SIDs following mSID 253 encode the sub-trees. The value of N-SIDs field in mSID is B plus 254 the number of the SIDs in SidSeq-1, ..., SidSeq-B. mSID-j (j = 1, 255 ..., B) contains the number of branches in its N-Branches field, 256 which is the number of branches from node BNH-j, and the number of 257 SIDs in its N-SIDs field, which is the number of the SIDs in SidSeq-j 258 to SidSeq-B. 260 For the P2MP path in Figure 1 from ingress node R to egress nodes L1, 261 L2, L3 and L4, there is one sub-tree from R. Suppose that the 262 multicast SIDs of P1, P2, P3, P4, L1, L2, L3 and L4 are P1-m, P2-m, 263 P3-m, P4-m, L1-m, L2-m, L3-m and L4-m respectively. 265 The sub-tree is encoded as segment list 267 < P1-m, P2-m, P3-m, L1-m, L2-m, P4-m, L3-m, L4-m > 268 \__/ \___________/ \________/ \______________/ 269 SIDs of P1 2 branches/next-hops sub-trees sub-tree 270 P2 and P3 of node P1 from P2 from P3 272 where 274 o L1-m, L2-m is the SID sequence (SidSeq-1) in the segment list 275 encoding the sub-trees from P2. 277 o P4-m, L3-m, L4-m is the SID sequence (SidSeq-2) in the segment 278 list encoding the sub-tree from P3. 280 o P1-m's N-Branches field is set to 2 since there are 2 branches 281 from P1 and its N-SIDs field to 7 since there are 7 SIDs following 282 P1-m, which "points" to the sub-tree from P1. 284 o P2-m's N-Branches field is set to 2 since there are 2 branches 285 from P2 and its N-SIDs field to 5 since there are 5 SIDs in 286 SidSeq-1 and SidSeq-2. The N-SIDs = 5 acts as a pointer to the 287 sub-tree from P2. 289 o P3-m's N-Branches field is set to 1 since there is 1 branch from 290 P3 and its N-SIDs field to 3 since there are 3 SIDs in SidSeq-2. 291 The SIDs = 3 acts as a pointer to the sub-tree from P3. 293 o P4-m's N-Branches field is set to 2 and its N-SIDs field to 2. 295 Figure 2 shows in details the segment list, which is an encoding of 296 the sub-tree of the SR P2MP path from R via P1 to L1, L2, L3 and L4. 298 N-Branches N-SIDs 299 +---------------------------+----------+---------+-----------+ 300 1| L4's Multicast SID Locator| 0 | 0 | Arguments | L4-m 301 +---------------------------+----------+---------+-----------+ 302 2| L3's Multicast SID Locator| 0 | 0 | Arguments | L3-m 303 +---------------------------+----------+---------+-----------+ 304 3| P4's Multicast SID Locator| 2 | 2 | Arguments | P4-m 305 +---------------------------+----------+---------+-----------+ 306 4| L2's Multicast SID Locator| 0 | 0 | Arguments | L2-m 307 +---------------------------+----------+---------+-----------+ 308 5| L1's Multicast SID Locator| 0 | 0 | Arguments | L1-m 309 +---------------------------+----------+---------+-----------+ 310 6| P3's Multicast SID Locator| 1 | 3 | Arguments | P3-m 311 +---------------------------+----------+---------+-----------+ 312 7| P2's Multicast SID Locator| 2 | 5 | Arguments | P2-m 313 +---------------------------+----------+---------+-----------+ 314 8| P1's Multicast SID Locator| 2 | 7 | Arguments | P1-m 315 +---------------------------+----------+---------+-----------+ 317 Figure 2: Encoding of sub-tree of path from R via P1 to L1 - L4 319 A bud node is considered as a loopback leaf of itself. The bud node 320 will have one more branch for this loopback leaf. For example, 321 suppose that L4 is a bud node and connected to a leaf L5 (not shown 322 in Figure 1). The N-Branches in L4-m as multicast SID of bud L4 is 2 323 since there are 2 branches from L4: one to L5 and the other to L4 324 itself as a leaf. 326 Figure 3 shows in details the segment list, which is an encoding of 327 the sub-tree of the SR P2MP path from R via P1 to L1, L2, L3, L4 and 328 L5. 330 For L4-m as multicast SID of bud L4, its N-Branches = 2, N-SIDs = 2. 331 The N-SIDs = 2 acts as a pointer to the sub-tree from L4. This sub- 332 tree has 2 branches: one from L4 to L5, and the other from L4 333 (loopback) to L4 itself. 335 The others in Figure 3 are the same as or similar to those in 336 Figure 2. 338 N-Branches N-SIDs 339 +---------------------------+----------+---------+-----------+ 340 1| L4's Multicast SID Locator| 0 | 0 | Arguments | L5-m 341 +---------------------------+----------+---------+-----------+ 342 2| L4's Multicast SID Locator| 0 | 0 | Arguments | L4-m 343 +---------------------------+----------+---------+-----------+ 344 3| L4's Multicast SID Locator| 2 | 2 | Arguments | L4-m 345 +---------------------------+----------+---------+-----------+ 346 4| L3's Multicast SID Locator| 0 | 0 | Arguments | L3-m 347 +---------------------------+----------+---------+-----------+ 348 5| P4's Multicast SID Locator| 2 | 4 | Arguments | P4-m 349 +---------------------------+----------+---------+-----------+ 350 6| L2's Multicast SID Locator| 0 | 0 | Arguments | L2-m 351 +---------------------------+----------+---------+-----------+ 352 7| L1's Multicast SID Locator| 0 | 0 | Arguments | L1-m 353 +---------------------------+----------+---------+-----------+ 354 8| P3's Multicast SID Locator| 1 | 5 | Arguments | P3-m 355 +---------------------------+----------+---------+-----------+ 356 9| P2's Multicast SID Locator| 2 | 7 | Arguments | P2-m 357 +---------------------------+----------+---------+-----------+ 358 | P1's Multicast SID Locator| 2 | 9 | Arguments | P1-m 359 +---------------------------+----------+---------+-----------+ 361 Figure 3: Encoding of sub-tree of path from R via P1 to L1 - L5 363 4. Procedures/Behaviors 365 This section describes the procedures or behaviors on the ingress, 366 transit and egress/leaf node of a SR P2MP path to deliver a packet 367 received from the path to its destinations. 369 4.1. Procedure/Behavior on Ingress Node 371 For a packet to be transported by a SR P2MP Path, the ingress of the 372 P2MP path duplicates the packet for each sub-tree of the SR P2MP path 373 branching from the ingress, pushes the segment list encoding the sub- 374 tree into the packet by executing H.Encaps [RFC8986] and sends the 375 packet to the next hop node along the sub-tree. 377 Regarding to the finite size of the segment list, a sub-tree can be 378 "split" into multiple sub-trees such that each of the sub-trees can 379 be encoded in the segment list of the finite size. 381 For example, there is one sub-tree from the ingress R of the SR P2MP 382 path in Figure 1 via next hop node P1 towards egress/leaf nodes L1, 383 L2, L3 and L4. 385 For this sub-tree, the ingress R duplicates the packet, set the 386 destination address (DA) to P1-m (i.e., multicast SID of node P1), 387 pushes the segment list without P1-m (i.e., ) encoding the sub-tree into a Segment Routing 389 Header (SRH) of the packet by executing H.Encaps and sends the packet 390 to DA (i.e., node P1). The contents of the multicast SIDs P1-m, 391 P2-m, P3-m, L1-m, L2-m, P4-m, L3-m, L4-m are shown in Figure 2. 393 Suppose that the duplicated packet is Pkt0 for the sub-tree. The 394 execution of H.Encaps pushes an IPv6 header (i.e., SRH) to Pkt0 and 395 sets some fields in the header to produce an encapsulated packet 396 Pkt'. Pkt' is represented in the following: 398 Pkt' = (SA=R, DA=P1-m)( L4-m, L3-m,..., P3-m,P2-m; SL=7)Pkt0 399 \________________________/ 400 corresponds to: 402 where DA=P1-m means that the destination address (DA) is set to P1-m; 403 SA=R means that the source address (SA) is set to R; SL=7 means that 404 the number of Segments Left (SL) is 7. 406 4.2. Procedure/Behavior on Transit Node 408 When a transit node of a SR P2MP path receives a packet transported 409 by the P2MP path, the DA of the packet is a multicast SID of the node 410 and the packet contains a segment list for the next hops and the sub- 411 trees of the transit node. The DA and the segment list comprise the 412 information for encoding the sub-trees. 414 For example, when node P1 receives a packet transported by the SR 415 P2MP path in Figure 1, the packet's DA is P1-m (which is a multicast 416 SID of node P1) and the segment list in the packet is . 419 The N-Branches field (which has value of B) of the DA indicates that 420 there are B branches or next hops from the transit node. The N-SIDs 421 field of the DA indicates the number of SIDs for the B sub-trees from 422 the transit node. The multicast SIDs of the B next hop nodes are the 423 first B multicast SIDs of the segment list in the packet. 425 For example, the N-Branches field (which has value of 2) of DA = P1-m 426 indicates that there are 2 branches or next hops from node P1. The 427 N-SIDs field (which has value of 7) of the DA = P1-m indicates that 428 there are 7 SIDs for the 2 sub-trees from node P1. 430 The first multicast SID (P2-m) of the segment list is the SID of the 431 first next hop node (P2); The second multicast SID (P3-m) of the 432 segment list is the SID of the second next hop node (P3). 434 After the multicast SIDs of the next hop nodes, there are B SidSeqs 435 (SIDs sequences) for the B sub-trees. The N-SIDs field (which has 436 value of S1) of the first multicast SID of the next hop nodes 437 indicates that there are S1 SIDs from SidSeq-1 to SidSeq-B; the 438 N-SIDs field (which has value of S2) of the second multicast SID of 439 the next hop nodes indicates that there are S2 SIDs from SidSeq-2 to 440 SidSeq-B; and so on. 442 For example, there are 2 SidSeqs for the 2 sub-trees from node P1 443 after the multicast SIDs P2-m and P3-m of the next hop nodes P2 and 444 P3. The N-SIDs field of P2-m (the first multicast SID of the next 445 hop nodes) has value of 5, indicating that there are 5 SIDs from 446 SidSeq-1 to SidSeq-2. 448 The N-SIDs field of P3-m (the second multicast SID of the next hop 449 nodes) has value of 3, indicating that there are 3 SIDs from SidSeq- 450 2. 452 The transit node duplicates the packet for each next hop under it, 453 sets the DA of the duplicated packet to the multicast SID of the next 454 hop, SL in SRH to the N-SIDs in the DA, and sends the packet to the 455 DA (i.e., the next hop). 457 For example, node P1 duplicates the packet for the first next hop P2, 458 sets DA to P2-m (multicast SID of P2), SL in SRH to 5 (N-SIDs in 459 P2-m), and sends the packet Pkt' to DA (i.e., P2). 461 Pkt' = (SA=R, DA=P2-m)(L4-m,L3-m,P4-m,L2-m,L1-m; SL=5)Pkt0 462 \________________________/ 463 corresponds to: 465 Node P1 duplicates the packet for the second next hop P3, sets DA to 466 P3-m (multicast SID of P3), SL in SRH to 3 (N-SIDs in P3-m), and 467 sends the packet Pkt' to DA (i.e., P3). 469 Pkt' = (SA=R, DA=P3-m)(L4-m,L3-m,P4-m; SL=3)Pkt0 470 \______________/ 471 corresponds to: 473 The behavior of Multicast SID is executed by node N when the DA of 474 the packet received by N is N's Multicast SID. It is a variant of 475 the Endpoint behavior in Section 4.1 of [RFC8986] with the change 476 from S13 - S15 to S13a - S15b below. 478 S13a. Duplicate the packet B times (where B = N-Branches in DA) 479 S13b. FOR (i = 1 to B) { 480 S13c. Set SL of the i-th duplicated packet to N-SIDs in the i-th SID 481 S14a. Set IPv6 DA of the i-th duplicated packet to the i-th SID 482 S15a. Submit the i-th duplicated packet to the egress IPv6 FIB 483 lookup for transmission to the new destination 484 s15b. } 486 This change duplicates the packet for each of B branches or sub-trees 487 from N, sends the duplicated packet to the next hop node along the 488 branch through setting the DA of the duplicated packet to the 489 multicast SID of the next hop node, SL in SRH to the N-SIDs in DA to 490 pop SIDs and have the SIDs sequence encoding the sub-trees from the 491 next hop at the top of the segment list in SRH, and submitting the 492 duplicated packet to the egress IPv6 FIB lookup for transmission to 493 the new destination DA (i.e., the next hop). 495 4.3. Procedure/Behavior on Egress Node 497 When an egress node of a SR P2MP path receives a packet transported 498 by the P2MP path, the DA of the packet is the Multicast SID of the 499 egress node and SL = 0. The egress node proceeds to process the next 500 header in the packet (refer to S03 in Section 4.1 of [RFC8986]). 502 5. Stateless SRv6 P2MP Path for Ingress 504 A controller such as PCE can compute a stateless SRv6 P2MP path and 505 send it to its ingress. For a packet to be transported by the path, 506 the ingress encapsulates the packet with the path and the packet will 507 be delivered to the egresses of the path without any states in the 508 network core. 510 An example architecture using PCE as a controller is illustrated in 511 Figure 4. There is a connection (i.e., PCE session) between the PCE 512 and (the PCC running on) each of the PEs, which are possible ingress 513 nodes in the network domain. Note that some of connections between 514 the PCE and PEs are not shown in the figure. 516 +------------------------------------+ 517 | PCE | 518 +------------------------------------+ 519 / \ 520 / \ 521 / ~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~~\~^~ 522 / _( (P2)---------(P3)-----------(PE2) ) 523 / ( / \_______ / ) 524 / _( / _______)____/ ) 525 / _( / / (_____ ) 526 /_( / / \ ) 527 /( / / \ ) 528 (CE) --- (PE1)--------(P1)-------------(P4)-------------(PE3) ) 529 ( \ \ \ ) 530 ( \ \ \ Network ) 531 ( \ \ \ ) 532 (_ (PE5)------(P5)------------(PE4) ) 533 ( ) 534 '---._.-.-._.-._.-.-._.-._.-.-._.-.-._.-.-._.-.) 536 Figure 4: Architecture using PCE 538 The PCE has the information about the network domain from the IGP or 539 BGP (BGP-LS). The information includes link bandwidth, link colors, 540 node SIDs, and so on. A separate multicast SID could be provisioned 541 on every replication node and the PCE gets the SID on the node from 542 IGP or BGP. 544 The PCE maintains the current status of the network resource usage in 545 its local TED (Traffic Engineering Database), and the status of every 546 stateless SRv6 P2MP path in its local LSP-DB (Label Switch Path 547 Database). 549 Upon receiving a request for a stateless SRv6 P2MP path from a user 550 or application, the PCE computes a path based on the network resource 551 availability stored in the TED. After a path satisfying the given 552 constraints is found, the PCE constructs a stateless SRv6 P2MP path 553 using the multicast SIDs of the nodes on the path and encodes the 554 structure of the P2MP path/tree into the parameters of the SIDs. In 555 fact, the stateless SRv6 P2MP path is a segment list consisting of 556 multicast SIDs with parameter values. 558 And then the PCE sends the segment list representing the path to the 559 ingress node of the path in a PCEP message such as PCInitiate. After 560 receiving the path from the PCE, the ingress node establishes the 561 path by creating a forwarding entry in its FIB. For every multicast 562 packet to be transported by the path, the forwarding entry 563 encapsulates the packet with the segment list and the packet will be 564 delivered to the egress nodes of the path along the path without any 565 state in the core of the network. 567 6. Protection 569 Protections for a SR P2MP path can be classified into two types: 570 global protection and local protection. 572 6.1. Global Protection 574 For a primary SR P2MP path from an ingress node R1 to multiple egress 575 nodes Li (i = 1, ..., n), a backup SR P2MP path from an ingress node 576 R1' to multiple egress nodes Li' (i = 1, ..., n) is set up to provide 577 global protection for the primary SR P2MP path. If R1' is the same 578 as R1, the failure of the ingress node R1 of the primary SR P2MP path 579 is not protected; otherwise (i.e., R1' and R1 are different and 580 connected to the same traffic source), the failure of the ingress 581 node R1 is protected. If Li' is the same as Li (i = 1, ..., n), the 582 failure of the egress nodes Li (i = 1, ..., n) of the primary SR P2MP 583 path is not protected; otherwise (i.e., Li' and Li are different and 584 connected to the same destination), the failure of the egress nodes 585 Li is protected. 587 When a failure happens on the primary SR P2MP path and is detected by 588 the source of the traffic or other entity, the traffic to be 589 transported by the primary SR P2MP path is switched to the backup SR 590 P2MP path, which sends the traffic from its ingress node R1' to its 591 egress nodes Li' (i = 1, ..., n). 593 6.2. Local Protection 595 Local protection or say Fast Reroute (FRR) of a SR P2P path is 596 proposed in [I-D.ietf-rtgwg-segment-routing-ti-lfa] and 597 [I-D.ietf-rtgwg-srv6-egress-protection]. It can be applied to FRR of 598 a SR P2MP path in a similar way. But FRR for SR P2MP path is more 599 complicated. 601 More details will be added later. 603 7. IANA Considerations 605 TBD 607 8. Security Considerations 609 TBD 611 9. Acknowledgements 613 The authors would like to thank Acee Lindem, Jeffrey Zhang, Rishabh 614 Parekh, Arvind Venkateswaran and Daniel Voyer for their valuable 615 comments and suggestions on this draft. 617 10. References 619 10.1. Normative References 621 [I-D.ietf-6man-segment-routing-header] 622 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 623 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 624 (SRH)", draft-ietf-6man-segment-routing-header-26 (work in 625 progress), October 2019. 627 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 628 Litkowski, S., Bashandy, A., Filsfils, C., Francois, P., 629 Decraene, B., and D. Voyer, "Topology Independent Fast 630 Reroute using Segment Routing", draft-ietf-rtgwg-segment- 631 routing-ti-lfa-08 (work in progress), January 2022. 633 [I-D.ietf-rtgwg-srv6-egress-protection] 634 Hu, Z., Chen, H., Chen, H., Wu, P., Toy, M., Cao, C., Liu, 635 L., and X. Liu, "SRv6 Path Egress Protection", draft-ietf- 636 rtgwg-srv6-egress-protection-05 (work in progress), April 637 2022. 639 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 640 Requirement Levels", BCP 14, RFC 2119, 641 DOI 10.17487/RFC2119, March 1997, 642 . 644 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 645 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 646 May 2017, . 648 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 649 (IPv6) Specification", STD 86, RFC 8200, 650 DOI 10.17487/RFC8200, July 2017, 651 . 653 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 654 Decraene, B., Litkowski, S., and R. Shakir, "Segment 655 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 656 July 2018, . 658 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 659 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 660 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 661 . 663 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 664 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 665 (SRv6) Network Programming", RFC 8986, 666 DOI 10.17487/RFC8986, February 2021, 667 . 669 10.2. Informative References 671 [I-D.ietf-pim-sr-p2mp-policy] 672 (editor), D. V., Filsfils, C., Parekh, R., Bidgoli, H., 673 and Z. Zhang, "Segment Routing Point-to-Multipoint 674 Policy", draft-ietf-pim-sr-p2mp-policy-04 (work in 675 progress), March 2022. 677 [I-D.ietf-spring-sr-replication-segment] 678 (editor), D. V., Filsfils, C., Parekh, R., Bidgoli, H., 679 and Z. Zhang, "SR Replication Segment for Multi-point 680 Service Delivery", draft-ietf-spring-sr-replication- 681 segment-07 (work in progress), March 2022. 683 [I-D.shen-spring-p2mp-transport-chain] 684 Shen, Y., Zhang, Z., Parekh, R., Bidgoli, H., and Y. 685 Kamite, "Point-to-Multipoint Transport Using Chain 686 Replication in Segment Routing", draft-shen-spring-p2mp- 687 transport-chain-04 (work in progress), June 2021. 689 Appendix A. Example IPv6 Header using G-SRv6 691 For simplicity, 64 bits for Common Prefix, 16 bits for Node ID, 8 692 bits for the number of branches (N-Branches) and 8 bits for the 693 number of SIDs (N-SIDs) are used when G-SRv6 compression method is 694 applied for at 695 ingress node R in Figure 1. The Destination Address (DA) is 696 illustrated below in Figure 5. It contains the Common Prefix of 64 697 bits, node P1's ID of 16 bits, the value 2 for the number of branches 698 (N-Branches) of 8 bits, and the value 7 for the number of SIDs 699 (N-SIDs) of 8 bits. 701 0 1 2 3 702 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 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 | 2001:db9:0:0 (Common Prefix) | 705 | | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | P1 ID | 2 | 7 | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 Figure 5: Destination Address (DA) 714 The IPv6 header is shown in Figure 6. Ingress node R sends a packet 715 with the IPv6 header to the DA. 717 0 1 2 3 718 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 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | Last Entry | Flags | Tag | 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 | P4 ID | 2 | 2 | 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 | L3 ID | 0 | 0 | 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 | L4 ID | 0 | 0 | 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 | Padding | 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 | P2 ID | 2 | 5 | 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 | P3 ID | 1 | 3 | 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 | L1 ID | 0 | 0 | 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | L2 ID | 0 | 0 | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 Figure 6: IPv6 Header 743 Authors' Addresses 744 Huaimo Chen 745 Futurewei 746 Boston, MA 747 USA 749 Email: Huaimo.chen@futurewei.com 751 Mike McBride 752 Futurewei 754 Email: michael.mcbride@futurewei.com 756 Yanhe Fan 757 Casa Systems 758 USA 760 Email: yfan@casa-systems.com 762 Zhenbin Li 763 Huawei 765 Email: lizhenbin@huawei.com 767 Xuesong Geng 768 Huawei 770 Email: gengxuesong@huawei.com 772 Mehmet Toy 773 Verizon 774 USA 776 Email: mehmet.toy@verizon.com 778 Gyan S. Mishra 779 Verizon 780 13101 Columbia Pike 781 Silver Spring MD 20904 782 USA 784 Phone: 301 502-1347 785 Email: gyan.s.mishra@verizon.com 786 Aijun Wang 787 China Telecom 788 Beiqijia Town, Changping District 789 Beijing 102209 790 China 792 Email: wangaj3@chinatelecom.cn 794 Lei Liu 795 Fujitsu 796 USA 798 Email: liulei.kddi@gmail.com 800 Xufeng Liu 801 Volta Networks 802 McLean, VA 803 USA 805 Email: xufeng.liu.ietf@gmail.com