idnits 2.17.1 draft-chen-pim-srv6-p2mp-path-03.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 : ---------------------------------------------------------------------------- ** There are 8 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 244 has weird spacing: '...xt-hops sub-...' == Line 273 has weird spacing: '...xt-hops sub-...' -- The document date (July 11, 2021) is 1020 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'L1' is mentioned on line 171, but not defined == Missing Reference: 'R' is mentioned on line 179, but not defined == Missing Reference: 'P1' is mentioned on line 179, but not defined == Missing Reference: 'L3' is mentioned on line 179, but not defined == Unused Reference: 'I-D.ietf-6man-segment-routing-header' is defined on line 570, but no explicit reference was found in the text == Unused Reference: 'RFC8200' is defined on line 599, but no explicit reference was found in the text == Unused Reference: 'RFC8754' is defined on line 609, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-sr-replication-segment' is defined on line 622, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-rtgwg-segment-routing-ti-lfa-06 == Outdated reference: A later version (-16) exists of draft-ietf-rtgwg-srv6-egress-protection-02 == Outdated reference: A later version (-08) exists of draft-ietf-pim-sr-p2mp-policy-02 == Outdated reference: A later version (-19) exists of draft-ietf-spring-sr-replication-segment-04 == Outdated reference: A later version (-04) exists of draft-shen-spring-p2mp-transport-chain-03 Summary: 1 error (**), 0 flaws (~~), 16 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: January 12, 2022 Y. Fan 6 Casa Systems 7 X. Geng 8 Huawei 9 M. Toy 10 Verizon 11 A. Wang 12 China Telecom 13 L. Liu 14 Fujitsu 15 X. Liu 16 Volta Networks 17 July 11, 2021 19 Stateless SRv6 Point-to-Multipoint Path 20 draft-chen-pim-srv6-p2mp-path-03 22 Abstract 24 This document describes a solution for a SRv6 Point-to-Multipoint 25 (P2MP) Path/Tree to deliver the traffic from the ingress of the path 26 to the multiple egresses/leaves of the path in a SR domain. There is 27 no state stored in the core of the network for a SR P2MP path like a 28 SR Point-to-Point (P2P) path in this solution. 30 Requirements Language 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 34 document are to be interpreted as described in RFC 2119 [RFC2119]. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on January 12, 2022. 53 Copyright Notice 55 Copyright (c) 2021 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 71 2. Overview of P2MP Multicast Tree . . . . . . . . . . . . . . . 3 72 3. Encoding P2MP Multicast Tree . . . . . . . . . . . . . . . . 5 73 4. Procedures/Behaviors . . . . . . . . . . . . . . . . . . . . 7 74 4.1. Procedure/Behavior on Ingress Node . . . . . . . . . . . 7 75 4.2. Procedure/Behavior on Transit Node . . . . . . . . . . . 8 76 4.3. Procedure/Behavior on Egress Node . . . . . . . . . . . . 10 77 5. Stateless SRv6 P2MP Path for Ingress . . . . . . . . . . . . 10 78 6. Protection . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 6.1. Global Protection . . . . . . . . . . . . . . . . . . . . 12 80 6.2. Local Protection . . . . . . . . . . . . . . . . . . . . 12 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 82 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 83 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 85 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 86 10.2. Informative References . . . . . . . . . . . . . . . . . 14 87 Appendix A. Example IPv6 Header using G-SRv6 . . . . . . . . . . 14 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 90 1. Introduction 92 The Segment Routing (SR) for unicast or Point-to-Point (P2P) path is 93 described in [RFC8402]. For SR multicast or Point-to-Multipoint 94 (P2MP) path/tree, it may be implemented through using multiple SR P2P 95 paths. The function of a SR P2MP path/tree from an ingress node to 96 multiple (say n) egress/leaf nodes is implemented by n SR P2P paths. 97 These n P2P paths are from the ingress to those n egress/leaf nodes 98 of the P2MP path/tree. This solution may waste some network 99 resources such as link bandwidth. 101 An alternative solution proposed in 102 [I-D.shen-spring-p2mp-transport-chain] uses a number of P2MP chain 103 tunnels to implement a P2MP path/tree from an ingress to n egress/ 104 leaf nodes. Each P2MP chain tunnel is a tunnel from the ingress to a 105 leaf node as its tail end and may have some leaf nodes as its bud 106 nodes along the tunnel. This alternative solution improves the usage 107 of network resources over the solution above using pure P2P paths. 108 However, these two solutions are based on SR P2P paths. 110 A solution for a SR P2MP path/tree using a P2MP multicast tree is 111 proposed in [I-D.ietf-pim-sr-p2mp-policy]. For a SR P2MP path/tree 112 from an ingress/root to multiple egress/leaf nodes, a multicast P2MP 113 tree is created to deliver the traffic from the ingress/root to the 114 egress/leaf nodes. The state of the tree is instantiated in the 115 forwarding plane by a controller such as PCE at Root node, 116 intermediate Replication nodes and Leaf nodes of the tree. This is 117 not consistent with the SR principles in which no state is stored at 118 the core of the network. 120 This document describes a new solution for a SRv6 Point-to-Multipoint 121 (P2MP) Path/Tree to deliver the traffic from the ingress of the path 122 to the multiple egresses/leaves of the path in a SR domain. This 123 solution uses a P2MP multicast tree without storing its state in the 124 core of the network for a SR P2MP path/tree like a SR P2P path. For 125 distinguishing a SRv6 P2MP path/tree used in the other solutions with 126 storing some states in the core, a new name, called stateless SRv6 127 P2MP path/tree, is used in the solution in this document. Even 128 though SRv6 P2MP path/tree and stateless SRv6 P2MP path/tree are used 129 interchangably in the document, they both mean stateless SRv6 P2MP 130 path/tree. 132 2. Overview of P2MP Multicast Tree 134 For a SR P2P path from its ingress to its egress, a segment list for 135 the path is provided to the ingress. The ingress pushes the list 136 into a packet, and the packet is delivered to the egress according to 137 the segment list without any state in the core of the network. 139 For a SR P2MP path from its ingress to multiple egress/leaf nodes, a 140 segment list for the P2MP path is provided to the ingress. The 141 ingress pushes the list into a packet, and the packet is delivered to 142 the multiple egress/leaf nodes according to the segment list without 143 any state in the core of the network. 145 Figure 1 shows a SR P2MP path from ingress/root R to four egress/leaf 146 nodes L1, L2, L3 and L4. Nodes P1, P2, P3 and P4 are the transit 147 nodes of the P2MP path. 149 Suppose that X-m is the segment identifier (SID) of node X. X-m is 150 an adjacent SID or node SID. For simplicity, we assume X-m is a node 151 SID in the illustrations below. R-m, P1-m, P2-m, P3-m, P4-m, L1-m, 152 L2-m, L3-m and L4-m are the SIDs of the nodes on the SR P2MP path. 153 They are multicast SIDs or replication SIDs in general. 155 A multicast SID is a SID from a multicast SID block. In a SR domain 156 supporting SR multicast, each node has a multicast node SID, which is 157 globally significant; each adjacency of a node has a multicast 158 adjacency SID, which is locally significant. A multicast SID of a 159 node on a SR P2MP path is associated with the SIDs of the next hop 160 (or say downstream) nodes. When the node receives a packet with its 161 multicast SID, it duplicates and sends the packet to each of the next 162 hop nodes according to their SIDs. 164 If node P on a SR P2MP path has B (B > 1) next hop nodes along the 165 path, the SID of node P, P-m, MUST be a multicast SID when it is in 166 the segment list for the P2MP path. The SIDs of the B next hop nodes 167 just follow P-m in the segment list. When node P receives the packet 168 with P-m, it duplicates and sends the packet to each of the B next 169 hop nodes along the P2MP path. 171 [L1] R Ingress/Root 172 / Li Egress/Leaf 173 / Pi Transit Node 174 / 175 [P2]------[L2] 176 / 177 / 178 / 179 [R]------[P1] [L3] 180 \ / 181 \ / 182 \ / 183 [P3]------[P4]------[L4] 185 Figure 1: SR P2MP Path from R to L1, L2, L3 and L4 187 is a segment list 188 for the SR P2MP path in Figure 1 to be pushed into a packet at 189 ingress/root R. Node P1 has 2 next hop nodes P2 and P3 along the 190 P2MP path. The next hop nodes' SIDs P2-m and P3-m follow P1-m, which 191 is P1's multicast SID. When P1 receives a packet transported by the 192 P2MP path, it duplicates and sends the packet to the next hop nodes 193 P2 and P3 according to P1-m, P2-m and P3-m. 195 The number of branches or next hops from node P1 is a value of one 196 argument in P1-m, called N-Branches. The value of N-Branches in P1-m 197 is 2. With this information, node P1 duplicates and sends the packet 198 to 2 next hop nodes P2 and P3, which are indicated by the 2 SIDs P2-m 199 and P3-m following P1-m. 201 The number of SIDs of the nodes under node P1 is a value of another 202 argument in P1-m, called N-SIDs. The value of N-SIDs in P1-m is 7, 203 indicating that there are 7 SIDs following P1-m in the segment list. 205 There are 2 branches or next hops (i.e., L1 and L2) from node P2 and 206 2 SIDs (i.e., L1-m and L2-m) of the nodes under node P2. The values 207 of N-Branches and N-SIDs in P2-m are 2 and 2. with this information, 208 before sending the packet to node P2, node P1 pushes the SIDs under 209 node P2 into the packet (i.e., the packet has a new segment list with 210 the SIDs under node P2. The new segment list replaces the old one in 211 the packet). 213 There are 1 branch or next hop (i.e., P4) from node P3 and 3 SIDs 214 (i.e., P4-m, L3-m and L4-m) of the nodes under node P3. The values 215 of N-Branches and N-SIDs in P3-m are 1 and 3 respectively. with this 216 information, before sending the packet to node P3, node P1 pushes the 217 SIDs under node P3 into the packet. 219 Each node on the SR P2MP path sends the packet to its next hop nodes 220 according to the segment list and no state is stored in any transit 221 node (i.e., the core of the network). The packet is delivered to the 222 egress/leaf nodes from the ingress. 224 3. Encoding P2MP Multicast Tree 226 For each sub-tree STi of a SR P2MP path from the ingress node of the 227 P2MP path, suppose that 229 o the multicast SID of the next hop node NHi is mSIDi; 231 o there are Bi branches (i.e., outgoing interfaces) to the next hop 232 node BNHj (j = 1, ..., Bi) from node NHi along the sub-tree, the 233 multicast SID of BNHj is mSIDij; 235 o the number of branches (i.e., outgoing interfaces) under the node 236 BNHj (j = 1, ..., Bi) is BBj; and the number of SIDs of the nodes 237 under each of the Bi branches from node BNHj is NSj (j = 1, ..., 238 Bi). 240 Sub-tree STi is encoded as segment list 242 < mSIDi, mSIDi1, ..., mSIDiBi, SegSeq1, ..., SegSeqBi >, 243 \___/ \____________________/ \______/ \________/ 244 SIDs of NHi Bi branches/next-hops sub-tree sub-tree 245 BNHj of node NHi from BNH1 from BNHBi 247 where mSIDi contains the number of branches, Bi, in its N-Branches 248 field, and the number of SIDs under mSIDi in its N-SIDs field; mSIDij 249 (j = 1, ..., Bi) contains the number of branches, BBj, in its 250 N-Branches field and the number of SIDs, NSj, in its N-SIDs field; 251 SegSeqj (j = 1, ..., Bi) is the SID sequence in the segment list 252 encoding the sub-trees from node BNHj. 254 For the P2MP path in Figure 1 from ingress node R to egress nodes L1, 255 L2, L3 and L4, there is one sub-tree from R. 257 For this sub-tree, 259 o the next hop node is P1 and the multicast SID of P1 is P1-m; 261 o there are 2 branches to the next hop nodes P2 and P3 from node P1 262 along the sub-tree; the number of SIDs of the nodes under P1 is 7; 263 the multicast SIDs of P2 and P3 are P2-m and P3-m respectively; 265 o the numbers of SIDs of the nodes under these two branches are 2 266 and 3 respectively. The SIDs of the nodes under P2 are L1-m and 267 L2-m. The SIDs of the nodes under P3 are P4-m, L3-m and L4-m. 269 The sub-tree is encoded as segment list 271 < P1-m, P2-m, P3-m, L1-m, L2-m, P4-m, L3-m, L4-m >, 272 \__/ \___________/ \________/ \______________/ 273 SIDs of P1 2 branches/next-hops sub-tree sub-tree 274 P2 and P3 of node P1 from P2 from P3 275 where 276 P1-m's N-Branches field is set to 2 and its N-SIDs field to 7; 277 P2-m's N-Branches field is set to 2 and its N-SIDs field to 2; 278 P3-m's N-Branches field is set to 1 and its N-SIDs field to 3; 280 L1-m and L2-m are the SID sequence in the segment list encoding 281 the sub-trees from P2; 283 P4-m, L3-m and L4-m are the SID sequence in the segment list 284 encoding the sub-trees from P3; and 286 P4-m's N-Branches field is set to 2 and its N-SIDs field to 2. 288 Figure 2 shows in details the segment list, which is an encoding of 289 the P2MP multicast tree for the SR P2MP path from R to L1, L2, L3 and 290 L4. 292 N-Branches N-SIDs 293 +---------------------------+-----------+-----------+--------------+ 294 | P1's Multicast SID Locator| 2 | 7 | Arguments | P1-m 295 +---------------------------+-----------+-----------+--------------+ 296 | P2's Multicast SID Locator| 2 | 2 | Arguments | P2-m 297 +---------------------------+-----------+-----------+--------------+ 298 | P3's Multicast SID Locator| 1 | 3 | Arguments | P3-m 299 +---------------------------+-----------+-----------+--------------+ 300 | L1's Multicast SID Locator| 0 | 0 | Arguments | L1-m 301 +---------------------------+-----------+-----------+--------------+ 302 | L2's Multicast SID Locator| 0 | 0 | Arguments | L2-m 303 +---------------------------+-----------+-----------+--------------+ 304 | P4's Multicast SID Locator| 2 | 2 | Arguments | P4-m 305 +---------------------------+-----------+-----------+--------------+ 306 | L3's Multicast SID Locator| 0 | 0 | Arguments | L3-m 307 +---------------------------+-----------+-----------+--------------+ 308 | L4's Multicast SID Locator| 0 | 0 | Arguments | L4-m 309 +---------------------------+-----------+-----------+--------------+ 311 Figure 2: Encoding of P2MP Multicast Tree from R to L1 - L4 313 SID P1-m indicates that there are 2 branches and 7 SIDs under P1. 314 SID P2-m indicates that there are 2 branches and 2 SIDs under P2. 315 SID P3-m indicates that there are 1 branch and 3 SIDs under P3. SIDs 316 L1-m and L2-m indicate that there is no branch under them. SID P4-m 317 indicates that there are 2 branches and 2 SIDs under P4. L3-m and 318 L4-m indicate that there is no branch under them. 320 4. Procedures/Behaviors 322 This section describes the procedures or behaviors on the ingress, 323 transit and egress/leaf node of a SR P2MP path to deliver a packet 324 received from the path to its destinations. 326 4.1. Procedure/Behavior on Ingress Node 328 For a packet to be transported by a SR P2MP Path, the ingress of the 329 P2MP path duplicates the packet for each sub-tree of the SR P2MP path 330 branching from the ingress, pushes the segment list encoding the sub- 331 tree into the packet by executing H.Encaps 332 [I-D.ietf-spring-srv6-network-programming] and sends the packet to 333 the next hop node along the sub-tree. 335 Regarding to the finite size of the segment list, a sub-tree can be 336 "split" into multiple sub-trees such that each of the sub-trees can 337 be encoded in the segment list of the finite size. 339 For example, there is one sub-tree from the ingress R of the SR P2MP 340 path in Figure 1 via next hop node P1 towards egress/leaf nodes L1, 341 L2, L3 and L4. 343 For this sub-tree, the ingress R duplicates the packet, set the 344 destination address (DA) to P1-m (i.e., multicast SID of node P1), 345 pushes the segment list without P1-m (i.e., ) encoding the sub-tree in a Segment Routing Header 347 (SRH) of the packet by executing H.Encaps and sends the packet to DA 348 (i.e., node P1). The contents of the multicast SIDs P1-m, P2-m, 349 P3-m, L1-m, L2-m, P4-m, L3-m, L4-m are shown in Figure 2. 351 Suppose that the duplicated packet is Pkt0 for the sub-tree. The 352 execution of H.Encaps pushes an IPv6 header (i.e., SRH) to Pkt0 and 353 sets some fields in the header to produce an encapsulated packet 354 Pkt'. Pkt' is represented in the following: 356 Pkt' = (SA=R, DA=P1-m)( L4-m, L3-m,..., P3-m,P2-m; SL=7)Pkt0 357 \________________________/ 358 corresponds to: 360 where DA=P1-m means that the destination address (DA) is set to P1-m; 361 SA=R means that the source address (SA) is set to R; SL=7 means that 362 the number of Segments Left (SL) is 7. 364 4.2. Procedure/Behavior on Transit Node 366 When a transit node of a SR P2MP path receives a packet transported 367 by the P2MP path, the DA of the packet is a multicast SID of the node 368 and the packet contains a segment list for the sub-trees under the 369 transit node. The DA and the segment list comprise the information 370 for encoding the sub-trees. 372 For example, when node P1 receives a packet transported by the SR 373 P2MP path in Figure 1, the packet's DA is P1-m (which is a multicast 374 SID of node P1) and the segment list in the packet is . 377 The N-Branches field (which has value of n) of the DA indicates that 378 there are n branches (or say sub-trees) under the transit node. The 379 N-SIDs field of the DA indicates the number of SIDs for these n sub- 380 trees under the transit node. The multicast SIDs of the next hop 381 nodes of these n sub-trees are the first n multicast SIDs of the 382 segment list in the packet. 384 For example, the N-Branches field (which has value of 2) of DA = P1-m 385 indicates that there are 2 branches (or say sub-trees) under node P1. 386 The N-SIDs field (which has value of 7) of the DA = P1-m indicates 387 that there are 7 SIDs for these 2 sub-trees under node P1. 389 The first multicast SID (P2-m) of the segment list is the SID of the 390 next hop node (P2) of the first sub-tree; The second multicast SID 391 (P3-m) of the segment list is the SID of the next hop node (P3) of 392 the second sub-tree. 394 After the multicast SIDs of the next hop nodes, there are n blocks of 395 SIDs for those n sub-trees. The N-SIDs field (which has value of B1) 396 of the first multicast SID of the next hop nodes indicates that there 397 are B1 SIDs in the first block for the first sub-tree; the N-SIDs 398 field (which has value of B2) of the second multicast SID of the next 399 hop nodes indicates that there are B2 SIDs in the second block for 400 the second sub-tree after the first block; and so on. 402 For example, there are 2 blocks of SIDs for the 2 sub-trees under 403 node P1 after the multicast SIDs P2-m and P3-m of the next hop nodes 404 P2 and P3. The N-SIDs field of P2-m (the first multicast SID of the 405 next hop nodes) has value of 2, indicating that there are 2 SIDs in 406 the first block for the first sub-tree, which are L1-m and L2-m. 408 The N-SIDs field of P3-m (the second multicast SID of the next hop 409 nodes) has value of 3, indicating that there are 3 SIDs in the second 410 block for the second sub-tree after the first block, which are P4-m, 411 L3-m and L4-m. 413 The transit node duplicates the packet without top header for each 414 sub-tree under it and adds a new header with a new segment list built 415 from the SID block for the sub-tree to the duplicated packet by 416 executing H.Encaps. It sets the DA of the packet to the multicast 417 SID of the next hop node along the sub-tree and sends the packet to 418 the DA. 420 For example, node P1 duplicates the packet for the first sub-tree 421 towards L1 and L2 and adds a new header with a new segment list 422 . It sets DA = P2-m (multicast SID of next hop P2), and 423 sends the packet to the DA (i.e., P2). 425 Suppose that the duplicated packet is Pkt0 for the sub-tree. The 426 execution of H.Encaps pushes a new IPv6 header (i.e., SRH) to Pkt0 427 and sets some fields in the header to produce an encapsulated packet 428 Pkt'. Pkt' is represented in the following: 430 Pkt' = (SA=P1, DA=P2-m)( L2-m, L1-m; SL=2)Pkt0. 431 \__________/ 432 corresponds to: 434 where DA=P2-m means that the destination address (DA) is set to P2-m; 435 SA=P1 means that the source address (SA) is set to P1; SL=2 means 436 that the number of Segments Left (SL) is 2. 438 Node P1 duplicates the packet for the second sub-tree via P3 towards 439 L3 and L4 and adds a new header with a new segment list . It sets DA = P3-m (multicast SID of next hop P3), and sends 441 the packet to the DA (i.e., P3). 443 4.3. Procedure/Behavior on Egress Node 445 When an egress node of a SR P2MP path receives a packet transported 446 by the P2MP path, the DA of the packet is a SID of the egress node. 447 The egress node sends the packet to its destination accordingly. If 448 the SID is a multicast SID of the egress, the N-Branches field and 449 N-SIDs field are all zeros. 451 5. Stateless SRv6 P2MP Path for Ingress 453 A controller such as PCE can compute a stateless SRv6 P2MP path and 454 send it to its ingress. For a packet to be transported by the path, 455 the ingress encapsulates the packet with the path and the packet will 456 be delivered to the egresses of the path without any states in the 457 network core. 459 An example architecture using PCE as a controller is illustrated in 460 Figure 3. There is a connection (i.e., PCE session) between the PCE 461 and (the PCC running on) each of the PEs, which are possible ingress 462 nodes in the network domain. Note that some of connections between 463 the PCE and PEs are not shown in the figure. 465 +------------------------------------+ 466 | PCE | 467 +------------------------------------+ 468 / \ 469 / \ 470 / ~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~~\~^~ 471 / _( (P2)---------(P3)-----------(PE2) ) 472 / ( / \_______ / ) 473 / _( / _______)____/ ) 474 / _( / / (_____ ) 475 /_( / / \ ) 476 /( / / \ ) 477 (CE) --- (PE1)--------(P1)-------------(P4)-------------(PE3) ) 478 ( \ \ \ ) 479 ( \ \ \ Network ) 480 ( \ \ \ ) 481 (_ (PE5)------(P5)------------(PE4) ) 482 ( ) 483 '---._.-.-._.-._.-.-._.-._.-.-._.-.-._.-.-._.-.) 485 Figure 3: Architecture using PCE 487 The PCE has the information about the network domain from the IGP or 488 BGP (BGP-LS). The information includes link bandwidth, link colors, 489 node SIDs, and so on. A separate multicast SID could be provisioned 490 on every replication node and the PCE gets the SID on the node from 491 IGP or BGP. 493 The PCE maintains the current status of the network resource usage in 494 its local TED (Traffic Engineering Database), and the status of every 495 stateless SRv6 P2MP path in its local LSP-DB (Label Switch Path 496 Database). 498 Upon receiving a request for a stateless SRv6 P2MP path from a user 499 or application, the PCE computes a path based on the network resource 500 availability stored in the TED. After a path satisfying the given 501 constraints is found, the PCE constructs a stateless SRv6 P2MP path 502 using the multicast SIDs of the nodes on the path and encodes the 503 structure of the P2MP path/tree into the parameters of the SIDs. In 504 fact, the stateless SRv6 P2MP path is a segment list consisting of 505 multicast SIDs with parameter values. 507 And then the PCE sends the segment list representing the path to the 508 ingress node of the path in a PCEP message such as PCInitiate. After 509 receiving the path from the PCE, the ingress node establishes the 510 path by creating a forwarding entry in its FIB. For every multicast 511 packet to be transported by the path, the forwarding entry 512 encapsulates the packet with the segment list and the packet will be 513 delivered to the egress nodes of the path along the path without any 514 state in the core of the network. 516 6. Protection 518 Protections for a SR P2MP path can be classified into two types: 519 global protection and local protection. 521 6.1. Global Protection 523 For a primary SR P2MP path from an ingress node R1 to multiple egress 524 nodes Li (i = 1, ..., n), a backup SR P2MP path from an ingress node 525 R1' to multiple egress nodes Li' (i = 1, ..., n) is set up to provide 526 global protection for the primary SR P2MP path. If R1' is the same 527 as R1, the failure of the ingress node R1 of the primary SR P2MP path 528 is not protected; otherwise (i.e., R1' and R1 are different and 529 connected to the same traffic source), the failure of the ingress 530 node R1 is protected. If Li' is the same as Li (i = 1, ..., n), the 531 failure of the egress nodes Li (i = 1, ..., n) of the primary SR P2MP 532 path is not protected; otherwise (i.e., Li' and Li are different and 533 connected to the same destination), the failure of the egress nodes 534 Li is protected. 536 When a failure happens on the primary SR P2MP path and is detected by 537 the source of the traffic or other entity, the traffic to be 538 transported by the primary SR P2MP path is switched to the backup SR 539 P2MP path, which sends the traffic from its ingress node R1' to its 540 egress nodes Li' (i = 1, ..., n). 542 6.2. Local Protection 544 Local protection or say Fast Reroute (FRR) of a node and adjacency 545 segment on a SR P2P path is proposed in 546 [I-D.ietf-rtgwg-segment-routing-ti-lfa] and 547 [I-D.ietf-rtgwg-srv6-egress-protection]. It can be applied to FRR of 548 a node and adjacency segment on a SR P2MP path in a similar way. But 549 FRR for SR P2MP path is more complicated. 551 More details will be added later. 553 7. IANA Considerations 555 TBD 557 8. Security Considerations 559 TBD 561 9. Acknowledgements 563 The authors would like to thank Acee Lindem, Jeffrey Zhang and Daniel 564 Voyer for their valuable comments and suggestions on this draft. 566 10. References 568 10.1. Normative References 570 [I-D.ietf-6man-segment-routing-header] 571 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 572 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 573 (SRH)", draft-ietf-6man-segment-routing-header-26 (work in 574 progress), October 2019. 576 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 577 Litkowski, S., Bashandy, A., Filsfils, C., Francois, P., 578 Decraene, B., and D. Voyer, "Topology Independent Fast 579 Reroute using Segment Routing", draft-ietf-rtgwg-segment- 580 routing-ti-lfa-06 (work in progress), February 2021. 582 [I-D.ietf-rtgwg-srv6-egress-protection] 583 Hu, Z., Chen, H., Chen, H., Wu, P., Toy, M., Cao, C., He, 584 T., Liu, L., and X. Liu, "SRv6 Path Egress Protection", 585 draft-ietf-rtgwg-srv6-egress-protection-02 (work in 586 progress), November 2020. 588 [I-D.ietf-spring-srv6-network-programming] 589 Filsfils, C., Garvia, P. C., Leddy, J., Voyer, D., 590 Matsushima, S., and Z. Li, "Segment Routing over IPv6 591 (SRv6) Network Programming", draft-ietf-spring-srv6- 592 network-programming-28 (work in progress), December 2020. 594 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 595 Requirement Levels", BCP 14, RFC 2119, 596 DOI 10.17487/RFC2119, March 1997, 597 . 599 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 600 (IPv6) Specification", STD 86, RFC 8200, 601 DOI 10.17487/RFC8200, July 2017, 602 . 604 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 605 Decraene, B., Litkowski, S., and R. Shakir, "Segment 606 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 607 July 2018, . 609 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 610 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 611 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 612 . 614 10.2. Informative References 616 [I-D.ietf-pim-sr-p2mp-policy] 617 Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z. 618 Zhang, "Segment Routing Point-to-Multipoint Policy", 619 draft-ietf-pim-sr-p2mp-policy-02 (work in progress), 620 February 2021. 622 [I-D.ietf-spring-sr-replication-segment] 623 Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z. 624 Zhang, "SR Replication Segment for Multi-point Service 625 Delivery", draft-ietf-spring-sr-replication-segment-04 626 (work in progress), February 2021. 628 [I-D.shen-spring-p2mp-transport-chain] 629 Shen, Y., Zhang, Z., Parekh, R., Bidgoli, H., and Y. 630 Kamite, "Point-to-Multipoint Transport Using Chain 631 Replication in Segment Routing", draft-shen-spring-p2mp- 632 transport-chain-03 (work in progress), October 2020. 634 Appendix A. Example IPv6 Header using G-SRv6 636 For simplicity, 64 bits for Common Prefix, 16 bits for Node ID, 8 637 bits for the number of branches (N-Branches) and 8 bits for the 638 number of SIDs (N-SIDs) are used when G-SRv6 compression method is 639 applied for at 640 ingress node R in Figure 1. The Destination Address (DA) is 641 illustrated below in Figure 4. It contains the Common Prefix of 64 642 bits, node P1's ID of 16 bits, the value 2 for the number of branches 643 (N-Branches) of 8 bits, and the value 7 for the number of SIDs 644 (N-SIDs) of 8 bits. 646 0 1 2 3 647 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 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | 2001:db9:0:0 (Common Prefix) | 650 | | 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | P1 ID | 2 | 7 | 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 | | 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 Figure 4: Destination Address (DA) 659 The IPv6 header is shown in Figure 5. Ingress node R sends a packet 660 with the IPv6 header to the DA. 662 0 1 2 3 663 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 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | Last Entry | Flags | Tag | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | P4 ID | 2 | 2 | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | L3 ID | 0 | 0 | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 | L4 ID | 0 | 0 | 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 | Padding | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | P2 ID | 2 | 2 | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | P3 ID | 1 | 3 | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | L1 ID | 0 | 0 | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | L2 ID | 0 | 0 | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 Figure 5: IPv6 Header 688 Authors' Addresses 689 Huaimo Chen 690 Futurewei 691 Boston, MA 692 USA 694 Email: Huaimo.chen@futurewei.com 696 Mike McBride 697 Futurewei 699 Email: michael.mcbride@futurewei.com 701 Yanhe Fan 702 Casa Systems 703 USA 705 Email: yfan@casa-systems.com 707 Xuesong Geng 708 Huawei 710 Email: gengxuesong@huawei.com 712 Mehmet Toy 713 Verizon 714 USA 716 Email: mehmet.toy@verizon.com 718 Aijun Wang 719 China Telecom 720 Beiqijia Town, Changping District 721 Beijing, 102209 722 China 724 Email: wangaj3@chinatelecom.cn 725 Lei Liu 726 Fujitsu 728 USA 730 Email: liulei.kddi@gmail.com 732 Xufeng Liu 733 Volta Networks 735 McLean, VA 736 USA 738 Email: xufeng.liu.ietf@gmail.com