idnits 2.17.1 draft-ietf-spring-sr-replication-segment-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 (October 29, 2020) is 1273 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-08 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: May 2, 2021 R. Parekh 6 Cisco Systems, Inc. 7 H. Bidgoli 8 Nokia 9 Z. Zhang 10 Juniper Networks 11 October 29, 2020 13 SR Replication Segment for Multi-point Service Delivery 14 draft-ietf-spring-sr-replication-segment-03 16 Abstract 18 This document describes the SR Replication segment for Multi-point 19 service delivery. A SR Replication segment allows a packet to be 20 replicated from a replication node to downstream nodes. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on May 2, 2021. 45 Copyright Notice 47 Copyright (c) 2020 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Replication Segment . . . . . . . . . . . . . . . . . . . . . 3 64 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 67 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 68 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 5 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 71 8.2. Informative References . . . . . . . . . . . . . . . . . 7 72 Appendix A. Illustration of a Replication Segment . . . . . . . 7 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 We define a new type of segment for Segment Routing [RFC8402], called 78 Replication segment, which allows a node (henceforth called as 79 Replication Node) to replicate packets to a set of other nodes 80 (called Downstream Nodes) in a Segment Routing Domain. Replication 81 segments provide building blocks for Point-to-Multipoint Service 82 delivery via SR Point-to-Multipoint (SR P2MP) policy. A Replication 83 segment can replicate packet to directly connected nodes or to 84 downstream nodes (without need for state on the transit routers). 85 This document focuses on the Replication Segment building block. The 86 use of one or more stitched Replication Segments constructed for SR 87 P2MP Policy tree is specified in [I-D.voyer-pim-sr-p2mp-policy]. 89 2. Replication Segment 91 In a Segment Routing Domain, a Replication segment is a logical 92 construct which connects a Replication Node to a set of Downstream 93 Nodes. A Replication segment is a local segment instantiated at a 94 Replication node. It can be either provisioned locally on a node or 95 programmed by a PCE. Replication segments apply equally to both SR- 96 MPLS and SRv6 instantiations of Segment Routing. 98 A Replication segment is identified by the tuple , where: 101 o Replication-ID: An identifier for a Replication segment that is 102 unique in context of the Replication Node. 104 o Node-ID: The address of the Replication Node that the Replication 105 segment is for. Note that the root of a multi-point service is 106 also a replication node. 108 In simplest case, Replication-ID can be a 32-bit number, but it can 109 be extended or modified as required based on specific use of a 110 Replication segment. When the PCE signals a Replication segment to 111 its node, the tuple identifies the segment. 112 Examples of such signaling and extension are described in 113 [I-D.voyer-pim-sr-p2mp-policy]. 115 A Replication segment includes the following elements: 117 o Replication SID: The Segment Identifier of a Replication segment. 118 This is a SR-MPLS label or a SRv6 SID [RFC8402]. 120 o Downstream Nodes: Set of nodes in Segment Routing domain to which 121 a packet is replicated by the Replication segment. 123 o Replication State: See below. 125 The Downstream Nodes and Replication State of a Replication segment 126 can change over time, depending on the network state and leaf nodes 127 of a multi-point service that the segment is part of. 129 Replication State is a list of replication branches to the Downstream 130 Nodes. In this document, each branch is abstracted to a tuple. A Downstream Node is 132 represented by a SID-list or a Segment Routing Policy 133 [I-D.ietf-spring-segment-routing-policy] that specifies the explicit 134 path from the Replication Node to the Downstream Node, or even 135 represented by another Replication segment. The SID-list MAY just 136 have one SID. If a downstream node is adjacent to a Replication 137 node, it MAY also be represented by an interface. 139 Replication SID identifies the Replication segment in the forwarding 140 plane. At a Replication node, the Replication SID is the equivalent 141 of Binding SID [I-D.ietf-spring-segment-routing-policy] of a Segment 142 Routing Policy. 144 A packet steered into a Replication segment at a Replication node is 145 replicated to each Downstream Node with the Downstream Replication 146 SID that is relevant at that node. A packet is steered into a 147 Replication Segment in two ways: 149 o When the Active Segment [RFC8402] is the Replication SID. In this 150 case, the operation is NEXT followed by a PUSH for a replicated 151 copy. 153 o On the root of a multi-point service, based on local policy-based 154 routing. In this case, the operation for a replicated copy is 155 PUSH. 157 If a Downstream Node is an egress (aka leaf) of the multi-point 158 service, i.e. no further replication is needed, then that leaf node's 159 Replication segment will not have any Replication State and the 160 operation is NEXT. At an egress node, the Replication SID MAY be 161 used to identify that portion of the multi-point service. Notice 162 that the segment on the leaf node is still referred to as a 163 Replication segment for the purpose of generalization. 165 A node can be a bud node, i.e. it is a replication node and a leaf 166 node of a multi-point service at the same time 167 [I-D.voyer-pim-sr-p2mp-policy]. In this case, the Replication 168 segment's Replication State includes a branch with the Downstream 169 Node being itself and the operation for the replicated copy is NEXT. 171 The Replication SID MUST be the last SID (at the bottom of stack for 172 SR-MPLS) in a packet that is steered out from a Replication node of a 173 Replication Segment. The behavior at Downstream nodes of a 174 Replication Segment is undefined If there are any SIDs after the 175 Replication SID and is outside the scope of this document. 177 3. Use Cases 179 In the simplest use case, a single Replication segment includes the 180 root node of a multi-point service and the egress/leaf nodes of the 181 the service as all the Downstream Nodes. This achieves Ingress 182 Replication [RFC7988] that has been widely used for MVPN [RFC6513] 183 and EVPN [RFC7432] BUM (Broadcast, Unknown and Multicast) traffic. 185 Replication segments can also be used as building blocks for 186 replication trees when Replication segments on the root, intermediate 187 replication nodes and leaf nodes are stitched together to achieve 188 efficient replication. That is specified in 189 [I-D.voyer-pim-sr-p2mp-policy]. 191 4. IANA Considerations 193 This document makes no request of IANA. 195 5. Security Considerations 197 There are no additional security risks introduced by this design. 199 6. Acknowledgements 201 The authors would like to acknowledge Siva Sivabalan, Mike Koldychev, 202 Vishnu Pavan Beeram, Alexander Vainshtein, Bruno Decraene and Joel 203 Halpern for their valuable inputs. 205 7. Contributors 207 Clayton Hassen 208 Bell Canada 209 Vancouver 210 Canada 212 Email: clayton.hassen@bell.ca 214 Kurtis Gillis 215 Bell Canada 216 Halifax 217 Canada 219 Email: kurtis.gillis@bell.ca 221 Arvind Venkateswaran 222 Cisco Systems, Inc. 223 San Jose 224 US 226 Email: arvvenka@cisco.com 228 Zafar Ali 229 Cisco Systems, Inc. 230 US 232 Email: zali@cisco.com 233 Swadesh Agrawal 234 Cisco Systems, Inc. 235 San Jose 236 US 238 Email: swaagraw@cisco.com 240 Jayant Kotalwar 241 Nokia 242 Mountain View 243 US 245 Email: jayant.kotalwar@nokia.com 247 Tanmoy Kundu 248 Nokia 249 Mountain View 250 US 252 Email: tanmoy.kundu@nokia.com 254 Andrew Stone 255 Nokia 256 Ottawa 257 Canada 259 Email: andrew.stone@nokia.com 261 Tarek Saad 262 Juniper Networks 263 Canada 265 Email:tsaad@juniper.net 267 8. References 269 8.1. Normative References 271 [I-D.ietf-spring-segment-routing-policy] 272 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 273 P. Mattes, "Segment Routing Policy Architecture", draft- 274 ietf-spring-segment-routing-policy-08 (work in progress), 275 July 2020. 277 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 278 Requirement Levels", BCP 14, RFC 2119, 279 DOI 10.17487/RFC2119, March 1997, 280 . 282 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 283 Decraene, B., Litkowski, S., and R. Shakir, "Segment 284 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 285 July 2018, . 287 8.2. Informative References 289 [I-D.voyer-pim-sr-p2mp-policy] 290 Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z. 291 Zhang, "Segment Routing Point-to-Multipoint Policy", 292 draft-voyer-pim-sr-p2mp-policy-02 (work in progress), July 293 2020. 295 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 296 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 297 2012, . 299 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 300 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 301 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 302 2015, . 304 [RFC7988] Rosen, E., Ed., Subramanian, K., and Z. Zhang, "Ingress 305 Replication Tunnels in Multicast VPN", RFC 7988, 306 DOI 10.17487/RFC7988, October 2016, 307 . 309 Appendix A. Illustration of a Replication Segment 311 This section illustrates an example of a single Replication Segment. 312 Examples showing Replication Segment stitched together to form P2MP 313 tree (based on SR P2MP policy) are in [I-D.voyer-pim-sr-p2mp-policy]. 315 Consider the following topology: 317 R3------R6 318 / \ 319 R1----R2----R5-----R7 320 \ / 321 +--R4---+ 323 Figure 1 325 In this example, the Node-SID of a node Rn is N-SIDn and Adjacency- 326 SID from node Rm to node Rn is A-SIDmn. Interface between Rm and Rn 327 is Lmn. 329 Assume a Replication Segment identified with R-ID at replication node 330 R1 and downstream Nodes R2, R6 and R7. The Replication SID at node n 331 is R-SIDn. A packet replicated from R1 to R7 has to traverse R4. 333 The Replication Segment state at nodes R1, R2, R6 and R7 is shown 334 below. Note nodes R3, R4 and R5 do not have state for the 335 Replication Segment. 337 Replication Segment at R1: 339 Replication Segment : 340 Replication SID: R-SID1 341 Replication State: 342 R2: L12> 343 R6: 344 R7: 346 Replication to R2 steers packet directly to R2 on interface L12. 347 Replication to R6, using N-SID6, steers packet via IGP shortest path 348 to that node. Replication to R7 is steered via R4, using N-SID4 and 349 then adjacency SID A-sID47 to R7. 351 Replication Segment at R2: 353 Replication Segment : 354 Replication SID: R-SID2 355 Replication State: 356 R2: 358 Replication Segment at R6: 360 Replication Segment : 361 Replication SID: R-SID6 362 Replication State: 363 R6: 365 Replication Segment at R7: 367 Replication Segment : 368 Replication SID: R-SID7 369 Replication State: 370 R7: 372 When a packet is steered into the replication segment at R1: 374 o Since R1 is directly connected to R2, R1 performs PUSH operation 375 with just label for the replicated copy and sends it to 376 R2 on interface L12. R2, as Leaf, performs NEXT operation, pops 377 R-SID2 label and delivers the payload. 379 o R1 performs PUSH operation with label stack for 380 the replicated copy to R6 and sends it to R2, the nexthop on IGP 381 shortest path to R6. R2 performs CONTINUE operation on N-SID6 and 382 forwards it to R3. R3 is the penultimate hop for N-SID6; it 383 performs penultimate hop popping, which corresponds to the NEXT 384 operation and the packet is then sent to R6 with in the 385 label stack. R6, as Leaf, performs NEXT operation, pops R-SID6 386 label and delivers the payload. 388 o R1 performs PUSH operation with label 389 stack for the replicated copy to R7 and sends it to R2, the 390 nexthop on IGP shortest path to R4. R2 is the penultimate hop for 391 N-SID4; it performs penultimate hop popping, which corresponds to 392 the NEXT operation and the packet is then sent to R4 with 393 in the label stack. R4 performs NEXT operation, 394 pops A-SID47, and delivers packet to R7 with in the label 395 stack. R7, as Leaf, performs NEXT operation, pops R-SID7 label 396 and delivers the payload. 398 Authors' Addresses 400 Daniel Voyer (editor) 401 Bell Canada 402 Montreal 403 CA 405 Email: daniel.voyer@bell.ca 407 Clarence Filsfils 408 Cisco Systems, Inc. 409 Brussels 410 BE 412 Email: cfilsfil@cisco.com 414 Rishabh Parekh 415 Cisco Systems, Inc. 416 San Jose 417 US 419 Email: riparekh@cisco.com 420 Hooman Bidgoli 421 Nokia 422 Ottawa 423 CA 425 Email: hooman.bidgoli@nokia.com 427 Zhaohui Zhang 428 Juniper Networks 430 Email: zzhang@juniper.net