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