idnits 2.17.1 draft-ietf-pim-sr-p2mp-policy-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (July 27, 2020) is 1341 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) == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-08 == Outdated reference: A later version (-19) exists of draft-ietf-spring-sr-replication-segment-00 == Outdated reference: A later version (-14) exists of draft-ietf-bess-mvpn-evpn-aggregation-label-03 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Voyer, Ed. 3 Internet-Draft Bell Canada 4 Intended status: Standards Track C. Filsfils 5 Expires: January 28, 2021 R. Parekh 6 Cisco Systems, Inc. 7 H. Bidgoli 8 Nokia 9 Z. Zhang 10 Juniper Networks 11 July 27, 2020 13 Segment Routing Point-to-Multipoint Policy 14 draft-ietf-pim-sr-p2mp-policy-00 16 Abstract 18 This document describes an architecture to construct a Point-to- 19 Multipoint (P2MP) tree to deliver Multi-point services in a Segment 20 Routing domain. A SR P2MP tree is constructed by stitching a set of 21 Replication segments together. A SR Point-to-Multipoint (SR P2MP) 22 Policy is used to define and instantiate a P2MP tree which is 23 computed by a PCE. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on January 28, 2021. 48 Copyright Notice 50 Copyright (c) 2020 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. P2MP Tree . . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2.1. Sharing Replication segments across P2MP trees . . . . . 4 68 3. SR P2MP Policy . . . . . . . . . . . . . . . . . . . . . . . 5 69 4. Using Controller to build a P2MP Tree . . . . . . . . . . . . 6 70 4.1. Provisioning SR P2MP Policy Creation . . . . . . . . . . 6 71 4.1.1. API . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 4.1.2. Invoking API . . . . . . . . . . . . . . . . . . . . 7 73 4.2. P2MP Tree Computation . . . . . . . . . . . . . . . . . . 7 74 4.2.1. Topology Discovery . . . . . . . . . . . . . . . . . 8 75 4.2.2. Capability and Attribute Discovery . . . . . . . . . 8 76 4.3. Instantiating P2MP tree on nodes . . . . . . . . . . . . 8 77 4.3.1. PCEP . . . . . . . . . . . . . . . . . . . . . . . . 8 78 4.3.2. BGP . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 4.3.3. NetConf . . . . . . . . . . . . . . . . . . . . . . . 8 80 4.4. Protection . . . . . . . . . . . . . . . . . . . . . . . 9 81 4.4.1. Local Protection . . . . . . . . . . . . . . . . . . 9 82 4.4.2. Path Protection . . . . . . . . . . . . . . . . . . . 9 83 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 85 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 86 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 87 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 88 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 89 9.2. Informative References . . . . . . . . . . . . . . . . . 11 90 Appendix A. Illustration of SR P2MP Policy and P2MP Tree . . . . 11 91 A.1. P2MP Tree with non-adjacent Replication Segments . . . . 12 92 A.2. P2MP Tree with adjacent Replication Segments . . . . . . 14 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 95 1. Introduction 97 A Multi-point service delivery could be realized via P2MP trees in a 98 Segment Routing domain [RFC8402]. A P2MP tree spans from a Root node 99 to a set of Leaf nodes via intermediate Replication nodes. It 100 consists of a Replication segment 101 [I-D.ietf-spring-sr-replication-segment] at the root node, one or 102 more Replication segments at Leaf nodes and intermediate Replication 103 nodes. The Replication segments are stitched together. 105 A Segment Routing P2MP policy, a variant of the SR Policy 106 [I-D.ietf-spring-segment-routing-policy], is used to define a P2MP 107 tree. A PCE is used to compute the tree from the Root node to the 108 set of Leaf nodes via a set of replication nodes. The PCE then 109 instantiates the P2MP tree in the SR domain by signaling Replication 110 segments to Root, replication and Leaf nodes using various protocols 111 (PCEP, BGP, NetConf etc.). 113 2. P2MP Tree 115 A P2MP tree in a SR domain connects a Root to a set of Leaf nodes via 116 a set of intermediate Replication nodes. It consists of a 117 Replication segment at the root stitched to Replication segments at 118 intermediate Replication nodes eventually reaching the Leaf nodes. 120 The Replication SID of the Replication Segment at Root node is called 121 Tree-SID. The Tree-SID SHOULD also be used as Replication SID of 122 Replication segments at Replication and Leaf nodes. The Replication 123 segments at Replication and Leaf nodes MAY use Replication SIDs that 124 are not same as the Tree-SID. 126 The Replication segment at Root of a P2MP tree MUST be associated 127 with that P2MP tree (i.e. identifier in SR P2MP 128 policy section below) to map a Multi-point service to the tree. A 129 Replication segment that terminates a P2MP tree at a Leaf node MUST 130 be associated with the P2MP tree to determine the context for a 131 Multi-point service. The The information that can be used to derive 132 this association is specific to encoding of the protocol (PCEP, BGP, 133 NetConf etc.) used to instantiate the Replication segment for a P2MP 134 tree. Replication segments at intermediate Replication nodes of a 135 tree are also associated with that tree. 137 A PCE MAY decide not instantiate Replication segments at Leaf nodes 138 of a P2MP tree if it is known a priori that Multi-point services 139 mapped to the P2MP tree can be identified using a context that is 140 globally unique in SR domain. Multi-point service contexts assigned 141 from "Domain-wide Common Block" (DCB) 142 [I-D.ietf-bess-mvpn-evpn-aggregation-label] are an example of such 143 globally unique contexts. A Segment Routing Global Block (SRGB) 144 [RFC8402] MAY be used to allocate globally unique Multi-point service 145 contexts, but it is NOT RECOMMENDED to do so as the service contexts 146 only need to be unique at service edge nodes. In this case, 147 Replication nodes connecting to Leaf nodes SHOULD use Penultimate-Hop 148 Pop (PHP) behavior to pop Tree-SID from a packet. 150 A packet steered into a P2MP tree is replicated by the Replication 151 segment at Root node to each downstream node in the Replication 152 segment, with the Replication SID of the Replication Segment at the 153 downstream node. A downstream node could be a Leaf node or an 154 intermediate Replication node. In the latter case, replication 155 continues with the Replication segments until all Leaf nodes are 156 reached. A packet is steered into a P2MP tree in two ways: 158 o Based on a local policy-based routing at the Root node. 160 o Based on steering via the Tree-SID at the Root node. 162 2.1. Sharing Replication segments across P2MP trees 164 Two or more P2MP trees MAY share a Replication segment at Root or 165 Replication nodes if at minimum as the first condition below is 166 satisfied. A tree always has its own Replication segment at its root 167 even if shares another Replication segment. A tree that shares 168 another Replication segment may or may not have its own Replication 169 segment on its Leaf nodes. If not, the second and third conditions 170 apply to such situations. 172 1. The Leaf nodes reached via a shared Replication segment must be 173 subset of Leaf or Replication nodes of the P2MP trees that shares 174 this segment. Note if a Replication segment is shared, all its 175 downstream Replication segments are also shared. 177 2. Some Multi-point services realized by the P2MP trees may need 178 service context (e.g. packets are for certain VPNs, and/or from 179 certain nodes). If the trees do not have their own Replication 180 segments at their Leaf nodes then the packets transported on the 181 P2MP trees MUST carry a service context that does not rely on the 182 tree or root identification, e.g. a service label assigned from 183 Domain-wide Common Block or common SRGB. 185 3. For some Multi-point services using P2MP trees that share 186 Replication segments, packets transported on these trees MAY 187 require a Tree context (e.g. MVPN Extranet [RFC7900] to avoid 188 certain ambiguities - see Section 2.3.1 of RFC 7900). In this 189 case, the trees MUST have their own Replication segments on the 190 Leaf nodes. This is similar to "tunnel stacking" concept. 192 Sharing of a Replication segment for P2MP trees is OPTIONAL. Exact 193 procedures to ensure validity of above conditions across PM2P 194 services on nodes of a Segment Routing domain are outside the scope 195 of this document. 197 3. SR P2MP Policy 199 The SR P2MP policy is a variant of an SR policy 200 [I-D.ietf-spring-segment-routing-policy] and is used to instantiate 201 SR P2MP trees. 203 A SR P2MP Policy is identified by the tuple , where: 205 o Root: The address of Root node of P2MP tree instantiated by the SR 206 P2MP Policy 208 o Tree-ID: A identifier that is unique in context of the Root. This 209 is an unsigned 32-bit number. 211 A SR P2MP Policy is defined by following elements: 213 o Leaf nodes: A set of nodes that terminate the P2MP trees. 215 o Candidate Paths: See below. 217 A SR P2MP policy is provisioned on a PCE to instantiate the P2MP 218 tree. The Tree-SID SHOULD be used as Binding SID of the P2MP policy. 219 A PCE computes the P2MP tree and instantiates Replication segments at 220 Root, Replication and Leaf nodes. When Replication segments are not 221 shared across P2MP trees, the Root and Tree-ID of the SR P2MP policy 222 are mapped to Replication-ID element of the Replication segment 223 identifier i.e the SR Replication segment identifier is . A shared Replication segment MAY be identified with 225 zero Root-ID address (0.0.0.0 for IPv4 and :: for IPv6) and a 226 Replication-ID that is unique in context of Node address where the 227 Replication segment is instantiated when it is not associated a 228 particular tree. 230 A SR P2MP Policy has one or more Candidate paths. The active 231 Candidate path is selected based on the tie breaking rules amongst 232 the candidate-paths as specified 233 in[I-D.ietf-spring-segment-routing-policy]. Each candidate path has 234 a set of topological/resource constraints and/or optimization 235 objectives which determine the P2MP tree for that Candidate path. 236 Tree-SID is an identifier of the P2MP tree of the candidate path in 237 the forwarding plane. It is instantiated in the forwarding plane at 238 Root node, intermediate Replication nodes and Leaf nodes. The Tree- 239 SID MAY be different at Replication and Leaf nodes. 241 4. Using Controller to build a P2MP Tree 243 A P2MP tree can be built using a Path Computation Element (PCE). 244 This section outlines a high-level architecture for such an approach. 246 North Bound South Bound 247 Programming ..... Programming 248 Interface Interface 249 | 250 | 251 v 252 +-----+ .......................... 253 .............| PCE | ............. . 254 . +-----+ . . 255 . . . . 256 . . . . 257 . . . . 258 . . V . 259 . . +----+ . 260 . . | N3 | . 261 . . +----+ . 262 . . | Leaf (L2) . 263 . . | . 264 . . | . 265 V V | V 266 +----+ +----+ -------------- +----+ 267 | N1 |----------| N2 |-------------------------| N4 | 268 +----+ +----+ +----+ 269 Root (R) Replication node (M) Leaf (L1) 271 Figure 1: Centralized Control Plane Model 273 4.1. Provisioning SR P2MP Policy Creation 275 A SR P2MP policy can be instantiated and maintained in a centralized 276 fashion using a Path Computation Element (PCE). 278 4.1.1. API 280 North-bound APIs on a PCE can be used to: 282 1. Create SR P2MP policy 284 2. Delete SR P2MP policy 286 3. Update SR P2MP policy 287 4. Create a Candidate Path for SR P2MP policy 289 5. Update a Candidate Path for SR P2MP policy 291 6. Delete a Candidate Path for SR P2MP policy 293 4.1.2. Invoking API 295 Interaction with a PCE can be via PCEP, REST, Netconf, gRPC, CLI. 296 Yang model shall be be developed for this purpose as well. 298 4.2. P2MP Tree Computation 300 An entity (an operator, a network node or a machine) provisions a SR 301 P2MP policy by specifying the addresses of the root (R) and set of 302 leaves {L} as well as Traffic Engineering (TE) attributes of 303 Candidate paths via a suitable North-Bound API. The PCE computes the 304 tree of Active candidate path. The PCE MAY compute P2MP trees for 305 all Candidate paths., If tree computation is successful, PCE 306 instantiates the P2MP tree(s) using Replication segments on Root, 307 Replication, and Leaf nodes. 309 Candidate path constraints shall include link color affinity, 310 bandwidth, disjointness (link, node, SRLG), delay bound, link loss, 311 etc. Candidate path shall be optimized based on IGP or TE metric or 312 link latency. 314 The Tree SID of Candidate path of a SR P2MP policy can be either 315 dynamically allocated by the PCE or statically assigned by entity 316 provisioning the SR P2MP policy. Ideally, same Tree-SID SHOULD be 317 used for Replication segments at Root, Replication, and Leaf nodes. 318 Different Tree-SIDs MAY be used at replication node(s) if it is not 319 feasible to use same Tree SID. 321 A PCE can modify a P2MP tree following network element failure or in 322 case a better path can be found based on the new network state. In 323 this case, the PCE may want to setup the new instance of the tree and 324 remove the old instance of the tree from the network in order to 325 minimize traffic loss. In this case, the instances of trees for all 326 the Candidate paths of a P2MP policy can be identified by an 327 Instance-ID which is unique in context of the P2MP policy. As such, 328 the identifier of non-shared Replication segments used to instantiate 329 these trees becomes . 331 A PCE shall be capable of computing paths across multiple IGP areas 332 or levels as well as Autonomous Systems (ASs). 334 4.2.1. Topology Discovery 336 A PCE shall learn network topology, TE attributes of link/node as 337 well as SIDs via dynamic routing protocols (IGP and/or BGP-LS). It 338 may be possible for entities to pass topology information to PCE via 339 north-bound API. 341 4.2.2. Capability and Attribute Discovery 343 It shall be possible for a node to advertise SR P2MP tree capability 344 via IGP and/or BGP-LS. Similarly, a PCE can also advertise its P2MP 345 tree computation capability via IGP and/or BGP-LS. Capability 346 advertisement allows a network node to dynamically choose one or more 347 PCE(s) to obtain services pertaining to SR P2MP policies, as well a 348 PCE to dynamically identify SR P2MP tree capable nodes. 350 4.3. Instantiating P2MP tree on nodes 352 Once a PCE computes a P2MP tree for Candidate path of SR P2MP policy, 353 it needs to instantiate the tree on the relevant network nodes via 354 Replication segments. The PCE can use various protocols to program 355 the Replication segments as described below. 357 4.3.1. PCEP 359 PCE Protocol (PCEP)has been traditionally used: 361 1. For a head-end to obtain paths from a PCE. 363 2. A PCE to instantiate SR policies. 365 PCEP protocol can be stateful in that a PCE can have a stateful 366 control of an SR policy on a head-end which has delegated the control 367 of the SR policy to the PCE. PCEP shall be extended to provision and 368 maintain SR P2MP trees in a stateful fashion. 370 4.3.2. BGP 372 BGP has been extended to instantiate and report SR policies. It 373 shall be extended to instantiate and maintain P2MP trees for SR P2MP 374 policies. 376 4.3.3. NetConf 378 TBD 380 4.4. Protection 382 4.4.1. Local Protection 384 A network link, node or path on the tree of a P2MP tree can be 385 protected using SR policies computed by PCE. The backup SR policies 386 shall be programmed in forwarding plane in order to minimize traffic 387 loss when the protected link/node fails. It is also possible to use 388 node local Fast Re-Route protection mechanisms (LFA) to protect link/ 389 nodes of P2MP tree. 391 4.4.2. Path Protection 393 It is possible for PCE create a disjoint backup tree for providing 394 end-to-end path protection. 396 5. IANA Considerations 398 This document makes no request of IANA. 400 6. Security Considerations 402 There are no additional security risks introduced by this design. 404 7. Acknowledgements 406 The authors would like to acknowledge Siva Sivabalan, Mike Koldychev 407 and Vishnu Pavan Beeram for their valuable inputs.. 409 8. Contributors 411 Clayton Hassen 412 Bell Canada 413 Vancouver 414 Canada 416 Email: clayton.hassen@bell.ca 418 Kurtis Gillis 419 Bell Canada 420 Halifax 421 Canada 423 Email: kurtis.gillis@bell.ca 425 Arvind Venkateswaran 426 Cisco Systems, Inc. 427 San Jose 428 US 430 Email: arvvenka@cisco.com 432 Zafar Ali 433 Cisco Systems, Inc. 434 US 436 Email: zali@cisco.com 438 Swadesh Agrawal 439 Cisco Systems, Inc. 440 San Jose 441 US 443 Email: swaagraw@cisco.com 445 Jayant Kotalwar 446 Nokia 447 Mountain View 448 US 450 Email: jayant.kotalwar@nokia.com 452 Tanmoy Kundu 453 Nokia 454 Mountain View 455 US 457 Email: tanmoy.kundu@nokia.com 459 Andrew Stone 460 Nokia 461 Ottawa 462 Canada 464 Email: andrew.stone@nokia.com 466 Tarek Saad 467 Juniper Networks 468 Canada 470 Email:tsaad@juniper.net 472 9. References 474 9.1. Normative References 476 [I-D.ietf-spring-segment-routing-policy] 477 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 478 P. Mattes, "Segment Routing Policy Architecture", draft- 479 ietf-spring-segment-routing-policy-08 (work in progress), 480 July 2020. 482 [I-D.ietf-spring-sr-replication-segment] 483 Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z. 484 Zhang, "SR Replication Segment for Multi-point Service 485 Delivery", draft-ietf-spring-sr-replication-segment-00 486 (work in progress), July 2020. 488 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 489 Requirement Levels", BCP 14, RFC 2119, 490 DOI 10.17487/RFC2119, March 1997, 491 . 493 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 494 Decraene, B., Litkowski, S., and R. Shakir, "Segment 495 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 496 July 2018, . 498 9.2. Informative References 500 [I-D.ietf-bess-mvpn-evpn-aggregation-label] 501 Zhang, Z., Rosen, E., Lin, W., Li, Z., and I. Wijnands, 502 "MVPN/EVPN Tunnel Aggregation with Common Labels", draft- 503 ietf-bess-mvpn-evpn-aggregation-label-03 (work in 504 progress), October 2019. 506 [RFC7900] Rekhter, Y., Ed., Rosen, E., Ed., Aggarwal, R., Cai, Y., 507 and T. Morin, "Extranet Multicast in BGP/IP MPLS VPNs", 508 RFC 7900, DOI 10.17487/RFC7900, June 2016, 509 . 511 Appendix A. Illustration of SR P2MP Policy and P2MP Tree 513 Consider the following topology: 515 R3------R6 516 PCE--/ \ 517 R1----R2----R5-----R7 518 \ / 519 +--R4---+ 521 Figure 1 523 In these examples, the Node-SID of a node Rn is N-SIDn and Adjacency- 524 SID from node Rm to node Rn is A-SIDmn. Interface between Rm and Rn 525 is Lmn. 527 Assume PCE is provisioned following SR P2MP policy at Root R1 with 528 Tree-ID T-ID: 530 SR P2MP Policy : 531 Leaf Nodes: {R2, R6, R7} 532 Candidate-path 1: 533 Optimize: IGP metric 534 Tree-SID: T-SID1 536 The PCE is responsible for P2MP tree computation. Assume PCE 537 instantiates P2MP trees by signalling non-shared Replication segments 538 i.e. Replication-ID of these Replication Segments is . 539 If a Candidat-path can have multiple instances of P2MP trees, the 540 Replication-ID is . In this example, we 541 assume one instance of P2MP tree for a candidate-path. All 542 Replication Segments use the Tree-SID T-SID1 as Replication-SID. 544 A.1. P2MP Tree with non-adjacent Replication Segments 546 Assume PCE computes a P2MP tree with Root node R1, Intermediate and 547 Leaf node R2, and Leaf nodes R6 and R7. The PCE instantiates the 548 P2MP tree by stitching Replication Segments at R1, R2, R6 and R7. 549 Replication Segment at R1 replicates to R2. Replication Segment at 550 R2 replicates to R6 and R7. Note nodes R3, R4 and R5 do not have any 551 Replication Segment state for the tree. 553 The Replication Segment state at nodes R1, R2, R6 and R7 is shown 554 below. 556 Replication Segment at R1: 558 Replication Segment : 559 Replication SID: T-SID1 560 Replication State: 561 R2: L12> 563 Replication to R2 steers packet directly to the node on interface 564 L12. 566 Replication Segment at R2: 568 Replication Segment : 569 Replication SID: T-SID1 570 Replication State: 571 R2: 572 R6: 573 R7: 575 R2 is a Bud-Node. It performs role of Leaf as well as a transit node 576 replicating to R6 and R7. Replication to R6, using N-SID6, steers 577 packet via IGP shortest path to that node. Replication to R7, using 578 N-SID7, steers packet via IGP shortest path to R7 via either R5 or R4 579 based on ECMP hashing. 581 Replication Segment at R6: 583 Replication Segment : 584 Replication SID: T-SID1 585 Replication State: 586 R6: 588 Replication Segment at R7: 590 Replication Segment : 591 Replication SID: T-SID1 592 Replication State: 593 R7: 595 When a packet is steered into the SR P2MP Policy at R1: 597 o Since R1 is directly connected to R2, R1 performs PUSH operation 598 with just label for the replicated copy and sends it to 599 R2 on interface L12. 601 o R2, as Leaf, performs NEXT operation, pops T-SID1 label and 602 delivers the payload. For replication to R6, R2 performs a PUSH 603 operation of N-SID6, to send label stack to R3. 604 R3 is the penultimate hop for N-SID6; it performs penultimate hop 605 popping, which corresponds to the NEXT operation and the packet is 606 then sent to R6 with in the label stack. For replication 607 to R7, R2 performs a PUSH operation of N-SID7, to send 608 label stack to R4, one of IGP ECMP nexthops 609 towards R7. R4 is the penultimate hop for N-SID6; it performs 610 penultimate hop popping, which corresponds to the NEXT operation 611 and the packet is then sent to R7 with in the label 612 stack. 614 o R6, as Leaf, performs NEXT operation, pops T-SID1 label and 615 delivers the payload. 617 o R7, as Leaf, performs NEXT operation, pops R-SID7 label and 618 delivers the payload. 620 A.2. P2MP Tree with adjacent Replication Segments 622 Assume PCE computes a P2MP tree with Root node R1, Intermediate and 623 Leaf node R2, Intermediate nodes R3 and R5, and Leaf nodes R6 and R7. 624 The PCE instantiates the P2MP tree by stitching Replication Segments 625 at R1, R2, R3, R5, R6 and R7. Replication Segment at R1 replicates 626 to R2. Replication Segment at R2 replicates to R3 and R5. 627 Replication segment at R3 replicates to R6. Replication segment at 628 R5 replicates to R7. Note node R4 does not have any Replication 629 Segment state for the tree. 631 The Replication Segment state at nodes R1, R2, R3, R5, R6 and R7 is 632 shown below. 634 Replication Segment at R1: 636 Replication Segment : 637 Replication SID: T-SID1 638 Replication State: 639 R2: L12> 641 Replication to R2 steers packet directly to tje node on interface 642 L12. 644 Replication Segment at R2: 646 Replication Segment : 647 Replication SID: T-SID1 648 Replication State: 649 R2: 650 R3: L23> 651 R5: L25> 653 R2 is a Bud-Node. It performs role of Leaf as well as a transit node 654 replicating to R3 and R5. Replication to R3, steers packet directly 655 to the node on L23. Replication to R5, steers packet directly to the 656 node on L25. 658 Replication Segment at R3: 660 Replication Segment : 661 Replication SID: T-SID1 662 Replication State: 663 R6: L36> 665 Replication to R6, steers packet directly to the node on L36. 667 Replication Segment at R5: 669 Replication Segment : 670 Replication SID: T-SID1 671 Replication State: 672 R7: L57> 674 Replication to R7, steers packet directly to the node on L57. 676 Replication Segment at R6: 678 Replication Segment : 679 Replication SID: T-SID1 680 Replication State: 681 R6: 683 Replication Segment at R7: 685 Replication Segment : 686 Replication SID: T-SID1 687 Replication State: 688 R7: 690 When a packet is steered into the SR P2MP Policy at R1: 692 o Since R1 is directly connected to R2, R1 performs PUSH operation 693 with just label for the replicated copy and sends it to 694 R2 on interface L12. 696 o R2, as Leaf, performs NEXT operation, pops T-SID1 label and 697 delivers the payload. It also performs CONTINUE operation on 698 T-SID1 for replication to R3 and R5. For replication to R6, R2 699 sends label stack to R3 on interface L23. For 700 replication to R5, R2 sends label stack to R5 on 701 interface L25. 703 o R3 performs CONTINUE operation on T-SID1 for replication to R6 and 704 sends label stack to R6 on interface L36. 706 o R5 performs CONTINUE operation on T-SID1 for replication to R7 and 707 sends label stack to R7 on interface L57. 709 o R6, as Leaf, performs NEXT operation, pops T-SID1 label and 710 delivers the payload. 712 o R7, as Leaf, performs NEXT operation, pops R-SID7 label and 713 delivers the payload. 715 Authors' Addresses 717 Daniel Voyer (editor) 718 Bell Canada 719 Montreal 720 CA 722 Email: daniel.voyer@bell.ca 724 Clarence Filsfils 725 Cisco Systems, Inc. 726 Brussels 727 BE 729 Email: cfilsfil@cisco.com 731 Rishabh Parekh 732 Cisco Systems, Inc. 733 San Jose 734 US 736 Email: riparekh@cisco.com 738 Hooman Bidgoli 739 Nokia 740 Ottawa 741 CA 743 Email: hooman.bidgoli@nokia.com 745 Zhaohui Zhang 746 Juniper Networks 748 Email: zzhang@juniper.net