idnits 2.17.1 draft-ietf-spring-sr-replication-segment-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 date (July 26, 2020) is 1362 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: January 27, 2021 R. Parekh 6 Cisco Systems, Inc. 7 H. Bidgoli 8 Nokia 9 Z. Zhang 10 Juniper Networks 11 July 26, 2020 13 SR Replication Segment for Multi-point Service Delivery 14 draft-ietf-spring-sr-replication-segment-00 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 January 27, 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 for a replicated copy is CONTINUE. 152 o On the root of a multi-point service, based on local policy-based 153 routing. In this case, the operation for a replicated copy is 154 PUSH. 156 If a Downstream Node is an egress (aka leaf) of the multi-point 157 service, i.e. no further replication is needed, then that leaf node's 158 Replication segment will not have any Replication State and the 159 operation is NEXT. At an egress node, the Replication SID MAY be 160 used to identify that portion of the multi-point service. Notice 161 that the segment on the leaf node is still referred to as a 162 Replication segment for the purpose of generalization. 164 A node can be a bud node, i.e. it is a replication node and a leaf 165 node of a multi-point service at the same time 166 [I-D.voyer-pim-sr-p2mp-policy]. In this case, the Replication 167 segment's Replication State includes a branch with the Downstream 168 Node being itself and the operation for the replicated copy is NEXT. 170 The Replication SID MUST be the last SID (at the bottom of stack for 171 SR-MPLS) in a packet that is steered out from a Replication node of a 172 Replication Segment. The behavior at Downstream nodes of a 173 Replication Segment is undefined If there are any SIDs after the 174 Replication SID and is outside the scope of this document. 176 3. Use Cases 178 In the simplest use case, a single Replication segment includes the 179 root node of a multi-point service and the egress/leaf nodes of the 180 the service as all the Downstream Nodes. This achieves Ingress 181 Replication [RFC7988] that has been widely used for MVPN [RFC6513] 182 and EVPN [RFC7432] BUM (Broadcast, Unknown and Multicast) traffic. 184 Replication segments can also be used as building blocks for 185 replication trees when Replication segments on the root, intermediate 186 replication nodes and leaf nodes are stitched together to achieve 187 efficient replication. That is specified in 188 [I-D.voyer-pim-sr-p2mp-policy]. 190 4. IANA Considerations 192 This document makes no request of IANA. 194 5. Security Considerations 196 There are no additional security risks introduced by this design. 198 6. Acknowledgements 200 The authors would like to acknowledge Siva Sivabalan, Mike Koldychev, 201 Vishnu Pavan Beeram, Alexander Vainshtein, Bruno Decraene and Joel 202 Halpern for their valuable inputs. 204 7. Contributors 206 Clayton Hassen 207 Bell Canada 208 Vancouver 209 Canada 211 Email: clayton.hassen@bell.ca 213 Kurtis Gillis 214 Bell Canada 215 Halifax 216 Canada 218 Email: kurtis.gillis@bell.ca 220 Arvind Venkateswaran 221 Cisco Systems, Inc. 222 San Jose 223 US 225 Email: arvvenka@cisco.com 227 Zafar Ali 228 Cisco Systems, Inc. 229 US 231 Email: zali@cisco.com 232 Swadesh Agrawal 233 Cisco Systems, Inc. 234 San Jose 235 US 237 Email: swaagraw@cisco.com 239 Jayant Kotalwar 240 Nokia 241 Mountain View 242 US 244 Email: jayant.kotalwar@nokia.com 246 Tanmoy Kundu 247 Nokia 248 Mountain View 249 US 251 Email: tanmoy.kundu@nokia.com 253 Andrew Stone 254 Nokia 255 Ottawa 256 Canada 258 Email: andrew.stone@nokia.com 260 Tarek Saad 261 Juniper Networks 262 Canada 264 Email:tsaad@juniper.net 266 8. References 268 8.1. Normative References 270 [I-D.ietf-spring-segment-routing-policy] 271 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 272 P. Mattes, "Segment Routing Policy Architecture", draft- 273 ietf-spring-segment-routing-policy-08 (work in progress), 274 July 2020. 276 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 277 Requirement Levels", BCP 14, RFC 2119, 278 DOI 10.17487/RFC2119, March 1997, 279 . 281 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 282 Decraene, B., Litkowski, S., and R. Shakir, "Segment 283 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 284 July 2018, . 286 8.2. Informative References 288 [I-D.voyer-pim-sr-p2mp-policy] 289 Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z. 290 Zhang, "Segment Routing Point-to-Multipoint Policy", 291 draft-voyer-pim-sr-p2mp-policy-02 (work in progress), July 292 2020. 294 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 295 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 296 2012, . 298 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 299 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 300 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 301 2015, . 303 [RFC7988] Rosen, E., Ed., Subramanian, K., and Z. Zhang, "Ingress 304 Replication Tunnels in Multicast VPN", RFC 7988, 305 DOI 10.17487/RFC7988, October 2016, 306 . 308 Appendix A. Illustration of a Replication Segment 310 This section illustrates an example of a single Replication Segment. 311 Examples showing Replication Segment stitched together to form P2MP 312 tree (based on SR P2MP policy) are in [I-D.voyer-pim-sr-p2mp-policy]. 314 Consider the following topology: 316 R3------R6 317 / \ 318 R1----R2----R5-----R7 319 \ / 320 +--R4---+ 322 Figure 1 324 In this example, the Node-SID of a node Rn is N-SIDn and Adjacency- 325 SID from node Rm to node Rn is A-SIDmn. Interface between Rm and Rn 326 is Lmn. 328 Assume a Replication Segment identified with R-ID at replication node 329 R1 and downstream Nodes R2, R6 and R7. The Replication SID at node n 330 is R-SIDn. A packet replicated from R1 to R7 has to traverse R4. 332 The Replication Segment state at nodes R1, R2, R6 and R7 is shown 333 below. Note nodes R3, R4 and R5 do not have state for the 334 Replication Segment. 336 Replication Segment at R1: 338 Replication Segment : 339 Replication SID: R-SID1 340 Replication State: 341 R2: L12> 342 R6: 343 R7: 345 Replication to R2 steers packet directly to R2 on interface L12. 346 Replication to R6, using N-SID6, steers packet via IGP shortest path 347 to that node. Replication to R7 is steered via R4, using N-SID4 and 348 then adjacency SID A-sID47 to R7. 350 Replication Segment at R2: 352 Replication Segment : 353 Replication SID: R-SID2 354 Replication State: 355 R2: 357 Replication Segment at R6: 359 Replication Segment : 360 Replication SID: R-SID6 361 Replication State: 362 R6: 364 Replication Segment at R7: 366 Replication Segment : 367 Replication SID: R-SID7 368 Replication State: 369 R7: 371 When a packet is steered into the replication segment at R1: 373 o Since R1 is directly connected to R2, R1 performs PUSH operation 374 with just label for the replicated copy and sends it to 375 R2 on interface L12. R2, as Leaf, performs NEXT operation, pops 376 R-SID2 label and delivers the payload. 378 o R1 performs PUSH operation with label stack for 379 the replicated copy to R6 and sends it to R2, the nexthop on IGP 380 shortest path to R6. R2 performs CONTINUE operation on N-SID6 and 381 forwards it to R3. R3 is the penultimate hop for N-SID6; it 382 performs penultimate hop popping, which corresponds to the NEXT 383 operation and the packet is then sent to R6 with in the 384 label stack. R6, as Leaf, performs NEXT operation, pops R-SID6 385 label and delivers the payload. 387 o R1 performs PUSH operation with label 388 stack for the replicated copy to R7 and sends it to R2, the 389 nexthop on IGP shortest path to R4. R2 is the penultimate hop for 390 N-SID4; it performs penultimate hop popping, which corresponds to 391 the NEXT operation and the packet is then sent to R4 with 392 in the label stack. R4 performs NEXT operation, 393 pops A-SID47, and delivers packet to R7 with in the label 394 stack. R7, as Leaf, performs NEXT operation, pops R-SID7 label 395 and delivers the payload. 397 Authors' Addresses 399 Daniel Voyer (editor) 400 Bell Canada 401 Montreal 402 CA 404 Email: daniel.voyer@bell.ca 406 Clarence Filsfils 407 Cisco Systems, Inc. 408 Brussels 409 BE 411 Email: cfilsfil@cisco.com 413 Rishabh Parekh 414 Cisco Systems, Inc. 415 San Jose 416 US 418 Email: riparekh@cisco.com 419 Hooman Bidgoli 420 Nokia 421 Ottawa 422 CA 424 Email: hooman.bidgoli@nokia.com 426 Zhaohui Zhang 427 Juniper Networks 429 Email: zzhang@juniper.net