idnits 2.17.1 draft-ietf-pim-sr-p2mp-policy-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 : ---------------------------------------------------------------------------- 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 (October 30, 2020) is 1272 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: 'Constraints' is mentioned on line 299, but not defined == Missing Reference: 'Optimization' is mentioned on line 299, but not defined == 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 (~~), 7 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: May 3, 2021 R. Parekh 6 Cisco Systems, Inc. 7 H. Bidgoli 8 Nokia 9 Z. Zhang 10 Juniper Networks 11 October 30, 2020 13 Segment Routing Point-to-Multipoint Policy 14 draft-ietf-pim-sr-p2mp-policy-01 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 May 3, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 4.3.3. NetConf . . . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . . . . . 10 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 . . . . 12 91 A.1. P2MP Tree with non-adjacent Replication Segments . . . . 12 92 A.1.1. SR-MPLS . . . . . . . . . . . . . . . . . . . . . . . 13 93 A.2. P2MP Tree with adjacent Replication Segments . . . . . . 14 94 A.2.1. SR-MPLS . . . . . . . . . . . . . . . . . . . . . . . 14 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 97 1. Introduction 99 A Multi-point service delivery could be realized via P2MP trees in a 100 Segment Routing domain [RFC8402]. A P2MP tree spans from a Root node 101 to a set of Leaf nodes via intermediate Replication nodes. It 102 consists of a Replication segment 103 [I-D.ietf-spring-sr-replication-segment] at the root node, one or 104 more Replication segments at Leaf nodes and intermediate Replication 105 nodes. The Replication segments are stitched together. 107 A Segment Routing P2MP policy, a variant of the SR Policy 108 [I-D.ietf-spring-segment-routing-policy], is used to define a P2MP 109 tree. A PCE is used to compute the tree from the Root node to the 110 set of Leaf nodes via a set of replication nodes. The PCE then 111 instantiates the P2MP tree in the SR domain by signaling Replication 112 segments to Root, replication and Leaf nodes using various protocols 113 (PCEP, BGP, NetConf etc.). 115 2. P2MP Tree 117 A P2MP tree in a SR domain connects a Root to a set of Leaf nodes via 118 a set of intermediate Replication nodes. It consists of a 119 Replication segment at the root stitched to Replication segments at 120 intermediate Replication nodes eventually reaching the Leaf nodes. 122 The Replication SID of the Replication Segment at Root node is called 123 Tree-SID. The Tree-SID SHOULD also be used as Replication SID of 124 Replication segments at Replication and Leaf nodes. The Replication 125 segments at Replication and Leaf nodes MAY use Replication SIDs that 126 are not same as the Tree-SID. 128 The Replication segment at Root of a P2MP tree MUST be associated 129 with that P2MP tree (i.e. identifier in SR P2MP 130 policy section below) to map a Multi-point service to the tree. A 131 Replication segment that terminates a P2MP tree at a Leaf node MUST 132 be associated with the P2MP tree to determine the context for a 133 Multi-point service. The The information that can be used to derive 134 this association is specific to encoding of the protocol (PCEP, BGP, 135 NetConf etc.) used to instantiate the Replication segment for a P2MP 136 tree. Replication segments at intermediate Replication nodes of a 137 tree are also associated with that tree. 139 A PCE MAY decide not instantiate Replication segments at Leaf nodes 140 of a P2MP tree if it is known a priori that Multi-point services 141 mapped to the P2MP tree can be identified using a context that is 142 globally unique in SR domain. A Multi-point service context assigned 143 from "Domain-wide Common Block" (DCB) 144 [I-D.ietf-bess-mvpn-evpn-aggregation-label] is an example of globally 145 unique context. SR-MPLS Segment Routing Global Block (SRGB) 146 [RFC8402] MAY be used to allocate globally unique Multi-point service 147 contexts, but it is NOT RECOMMENDED to do so as the service contexts 148 only need to be unique at service edge nodes. In this case, 149 Replication nodes connecting to Leaf nodes SHOULD use Penultimate-Hop 150 Pop (PHP) behavior to pop Tree-SID from a packet. 152 A packet steered into a P2MP tree is replicated by the Replication 153 segment at Root node to each downstream node in the Replication 154 segment, with the Replication SID of the Replication Segment at the 155 downstream node. A downstream node could be a Leaf node or an 156 intermediate Replication node. In the latter case, replication 157 continues with the Replication segments until all Leaf nodes are 158 reached. A packet is steered into a P2MP tree in two ways: 160 o Based on a local policy-based routing at the Root node. 162 o Based on steering via the Tree-SID at the Root node. 164 2.1. Sharing Replication segments across P2MP trees 166 Two or more P2MP trees MAY share a Replication segment at Root or 167 Replication nodes if at minimum the first condition below is 168 satisfied. A tree always has its own Replication segment at its root 169 even if shares another Replication segment. A tree that shares 170 another Replication segment may or may not have its own Replication 171 segment on its Leaf nodes. If not, the second and third conditions 172 apply to such situations. 174 1. The Leaf nodes reached via a shared Replication segment must be 175 subset of Leaf or Replication nodes of the P2MP trees that share 176 this segment. Note if a Replication segment is shared, all its 177 downstream Replication segments are also shared. 179 2. Some Multi-point services realized by the P2MP trees may need 180 service context (e.g. packets are for certain VPNs, and/or from 181 certain nodes). If the trees do not have their own Replication 182 segments at their Leaf nodes then the packets transported on the 183 P2MP trees MUST carry a service context that does not rely on the 184 tree or root identification, e.g. a service label assigned from 185 Domain-wide Common Block or common SRGB for SR-MPLS. 187 3. For some Multi-point services using P2MP trees that share 188 Replication segments, packets transported on these trees MAY 189 require a Tree context (e.g. MVPN Extranet [RFC7900] to avoid 190 certain ambiguities - see Section 2.3.1 of RFC 7900). In this 191 case, the trees MUST have their own Replication segments on the 192 Leaf nodes. For SR-MPLS, this is similar to "tunnel stacking" 193 concept. 195 Sharing of a Replication segment for P2MP trees is OPTIONAL. Exact 196 procedures to ensure validity of above conditions across PM2P 197 services on nodes of a Segment Routing domain are outside the scope 198 of this document. 200 3. SR P2MP Policy 202 The SR P2MP policy is a variant of an SR policy 203 [I-D.ietf-spring-segment-routing-policy] and is used to instantiate 204 SR P2MP trees. 206 A SR P2MP Policy is identified by the tuple , where: 208 o Root: The address of Root node of P2MP tree instantiated by the SR 209 P2MP Policy 211 o Tree-ID: A identifier that is unique in context of the Root. This 212 is an unsigned 32-bit number. 214 A SR P2MP Policy is defined by following elements: 216 o Leaf nodes: A set of nodes that terminate the P2MP trees. 218 o Candidate Paths: See below. 220 A SR P2MP policy is provisioned on a PCE to instantiate the P2MP 221 tree. The Tree-SID SHOULD be used as Binding SID of the P2MP policy. 222 A PCE computes the P2MP tree and instantiates Replication segments at 223 Root, Replication and Leaf nodes. When Replication segments are not 224 shared across P2MP trees, the Root and Tree-ID of the SR P2MP policy 225 are mapped to Replication-ID element of the Replication segment 226 identifier i.e the SR Replication segment identifier is . A shared Replication segment MAY be identified with 228 zero Root-ID address (0.0.0.0 for IPv4 and :: for IPv6) and a 229 Replication-ID that is unique in context of Node address where the 230 Replication segment is instantiated when it is not associated a 231 particular tree. 233 A SR P2MP Policy has one or more Candidate paths. The active 234 Candidate path is selected based on the tie breaking rules amongst 235 the candidate-paths as specified 236 in[I-D.ietf-spring-segment-routing-policy]. Each candidate path has 237 a set of topological/resource constraints and/or optimization 238 objectives which determine the P2MP tree for that Candidate path. 239 Tree-SID is an identifier of the P2MP tree of the candidate path in 240 the forwarding plane. It is instantiated in the forwarding plane at 241 Root node, intermediate Replication nodes and Leaf nodes. The Tree- 242 SID MAY be different at Replication and Leaf nodes. 244 4. Using Controller to build a P2MP Tree 246 A P2MP tree can be built using a Path Computation Element (PCE). 247 This section outlines a high-level architecture for such an approach. 249 North Bound South Bound 250 Programming ..... Programming 251 Interface Interface 252 | 253 | 254 v 255 +-----+ .......................... 256 .............| PCE | ............. . 257 . +-----+ . . 258 . . . . 259 . . . . 260 . . . . 261 . . V . 262 . . +----+ . 263 . . | N3 | . 264 . . +----+ . 265 . . | Leaf (L2) . 266 . . | . 267 . . | . 268 V V | V 269 +----+ +----+ -------------- +----+ 270 | N1 |----------| N2 |-------------------------| N4 | 271 +----+ +----+ +----+ 272 Root (R) Replication node (M) Leaf (L1) 274 Figure 1: Centralized Control Plane Model 276 4.1. Provisioning SR P2MP Policy Creation 278 A SR P2MP policy can be instantiated and maintained in a centralized 279 fashion using a Path Computation Element (PCE). 281 4.1.1. API 283 North-bound APIs on a PCE can be used to: 285 1. Create SR P2MP policy: CreateSRP2MPPolicy 286 2. Delete SR P2MP policy: DeleteSRP2MPPolicy 288 3. Modify SR P2MP policy Leaf Set: SRP2MPPolicyLeafSetModify 291 4. Create a Candidate Path for SR P2MP policy: 292 CreateSRP2MPCandidatePath> 294 5. Delete a Candidate Path for SR P2MP policy: 295 DeleteSRP2MPCandidatePath> 297 6. Update a Candidate Path for SR P2MP policy: 298 UpdateSRP2MPCandidatePath, Preference, 299 [Constraints], [Optimization], ...> 301 CP-ID is identifier of a Candidate Path within a SR P2MP policy. One 302 possible identifier is the tuple as specified in 304 [I-D.ietf-spring-segment-routing-policy]. 306 Note these are conceptual APIs. Actual implementations may offer 307 different APIs as long as they provide same functionality. For 308 example, API might allow symbolic name to be assigned for a P2MP 309 policy or APIs might allow individual Leaf nodes to be added or 310 deleted from a policy instead of an update operation. 312 4.1.2. Invoking API 314 Interaction with a PCE can be via PCEP, REST, Netconf, gRPC, CLI. 315 Yang model shall be be developed for this purpose as well. 317 4.2. P2MP Tree Computation 319 An entity (an operator, a network node or a machine) provisions a SR 320 P2MP policy by specifying the addresses of the root (R) and set of 321 leaves {L} as well as Traffic Engineering (TE) attributes of 322 Candidate paths via a suitable North-Bound API. The PCE computes the 323 tree of Active candidate path. The PCE MAY compute P2MP trees for 324 all Candidate paths., If tree computation is successful, PCE 325 instantiates the P2MP tree(s) using Replication segments on Root, 326 Replication, and Leaf nodes. 328 Candidate path constraints shall include link color affinity, 329 bandwidth, disjointness (link, node, SRLG), delay bound, link loss, 330 etc. Candidate path shall be optimized based on IGP or TE metric or 331 link latency. 333 The Tree SID of Candidate path of a SR P2MP policy can be either 334 dynamically allocated by the PCE or statically assigned by entity 335 provisioning the SR P2MP policy. Ideally, same Tree-SID SHOULD be 336 used for Replication segments at Root, Replication, and Leaf nodes. 337 Different Tree-SIDs MAY be used at replication node(s) if it is not 338 feasible to use same Tree SID. 340 A PCE can modify a P2MP tree following network element failure or in 341 case a better path can be found based on the new network state. In 342 this case, the PCE may want to setup the new instance of the tree and 343 remove the old instance of the tree from the network in order to 344 minimize traffic loss. In this case, the instances of trees for all 345 the Candidate paths of a P2MP policy can be identified by an 346 Instance-ID which is unique in context of the P2MP policy. As such, 347 the identifier of non-shared Replication segments used to instantiate 348 these trees becomes . 350 A PCE shall be capable of computing paths across multiple IGP areas 351 or levels as well as Autonomous Systems (ASs). 353 4.2.1. Topology Discovery 355 A PCE shall learn network topology, TE attributes of link/node as 356 well as SIDs via dynamic routing protocols (IGP and/or BGP-LS). It 357 may be possible for entities to pass topology information to PCE via 358 north-bound API. 360 4.2.2. Capability and Attribute Discovery 362 It shall be possible for a node to advertise SR P2MP tree capability 363 via IGP and/or BGP-LS. Similarly, a PCE can also advertise its P2MP 364 tree computation capability via IGP and/or BGP-LS. Capability 365 advertisement allows a network node to dynamically choose one or more 366 PCE(s) to obtain services pertaining to SR P2MP policies, as well a 367 PCE to dynamically identify SR P2MP tree capable nodes. 369 4.3. Instantiating P2MP tree on nodes 371 Once a PCE computes a P2MP tree for Candidate path of SR P2MP policy, 372 it needs to instantiate the tree on the relevant network nodes via 373 Replication segments. The PCE can use various protocols to program 374 the Replication segments as described below. 376 4.3.1. PCEP 378 PCE Protocol (PCEP)has been traditionally used: 380 1. For a head-end to obtain paths from a PCE. 382 2. A PCE to instantiate SR policies. 384 PCEP protocol can be stateful in that a PCE can have a stateful 385 control of an SR policy on a head-end which has delegated the control 386 of the SR policy to the PCE. PCEP shall be extended to provision and 387 maintain SR P2MP trees in a stateful fashion. 389 4.3.2. BGP 391 BGP has been extended to instantiate and report SR policies. It 392 shall be extended to instantiate and maintain P2MP trees for SR P2MP 393 policies. 395 4.3.3. NetConf 397 TBD 399 4.4. Protection 401 4.4.1. Local Protection 403 A network link, node or path on the tree of a P2MP tree can be 404 protected using SR policies computed by PCE. The backup SR policies 405 shall be programmed in forwarding plane in order to minimize traffic 406 loss when the protected link/node fails. It is also possible to use 407 node local Fast Re-Route protection mechanisms (LFA) to protect link/ 408 nodes of P2MP tree. 410 4.4.2. Path Protection 412 It is possible for PCE create a disjoint backup tree for providing 413 end-to-end path protection. 415 5. IANA Considerations 417 This document makes no request of IANA. 419 6. Security Considerations 421 There are no additional security risks introduced by this design. 423 7. Acknowledgements 425 The authors would like to acknowledge Siva Sivabalan, Mike Koldychev 426 and Vishnu Pavan Beeram for their valuable inputs.. 428 8. Contributors 430 Clayton Hassen 431 Bell Canada 432 Vancouver 433 Canada 435 Email: clayton.hassen@bell.ca 437 Kurtis Gillis 438 Bell Canada 439 Halifax 440 Canada 442 Email: kurtis.gillis@bell.ca 444 Arvind Venkateswaran 445 Cisco Systems, Inc. 446 San Jose 447 US 449 Email: arvvenka@cisco.com 451 Zafar Ali 452 Cisco Systems, Inc. 453 US 455 Email: zali@cisco.com 457 Swadesh Agrawal 458 Cisco Systems, Inc. 459 San Jose 460 US 462 Email: swaagraw@cisco.com 464 Jayant Kotalwar 465 Nokia 466 Mountain View 467 US 469 Email: jayant.kotalwar@nokia.com 471 Tanmoy Kundu 472 Nokia 473 Mountain View 474 US 475 Email: tanmoy.kundu@nokia.com 477 Andrew Stone 478 Nokia 479 Ottawa 480 Canada 482 Email: andrew.stone@nokia.com 484 Tarek Saad 485 Juniper Networks 486 Canada 488 Email:tsaad@juniper.net 490 9. References 492 9.1. Normative References 494 [I-D.ietf-spring-segment-routing-policy] 495 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 496 P. Mattes, "Segment Routing Policy Architecture", draft- 497 ietf-spring-segment-routing-policy-08 (work in progress), 498 July 2020. 500 [I-D.ietf-spring-sr-replication-segment] 501 Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z. 502 Zhang, "SR Replication Segment for Multi-point Service 503 Delivery", draft-ietf-spring-sr-replication-segment-00 504 (work in progress), July 2020. 506 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 507 Requirement Levels", BCP 14, RFC 2119, 508 DOI 10.17487/RFC2119, March 1997, 509 . 511 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 512 Decraene, B., Litkowski, S., and R. Shakir, "Segment 513 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 514 July 2018, . 516 9.2. Informative References 518 [I-D.ietf-bess-mvpn-evpn-aggregation-label] 519 Zhang, Z., Rosen, E., Lin, W., Li, Z., and I. Wijnands, 520 "MVPN/EVPN Tunnel Aggregation with Common Labels", draft- 521 ietf-bess-mvpn-evpn-aggregation-label-03 (work in 522 progress), October 2019. 524 [RFC7900] Rekhter, Y., Ed., Rosen, E., Ed., Aggarwal, R., Cai, Y., 525 and T. Morin, "Extranet Multicast in BGP/IP MPLS VPNs", 526 RFC 7900, DOI 10.17487/RFC7900, June 2016, 527 . 529 Appendix A. Illustration of SR P2MP Policy and P2MP Tree 531 Consider the following topology: 533 R3------R6 534 PCE--/ \ 535 R1----R2----R5-----R7 536 \ / 537 +--R4---+ 539 Figure 1 541 In these examples, the Node-SID of a node Rn is N-SIDn and Adjacency- 542 SID from node Rm to node Rn is A-SIDmn. Interface between Rm and Rn 543 is Lmn. 545 Assume PCE is provisioned following SR P2MP policy at Root R1 with 546 Tree-ID T-ID: 548 SR P2MP Policy : 549 Leaf Nodes: {R2, R6, R7} 550 Candidate-path 1: 551 Optimize: IGP metric 552 Tree-SID: T-SID1 554 The PCE is responsible for P2MP tree computation. Assume PCE 555 instantiates P2MP trees by signalling non-shared Replication segments 556 i.e. Replication-ID of these Replication Segments is . 557 If a Candidat-path can have multiple instances of P2MP trees, the 558 Replication-ID is . In this example, we 559 assume one instance of P2MP tree for a candidate-path. All 560 Replication Segments use the Tree-SID T-SID1 as Replication-SID. 562 A.1. P2MP Tree with non-adjacent Replication Segments 564 Assume PCE computes a P2MP tree with Root node R1, Intermediate and 565 Leaf node R2, and Leaf nodes R6 and R7. The PCE instantiates the 566 P2MP tree by stitching Replication Segments at R1, R2, R6 and R7. 567 Replication Segment at R1 replicates to R2. Replication Segment at 568 R2 replicates to R6 and R7. Note nodes R3, R4 and R5 do not have any 569 Replication Segment state for the tree. 571 A.1.1. SR-MPLS 573 The Replication Segment state at nodes R1, R2, R6 and R7 is shown 574 below. 576 Replication Segment at R1: 578 Replication Segment : 579 Replication SID: T-SID1 580 Replication State: 581 R2: L12> 583 Replication to R2 steers packet directly to the node on interface 584 L12. 586 Replication Segment at R2: 588 Replication Segment : 589 Replication SID: T-SID1 590 Replication State: 591 R2: 592 R6: 593 R7: 595 R2 is a Bud-Node. It performs role of Leaf as well as a transit node 596 replicating to R6 and R7. Replication to R6, using N-SID6, steers 597 packet via IGP shortest path to that node. Replication to R7, using 598 N-SID7, steers packet via IGP shortest path to R7 via either R5 or R4 599 based on ECMP hashing. 601 Replication Segment at R6: 603 Replication Segment : 604 Replication SID: T-SID1 605 Replication State: 606 R6: 608 Replication Segment at R7: 610 Replication Segment : 611 Replication SID: T-SID1 612 Replication State: 613 R7: 615 When a packet is steered into the SR P2MP Policy at R1: 617 o Since R1 is directly connected to R2, R1 performs PUSH operation 618 with just label for the replicated copy and sends it to 619 R2 on interface L12. 621 o R2, as Leaf, performs NEXT operation, pops T-SID1 label and 622 delivers the payload. For replication to R6, R2 performs a PUSH 623 operation of N-SID6, to send label stack to R3. 624 R3 is the penultimate hop for N-SID6; it performs penultimate hop 625 popping, which corresponds to the NEXT operation and the packet is 626 then sent to R6 with in the label stack. For replication 627 to R7, R2 performs a PUSH operation of N-SID7, to send 628 label stack to R4, one of IGP ECMP nexthops 629 towards R7. R4 is the penultimate hop for N-SID6; it performs 630 penultimate hop popping, which corresponds to the NEXT operation 631 and the packet is then sent to R7 with in the label 632 stack. 634 o R6, as Leaf, performs NEXT operation, pops T-SID1 label and 635 delivers the payload. 637 o R7, as Leaf, performs NEXT operation, pops R-SID7 label and 638 delivers the payload. 640 A.2. P2MP Tree with adjacent Replication Segments 642 Assume PCE computes a P2MP tree with Root node R1, Intermediate and 643 Leaf node R2, Intermediate nodes R3 and R5, and Leaf nodes R6 and R7. 644 The PCE instantiates the P2MP tree by stitching Replication Segments 645 at R1, R2, R3, R5, R6 and R7. Replication Segment at R1 replicates 646 to R2. Replication Segment at R2 replicates to R3 and R5. 647 Replication segment at R3 replicates to R6. Replication segment at 648 R5 replicates to R7. Note node R4 does not have any Replication 649 Segment state for the tree. 651 A.2.1. SR-MPLS 653 The Replication Segment state at nodes R1, R2, R3, R5, R6 and R7 is 654 shown below. 656 Replication Segment at R1: 658 Replication Segment : 659 Replication SID: T-SID1 660 Replication State: 661 R2: L12> 663 Replication to R2 steers packet directly to tje node on interface 664 L12. 666 Replication Segment at R2: 668 Replication Segment : 669 Replication SID: T-SID1 670 Replication State: 671 R2: 672 R3: L23> 673 R5: L25> 675 R2 is a Bud-Node. It performs role of Leaf as well as a transit node 676 replicating to R3 and R5. Replication to R3, steers packet directly 677 to the node on L23. Replication to R5, steers packet directly to the 678 node on L25. 680 Replication Segment at R3: 682 Replication Segment : 683 Replication SID: T-SID1 684 Replication State: 685 R6: L36> 687 Replication to R6, steers packet directly to the node on L36. 689 Replication Segment at R5: 691 Replication Segment : 692 Replication SID: T-SID1 693 Replication State: 694 R7: L57> 696 Replication to R7, steers packet directly to the node on L57. 698 Replication Segment at R6: 700 Replication Segment : 701 Replication SID: T-SID1 702 Replication State: 703 R6: 705 Replication Segment at R7: 707 Replication Segment : 708 Replication SID: T-SID1 709 Replication State: 710 R7: 712 When a packet is steered into the SR P2MP Policy at R1: 714 o Since R1 is directly connected to R2, R1 performs PUSH operation 715 with just label for the replicated copy and sends it to 716 R2 on interface L12. 718 o R2, as Leaf, performs NEXT operation, pops T-SID1 label and 719 delivers the payload. It also performs PUSH operation on T-SID1 720 for replication to R3 and R5. For replication to R6, R2 sends 721 label stack to R3 on interface L23. For replication to 722 R5, R2 sends label stack to R5 on interface L25. 724 o R3 performs NEXT operation on T-SID1 and performs a PUSH operation 725 for replication to R6 and sends label stack to R6 on 726 interface L36. 728 o R5 performs NEXT operation on T-SID1 and performs a PUSH operation 729 for replication to R7 and sends label stack to R7 on 730 interface L57. 732 o R6, as Leaf, performs NEXT operation, pops T-SID1 label and 733 delivers the payload. 735 o R7, as Leaf, performs NEXT operation, pops R-SID7 label and 736 delivers the payload. 738 Authors' Addresses 740 Daniel Voyer (editor) 741 Bell Canada 742 Montreal 743 CA 745 Email: daniel.voyer@bell.ca 747 Clarence Filsfils 748 Cisco Systems, Inc. 749 Brussels 750 BE 752 Email: cfilsfil@cisco.com 754 Rishabh Parekh 755 Cisco Systems, Inc. 756 San Jose 757 US 759 Email: riparekh@cisco.com 760 Hooman Bidgoli 761 Nokia 762 Ottawa 763 CA 765 Email: hooman.bidgoli@nokia.com 767 Zhaohui Zhang 768 Juniper Networks 770 Email: zzhang@juniper.net