idnits 2.17.1 draft-chen-pim-srv6-p2mp-path-00.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 -- The document date (July 12, 2020) is 1384 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 447, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-srv6-network-programming' is defined on line 466, but no explicit reference was found in the text == Unused Reference: 'RFC8200' is defined on line 477, but no explicit reference was found in the text == Unused Reference: 'RFC8754' is defined on line 487, but no explicit reference was found in the text == Unused Reference: 'I-D.voyer-spring-sr-replication-segment' is defined on line 506, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-rtgwg-segment-routing-ti-lfa-03 == Outdated reference: A later version (-16) exists of draft-ietf-rtgwg-srv6-egress-protection-00 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-16 == Outdated reference: A later version (-04) exists of draft-shen-spring-p2mp-transport-chain-02 Summary: 1 error (**), 0 flaws (~~), 14 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: January 13, 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 July 12, 2020 17 SRv6 Point-to-Multipoint Path 18 draft-chen-pim-srv6-p2mp-path-00 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 January 13, 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 . . . . . . . . . . . . 9 74 5. Protection . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 5.1. Global Protection . . . . . . . . . . . . . . . . . . . . 9 76 5.2. Local Protection . . . . . . . . . . . . . . . . . . . . 10 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 79 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 81 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 82 9.2. Informative References . . . . . . . . . . . . . . . . . 11 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 {P1-m, P2-m, P3-m, L1-m, L2-m, P4-m, L3-m, L4-m} 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 No-Branches. The value of No-Branches in 186 P1-m is 2. With this information, node P1 duplicates and sends the 187 packet to 2 next hop nodes P2 and P3, which are indicated by the 2 188 SIDs P2-m 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 No-SIDs. The value of No-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 No-Branches and No-SIDs in P2-m are 2 and 2. with this 197 information, before sending the packet to node P2, node P1 pushes the 198 SIDs under node P2 into the packet (i.e., the packet has a new 199 segment list with the SIDs under node P2. The new segment list 200 replaces the old one in 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 No-Branches and No-SIDs in P3-m are 1 and 3 respectively. with 205 this information, before sending the packet to node P3, node P1 206 pushes the 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 {mSIDi, mSIDi1, ..., mSIDiBi, 230 SegSeq1, ..., SegSeqBi}, where mSIDi contains the number of branches, 231 Bi, in its No-Branches field, and the number of SIDs under mSIDi in 232 its No-SIDs field; mSIDij (j = 1, ..., Bi) contains the number of 233 branches, BBj, in its No-Branches field and the number of SIDs, NSj, 234 in its No-SIDs field; SegSeqj (j = 1, ..., Bi) is the SID sequence in 235 the segment list encoding the sub-trees from node BNHj. 237 For the P2MP path in Figure 1 from ingress node R to egress nodes L1, 238 L2, L3 and L4, there is one sub-tree from R. 240 For this sub-tree, 242 o the next hop node is P1 and the multicast SID of P1 is P1-m; 244 o there are two branches to the next hop nodes P2 and P3 from node 245 P1 along the sub-tree; the number of SIDs of the nodes under P1 is 246 7; the multicast SIDs of P2 and P3 are P2-m and P3-m respectively; 248 o the numbers of SIDs of the nodes under these two branches are 2 249 and 3 respectively. The SIDs of the nodes under P2 are L1-m and 250 L2-m. The SIDs of the nodes under P3 are P4-m, L3-m and L4-m. 252 The sub-tree is encoded as segment list {P1-m, P2-m, P3-m, L1-m, 253 L2-m, P4-m, L3-m, L4-m}, where P1-m's No-Branches field is set to 2 254 and its No-SIDs field to 7; P2-m's No-Branches field is set to 2 and 255 P3-m's No-Branches field is set to 1; P2-m's No-SIDs field is set to 256 2 and P3-m's No-SIDs field is set to 3; L1-m and L2-m are the SID 257 sequence in the segment list encoding the sub-trees from P2; P4-m, 258 L3-m and L4-m are the SID sequence in the segment list encoding the 259 sub-trees from P3. P4-m's No-Branches field is set to 2 and No-SIDs 260 field is set to 2. 262 Figure 2 shows in details the segment list, which is an encoding of 263 the P2MP multicast tree for the SR P2MP path from R to L1, L2, L3 and 264 L4. 266 No-Branches No-SIDs 267 +---------------------------+-----------+-----------+--------------+ 268 | P1's Multicast SID Locator| 2 | 7 | Arguments | P1-m 269 +---------------------------+-----------+-----------+--------------+ 270 | P2's Multicast SID Locator| 2 | 2 | Arguments | P2-m 271 +---------------------------+-----------+-----------+--------------+ 272 | P3's Multicast SID Locator| 1 | 3 | Arguments | P3-m 273 +---------------------------+-----------+-----------+--------------+ 274 | L1's Multicast SID Locator| 0 | 0 | Arguments | L1-m 275 +---------------------------+-----------+-----------+--------------+ 276 | L2's Multicast SID Locator| 0 | 0 | Arguments | L2-m 277 +---------------------------+-----------+-----------+--------------+ 278 | P4's Multicast SID Locator| 2 | 2 | Arguments | P4-m 279 +---------------------------+-----------+-----------+--------------+ 280 | L3's Multicast SID Locator| 0 | 0 | Arguments | L3-m 281 +---------------------------+-----------+-----------+--------------+ 282 | L4's Multicast SID Locator| 0 | 0 | Arguments | L4-m 283 +---------------------------+-----------+-----------+--------------+ 285 Figure 2: Encoding of P2MP Multicast Tree from R to L1 - L4 287 SID P1-m indicates that there are 2 branches and 7 SIDs under P1. 288 SID P2-m indicates that there are 2 branches and 2 SIDs under P2. 289 SID P3-m indicates that there are 1 branch and 3 SIDs under P3. SIDs 290 L1-m and L2-m indicate that there is no branch under them. SID P4-m 291 indicates that there are 2 branches and 2 SIDs under P4. L3-m and 292 L4-m indicate that there is no branch under them. 294 4. Procedures/Behaviors 296 This section describes the procedures or behaviors on the ingress, 297 transit and egress/leaf node of a SR P2MP path to deliver a packet 298 received from the path to its destinations. 300 4.1. Procedure/Behavior on Ingress Node 302 For a packet to be transported by a SR P2MP Path, the ingress of the 303 P2MP path duplicates the packet for each sub-tree of the SR P2MP path 304 branching from the ingress, pushes the segment list encoding the sub- 305 tree into the packet and sends the packet to the next hop node along 306 the sub-tree. 308 For example, there is one sub-tree from the ingress R of the SR P2MP 309 path in Figure 1 via next hop node P1 towards egress/leaf nodes L1, 310 L2, L3 and L4. 312 For this sub-tree, the ingress R duplicates the packet, set the 313 destination address (DA) to P1-m (i.e., multicast SID of node P1), 314 pushes the segment list without P1-m (i.e., {P2-m, P3-m, L1-m, L2-m, 315 P4-m, L3-m, L4-m}) encoding the sub-tree in SRH of the packet and 316 sends the packet to DA (i.e., node P1). The contents of the 317 multicast SIDs P1-m, P2-m, P3-m, L1-m, L2-m, P4-m, L3-m, L4-m are 318 shown in Figure 2. 320 4.2. Procedure/Behavior on Transit Node 322 When a transit node of a SR P2MP path receives a packet transported 323 by the P2MP path, the DA of the packet is a multicast SID of the node 324 and the packet contains a segment list for the sub-trees under the 325 transit node. The DA and the segment list comprise the information 326 for encoding the sub-trees. 328 For example, when node P1 receives a packet transported by the SR 329 P2MP path in Figure 1, the packet's DA is P1-m (which is a multicast 330 SID of node P1) and the segment list in the packet is {P2-m, P3-m, 331 L1-m, L2-m, P4-m, L3-m, L4-m}. 333 The No-Branches field (which has value of n) of the DA indicates that 334 there are n branches (or say sub-trees) under the transit node. The 335 No-SIDs field of the DA indicates the number of SIDs for these n sub- 336 trees under the transit node. The multicast SIDs of the next hop 337 nodes of these n sub-trees are the first n multicast SIDs of the 338 segment list in the packet. 340 For example, the No-Branches field (which has value of 2) of DA = 341 P1-m indicates that there are 2 branches (or say sub-trees) under 342 node P1. The No-SIDs field (which has value of 7) of the DA = P1-m 343 indicates that there are 7 SIDs for these 2 sub-trees under node P1. 345 The first multicast SID (P2-m) of the segment list is the SID of the 346 next hop node (P2) of the first sub-tree; The second multicast SID 347 (P3-m) of the segment list is the SID of the next hop node (P3) of 348 the second sub-tree. 350 After the multicast SIDs of the next hop nodes, there are n blocks of 351 SIDs for those n sub-trees. The No-SIDs field (which has value of 352 B1) of the first multicast SID of the next hop nodes indicates that 353 there are B1 SIDs in the first block for the first sub-tree; the No- 354 SIDs field (which has value of B2) of the second multicast SID of the 355 next hop nodes indicates that there are B2 SIDs in the second block 356 for the second sub-tree after the first block; and so on. 358 For example, there are 2 blocks of SIDs for the 2 sub-trees under 359 node P1 after the multicast SIDs P2-m and P3-m of the next hop nodes 360 P2 and P3. The No-SIDs field of P2-m (the first multicast SID of the 361 next hop nodes) has value of 2, indicating that there are 2 SIDs in 362 the first block for the first sub-tree, which are L1-m and L2-m. 364 The No-SIDs field of P3-m (the second multicast SID of the next hop 365 nodes) has value of 3, indicating that there are 3 SIDs in the second 366 block for the second sub-tree after the first block, which are P4-m, 367 L3-m and L4-m. 369 The transit node duplicates the packet without top header for each 370 sub-tree under it and adds a new header with a new segment list built 371 from the SID block for the sub-tree to the duplicated packet. It 372 sets the DA of the packet to the multicast SID of the next hop node 373 along the sub-tree and sends the packet to the DA. 375 For example, node P1 duplicates the packet for the first sub-tree 376 towards L1 and L2 and adds a new header with a new segment list 377 {L1-m, L2-m}. It sets DA = P2-m (multicast SID of next hop P2), and 378 sends the packet to the DA (i.e., P2). 380 Node P1 duplicates the packet for the second sub-tree via P3 towards 381 L3 and L4 and adds a new header with a new segment list {P4-m, L3-m, 382 L4-m}. It sets DA = P3-m (multicast SID of next hop P3), and sends 383 the packet to the DA (i.e., P3). 385 4.3. Procedure/Behavior on Egress Node 387 When an egress node of a SR P2MP path receives a packet transported 388 by the P2MP path, the DA of the packet is a SID of the egress node. 389 The egress node sends the packet to its destination accordingly. If 390 the SID is a multicast SID of the egress, the No-Branches field and 391 No-SIDs field are all zeros. 393 5. Protection 395 Protections for a SR P2MP path can be classified into two types: 396 global protection and local protection. 398 5.1. Global Protection 400 For a primary SR P2MP path from an ingress node R1 to multiple egress 401 nodes Li (i = 1, ..., n), a backup SR P2MP path from an ingress node 402 R1' to multiple egress nodes Li' (i = 1, ..., n) is set up to provide 403 global protection for the primary SR P2MP path. If R1' is the same 404 as R1, the failure of the ingress node R1 of the primary SR P2MP path 405 is not protected; otherwise (i.e., R1' and R1 are different and 406 connected to the same traffic source), the failure of the ingress 407 node R1 is protected. If Li' is the same as Li (i = 1, ..., n), the 408 failure of the egress nodes Li (i = 1, ..., n) of the primary SR P2MP 409 path is not protected; otherwise (i.e., Li' and Li are different and 410 connected to the same destination), the failure of the egress nodes 411 Li is protected. 413 When a failure happens on the primary SR P2MP path and is detected by 414 the source of the traffic or other entity, the traffic to be 415 transported by the primary SR P2MP path is switched to the backup SR 416 P2MP path, which sends the traffic from its ingress node R1' to its 417 egress nodes Li' (i = 1, ..., n). 419 5.2. Local Protection 421 Local protection or say Fast Reroute (FRR) of a node and adjacency 422 segment on a SR P2P path is proposed in 423 [I-D.ietf-rtgwg-segment-routing-ti-lfa] and 424 [I-D.ietf-rtgwg-srv6-egress-protection]. It can be applied to FRR of 425 a node and adjacency segment on a SR P2MP path in a similar way. But 426 FRR for SR P2MP path is more complicated. 428 More details will be added later. 430 6. IANA Considerations 432 TBD 434 7. Security Considerations 436 TBD 438 8. Acknowledgements 440 The authors would like to thank people for his valuable comments and 441 suggestions on this draft. 443 9. References 445 9.1. Normative References 447 [I-D.ietf-6man-segment-routing-header] 448 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 449 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 450 (SRH)", draft-ietf-6man-segment-routing-header-26 (work in 451 progress), October 2019. 453 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 454 Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B., 455 Francois, P., Voyer, D., Clad, F., and P. Camarillo, 456 "Topology Independent Fast Reroute using Segment Routing", 457 draft-ietf-rtgwg-segment-routing-ti-lfa-03 (work in 458 progress), March 2020. 460 [I-D.ietf-rtgwg-srv6-egress-protection] 461 Hu, Z., Chen, H., Chen, H., Wu, P., Toy, M., Cao, C., Liu, 462 L., and X. Liu, "SRv6 Path Egress Protection", draft-ietf- 463 rtgwg-srv6-egress-protection-00 (work in progress), March 464 2020. 466 [I-D.ietf-spring-srv6-network-programming] 467 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 468 Matsushima, S., and Z. Li, "SRv6 Network Programming", 469 draft-ietf-spring-srv6-network-programming-16 (work in 470 progress), June 2020. 472 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 473 Requirement Levels", BCP 14, RFC 2119, 474 DOI 10.17487/RFC2119, March 1997, 475 . 477 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 478 (IPv6) Specification", STD 86, RFC 8200, 479 DOI 10.17487/RFC8200, July 2017, 480 . 482 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 483 Decraene, B., Litkowski, S., and R. Shakir, "Segment 484 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 485 July 2018, . 487 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 488 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 489 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 490 . 492 9.2. Informative References 494 [I-D.shen-spring-p2mp-transport-chain] 495 Shen, Y., Zhang, Z., Parekh, R., Bidgoli, H., and Y. 496 Kamite, "Point-to-Multipoint Transport Using Chain 497 Replication in Segment Routing", draft-shen-spring-p2mp- 498 transport-chain-02 (work in progress), April 2020. 500 [I-D.voyer-pim-sr-p2mp-policy] 501 Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z. 502 Zhang, "Segment Routing Point-to-Multipoint Policy", 503 draft-voyer-pim-sr-p2mp-policy-02 (work in progress), July 504 2020. 506 [I-D.voyer-spring-sr-replication-segment] 507 Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z. 508 Zhang, "SR Replication Segment for Multi-point Service 509 Delivery", draft-voyer-spring-sr-replication-segment-04 510 (work in progress), July 2020. 512 Authors' Addresses 514 Huaimo Chen 515 Futurewei 516 Boston, MA 517 USA 519 Email: Huaimo.chen@futurewei.com 521 Mike McBride 522 Futurewei 524 Email: michael.mcbride@futurewei.com 526 Yanhe Fan 527 Casa Systems 528 USA 530 Email: yfan@casa-systems.com 532 Mehmet Toy 533 Verizon 534 USA 536 Email: mehmet.toy@verizon.com 537 Aijun Wang 538 China Telecom 539 Beiqijia Town, Changping District 540 Beijing 102209 541 China 543 Email: wangaj3@chinatelecom.cn 545 Lei Liu 546 Fujitsu 547 USA 549 Email: liulei.kddi@gmail.com 551 Xufeng Liu 552 Volta Networks 553 McLean, VA 554 USA 556 Email: xufeng.liu.ietf@gmail.com