idnits 2.17.00 (12 Aug 2021) /tmp/idnits62898/draft-ietf-pim-sr-p2mp-policy-04.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 document date (7 March 2022) is 68 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-18 == Outdated reference: A later version (-07) exists of draft-ietf-spring-sr-replication-segment-06 Summary: 0 errors (**), 0 flaws (~~), 2 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: 8 September 2022 R. Parekh 6 Cisco Systems, Inc. 7 H. Bidgoli 8 Nokia 9 Z. Zhang 10 Juniper Networks 11 7 March 2022 13 Segment Routing Point-to-Multipoint Policy 14 draft-ietf-pim-sr-p2mp-policy-04 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 8 September 2022. 48 Copyright Notice 50 Copyright (c) 2022 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 (https://trustee.ietf.org/ 55 license-info) in effect on the date of publication of this document. 56 Please review these documents carefully, as they describe your rights 57 and restrictions with respect to this document. Code Components 58 extracted from this document must include Revised BSD License text as 59 described in Section 4.e of the Trust Legal Provisions and are 60 provided without warranty as described in the Revised BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. P2MP Tree . . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2.1. Sharing Replication segments across P2MP trees . . . . . 4 67 3. SR P2MP Policy . . . . . . . . . . . . . . . . . . . . . . . 5 68 4. Using Controller to build a P2MP Tree . . . . . . . . . . . . 6 69 4.1. Provisioning SR P2MP Policy Creation . . . . . . . . . . 6 70 4.1.1. API . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 4.1.2. Invoking API . . . . . . . . . . . . . . . . . . . . 7 72 4.2. P2MP Tree Computation . . . . . . . . . . . . . . . . . . 7 73 4.2.1. Topology Discovery . . . . . . . . . . . . . . . . . 8 74 4.2.2. Capability and Attribute Discovery . . . . . . . . . 8 75 4.3. Instantiating P2MP tree on nodes . . . . . . . . . . . . 8 76 4.3.1. PCEP . . . . . . . . . . . . . . . . . . . . . . . . 9 77 4.3.2. BGP . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 4.3.3. NetConf . . . . . . . . . . . . . . . . . . . . . . . 9 79 4.4. Protection . . . . . . . . . . . . . . . . . . . . . . . 9 80 4.4.1. Local Protection . . . . . . . . . . . . . . . . . . 9 81 4.4.2. Path Protection . . . . . . . . . . . . . . . . . . . 9 82 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 84 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 85 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 87 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 88 9.2. Informative References . . . . . . . . . . . . . . . . . 11 89 Appendix A. Illustration of SR P2MP Policy and P2MP Tree . . . . 12 90 A.1. P2MP Tree with non-adjacent Replication Segments . . . . 13 91 A.1.1. SR-MPLS . . . . . . . . . . . . . . . . . . . . . . . 14 92 A.1.2. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . 15 93 A.2. P2MP Tree with adjacent Replication Segments . . . . . . 17 94 A.2.1. SR-MPLS . . . . . . . . . . . . . . . . . . . . . . . 17 95 A.2.2. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . 19 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 99 1. Introduction 101 A Multi-point service delivery could be realized via P2MP trees in a 102 Segment Routing domain [RFC8402]. A P2MP tree spans from a Root node 103 to a set of Leaf nodes via intermediate Replication Nodes. It 104 consists of a Replication segment 105 [I-D.ietf-spring-sr-replication-segment] at the root node, one or 106 more Replication segments at Leaf nodes and intermediate Replication 107 Nodes. The Replication segments are stitched together. 109 A Segment Routing P2MP policy, a variant of the SR Policy 110 [I-D.ietf-spring-segment-routing-policy], is used to define a P2MP 111 tree. A PCE is used to compute the tree from the Root node to the 112 set of Leaf nodes via a set of Replication Nodes. The PCE then 113 instantiates the P2MP tree in the SR domain by signaling Replication 114 segments to Root, replication and Leaf nodes using various protocols 115 (PCEP, BGP, NetConf etc.). Replication segments of a P2MP tree can 116 be instantiated for SR-MPLS and SRv6 dataplanes. 118 2. P2MP Tree 120 A P2MP tree in a SR domain connects a Root to a set of Leaf nodes via 121 a set of intermediate Replication Nodes. It consists of a 122 Replication segment at the root stitched to Replication segments at 123 intermediate Replication Nodes eventually reaching the Leaf nodes. 125 The Replication SID of the Replication segment at Root node is called 126 Tree-SID. The Tree-SID SHOULD also be used as Replication SID of 127 Replication segments at Replication and Leaf nodes. The Replication 128 segments at Replication and Leaf nodes MAY use Replication SIDs that 129 are not same as the Tree-SID. 131 The Replication segment at Root of a P2MP tree MUST be associated 132 with that P2MP tree (i.e. identifier in SR P2MP 133 policy section below) to map a Multi-point service to the tree. A 134 Replication segment that terminates a P2MP tree at a Leaf node MUST 135 be associated with the P2MP tree to determine the context for a 136 Multi-point service. The The information that can be used to derive 137 this association is specific to encoding of the protocol (PCEP, BGP, 138 NetConf etc.) used to instantiate the Replication segment for a P2MP 139 tree. Replication segments at intermediate Replication Nodes of a 140 tree are also associated with that tree. 142 For SR-MPLS, a PCE MAY decide not to instantiate Replication segments 143 at Leaf nodes of a P2MP tree if it is known a priori that Multi-point 144 services mapped to the P2MP tree can be identified using a context 145 that is globally unique in SR domain. In this case, Replication Nodes 146 connecting to Leaf nodes effectively does Penultimate-Hop Pop (PHP) 147 behavior to pop Tree-SID from a packet. A Multi-point service 148 context assigned from "Domain-wide Common Block" (DCB) 149 [I-D.ietf-bess-mvpn-evpn-aggregation-label] is an example of globally 150 unique context. 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 * Based on a local policy-based routing at the Root node. 162 * 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 203 policy[I-D.ietf-spring-segment-routing-policy] and is used to 204 instantiate SR P2MP trees. 206 A SR P2MP Policy is identified by the tuple , where: 208 * Root: The address of Root node of P2MP tree instantiated by the SR 209 P2MP Policy 211 * 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 * Leaf nodes: A set of nodes that terminate the P2MP trees. 218 * 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 287 2. Delete SR P2MP policy: DeleteSRP2MPPolicy 289 3. Modify SR P2MP policy Leaf Set: SRP2MPPolicyLeafSetModify 292 4. Create a Candidate Path for SR P2MP policy: 293 CreateSRP2MPCandidatePath> 295 5. Delete a Candidate Path for SR P2MP policy: 296 DeleteSRP2MPCandidatePath> 298 6. Update a Candidate Path for SR P2MP policy: 299 UpdateSRP2MPCandidatePath, Preference, 300 Constraints, Optimization, ...> 302 CP-ID is identifier of a Candidate Path within a SR P2MP policy. One 303 possible identifier is the tuple as specified in 305 [I-D.ietf-spring-segment-routing-policy]. 307 Note these are conceptual APIs. Actual implementations may offer 308 different APIs as long as they provide same functionality. For 309 example, API might allow symbolic name to be assigned for a P2MP 310 policy or APIs might allow individual Leaf nodes to be added or 311 deleted from a policy instead of an update operation. 313 4.1.2. Invoking API 315 Interaction with a PCE can be via PCEP, REST, Netconf, gRPC, CLI. 316 Yang model shall be be developed for this purpose as well. 318 4.2. P2MP Tree Computation 320 An entity (an operator, a network node or a machine) provisions a SR 321 P2MP policy by specifying the addresses of the root (R) and set of 322 leaves {L} as well as Traffic Engineering (TE) attributes of 323 Candidate paths via a suitable North-Bound API. The PCE computes the 324 tree of Active candidate path. The PCE MAY compute P2MP trees for 325 all Candidate paths., If tree computation is successful, PCE 326 instantiates the P2MP tree(s) using Replication segments on Root, 327 Replication, and Leaf nodes. 329 Candidate path constraints shall include link color affinity, 330 bandwidth, disjointness (link, node, SRLG), delay bound, link loss, 331 etc. Candidate path shall be optimized based on IGP or TE metric or 332 link latency. 334 The Tree SID of Candidate path of a SR P2MP policy can be either 335 dynamically allocated by the PCE or statically assigned by entity 336 provisioning the SR P2MP policy. Ideally, same Tree-SID SHOULD be 337 used for Replication segments at Root, Replication, and Leaf nodes. 338 Different Tree-SIDs MAY be used at Replication Node(s) if it is not 339 feasible to use same Tree SID. 341 A PCE can modify a P2MP tree following network element failure or in 342 case a better path can be found based on the new network state. In 343 this case, the PCE may want to setup the new instance of the tree and 344 remove the old instance of the tree from the network in order to 345 minimize traffic loss. In this case, the instances of trees for all 346 the Candidate paths of a P2MP policy can be identified by an 347 Instance-ID which is unique in context of the P2MP policy. As such, 348 the identifier of non-shared Replication segments used to instantiate 349 these trees becomes . 351 A PCE shall be capable of computing paths across multiple IGP areas 352 or levels as well as Autonomous Systems (ASs). 354 4.2.1. Topology Discovery 356 A PCE shall learn network topology, TE attributes of link/node as 357 well as SIDs via dynamic routing protocols (IGP and/or BGP-LS). It 358 may be possible for entities to pass topology information to PCE via 359 north-bound API. 361 4.2.2. Capability and Attribute Discovery 363 It shall be possible for a node to advertise SR P2MP tree capability 364 via IGP and/or BGP-LS. Similarly, a PCE can also advertise its P2MP 365 tree computation capability via IGP and/or BGP-LS. Capability 366 advertisement allows a network node to dynamically choose one or more 367 PCE(s) to obtain services pertaining to SR P2MP policies, as well a 368 PCE to dynamically identify SR P2MP tree capable nodes. 370 4.3. Instantiating P2MP tree on nodes 372 Once a PCE computes a P2MP tree for Candidate path of SR P2MP policy, 373 it needs to instantiate the tree on the relevant network nodes via 374 Replication segments. The PCE can use various protocols to program 375 the Replication segments as described below. 377 4.3.1. PCEP 379 PCE Protocol (PCEP)has been traditionally used: 381 1. For a head-end to obtain paths from a PCE. 383 2. A PCE to instantiate SR policies. 385 PCEP protocol can be stateful in that a PCE can have a stateful 386 control of an SR policy on a head-end which has delegated the control 387 of the SR policy to the PCE. PCEP shall be extended to provision and 388 maintain SR P2MP trees in a stateful fashion. 390 4.3.2. BGP 392 BGP has been extended to instantiate and report SR policies. It 393 shall be extended to instantiate and maintain P2MP trees for SR P2MP 394 policies. 396 4.3.3. NetConf 398 TBD 400 4.4. Protection 402 4.4.1. Local Protection 404 A network link, node or path on the tree of a P2MP tree can be 405 protected using SR policies computed by PCE. The backup SR policies 406 shall be programmed in forwarding plane in order to minimize traffic 407 loss when the protected link/node fails. It is also possible to use 408 node local Fast Re-Route protection mechanisms (LFA) to protect link/ 409 nodes of P2MP tree. 411 4.4.2. Path Protection 413 It is possible for PCE create a disjoint backup tree for providing 414 end-to-end path protection. 416 5. IANA Considerations 418 This document makes no request of IANA. 420 6. Security Considerations 422 There are no additional security risks introduced by this design. 424 7. Acknowledgements 426 The authors would like to acknowledge Siva Sivabalan, Mike Koldychev 427 and Vishnu Pavan Beeram for their valuable inputs.. 429 8. Contributors 431 Clayton Hassen Bell Canada Vancouver Canada 433 Email: clayton.hassen@bell.ca 435 Kurtis Gillis Bell Canada Halifax Canada 437 Email: kurtis.gillis@bell.ca 439 Arvind Venkateswaran Cisco Systems, Inc. San Jose US 441 Email: arvvenka@cisco.com 443 Zafar Ali Cisco Systems, Inc. US 445 Email: zali@cisco.com 447 Swadesh Agrawal Cisco Systems, Inc. San Jose US 449 Email: swaagraw@cisco.com 451 Jayant Kotalwar Nokia Mountain View US 453 Email: jayant.kotalwar@nokia.com 455 Tanmoy Kundu Nokia Mountain View US 457 Email: tanmoy.kundu@nokia.com 459 Andrew Stone Nokia Ottawa Canada 461 Email: andrew.stone@nokia.com 463 Tarek Saad Juniper Networks Canada 465 Email:tsaad@juniper.net 467 9. References 469 9.1. Normative References 471 [I-D.ietf-spring-segment-routing-policy] 472 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 473 P. Mattes, "Segment Routing Policy Architecture", Work in 474 Progress, Internet-Draft, draft-ietf-spring-segment- 475 routing-policy-18, 17 February 2022, 476 . 479 [I-D.ietf-spring-sr-replication-segment] 480 (editor), D. V., Filsfils, C., Parekh, R., Bidgoli, H., 481 and Z. Zhang, "SR Replication Segment for Multi-point 482 Service Delivery", Work in Progress, Internet-Draft, 483 draft-ietf-spring-sr-replication-segment-06, 25 October 484 2021, . 487 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 488 Requirement Levels", BCP 14, RFC 2119, 489 DOI 10.17487/RFC2119, March 1997, 490 . 492 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 493 Decraene, B., Litkowski, S., and R. Shakir, "Segment 494 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 495 July 2018, . 497 9.2. Informative References 499 [I-D.filsfils-spring-srv6-net-pgm-illustration] 500 Filsfils, C., Garvia, P. C., Li, Z., Matsushima, S., 501 Decraene, B., Steinberg, D., Lebrun, D., Raszuk, R., and 502 J. Leddy, "Illustrations for SRv6 Network Programming", 503 Work in Progress, Internet-Draft, draft-filsfils-spring- 504 srv6-net-pgm-illustration-04, 30 March 2021, 505 . 508 [I-D.ietf-bess-mvpn-evpn-aggregation-label] 509 Zhang, Z., Rosen, E., Lin, W., Li, Z., and I. Wijnands, 510 "MVPN/EVPN Tunnel Aggregation with Common Labels", Work in 511 Progress, Internet-Draft, draft-ietf-bess-mvpn-evpn- 512 aggregation-label-08, 20 January 2022, 513 . 516 [RFC7900] Rekhter, Y., Ed., Rosen, E., Ed., Aggarwal, R., Cai, Y., 517 and T. Morin, "Extranet Multicast in BGP/IP MPLS VPNs", 518 RFC 7900, DOI 10.17487/RFC7900, June 2016, 519 . 521 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 522 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 523 (SRv6) Network Programming", RFC 8986, 524 DOI 10.17487/RFC8986, February 2021, 525 . 527 Appendix A. Illustration of SR P2MP Policy and P2MP Tree 529 Consider the following topology: 531 R3------R6 532 PCE--/ \ 533 R1----R2----R5-----R7 534 \ / 535 +--R4---+ 537 Figure 2: Figure 1 539 In these examples, the Node-SID of a node Rn is N-SIDn and Adjacency- 540 SID from node Rm to node Rn is A-SIDmn. Interface between Rm and Rn 541 is Lmn. 543 For SRv6, the reader is expected to be familiar with SRv6 Network 544 Programming [RFC8986] to follow the examples. We use SID allocation 545 scheme, reproduced below, from Illustrations for SRv6 Network 546 Programming [I-D.filsfils-spring-srv6-net-pgm-illustration] 548 * 2001:db8::/32 is an IPv6 block allocated by a RIR to the operator 550 * 2001:db8:0::/48 is dedicated to the internal address space 552 * 2001:db8:cccc::/48 is dedicated to the internal SRv6 SID space 554 * We assume a location expressed in 64 bits and a function expressed 555 in 16 bits 557 * Node k has a classic IPv6 loopback address 2001:db8::k/128 which 558 is advertised in the IGP 560 * Node k has 2001:db8:cccc:k::/64 for its local SID space. Its SIDs 561 will be explicitly assigned from that block 563 * Node k advertises 2001:db8:cccc:k::/64 in its IGP 564 * Function :1:: (function 1, for short) represents the End function 565 with PSP support 567 * Function :Cn:: (function Cn, for short) represents the End.X 568 function to Node n 570 * Function :C1n: (function C1n for short) represents the End.X 571 function to Node n with USD 573 Each node k has: 575 * An explicit SID instantiation 2001:db8:cccc:k:1::/128 bound to an 576 End function with additional support for PSP 578 * An explicit SID instantiation 2001:db8:cccc:k:Cj::/128 bound to an 579 End.X function to neighbor J with additional support for PSP 581 * An explicit SID instantiation 2001:db8:cccc:k:C1j::/128 bound to 582 an End.X function to neighbor J with additional support for USD 584 Assume PCE is provisioned following SR P2MP policy at Root R1 with 585 Tree-ID T-ID: 587 SR P2MP Policy : 588 Leaf Nodes: {R2, R6, R7} 589 Candidate-path 1: 590 Optimize: IGP metric 591 Tree-SID: T-SID1 593 The PCE is responsible for P2MP tree computation. Assume PCE 594 instantiates P2MP trees by signalling non-shared Replication segments 595 i.e. Replication-ID of these Replication segments is . 596 If a Candidate-path can have multiple instances of P2MP trees, the 597 Replication-ID is . In this example, we 598 assume one instance of P2MP tree for a candidate-path. All 599 Replication segments use the Tree-SID T-SID1 as Replication-SID. For 600 SRv6, assume the Replication SID at node k, bound to an End.Replcate 601 function, is 2001:db8:cccc:k:FA::/128. 603 A.1. P2MP Tree with non-adjacent Replication Segments 605 Assume PCE computes a P2MP tree with Root node R1, Intermediate and 606 Leaf node R2, and Leaf nodes R6 and R7. The PCE instantiates the 607 P2MP tree by stitching Replication segments at R1, R2, R6 and R7. 608 Replication segment at R1 replicates to R2. Replication segment at 609 R2 replicates to R6 and R7. Note nodes R3, R4 and R5 do not have any 610 Replication segment state for the tree. 612 A.1.1. SR-MPLS 614 The Replication segment state at nodes R1, R2, R6 and R7 is shown 615 below. 617 Replication segment at R1: 619 Replication segment : 620 Replication SID: T-SID1 621 Replication State: 622 R2: L12> 624 Replication to R2 steers packet directly to the node on interface 625 L12. 627 Replication segment at R2: 629 Replication segment : 630 Replication SID: T-SID1 631 Replication State: 632 R2: 633 R6: 634 R7: 636 R2 is a Bud-Node. It performs role of Leaf as well as a transit node 637 replicating to R6 and R7. Replication to R6, using N-SID6, steers 638 packet via IGP shortest path to that node. Replication to R7, using 639 N-SID7, steers packet via IGP shortest path to R7 via either R5 or R4 640 based on ECMP hashing. 642 Replication segment at R6: 644 Replication segment : 645 Replication SID: T-SID1 646 Replication State: 647 R6: 649 Replication segment at R7: 651 Replication segment : 652 Replication SID: T-SID1 653 Replication State: 654 R7: 656 When a packet is steered into the SR P2MP Policy at R1: 658 * Since R1 is directly connected to R2, R1 performs PUSH operation 659 with just label for the replicated copy and sends it to 660 R2 on interface L12. 662 * R2, as Leaf, performs NEXT operation, pops T-SID1 label and 663 delivers the payload. For replication to R6, R2 performs a PUSH 664 operation of N-SID6, to send label stack to R3. 665 R3 is the penultimate hop for N-SID6; it performs penultimate hop 666 popping, which corresponds to the NEXT operation and the packet is 667 then sent to R6 with in the label stack. For replication 668 to R7, R2 performs a PUSH operation of N-SID7, to send 669 label stack to R4, one of IGP ECMP nexthops 670 towards R7. R4 is the penultimate hop for N-SID6; it performs 671 penultimate hop popping, which corresponds to the NEXT operation 672 and the packet is then sent to R7 with in the label 673 stack. 675 * R6, as Leaf, performs NEXT operation, pops T-SID1 label and 676 delivers the payload. 678 * R7, as Leaf, performs NEXT operation, pops R-SID7 label and 679 delivers the payload. 681 A.1.2. SRv6 683 For SRv6, the replicated packet from R2 to R7 has to traverse R4 684 using a SR-TE policy, Policy27. The policy has one SID in segment 685 list: End.X function with USD of R4 to R7 . The Replication segment 686 state at nodes R1, R2, R6 and R7 is shown below. 688 Policy27: <2001:db8:cccc:4:C17::> 690 Replication segment at R1: 692 Replication segment : 693 Replication SID: 2001:db8:cccc:1:FA:: 694 Replication State: 695 R2: <2001:db8:cccc:2:FA::->L12> 697 Replication to R2 steers packet directly to the node on interface 698 L12. 700 Replication segment at R2: 702 Replication segment : 703 Replication SID: 2001:db8:cccc:2:FA:: 704 Replication State: 705 R2: 706 R6: <2001:db8:cccc:6:FA::> 707 R7: <2001:db8:cccc:7:FA:: -> Policy27> 709 R2 is a Bud-Node. It performs role of Leaf as well as a transit node 710 replicating to R6 and R7. Replication to R6, steers packet via IGP 711 shortest path to that node. Replication to R7, via SR-TE policy, 712 first encapsulates the packet using H.Encaps and then steers the 713 outer packet to R4. End.X USD on R4 decapsulates outer header and 714 sends the original inner packet to R7. 716 Replication segment at R6: 718 Replication segment : 719 Replication SID: 2001:db8:cccc:6:FA:: 720 Replication State: 721 R6: 723 Replication segment at R7: 725 Replication segment : 726 Replication SID: 2001:db8:cccc:7:FA:: 727 Replication State: 728 R7: 730 When a packet (A,B2) is steered into the SR P2MP Policy at R1 using 731 H.Encaps.Replicate behavior: 733 * Since R1 is directly connected to R2, R1 sends replicated copy 734 (2001:db8::1, 2001:db8:cccc:2:FA::) (A,B2) to R2 on interface L12. 736 * R2, as Leaf removes outer IPv6 header and delivers the payload. 737 R2, as a bud node, also replicates the packet. 739 - For replication to R6, R2 sends (2001:db8::1, 740 2001:db8:cccc:6:FA::) (A,B2) to R3. R3 forwards the packet 741 using 2001:db8:cccc:6::/64 packet to R6. 743 - For replication to R7 using Policy27, R2 encapsulates and sends 744 (2001:db8::2, 2001:db8:cccc:4:C17::) (2001:db8::1, 745 2001:db8:cccc:7:FA::) (A,B2) to R4. R4 performs End.X USD 746 behavior, decapsulates outer IPv6 header and sends 747 (2001:db8::1, 2001:db8:cccc:7:FA::) (A,B2) to R7. 749 * R6, as Leaf, removes outer IPv6 header and delivers the payload. 751 * R7, as Leaf, removes outer IPv6 header and delivers the payload. 753 A.2. P2MP Tree with adjacent Replication Segments 755 Assume PCE computes a P2MP tree with Root node R1, Intermediate and 756 Leaf node R2, Intermediate nodes R3 and R5, and Leaf nodes R6 and R7. 757 The PCE instantiates the P2MP tree by stitching Replication segments 758 at R1, R2, R3, R5, R6 and R7. Replication segment at R1 replicates 759 to R2. Replication segment at R2 replicates to R3 and R5. 760 Replication segment at R3 replicates to R6. Replication segment at 761 R5 replicates to R7. Note node R4 does not have any Replication 762 segment state for the tree. 764 A.2.1. SR-MPLS 766 The Replication segment state at nodes R1, R2, R3, R5, R6 and R7 is 767 shown below. 769 Replication segment at R1: 771 Replication segment : 772 Replication SID: T-SID1 773 Replication State: 774 R2: L12> 776 Replication to R2 steers packet directly to the node on interface 777 L12. 779 Replication segment at R2: 781 Replication segment : 782 Replication SID: T-SID1 783 Replication State: 784 R2: 785 R3: L23> 786 R5: L25> 788 R2 is a Bud-Node. It performs role of Leaf as well as a transit node 789 replicating to R3 and R5. Replication to R3, steers packet directly 790 to the node on L23. Replication to R5, steers packet directly to the 791 node on L25. 793 Replication segment at R3: 795 Replication segment : 796 Replication SID: T-SID1 797 Replication State: 798 R6: L36> 800 Replication to R6, steers packet directly to the node on L36. 802 Replication segment at R5: 804 Replication segment : 805 Replication SID: T-SID1 806 Replication State: 807 R7: L57> 809 Replication to R7, steers packet directly to the node on L57. 811 Replication segment at R6: 813 Replication segment : 814 Replication SID: T-SID1 815 Replication State: 816 R6: 818 Replication segment at R7: 820 Replication segment : 821 Replication SID: T-SID1 822 Replication State: 823 R7: 825 When a packet is steered into the SR P2MP Policy at R1: 827 * Since R1 is directly connected to R2, R1 performs PUSH operation 828 with just label for the replicated copy and sends it to 829 R2 on interface L12. 831 * R2, as Leaf, performs NEXT operation, pops T-SID1 label and 832 delivers the payload. It also performs PUSH operation on T-SID1 833 for replication to R3 and R5. For replication to R6, R2 sends 834 label stack to R3 on interface L23. For replication to 835 R5, R2 sends label stack to R5 on interface L25. 837 * R3 performs NEXT operation on T-SID1 and performs a PUSH operation 838 for replication to R6 and sends label stack to R6 on 839 interface L36. 841 * R5 performs NEXT operation on T-SID1 and performs a PUSH operation 842 for replication to R7 and sends label stack to R7 on 843 interface L57. 845 * R6, as Leaf, performs NEXT operation, pops T-SID1 label and 846 delivers the payload. 848 * R7, as Leaf, performs NEXT operation, pops R-SID7 label and 849 delivers the payload. 851 A.2.2. SRv6 853 The Replication segment state at nodes R1, R2, R3, R5, R6 and R7 is 854 shown below. 856 Replication segment at R1: 858 Replication segment : 859 Replication SID: 2001:db8:cccc:1:FA:: 860 Replication State: 861 R2: <2001:db8:cccc:2:FA::->L12> 863 Replication to R2 steers packet directly to the node on interface 864 L12. 866 Replication segment at R2: 868 Replication segment : 869 Replication SID: 2001:db8:cccc:2:FA:: 870 Replication State: 871 R2: 872 R3: <2001:db8:cccc:3:FA::->L23> 873 R5: <2001:db8:cccc:5:FA::->L25> 875 R2 is a Bud-Node. It performs role of Leaf as well as a transit node 876 replicating to R3 and R5. Replication to R3, steers packet directly 877 to the node on L23. Replication to R5, steers packet directly to the 878 node on L25. 880 Replication segment at R3: 882 Replication segment : 883 Replication SID: 2001:db8:cccc:3:FA:: 884 Replication State: 885 R6: <2001:db8:cccc:6:FA::->L36> 887 Replication to R6, steers packet directly to the node on L36. 889 Replication segment at R5: 891 Replication segment : 892 Replication SID: 2001:db8:cccc:5:FA:: 893 Replication State: 894 R7: <2001:db8:cccc:7:FA::->L57> 896 Replication to R7, steers packet directly to the node on L57. 898 Replication segment at R6: 900 Replication segment : 901 Replication SID: 2001:db8:cccc:6:FA:: 902 Replication State: 903 R6: 905 Replication segment at R7: 907 Replication segment : 908 Replication SID: 2001:db8:cccc:7:FA:: 909 Replication State: 910 R7: 912 When a packet (A,B2) is steered into the SR P2MP Policy at R1 using 913 H.Encaps.Replicate behavior: 915 * Since R1 is directly connected to R2, R1 sends replicated copy 916 (2001:db8::1, 2001:db8:cccc:2:FA::) (A,B2) to R2 on interface L12. 918 * R2, as Leaf, removes outer IPv6 header and delivers the payload. 919 R2, as a bud node, also replicates the packet. For replication to 920 R3, R2 sends (2001:db8::1, 2001:db8:cccc:3:FA::) (A,B2) to R3 on 921 interface L23. For replication to R5, R2 sends (2001:db8::1, 922 2001:db8:cccc:5:FA::) (A,B2) to R5 on interface L25. 924 * R3 replicates and sends (2001:db8::1, 2001:db8:cccc:6:FA::) (A,B2) 925 to R6 on interface L36. 927 * R5 replicates and sends (2001:db8::1, 2001:db8:cccc:7:FA::) (A,B2) 928 to R7 on interface L57. 930 * R6, as Leaf, removes outer IPv6 header and delivers the payload. 932 * R7, as Leaf, removes outer IPv6 header and delivers the payload. 934 Authors' Addresses 936 Daniel Voyer (editor) 937 Bell Canada 938 Montreal 939 Canada 940 Email: daniel.voyer@bell.ca 941 Clarence Filsfils 942 Cisco Systems, Inc. 943 Brussels 944 Belgium 945 Email: cfilsfil@cisco.com 947 Rishabh Parekh 948 Cisco Systems, Inc. 949 San Jose, 950 United States of America 951 Email: riparekh@cisco.com 953 Hooman Bidgoli 954 Nokia 955 Ottawa 956 Canada 957 Email: hooman.bidgoli@nokia.com 959 Zhaohui Zhang 960 Juniper Networks 961 Email: zzhang@juniper.net