idnits 2.17.1 draft-voyer-spring-sr-p2mp-policy-03.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 date (July 2, 2019) is 1753 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-03 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: February 3, 2020 R. Parekh 6 Cisco Systems, Inc. 7 H. Bidgoli 8 Nokia 9 Z. Zhang 10 Juniper Networks 11 July 2, 2019 13 SR Replication Policy for P2MP Service Delivery 14 draft-voyer-spring-sr-p2mp-policy-03 16 Abstract 18 This document describes the SR policy architecture for P2MP service 19 delivery. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on November 15, 2019. 44 Copyright Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. SR Replication Policy . . . . . . . . . . . . . . . . . . . . 3 63 3. SR P2MP Policy . . . . . . . . . . . . . . . . . . . . . . . 4 64 4. Using Controller to build a P2MP Segment . . . . . . . . . . 5 65 4.1. SR P2MP Policy Creation . . . . . . . . . . . . . . . . . 6 66 4.1.1. API . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 4.1.2. Invoking API . . . . . . . . . . . . . . . . . . . . 6 68 4.2. P2MP Segment Computation . . . . . . . . . . . . . . . . 7 69 4.2.1. Topology Discovery . . . . . . . . . . . . . . . . . 7 70 4.2.2. Capability and Attribute Discovery . . . . . . . . . 7 71 4.3. Instantiating P2MP segment nodes . . . . . . . . . . . . 7 72 4.3.1. PCEP . . . . . . . . . . . . . . . . . . . . . . . . 8 73 4.3.2. BGP . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 4.3.3. NetConf . . . . . . . . . . . . . . . . . . . . . . . 8 75 4.4. Protection . . . . . . . . . . . . . . . . . . . . . . . 8 76 4.4.1. Local Protection . . . . . . . . . . . . . . . . . . 8 77 4.4.2. Path Protection . . . . . . . . . . . . . . . . . . . 8 78 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 80 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 81 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 82 9. Normative References . . . . . . . . . . . . . . . . . . . . 10 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 85 1. Introduction 87 This document defines variants of the SR Policy [I-D. ietf-spring- 88 segment-routing-policy] to support Point-to-Multipoint service 89 delivery. 91 We define a Point-to-Multipoint (P2MP) segment, which connects a Root 92 node to a set of Leaf nodes in a Segment Routing Domain. 94 We also define a Replication Segment, which corresponds to the state 95 of a P2MP segment on a particular node. 97 A P2MP segment consists of replication segments for the root, leaves, 98 and optionally intermediate replication nodes. Note that a node may 99 forward only one copy to a downstream node (be it a leaf or another 100 intermediate node) or even just forward traffic off the p2mp segment 101 (i.e. as a leaf), but we still call the forwarding behavior on the 102 node a replication segment. 104 For a P2MP segment, a controller may be used to compute paths from a 105 Root node to a set of Leaf nodes, optionally via a set of replication 106 nodes. A packet is replicated at the root node and optionally on 107 Replication nodes towards each Leaf node. 109 A Point-to-Multipoint service delivery could be via Ingress 110 Replication (aka Spray in some SR context), i.e., the root unicasts 111 individual copies of traffic to each leaf. The corresponding P2MP 112 segment consists of replication segments only for the root and the 113 leaves. 115 A Point-to-Multipoint service delivery could also be via Downstream 116 Replication (aka TreeSID in some SR context), i.e., the root and some 117 downstream replication nodes replicate the traffic along the way as 118 it traverses closer to the leaves. 120 Notice that Spray is actually a special form of TreeSID. Also notice 121 that, the explicit path from the root or a replication node to a leaf 122 or a downstream replication node can optionally be partially or 123 completely specified by the controller or determined locally. 125 2. SR Replication Policy 127 An SR Replication policy is a variant of an SR policy [I-D.ietf- 128 spring-segment-routing-policy]. A replication policy corresponds to 129 a replication segment, which defines the forwarding behavior on a 130 particular node on a particular P2MP segment. 132 An SR Replication Policy can be either provisioned locally or 133 programmed by a controller. 135 An SR Replication Policy is identified through the tuple . 138 An SR Replication Policy is defined by following elements: 140 o Node-ID: The node that the replication segment is for. 142 o Root: The root of the P2MP segment that the replication segment is 143 for. 145 o Tree-ID: Tree that the replication segment is part of. 147 o Replication-SID: Segment ID for this Replication Segment. 149 o Candidate Paths: See below. 151 The Replication-SID is instantiated into the forwarding plane at the 152 node. An incoming packet with the SID is forwarded according to the 153 replication branches. The Replication-SID may be the same on all 154 nodes of the tree, and referred to as Tree-SID. 156 A SR Replication Policy may comprise of multiple candidate paths. 157 The active candidate path is selected based on the tie breaking rules 158 amongst the valid candidate-paths. 160 Each candidate path includes a list of replication branches. In this 161 document, each branch is abstracted to a tuple. For the signaling from a controller to a 163 tree node, the Downstream Node in the tuple could be represented by 164 its Node-SID (i.e. it does not matter how traffic gets to the 165 downstream node, whether it's directly connected or not), or in case 166 of a directly connected Downstream Node it could be represented by 167 one of this node's Adjacency-SIDs (for the interface connecting to 168 the directly connected Downstream Node). Alternatively, the 169 Downstream Node could also be expanded to a SID-list that partially/ 170 fully specify the explicit path to it. In all cases, the node 171 converts the signaled SIDs to its local forwarding representation 172 (e.g., a Node/Adjacency-SID of a directly connected Downstream Node 173 is translated to a local interface). 175 Each replication branch may also include one or more backup branches 176 for protection purpose. Details will be added in a future revision. 178 3. SR P2MP Policy 180 The SR P2MP policy is a variant of an SR policy [I-D.ietf-spring- 181 segment-routing-policy]. It correspond to an SR P2MP Segment. 183 A SR P2MP Policy is defined by following elements: 185 o Root node: This is the headend of the P2MP segment. 187 o Leaf nodes: A set of nodes that terminate the P2MP segment. 189 o Constraints/Objectives: Optional set of topological/resource 190 constraints and optimization objectives to be satisfied by the 191 P2MP segment. 193 A SR P2MP Policy is identified through the tuple . 196 An SR P2MP Policy has a BSID [I-D.ietf-spring-segment-routing-policy] 197 instantiated into the forwarding plane. The BSID is applicable only 198 at the Root node. 200 An SR P2MP policy can be either provisioned locally or programmed by 201 a controller onto the root node of the segment, for the purpose of 202 steering traffic into the segment. A controller calculates the tree 203 and program corresponding replication segments on root, leaves and 204 optional replication nodes. 206 Traffic is steered into a SR P2MP Policy in two ways: 208 o Based on a local policy-based routing at the Root node. 210 o Based on remote classification and steering via the BSID of the SR 211 P2MP Policy at the Root node. 213 Traffic is then forwarded toward the leaves following the replication 214 segments. 216 4. Using Controller to build a P2MP Segment 218 A P2MP segment can be built using a Path Computation Element (PCE) 219 and PCE Protocol (PCEP). This section outlines a high-level 220 architecture for such an approach. 222 North Bound South Bound 223 Programming ..... Programming 224 Interface Interface 225 | 226 | 227 v 228 +-----+ .......................... 229 .............| PCE | ............. . 230 . +-----+ . . 231 . . . . 232 . . . . 233 . . . . 234 . . V . 235 . . +----+ . 236 . . | N3 | . 237 . . +----+ . 238 . . | Leaf (L2) . 239 . . | . 240 . . | . 241 V V | V 242 +----+ +----+ -------------- +----+ 243 | N1 |----------| N2 |-------------------------| N4 | 244 +----+ +----+ +----+ 245 Root (R) Replication Node (M) Leaf (L1) 247 Figure 1: Centralized Control Plane Model 249 4.1. SR P2MP Policy Creation 251 A SR P2MP policy can be instantiated and maintained in a centralized 252 fashion using a Path Computation Element (PCE). 254 4.1.1. API 256 North-bound APIs on a PCE can be used to: 258 1. Create P2MP SR policy 260 2. Delete P2MP SR policy 262 3. Update P2MP SR policy 264 4.1.2. Invoking API 266 Operator shall interact with a PCE via REST, Netconf, gRPC, CLI. 267 Yang model shall be be developed for this purpose as well. 269 4.2. P2MP Segment Computation 271 Network operator passes the addresses of the root (R) and set of 272 leaves {L} as well as Traffic Engineering (TE) attributes (e.g., 273 constraints such as link color, optimization criteria such as 274 latency) of the P2MP segment to PCE via a suitable North-Bound API. 275 The PCE computes the tree instantiates the P2MP segment on Root, 276 Replication, and Leaf nodes. 278 Path constraints shall include link color affinity, bandwidth, 279 disjointness (link, node, SRLG), delay bound, link loss, etc. Path 280 shall be optimized based on IGP or TE metric or link latency. 282 Ideally, same P2MP SID SHOULD be used for forwarding entries at Root, 283 Mid, and Leaf nodes. Different P2MP SIDs MAY be used at different 284 node(s) if it is not feasible to use same P2MP SID. SIDs (BSID as 285 well as P2MP SID) can also be assigned by operator. 287 A PCE can modify a P2MP segment following network element failure or 288 in case a better path can be found based on the new network state. 289 In this case, the PCE may want to setup the new tree and remove the 290 old tree from the network in order to minimize traffic loss. As 291 such, a separate P2MP SID can be used for the new tree. 293 A PCE shall be capable of computing paths across multiple IGP areas 294 or levels as well as Autonomous Systems (ASs). 296 4.2.1. Topology Discovery 298 A PCE shall learn network topology, TE attributes of link/node as 299 well as SIDs via dynamic routing protocols (IGP and/or BGP-LS). It 300 may be possible for operators to pass topology information to PCE via 301 north-bound API. 303 4.2.2. Capability and Attribute Discovery 305 It shall be possible for a node to advertise TreeSID capability via 306 IGP and/or BGP-LS. Similarly, a PCE can also advertise its TreeSID 307 capability via IGP and/or BGP-LS. Capability advertisement allows a 308 network node to dynamically choose one or more PCE(s) to obtain 309 services pertaining to SR P2MP policies, as well a PCE to dynamically 310 identify TreeSID capable nodes. 312 4.3. Instantiating P2MP segment nodes 314 Once a PCE computes a tree for P2MP segment, it needs to instantiate 315 the segment on the relevant network nodes. The PCE can use various 316 protocols to program the forwarding entries, and these protocols are 317 described below. 319 4.3.1. PCEP 321 PCE Protocol (PCEP)has been traditionally used: 323 1. For a head-end to obtain paths from a PCE. 325 2. A PCE to instantiate SR policies. 327 PCEP protocol can be stateful in that a PCE can have a stateful 328 control of an SR policy on a head-end which has delegated the control 329 of the SR policy to the PCE. PCEP shall be extended to provision and 330 maintain forwarding entries in a stateful fashion. 332 4.3.2. BGP 334 BGP has been extended to instantiate and report SR policies. It 335 shall be used to instantiate and maintain forwarding entries for SR 336 P2MP policies. 338 4.3.3. NetConf 340 TBD 342 4.4. Protection 344 4.4.1. Local Protection 346 A network link/node on the tree of a P2MP segment can be protected 347 using SR policies computed by PCE. The backup SR policies shall be 348 programmed in forwarding plane in order to minimize traffic loss when 349 the protected link/node fails. 351 4.4.2. Path Protection 353 It is possible for PCE create a disjoint backup tree for providing 354 end-to-end path protection. 356 5. IANA Considerations 358 This document makes no request of IANA. 360 6. Security Considerations 362 There are no additional security risks introduced by this design. 364 7. Acknowledgements 366 The authors would like to acknowledge Siva Sivabalan. 368 8. Contributors 370 Clayton Hassen 371 Bell Canada 372 Vancouver 373 Canada 375 Email: clayton.hassen@bell.ca 377 Kurtis Gillis 378 Bell Canada 379 Halifax 380 Canada 382 Email: kurtis.gillis@bell.ca 384 Arvind Venkateswaran 385 Cisco Systems, Inc. 386 San Jose 387 US 389 Email: arvvenka@cisco.com 391 Zafar Ali 392 Cisco Systems, Inc. 393 US 395 Email: zali@cisco.com 397 Swadesh Agrawal 398 Cisco Systems, Inc. 399 San Jose 400 US 402 Email: swaagraw@cisco.com 404 Jayant Kotalwar 405 Nokia 406 Mountain View 407 US 408 Email: jayant.kotalwar@nokia.com 410 Tanmoy Kundu 411 Nokia 412 Mountain View 413 US 415 Email: tanmoy.kundu@nokia.com 417 9. Normative References 419 [I-D.ietf-spring-segment-routing-policy] 420 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 421 bogdanov@google.com, b., and P. Mattes, "Segment Routing 422 Policy Architecture", draft-ietf-spring-segment-routing- 423 policy-03 (work in progress), May 2019. 425 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 426 Requirement Levels", BCP 14, RFC 2119, 427 DOI 10.17487/RFC2119, March 1997, 428 . 430 Authors' Addresses 432 Daniel Voyer (editor) 433 Bell Canada 434 Montreal 435 CA 437 Email: daniel.voyer@bell.ca 439 Clarence Filsfils 440 Cisco Systems, Inc. 441 Brussels 442 BE 444 Email: cfilsfil@cisco.com 446 Rishabh Parekh 447 Cisco Systems, Inc. 448 San Jose 449 US 451 Email: riparekh@cisco.com 452 Hooman Bidgoli 453 Nokia 454 Ottawa 455 CA 457 Email: hooman.bidgoli@nokia.com 459 Zhaohui Zhang 460 Juniper Networks 462 Email: zzhang@juniper.net