idnits 2.17.1 draft-voyer-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 (October 11, 2019) is 1652 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) == Unused Reference: 'RFC6513' is defined on line 496, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-03 == Outdated reference: A later version (-04) exists of draft-voyer-spring-sr-replication-segment-00 == Outdated reference: A later version (-14) exists of draft-ietf-bess-mvpn-evpn-aggregation-label-02 Summary: 0 errors (**), 0 flaws (~~), 6 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: April 13, 2020 R. Parekh 6 Cisco Systems, Inc. 7 H. Bidgoli 8 Nokia 9 Z. Zhang 10 Juniper Networks 11 October 11, 2019 13 Segment Routing Point-to-Multipoint Policy 14 draft-voyer-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 April 13, 2020. 48 Copyright Notice 50 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . . 10 88 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 89 9.2. Informative References . . . . . . . . . . . . . . . . . 11 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 92 1. Introduction 94 A Multi-point service delivery could be realized via P2MP trees in a 95 Segment Routing domain [RFC8402]. A P2MP tree spans from a Root node 96 to a set of Leaf nodes via intermediate Replication nodes. It 97 consists of a Replication segment 98 [I-D.voyer-spring-sr-replication-segment] at the root node, one or 99 more Replication segments at Leaf nodes and intermediate Replication 100 nodes. The Replication segments are stitched together. 102 A Segment Routing P2MP policy, a variant of the SR Policy 103 [I-D.ietf-spring-segment-routing-policy], is used to define a P2MP 104 tree. A PCE is used to compute the tree from the Root node to the 105 set of Leaf nodes via a set of replication nodes. The PCE then 106 instantiates the P2MP tree in the SR domain by signaling Replication 107 segments to Root, replication and Leaf nodes using various protocols 108 (PCEP, BGP, NetConf etc.). 110 2. P2MP Tree 112 A P2MP tree in a SR domain connects a Root to a set of Leaf nodes via 113 a set of intermediate Replication nodes. It consists of a 114 Replication segment at the root stitched to Replication segments at 115 intermediate Replication nodes eventually reaching the Leaf nodes. 117 The Replication SID of the Replication Segment at Root node is called 118 Tree-SID. The Tree-SID SHOULD also be used as Replication SID of 119 Replication segments at Replication and Leaf nodes. The Replication 120 segments at Replication and Leaf nodes MAY use Replication SIDs that 121 are not same as the Tree-SID. 123 The Replication segment at Root of a P2MP tree MUST be associated 124 with that P2MP tree (i.e. identifier in SR P2MP 125 policy section below) to map a Multi-point service to the tree. A 126 Replication segment that terminates a P2MP tree at a Leaf node MUST 127 be associated with the P2MP tree to determine the context for a 128 Multi-point service. The The information that can be used to derive 129 this association is specific to encoding of the protocol (PCEP, BGP, 130 NetConf etc.) used to instantiate the Replication segment for a P2MP 131 tree. Replication segments at intermediate Replication nodes of a 132 tree are also associated with that tree. 134 A PCE MAY decide not instantiate Replication segments at Leaf nodes 135 of a P2MP tree if it is known a priori that Multi-point services 136 mapped to the P2MP tree can be identified using a context that is 137 globally unique in SR domain. Multi-point service contexts assigned 138 from "Domain-wide Common Block" (DCB) 139 [I-D.ietf-bess-mvpn-evpn-aggregation-label] are an example of such 140 globally unique contexts. A Segment Routing Global Block (SRGB) 141 [RFC8402] MAY be used to allocate globally unique Multi-point service 142 contexts, but it is NOT RECOMMENDED to do so as the service contexts 143 only need to be unique at service edge nodes. In this case, 144 Replication nodes connecting to Leaf nodes SHOULD use Penultimate-Hop 145 Pop (PHP) behavior to pop Tree-SID from a packet. 147 A packet steered into a P2MP tree is replicated by the Replication 148 segment at Root node to each downstream node in the Replication 149 segment, with the Replication SID of the Replication Segment at the 150 downstream node. A downstream node could be a Leaf node or an 151 intermediate Replication node. In the latter case, replication 152 continues with the Replication segments until all Leaf nodes are 153 reached. A packet is steered into a P2MP tree in two ways: 155 o Based on a local policy-based routing at the Root node. 157 o Based on steering via the Tree-SID at the Root node. 159 2.1. Sharing Replication segments across P2MP trees 161 Two or more P2MP trees MAY share a Replication segment at Root or 162 Replication nodes if at minimum as the first condition below is 163 satisfied. A tree always has its own Replication segment at its root 164 even if shares another Replication segment. A tree that shares 165 another Replication segment may or may not have its own Replication 166 segment on its Leaf nodes. If not, the second and third conditions 167 apply to such situations. 169 1. The Leaf nodes reached via a shared Replication segment must be 170 subset of Leaf or Replication nodes of the P2MP trees that shares 171 this segment. Note if a Replication segment is shared, all its 172 downstream Replication segments are also shared. 174 2. Some Multi-point services realized by the P2MP trees may need 175 service context (e.g. packets are for certain VPNs, and/or from 176 certain nodes). If the trees do not have their own Replication 177 segments at their Leaf nodes then the packets transported on the 178 P2MP trees MUST carry a service context that does not rely on the 179 tree or root identification, e.g. a service label assigned from 180 Domain-wide Common Block or common SRGB. 182 3. For some Multi-point services using P2MP trees that share 183 Replication segments, packets transported on these trees MAY 184 require a Tree context (e.g. MVPN Extranet [RFC7900] to avoid 185 certain ambiguities - see Section 2.3.1 of RFC 7900). In this 186 case, the trees MUST have their own Replication segments on the 187 Leaf nodes. This is similar to "tunnel stacking" concept. 189 Sharing of a Replication segment for P2MP trees is OPTIONAL. Exact 190 procedures to ensure validity of above conditions across PM2P 191 services on nodes of a Segment Routing domain are outside the scope 192 of this document. 194 3. SR P2MP Policy 196 The SR P2MP policy is a variant of an SR 197 policy[I-D.ietf-spring-segment-routing-policy] and is used to 198 instantiate SR P2MP trees. 200 A SR P2MP Policy is identified by the tuple , where: 202 o Root: The address of Root node of P2MP tree instantiated by the SR 203 P2MP Policy 205 o Tree-ID: A identifier that is unique in context of the Root. This 206 is an unsigned 32-bit number. 208 A SR P2MP Policy is defined by following elements: 210 o Leaf nodes: A set of nodes that terminate the P2MP trees. 212 o Candidate Paths: See below. 214 A SR P2MP policy is provisioned on a PCE to instantiate the P2MP 215 tree. The Tree-SID SHOULD be used as Binding SID of the P2MP policy. 216 A PCE computes the P2MP tree and instantiates Replication segments at 217 Root, Replication and Leaf nodes. When Replication segments are not 218 shared across P2MP trees, the Root and Tree-ID of the SR P2MP policy 219 are mapped to Replication-ID element of the Replication segment 220 identifier i.e the SR Replication segment identifier is . A shared Replication segment MAY be identified with 222 zero Root-ID address (0.0.0.0 for IPv4 and :: for IPv6) and a 223 Replication-ID that is unique in context of Node address where the 224 Replication segment is instantiated when it is not associated a 225 particular tree. 227 A SR P2MPPolicy has one or more Candidate paths.The active Candidate 228 path is selected based on the tie breaking rules amongst the 229 candidate-paths as specified 230 in[I-D.ietf-spring-segment-routing-policy]. Each candidate path has 231 a set of topological/resource constraints and/or optimization 232 objectives which determine the P2MP tree for that Candidate path. 233 Tree-SID is an identifier of the P2MP tree of the candidate path in 234 the forwarding plane. It is instantiated in the forwarding plane at 235 Root node, intermediate Replication nodes and Leaf nodes. The Tree- 236 SID MAY be different at Replication and Leaf nodes. 238 4. Using Controller to build a P2MP Tree 240 A P2MP tree can be built using a Path Computation Element (PCE). 241 This section outlines a high-level architecture for such an approach. 243 North Bound South Bound 244 Programming ..... Programming 245 Interface Interface 246 | 247 | 248 v 249 +-----+ .......................... 250 .............| PCE | ............. . 251 . +-----+ . . 252 . . . . 253 . . . . 254 . . . . 255 . . V . 256 . . +----+ . 257 . . | N3 | . 258 . . +----+ . 259 . . | Leaf (L2) . 260 . . | . 261 . . | . 262 V V | V 263 +----+ +----+ -------------- +----+ 264 | N1 |----------| N2 |-------------------------| N4 | 265 +----+ +----+ +----+ 266 Root (R) Replication node (M) Leaf (L1) 268 Figure 1: Centralized Control Plane Model 270 4.1. Provisioning SR P2MP Policy Creation 272 A SR P2MP policy can be instantiated and maintained in a centralized 273 fashion using a Path Computation Element (PCE). 275 4.1.1. API 277 North-bound APIs on a PCE can be used to: 279 1. Create SR P2MP policy 281 2. Delete SR P2MP policy 283 3. Update SR P2MP policy 284 4. Create a Candidate Path for SR P2MP policy 286 5. Update a Candidate Path for SR P2MP policy 288 6. Delete a Candidate Path for SR P2MP policy 290 4.1.2. Invoking API 292 Interaction with a PCE can be via PCEP, REST, Netconf, gRPC, CLI. 293 Yang model shall be be developed for this purpose as well. 295 4.2. P2MP Tree Computation 297 An entity (an operator, a network node or a machine) provisions a SR 298 P2MP policy by specifying the addresses of the root (R) and set of 299 leaves {L} as well as Traffic Engineering (TE) attributes of 300 Candidate paths via a suitable North-Bound API. The PCE computes the 301 tree of Active candidate path. The PCE MAY compute P2MP trees for 302 all Candidate paths., If tree computation is successful, PCE 303 instantiates the P2MP tree(s) using Replication segments on Root, 304 Replication, and Leaf nodes. 306 Candidate path constraints shall include link color affinity, 307 bandwidth, disjointness (link, node, SRLG), delay bound, link loss, 308 etc. Candidate path shall be optimized based on IGP or TE metric or 309 link latency. 311 The Tree SID of Candidate path of a SR P2MP policy can be either 312 dynamically allocated by the PCE or statically assigned by entity 313 provisioning the SR P2MP policy. Ideally, same Tree-SID SHOULD be 314 used for Replication segments at Root, Replication, and Leaf nodes. 315 Different Tree-SIDs MAY be used at replication node(s) if it is not 316 feasible to use same Tree SID. 318 A PCE can modify a P2MP tree following network element failure or in 319 case a better path can be found based on the new network state. In 320 this case, the PCE may want to setup the new instance of the tree and 321 remove the old instance of the tree from the network in order to 322 minimize traffic loss. In this case, the instances of trees for all 323 the Candidate paths of a P2MP policy can be identified by an 324 Instance-ID which is unique in context of the P2MP policy. As such, 325 the identifier of non-shared Replication segments used to instantiate 326 these trees becomes . 328 A PCE shall be capable of computing paths across multiple IGP areas 329 or levels as well as Autonomous Systems (ASs). 331 4.2.1. Topology Discovery 333 A PCE shall learn network topology, TE attributes of link/node as 334 well as SIDs via dynamic routing protocols (IGP and/or BGP-LS). It 335 may be possible for entities to pass topology information to PCE via 336 north-bound API. 338 4.2.2. Capability and Attribute Discovery 340 It shall be possible for a node to advertise SR P2MP tree capability 341 via IGP and/or BGP-LS. Similarly, a PCE can also advertise its P2MP 342 tree computation capability via IGP and/or BGP-LS. Capability 343 advertisement allows a network node to dynamically choose one or more 344 PCE(s) to obtain services pertaining to SR P2MP policies, as well a 345 PCE to dynamically identify SR P2MP tree capable nodes. 347 4.3. Instantiating P2MP tree on nodes 349 Once a PCE computes a P2MP tree for Candidate path of SR P2MP policy, 350 it needs to instantiate the tree on the relevant network nodes via 351 Replication segments. The PCE can use various protocols to program 352 the Replication segments as described below. 354 4.3.1. PCEP 356 PCE Protocol (PCEP)has been traditionally used: 358 1. For a head-end to obtain paths from a PCE. 360 2. A PCE to instantiate SR policies. 362 PCEP protocol can be stateful in that a PCE can have a stateful 363 control of an SR policy on a head-end which has delegated the control 364 of the SR policy to the PCE. PCEP shall be extended to provision and 365 maintain SR P2MP trees in a stateful fashion. 367 4.3.2. BGP 369 BGP has been extended to instantiate and report SR policies. It 370 shall be extended to instantiate and maintain P2MP trees for SR P2MP 371 policies. 373 4.3.3. NetConf 375 TBD 377 4.4. Protection 379 4.4.1. Local Protection 381 A network link, node or path on the tree of a P2MP tree can be 382 protected using SR policies computed by PCE. The backup SR policies 383 shall be programmed in forwarding plane in order to minimize traffic 384 loss when the protected link/node fails. It is also possible to use 385 node local Fast Re-Route protection mechanisms (LFA) to protect link/ 386 nodes of P2MP tree. 388 4.4.2. Path Protection 390 It is possible for PCE create a disjoint backup tree for providing 391 end-to-end path protection. 393 5. IANA Considerations 395 This document makes no request of IANA. 397 6. Security Considerations 399 There are no additional security risks introduced by this design. 401 7. Acknowledgements 403 The authors would like to acknowledge Siva Sivabalan, Mike Koldychev 404 and Vishnu Pavan Beeram for their valuable inputs.. 406 8. Contributors 408 Clayton Hassen 409 Bell Canada 410 Vancouver 411 Canada 413 Email: clayton.hassen@bell.ca 415 Kurtis Gillis 416 Bell Canada 417 Halifax 418 Canada 420 Email: kurtis.gillis@bell.ca 422 Arvind Venkateswaran 423 Cisco Systems, Inc. 424 San Jose 425 US 427 Email: arvvenka@cisco.com 429 Zafar Ali 430 Cisco Systems, Inc. 431 US 433 Email: zali@cisco.com 435 Swadesh Agrawal 436 Cisco Systems, Inc. 437 San Jose 438 US 440 Email: swaagraw@cisco.com 442 Jayant Kotalwar 443 Nokia 444 Mountain View 445 US 447 Email: jayant.kotalwar@nokia.com 449 Tanmoy Kundu 450 Nokia 451 Mountain View 452 US 454 Email: tanmoy.kundu@nokia.com 456 Tarek Saad 457 Juniper Networks 458 Canada 460 Email:tsaad@juniper.net 462 9. References 464 9.1. Normative References 466 [I-D.ietf-spring-segment-routing-policy] 467 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 468 bogdanov@google.com, b., and P. Mattes, "Segment Routing 469 Policy Architecture", draft-ietf-spring-segment-routing- 470 policy-03 (work in progress), May 2019. 472 [I-D.voyer-spring-sr-replication-segment] 473 daniel.voyer@bell.ca, d., Filsfils, C., Parekh, R., 474 Bidgoli, H., and Z. Zhang, "SR Replication Segment for 475 Multi-point Service Delivery", draft-voyer-spring-sr- 476 replication-segment-00 (work in progress), October 2019. 478 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 479 Requirement Levels", BCP 14, RFC 2119, 480 DOI 10.17487/RFC2119, March 1997, 481 . 483 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 484 Decraene, B., Litkowski, S., and R. Shakir, "Segment 485 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 486 July 2018, . 488 9.2. Informative References 490 [I-D.ietf-bess-mvpn-evpn-aggregation-label] 491 Zhang, Z., Rosen, E., Lin, W., Li, Z., and I. Wijnands, 492 "MVPN/EVPN Tunnel Aggregation with Common Labels", draft- 493 ietf-bess-mvpn-evpn-aggregation-label-02 (work in 494 progress), December 2018. 496 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 497 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 498 2012, . 500 [RFC7900] Rekhter, Y., Ed., Rosen, E., Ed., Aggarwal, R., Cai, Y., 501 and T. Morin, "Extranet Multicast in BGP/IP MPLS VPNs", 502 RFC 7900, DOI 10.17487/RFC7900, June 2016, 503 . 505 Authors' Addresses 507 Daniel Voyer (editor) 508 Bell Canada 509 Montreal 510 CA 512 Email: daniel.voyer@bell.ca 513 Clarence Filsfils 514 Cisco Systems, Inc. 515 Brussels 516 BE 518 Email: cfilsfil@cisco.com 520 Rishabh Parekh 521 Cisco Systems, Inc. 522 San Jose 523 US 525 Email: riparekh@cisco.com 527 Hooman Bidgoli 528 Nokia 529 Ottawa 530 CA 532 Email: hooman.bidgoli@nokia.com 534 Zhaohui Zhang 535 Juniper Networks 537 Email: zzhang@juniper.net