idnits 2.17.1 draft-chen-pim-srv6-p2mp-path-01.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 233 has weird spacing: '...xt-hops sub-...' == Line 262 has weird spacing: '...xt-hops sub-...' -- The document date (September 28, 2020) is 1303 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'L1' is mentioned on line 160, but not defined == Missing Reference: 'R' is mentioned on line 168, but not defined == Missing Reference: 'P1' is mentioned on line 168, but not defined == Missing Reference: 'L3' is mentioned on line 168, but not defined == Unused Reference: 'I-D.ietf-6man-segment-routing-header' is defined on line 490, but no explicit reference was found in the text == Unused Reference: 'RFC8200' is defined on line 520, but no explicit reference was found in the text == Unused Reference: 'RFC8754' is defined on line 530, but no explicit reference was found in the text == Unused Reference: 'I-D.voyer-spring-sr-replication-segment' is defined on line 549, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-rtgwg-segment-routing-ti-lfa-04 == Outdated reference: A later version (-16) exists of draft-ietf-rtgwg-srv6-egress-protection-01 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-20 == Outdated reference: A later version (-04) exists of draft-shen-spring-p2mp-transport-chain-02 Summary: 1 error (**), 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: Standards Track Futurewei 5 Expires: April 1, 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 September 28, 2020 17 SRv6 Point-to-Multipoint Path 18 draft-chen-pim-srv6-p2mp-path-01 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 April 1, 2021. 50 Copyright Notice 52 Copyright (c) 2020 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. Protection . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 5.1. Global Protection . . . . . . . . . . . . . . . . . . . . 10 76 5.2. Local Protection . . . . . . . . . . . . . . . . . . . . 10 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 79 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 82 9.2. Informative References . . . . . . . . . . . . . . . . . 12 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 85 1. Introduction 87 The Segment Routing (SR) for unicast or Point-to-Point (P2P) path is 88 described in [RFC8402]. For SR multicast or Point-to-Multipoint 89 (P2MP) path/tree, it may be implemented through using multiple SR P2P 90 paths. The function of a SR P2MP path/tree from an ingress node to 91 multiple (say n) egress/leaf nodes is implemented by n SR P2P paths. 92 These n P2P paths are from the ingress to those n egress/leaf nodes 93 of the P2MP path/tree. This solution may waste some network 94 resources such as link bandwidth. 96 An alternative solution proposed in 97 [I-D.shen-spring-p2mp-transport-chain] uses a number of P2MP chain 98 tunnels to implement a P2MP path/tree from an ingress to n egress/ 99 leaf nodes. Each P2MP chain tunnel is a tunnel from the ingress to a 100 leaf node as its tail end and may have some leaf nodes as its bud 101 nodes along the tunnel. This alternative solution improves the usage 102 of network resources over the solution above using pure P2P paths. 103 However, these two solutions are based on SR P2P paths. 105 A solution for a SR P2MP path/tree using a P2MP multicast tree is 106 proposed in [I-D.voyer-pim-sr-p2mp-policy]. For a SR P2MP path/tree 107 from an ingress/root to multiple egress/leaf nodes, a multicast P2MP 108 tree is created to deliver the traffic from the ingress/root to the 109 egress/leaf nodes. The state of the tree is instantiated in the 110 forwarding plane by a controller such as PCE at Root node, 111 intermediate Replication nodes and Leaf nodes of the tree. This is 112 not consistent with the SR principles in which no state is stored at 113 the core of the network. 115 This document describes a new solution for a SRv6 Point-to-Multipoint 116 (P2MP) Path/Tree to deliver the traffic from the ingress of the path 117 to the multiple egresses/leaves of the path in a SR domain. This 118 solution uses a P2MP multicast tree without storing its state in the 119 core of the network for a SR P2MP path/tree like a SR P2P path. 121 2. Overview of P2MP Multicast Tree 123 For a SR P2P path from its ingress to its egress, a segment list for 124 the path is provided to the ingress. The ingress pushes the list 125 into a packet, and the packet is delivered to the egress according to 126 the segment list without any state in the core of the network. 128 For a SR P2MP path from its ingress to multiple egress/leaf nodes, a 129 segment list for the P2MP path is provided to the ingress. The 130 ingress pushes the list into a packet, and the packet is delivered to 131 the multiple egress/leaf nodes according to the segment list without 132 any state in the core of the network. 134 Figure 1 shows a SR P2MP path from ingress/root R to four egress/leaf 135 nodes L1, L2, L3 and L4. Nodes P1, P2, P3 and P4 are the transit 136 nodes of the P2MP path. 138 Suppose that X-m is the segment identifier (SID) of node X. X-m is 139 an adjacent SID or node SID. For simplicity, we assume X-m is a node 140 SID in the illustrations below. R-m, P1-m, P2-m, P3-m, P4-m, L1-m, 141 L2-m, L3-m and L4-m are the SIDs of the nodes on the SR P2MP path. 142 They are multicast SIDs or replication SIDs in general. 144 A multicast SID is a SID from a multicast SID block. In a SR domain 145 supporting SR multicast, each node has a multicast node SID, which is 146 globally significant; each adjacency of a node has a multicast 147 adjacency SID, which is locally significant. A multicast SID of a 148 node on a SR P2MP path is associated with the SIDs of the next hop 149 (or say downstream) nodes. When the node receives a packet with its 150 multicast SID, it duplicates and sends the packet to each of the next 151 hop nodes according to their SIDs. 153 If node P on a SR P2MP path has B (B > 1) next hop nodes along the 154 path, the SID of node P, P-m, MUST be a multicast SID when it is in 155 the segment list for the P2MP path. The SIDs of the B next hop nodes 156 just follow P-m in the segment list. When node P receives the packet 157 with P-m, it duplicates and sends the packet to each of the B next 158 hop nodes along the P2MP path. 160 [L1] R Ingress/Root 161 / Li Egress/Leaf 162 / Pi Transit Node 163 / 164 [P2]------[L2] 165 / 166 / 167 / 168 [R]------[P1] [L3] 169 \ / 170 \ / 171 \ / 172 [P3]------[P4]------[L4] 174 Figure 1: SR P2MP Path from R to L1, L2, L3 and L4 176 is a segment list 177 for the SR P2MP path in Figure 1 to be pushed into a packet at 178 ingress/root R. Node P1 has 2 next hop nodes P2 and P3 along the 179 P2MP path. The next hop nodes' SIDs P2-m and P3-m follow P1-m, which 180 is P1's multicast SID. When P1 receives a packet transported by the 181 P2MP path, it duplicates and sends the packet to the next hop nodes 182 P2 and P3 according to P1-m, P2-m and P3-m. 184 The number of branches or next hops from node P1 is a value of one 185 argument in P1-m, called N-Branches. The value of N-Branches in P1-m 186 is 2. With this information, node P1 duplicates and sends the packet 187 to 2 next hop nodes P2 and P3, which are indicated by the 2 SIDs P2-m 188 and P3-m following P1-m. 190 The number of SIDs of the nodes under node P1 is a value of another 191 argument in P1-m, called N-SIDs. The value of N-SIDs in P1-m is 7, 192 indicating that there are 7 SIDs following P1-m in the segment list. 194 There are 2 branches or next hops (i.e., L1 and L2) from node P2 and 195 2 SIDs (i.e., L1-m and L2-m) of the nodes under node P2. The values 196 of N-Branches and N-SIDs in P2-m are 2 and 2. with this information, 197 before sending the packet to node P2, node P1 pushes the SIDs under 198 node P2 into the packet (i.e., the packet has a new segment list with 199 the SIDs under node P2. The new segment list replaces the old one in 200 the packet). 202 There are 1 branch or next hop (i.e., P4) from node P3 and 3 SIDs 203 (i.e., P4-m, L3-m and L4-m) of the nodes under node P3. The values 204 of N-Branches and N-SIDs in P3-m are 1 and 3 respectively. with this 205 information, before sending the packet to node P3, node P1 pushes the 206 SIDs under node P3 into the packet. 208 Each node on the SR P2MP path sends the packet to its next hop nodes 209 according to the segment list and no state is stored in any transit 210 node (i.e., the core of the network). The packet is delivered to the 211 egress/leaf nodes from the ingress. 213 3. Encoding P2MP Multicast Tree 215 For each sub-tree STi of a SR P2MP path from the ingress node of the 216 P2MP path, suppose that 218 o the multicast SID of the next hop node NHi is mSIDi; 220 o there are Bi branches (i.e., outgoing interfaces) to the next hop 221 node BNHj (j = 1, ..., Bi) from node NHi along the sub-tree, the 222 multicast SID of BNHj is mSIDij; 224 o the number of branches (i.e., outgoing interfaces) under the node 225 BNHj (j = 1, ..., Bi) is BBj; and the number of SIDs of the nodes 226 under each of the Bi branches from node BNHj is NSj (j = 1, ..., 227 Bi). 229 Sub-tree STi is encoded as segment list 231 < mSIDi, mSIDi1, ..., mSIDiBi, SegSeq1, ..., SegSeqBi >, 232 \___/ \____________________/ \______/ \________/ 233 SIDs of NHi Bi branches/next-hops sub-tree sub-tree 234 BNHj of node NHi from BNH1 from BNHBi 236 where mSIDi contains the number of branches, Bi, in its N-Branches 237 field, and the number of SIDs under mSIDi in its N-SIDs field; mSIDij 238 (j = 1, ..., Bi) contains the number of branches, BBj, in its 239 N-Branches field and the number of SIDs, NSj, in its N-SIDs field; 240 SegSeqj (j = 1, ..., Bi) is the SID sequence in the segment list 241 encoding the sub-trees from node BNHj. 243 For the P2MP path in Figure 1 from ingress node R to egress nodes L1, 244 L2, L3 and L4, there is one sub-tree from R. 246 For this sub-tree, 248 o the next hop node is P1 and the multicast SID of P1 is P1-m; 250 o there are 2 branches to the next hop nodes P2 and P3 from node P1 251 along the sub-tree; the number of SIDs of the nodes under P1 is 7; 252 the multicast SIDs of P2 and P3 are P2-m and P3-m respectively; 254 o the numbers of SIDs of the nodes under these two branches are 2 255 and 3 respectively. The SIDs of the nodes under P2 are L1-m and 256 L2-m. The SIDs of the nodes under P3 are P4-m, L3-m and L4-m. 258 The sub-tree is encoded as segment list 260 < P1-m, P2-m, P3-m, L1-m, L2-m, P4-m, L3-m, L4-m >, 261 \__/ \___________/ \________/ \______________/ 262 SIDs of P1 2 branches/next-hops sub-tree sub-tree 263 P2 and P3 of node P1 from P2 from P3 264 where 265 P1-m's N-Branches field is set to 2 and its N-SIDs field to 7; 266 P2-m's N-Branches field is set to 2 and its N-SIDs field to 2; 267 P3-m's N-Branches field is set to 1 and its N-SIDs field to 3; 269 L1-m and L2-m are the SID sequence in the segment list encoding 270 the sub-trees from P2; 272 P4-m, L3-m and L4-m are the SID sequence in the segment list 273 encoding the sub-trees from P3; and 275 P4-m's N-Branches field is set to 2 and its N-SIDs field to 2. 277 Figure 2 shows in details the segment list, which is an encoding of 278 the P2MP multicast tree for the SR P2MP path from R to L1, L2, L3 and 279 L4. 281 N-Branches N-SIDs 282 +---------------------------+-----------+-----------+--------------+ 283 | P1's Multicast SID Locator| 2 | 7 | Arguments | P1-m 284 +---------------------------+-----------+-----------+--------------+ 285 | P2's Multicast SID Locator| 2 | 2 | Arguments | P2-m 286 +---------------------------+-----------+-----------+--------------+ 287 | P3's Multicast SID Locator| 1 | 3 | Arguments | P3-m 288 +---------------------------+-----------+-----------+--------------+ 289 | L1's Multicast SID Locator| 0 | 0 | Arguments | L1-m 290 +---------------------------+-----------+-----------+--------------+ 291 | L2's Multicast SID Locator| 0 | 0 | Arguments | L2-m 292 +---------------------------+-----------+-----------+--------------+ 293 | P4's Multicast SID Locator| 2 | 2 | Arguments | P4-m 294 +---------------------------+-----------+-----------+--------------+ 295 | L3's Multicast SID Locator| 0 | 0 | Arguments | L3-m 296 +---------------------------+-----------+-----------+--------------+ 297 | L4's Multicast SID Locator| 0 | 0 | Arguments | L4-m 298 +---------------------------+-----------+-----------+--------------+ 300 Figure 2: Encoding of P2MP Multicast Tree from R to L1 - L4 302 SID P1-m indicates that there are 2 branches and 7 SIDs under P1. 303 SID P2-m indicates that there are 2 branches and 2 SIDs under P2. 304 SID P3-m indicates that there are 1 branch and 3 SIDs under P3. SIDs 305 L1-m and L2-m indicate that there is no branch under them. SID P4-m 306 indicates that there are 2 branches and 2 SIDs under P4. L3-m and 307 L4-m indicate that there is no branch under them. 309 4. Procedures/Behaviors 311 This section describes the procedures or behaviors on the ingress, 312 transit and egress/leaf node of a SR P2MP path to deliver a packet 313 received from the path to its destinations. 315 4.1. Procedure/Behavior on Ingress Node 317 For a packet to be transported by a SR P2MP Path, the ingress of the 318 P2MP path duplicates the packet for each sub-tree of the SR P2MP path 319 branching from the ingress, pushes the segment list encoding the sub- 320 tree into the packet by executing H.Encaps 321 [I-D.ietf-spring-srv6-network-programming] and sends the packet to 322 the next hop node along the sub-tree. 324 For example, there is one sub-tree from the ingress R of the SR P2MP 325 path in Figure 1 via next hop node P1 towards egress/leaf nodes L1, 326 L2, L3 and L4. 328 For this sub-tree, the ingress R duplicates the packet, set the 329 destination address (DA) to P1-m (i.e., multicast SID of node P1), 330 pushes the segment list without P1-m (i.e., ) encoding the sub-tree in a Segment Routing Header 332 (SRH) of the packet by executing H.Encaps and sends the packet to DA 333 (i.e., node P1). The contents of the multicast SIDs P1-m, P2-m, 334 P3-m, L1-m, L2-m, P4-m, L3-m, L4-m are shown in Figure 2. 336 Suppose that the duplicated packet is Pkt0 for the sub-tree. The 337 execution of H.Encaps pushes an IPv6 header (i.e., SRH) to Pkt0 and 338 sets some fields in the header to produce an encapsulated packet 339 Pkt'. Pkt' is represented in the following: 341 Pkt' = (SA=R, DA=P1-m)( L4-m, L3-m,..., P3-m,P2-m; SL=7)Pkt0 342 \________________________/ 343 corresponds to: 345 where DA=P1-m means that the destination address (DA) is set to P1-m; 346 SA=R means that the source address (SA) is set to R; SL=7 means that 347 the number of Segments Left (SL) is 7. 349 4.2. Procedure/Behavior on Transit Node 351 When a transit node of a SR P2MP path receives a packet transported 352 by the P2MP path, the DA of the packet is a multicast SID of the node 353 and the packet contains a segment list for the sub-trees under the 354 transit node. The DA and the segment list comprise the information 355 for encoding the sub-trees. 357 For example, when node P1 receives a packet transported by the SR 358 P2MP path in Figure 1, the packet's DA is P1-m (which is a multicast 359 SID of node P1) and the segment list in the packet is . 362 The N-Branches field (which has value of n) of the DA indicates that 363 there are n branches (or say sub-trees) under the transit node. The 364 N-SIDs field of the DA indicates the number of SIDs for these n sub- 365 trees under the transit node. The multicast SIDs of the next hop 366 nodes of these n sub-trees are the first n multicast SIDs of the 367 segment list in the packet. 369 For example, the N-Branches field (which has value of 2) of DA = P1-m 370 indicates that there are 2 branches (or say sub-trees) under node P1. 371 The N-SIDs field (which has value of 7) of the DA = P1-m indicates 372 that there are 7 SIDs for these 2 sub-trees under node P1. 374 The first multicast SID (P2-m) of the segment list is the SID of the 375 next hop node (P2) of the first sub-tree; The second multicast SID 376 (P3-m) of the segment list is the SID of the next hop node (P3) of 377 the second sub-tree. 379 After the multicast SIDs of the next hop nodes, there are n blocks of 380 SIDs for those n sub-trees. The N-SIDs field (which has value of B1) 381 of the first multicast SID of the next hop nodes indicates that there 382 are B1 SIDs in the first block for the first sub-tree; the N-SIDs 383 field (which has value of B2) of the second multicast SID of the next 384 hop nodes indicates that there are B2 SIDs in the second block for 385 the second sub-tree after the first block; and so on. 387 For example, there are 2 blocks of SIDs for the 2 sub-trees under 388 node P1 after the multicast SIDs P2-m and P3-m of the next hop nodes 389 P2 and P3. The N-SIDs field of P2-m (the first multicast SID of the 390 next hop nodes) has value of 2, indicating that there are 2 SIDs in 391 the first block for the first sub-tree, which are L1-m and L2-m. 393 The N-SIDs field of P3-m (the second multicast SID of the next hop 394 nodes) has value of 3, indicating that there are 3 SIDs in the second 395 block for the second sub-tree after the first block, which are P4-m, 396 L3-m and L4-m. 398 The transit node duplicates the packet without top header for each 399 sub-tree under it and adds a new header with a new segment list built 400 from the SID block for the sub-tree to the duplicated packet by 401 executing H.Encaps. It sets the DA of the packet to the multicast 402 SID of the next hop node along the sub-tree and sends the packet to 403 the DA. 405 For example, node P1 duplicates the packet for the first sub-tree 406 towards L1 and L2 and adds a new header with a new segment list 407 . It sets DA = P2-m (multicast SID of next hop P2), and 408 sends the packet to the DA (i.e., P2). 410 Suppose that the duplicated packet is Pkt0 for the sub-tree. The 411 execution of H.Encaps pushes a new IPv6 header (i.e., SRH) to Pkt0 412 and sets some fields in the header to produce an encapsulated packet 413 Pkt'. Pkt' is represented in the following: 415 Pkt' = (SA=P1, DA=P2-m)( L2-m, L1-m; SL=2)Pkt0. 416 \__________/ 417 corresponds to: 419 where DA=P2-m means that the destination address (DA) is set to P2-m; 420 SA=P1 means that the source address (SA) is set to P1; SL=2 means 421 that the number of Segments Left (SL) is 2. 423 Node P1 duplicates the packet for the second sub-tree via P3 towards 424 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 426 the packet to the DA (i.e., P3). 428 4.3. Procedure/Behavior on Egress Node 430 When an egress node of a SR P2MP path receives a packet transported 431 by the P2MP path, the DA of the packet is a SID of the egress node. 432 The egress node sends the packet to its destination accordingly. If 433 the SID is a multicast SID of the egress, the N-Branches field and 434 N-SIDs field are all zeros. 436 5. Protection 438 Protections for a SR P2MP path can be classified into two types: 439 global protection and local protection. 441 5.1. Global Protection 443 For a primary SR P2MP path from an ingress node R1 to multiple egress 444 nodes Li (i = 1, ..., n), a backup SR P2MP path from an ingress node 445 R1' to multiple egress nodes Li' (i = 1, ..., n) is set up to provide 446 global protection for the primary SR P2MP path. If R1' is the same 447 as R1, the failure of the ingress node R1 of the primary SR P2MP path 448 is not protected; otherwise (i.e., R1' and R1 are different and 449 connected to the same traffic source), the failure of the ingress 450 node R1 is protected. If Li' is the same as Li (i = 1, ..., n), the 451 failure of the egress nodes Li (i = 1, ..., n) of the primary SR P2MP 452 path is not protected; otherwise (i.e., Li' and Li are different and 453 connected to the same destination), the failure of the egress nodes 454 Li is protected. 456 When a failure happens on the primary SR P2MP path and is detected by 457 the source of the traffic or other entity, the traffic to be 458 transported by the primary SR P2MP path is switched to the backup SR 459 P2MP path, which sends the traffic from its ingress node R1' to its 460 egress nodes Li' (i = 1, ..., n). 462 5.2. Local Protection 464 Local protection or say Fast Reroute (FRR) of a node and adjacency 465 segment on a SR P2P path is proposed in 466 [I-D.ietf-rtgwg-segment-routing-ti-lfa] and 467 [I-D.ietf-rtgwg-srv6-egress-protection]. It can be applied to FRR of 468 a node and adjacency segment on a SR P2MP path in a similar way. But 469 FRR for SR P2MP path is more complicated. 471 More details will be added later. 473 6. IANA Considerations 475 TBD 477 7. Security Considerations 479 TBD 481 8. Acknowledgements 483 The authors would like to thank Acee Lindem and Daniel Voyer for 484 their valuable comments and suggestions on this draft. 486 9. References 488 9.1. Normative References 490 [I-D.ietf-6man-segment-routing-header] 491 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 492 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 493 (SRH)", draft-ietf-6man-segment-routing-header-26 (work in 494 progress), October 2019. 496 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 497 Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B., 498 Francois, P., Voyer, D., Clad, F., and P. Camarillo, 499 "Topology Independent Fast Reroute using Segment Routing", 500 draft-ietf-rtgwg-segment-routing-ti-lfa-04 (work in 501 progress), August 2020. 503 [I-D.ietf-rtgwg-srv6-egress-protection] 504 Hu, Z., Chen, H., Chen, H., Wu, P., Toy, M., Cao, C., Liu, 505 L., and X. Liu, "SRv6 Path Egress Protection", draft-ietf- 506 rtgwg-srv6-egress-protection-01 (work in progress), July 507 2020. 509 [I-D.ietf-spring-srv6-network-programming] 510 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 511 Matsushima, S., and Z. Li, "SRv6 Network Programming", 512 draft-ietf-spring-srv6-network-programming-20 (work in 513 progress), September 2020. 515 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 516 Requirement Levels", BCP 14, RFC 2119, 517 DOI 10.17487/RFC2119, March 1997, 518 . 520 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 521 (IPv6) Specification", STD 86, RFC 8200, 522 DOI 10.17487/RFC8200, July 2017, 523 . 525 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 526 Decraene, B., Litkowski, S., and R. Shakir, "Segment 527 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 528 July 2018, . 530 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 531 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 532 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 533 . 535 9.2. Informative References 537 [I-D.shen-spring-p2mp-transport-chain] 538 Shen, Y., Zhang, Z., Parekh, R., Bidgoli, H., and Y. 539 Kamite, "Point-to-Multipoint Transport Using Chain 540 Replication in Segment Routing", draft-shen-spring-p2mp- 541 transport-chain-02 (work in progress), April 2020. 543 [I-D.voyer-pim-sr-p2mp-policy] 544 Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z. 545 Zhang, "Segment Routing Point-to-Multipoint Policy", 546 draft-voyer-pim-sr-p2mp-policy-02 (work in progress), July 547 2020. 549 [I-D.voyer-spring-sr-replication-segment] 550 Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z. 551 Zhang, "SR Replication Segment for Multi-point Service 552 Delivery", draft-voyer-spring-sr-replication-segment-04 553 (work in progress), July 2020. 555 Authors' Addresses 557 Huaimo Chen 558 Futurewei 559 Boston, MA 560 USA 562 Email: Huaimo.chen@futurewei.com 563 Mike McBride 564 Futurewei 566 Email: michael.mcbride@futurewei.com 568 Yanhe Fan 569 Casa Systems 570 USA 572 Email: yfan@casa-systems.com 574 Mehmet Toy 575 Verizon 576 USA 578 Email: mehmet.toy@verizon.com 580 Aijun Wang 581 China Telecom 582 Beiqijia Town, Changping District 583 Beijing, 102209 584 China 586 Email: wangaj3@chinatelecom.cn 588 Lei Liu 589 Fujitsu 591 USA 593 Email: liulei.kddi@gmail.com 595 Xufeng Liu 596 Volta Networks 598 McLean, VA 599 USA 601 Email: xufeng.liu.ietf@gmail.com