idnits 2.17.1 draft-ietf-spring-sr-replication-segment-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 copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: There MUST not be any topological SID after a Replication SID in a packet. Otherwise, the behavior at Downstream nodes of a Replication segment is undefined and outside the scope of this document. -- The document date (February 17, 2021) is 1163 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: 'I-D.ietf-spring-srv6-network-programming' is defined on line 330, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-09 == Outdated reference: A later version (-04) exists of draft-filsfils-spring-srv6-net-pgm-illustration-03 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-13 == Outdated reference: A later version (-08) exists of draft-ietf-pim-sr-p2mp-policy-01 Summary: 0 errors (**), 0 flaws (~~), 7 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: August 21, 2021 R. Parekh 6 Cisco Systems, Inc. 7 H. Bidgoli 8 Nokia 9 Z. Zhang 10 Juniper Networks 11 February 17, 2021 13 SR Replication Segment for Multi-point Service Delivery 14 draft-ietf-spring-sr-replication-segment-04 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 August 21, 2021. 45 Copyright Notice 47 Copyright (c) 2021 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 2.1. SR-MPLS data plane . . . . . . . . . . . . . . . . . . . 4 65 2.2. SRv6 data plane . . . . . . . . . . . . . . . . . . . . . 5 66 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 69 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 70 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 73 8.2. Informative References . . . . . . . . . . . . . . . . . 8 74 Appendix A. Illustration of a Replication Segment . . . . . . . 9 75 A.1. SR-MPLS . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 A.2. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 79 1. Introduction 81 We define a new type of segment for Segment Routing [RFC8402], called 82 Replication segment, which allows a node (henceforth called as 83 Replication Node) to replicate packets to a set of other nodes 84 (called Downstream Nodes) in a Segment Routing Domain. Replication 85 segments provide building blocks for Point-to-Multipoint Service 86 delivery via SR Point-to-Multipoint (SR P2MP) policy. A Replication 87 segment can replicate packet to directly connected nodes or to 88 downstream nodes (without need for state on the transit routers). 89 This document focuses on the Replication segment building block. The 90 use of one or more stitched Replication segments constructed for SR 91 P2MP Policy tree is specified in [I-D.ietf-pim-sr-p2mp-policy]. 93 2. Replication Segment 95 In a Segment Routing Domain, a Replication segment is a logical 96 construct which connects a Replication Node to a set of Downstream 97 Nodes. A Replication segment is a local segment instantiated at a 98 Replication node. It can be either provisioned locally on a node or 99 programmed by a PCE. Replication segments apply equally to both SR- 100 MPLS and SRv6 instantiations of Segment Routing. 102 A Replication segment is identified by the tuple , where: 105 o Replication-ID: An identifier for a Replication segment that is 106 unique in context of the Replication Node. 108 o Node-ID: The address of the Replication Node that the Replication 109 segment is for. Note that the root of a multi-point service is 110 also a Replication Node. 112 In simplest case, Replication-ID can be a 32-bit number, but it can 113 be extended or modified as required based on specific use of a 114 Replication segment. When the PCE signals a Replication segment to 115 its node, the tuple identifies the segment. 116 Examples of such signaling and extension are described in 117 [I-D.ietf-pim-sr-p2mp-policy]. 119 A Replication segment includes the following elements: 121 o Replication SID: The Segment Identifier of a Replication segment. 122 This is a SR-MPLS label or a SRv6 SID [RFC8402]. 124 o Downstream Nodes: Set of nodes in Segment Routing domain to which 125 a packet is replicated by the Replication segment. 127 o Replication State: See below. 129 The Downstream Nodes and Replication State of a Replication segment 130 can change over time, depending on the network state and leaf nodes 131 of a multi-point service that the segment is part of. 133 Replication SID identifies the Replication segment in the forwarding 134 plane. At a Replication node, the Replication SID is the equivalent 135 of Binding SID [I-D.ietf-spring-segment-routing-policy] of a Segment 136 Routing Policy. 138 Replication State is a list of replication branches to the Downstream 139 Nodes. In this document, each branch is abstracted to a tuple. 142 In a branch tuple, represents the reachability from 143 the Replication Node to the Downstream Node. In its simplest form, 144 this MAY be specified as an interface or nexthop if downstream node 145 is adjacent to the Replication Node. The reachability may be 146 specified in terms of Flex-Algo path (including the default algo) 147 [I-D.ietf-lsr-flex-algo], or specified by an SR explicit path 148 represented either by a SID-list (of one or more SIDs) or by a 149 Segment Routing Policy [I-D.ietf-spring-segment-routing-policy]. 151 A packet is steered into a Replication segment at a Replication Node 152 in two ways: 154 o When the Active Segment [RFC8402] is a locally instantiated 155 Replication SID 157 o By the root of a multi-point service based on local configuration 158 outside the scope of this document. 160 In either case, the packet is replicated to each Downstream node in 161 the associated Replication state. 163 If a Downstream Node is an egress (aka leaf) of the multi-point 164 service, i.e. no further replication is needed, then that leaf node's 165 Replication segment will not have any Replication State and the 166 operation is NEXT. At an egress node, the Replication SID MAY be 167 used to identify that portion of the multi-point service. Notice 168 that the segment on the leaf node is still referred to as a 169 Replication segment for the purpose of generalization. 171 A node can be a bud node, i.e. it is a Replication Node and a leaf 172 node of a multi-point service at the same time 173 [I-D.ietf-pim-sr-p2mp-policy]. 175 There MUST not be any topological SID after a Replication SID in a 176 packet. Otherwise, the behavior at Downstream nodes of a Replication 177 segment is undefined and outside the scope of this document. 179 2.1. SR-MPLS data plane 181 When the Active Segment is a Replication SID, the processing results 182 in a POP operation and lookup of the associated Replication state. 183 For each replication in the Replication state, the operation is a 184 PUSH of the downstream Replication SID and an optional segment list 185 on to the packet which is forwarded to the Downstream node. For leaf 186 nodes the inner packet is forwarded as per local configuration. 188 When the root of a multi-point service steers a packet to a 189 Replication segment, it results in a replication to each Downstream 190 node in the associated replication state. The operation is a PUSH of 191 the replication SID and an optional segment list on to the packet 192 which is forwarded to the downstream node. 194 2.2. SRv6 data plane 196 The "Endpoint with replication" behavior (End.Replicate for short) 197 replicates a packet and forwards the packet according to a 198 Replication state. 200 When processing a packet destined to a local Replication-SID, the 201 packet is replicated to Downstream nodes in the associated 202 Replication state. For replication, the outer header is re-used, and 203 the Downstream Replication SID is written into the outer IPv6 header 204 destination address.If required, an optional segment list is used to 205 encapsulate the replicated packet via H.Encaps. For a leaf node, the 206 packet is decapsulated and the inner packet is forwarded as per local 207 configuration. 209 When the root of a multi-point service steers a packet into a 210 Replication segment, for each replication, H.Encaps is used to 211 encapsulate the packet with the segment list to the Downstream node . 213 An End.Replicate SID MUST only appear as the ultimate SID in a SID- 214 list. An implementation that receives a packet destined to a locally 215 instantiated End.Replicate SID that is not the ultimate segment 216 SHOULD reply with ICMP Parameter Problem error (Erroneous header 217 field encountered) and discard the packet. 219 3. Use Cases 221 In the simplest use case, a single Replication segment includes the 222 root node of a multi-point service and the egress/leaf nodes of the 223 service as all the Downstream Nodes. This achieves Ingress 224 Replication [RFC7988] that has been widely used for MVPN [RFC6513] 225 and EVPN [RFC7432] BUM (Broadcast, Unknown and Multicast) traffic. 227 Replication segments can also be used as building blocks for 228 replication trees when Replication segments on the root, intermediate 229 Replication Nodes and leaf nodes are stitched together to achieve 230 efficient replication. That is specified in 231 [I-D.ietf-pim-sr-p2mp-policy]. 233 4. IANA Considerations 235 This document requires registration of End.Replicate behavior in 236 "SRv6 Endpoint Behaviors" sub-registry of "Segment Routing 237 Parameters" top-level registry. 239 +-------+-----+-------------------+-----------+ 240 | Value | Hex | Endpoint behavior | Reference | 241 +-------+-----+-------------------+-----------+ 242 | TBD | TBD | End.Replicate | [This.ID] | 243 +-------+-----+-------------------+-----------+ 245 Table 1: IETF - SRv6 Endpoint Behaviors 247 5. Security Considerations 249 There are no additional security risks introduced by this design. 251 6. Acknowledgements 253 The authors would like to acknowledge Siva Sivabalan, Mike Koldychev, 254 Vishnu Pavan Beeram, Alexander Vainshtein, Bruno Decraene and Joel 255 Halpern for their valuable inputs. 257 7. Contributors 259 Clayton Hassen 260 Bell Canada 261 Vancouver 262 Canada 264 Email: clayton.hassen@bell.ca 266 Kurtis Gillis 267 Bell Canada 268 Halifax 269 Canada 271 Email: kurtis.gillis@bell.ca 273 Arvind Venkateswaran 274 Cisco Systems, Inc. 275 San Jose 276 US 278 Email: arvvenka@cisco.com 280 Zafar Ali 281 Cisco Systems, Inc. 282 US 284 Email: zali@cisco.com 286 Swadesh Agrawal 287 Cisco Systems, Inc. 288 San Jose 289 US 291 Email: swaagraw@cisco.com 293 Jayant Kotalwar 294 Nokia 295 Mountain View 296 US 298 Email: jayant.kotalwar@nokia.com 300 Tanmoy Kundu 301 Nokia 302 Mountain View 303 US 305 Email: tanmoy.kundu@nokia.com 307 Andrew Stone 308 Nokia 309 Ottawa 310 Canada 312 Email: andrew.stone@nokia.com 314 Tarek Saad 315 Juniper Networks 316 Canada 318 Email:tsaad@juniper.net 320 8. References 322 8.1. Normative References 324 [I-D.ietf-spring-segment-routing-policy] 325 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 326 P. Mattes, "Segment Routing Policy Architecture", draft- 327 ietf-spring-segment-routing-policy-09 (work in progress), 328 November 2020. 330 [I-D.ietf-spring-srv6-network-programming] 331 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 332 Matsushima, S., and Z. Li, "SRv6 Network Programming", 333 draft-ietf-spring-srv6-network-programming-28 (work in 334 progress), December 2020. 336 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 337 Requirement Levels", BCP 14, RFC 2119, 338 DOI 10.17487/RFC2119, March 1997, 339 . 341 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 342 Decraene, B., Litkowski, S., and R. Shakir, "Segment 343 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 344 July 2018, . 346 8.2. Informative References 348 [I-D.filsfils-spring-srv6-net-pgm-illustration] 349 Filsfils, C., Camarillo, P., Li, Z., Matsushima, S., 350 Decraene, B., Steinberg, D., Lebrun, D., Raszuk, R., and 351 J. Leddy, "Illustrations for SRv6 Network Programming", 352 draft-filsfils-spring-srv6-net-pgm-illustration-03 (work 353 in progress), September 2020. 355 [I-D.ietf-lsr-flex-algo] 356 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 357 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 358 algo-13 (work in progress), October 2020. 360 [I-D.ietf-pim-sr-p2mp-policy] 361 Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z. 362 Zhang, "Segment Routing Point-to-Multipoint Policy", 363 draft-ietf-pim-sr-p2mp-policy-01 (work in progress), 364 October 2020. 366 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 367 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 368 2012, . 370 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 371 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 372 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 373 2015, . 375 [RFC7988] Rosen, E., Ed., Subramanian, K., and Z. Zhang, "Ingress 376 Replication Tunnels in Multicast VPN", RFC 7988, 377 DOI 10.17487/RFC7988, October 2016, 378 . 380 Appendix A. Illustration of a Replication Segment 382 This section illustrates an example of a single Replication segment. 383 Examples showing Replication segment stitched together to form P2MP 384 tree (based on SR P2MP policy) are in [I-D.ietf-pim-sr-p2mp-policy]. 386 Consider the following topology: 388 R3------R6 389 / \ 390 R1----R2----R5-----R7 391 \ / 392 +--R4---+ 394 Figure 1 396 A.1. SR-MPLS 398 In this example, the Node-SID of a node Rn is N-SIDn and Adjacency- 399 SID from node Rm to node Rn is A-SIDmn. Interface between Rm and Rn 400 is Lmn. 402 Assume a Replication segment identified with R-ID at Replication Node 403 R1 and downstream Nodes R2, R6 and R7. The Replication SID at node n 404 is R-SIDn. A packet replicated from R1 to R7 has to traverse R4. 406 The Replication segment state at nodes R1, R2, R6 and R7 is shown 407 below. Note nodes R3, R4 and R5 do not have state for the 408 Replication segment. 410 Replication segment at R1: 412 Replication segment : 413 Replication SID: R-SID1 414 Replication State: 415 R2: L12> 416 R6: 417 R7: 419 Replication to R2 steers packet directly to R2 on interface L12. 420 Replication to R6, using N-SID6, steers packet via IGP shortest path 421 to that node. Replication to R7 is steered via R4, using N-SID4 and 422 then adjacency SID A-sID47 to R7. 424 Replication segment at R2: 426 Replication segment : 427 Replication SID: R-SID2 428 Replication State: 429 R2: 431 Replication segment at R6: 433 Replication segment : 434 Replication SID: R-SID6 435 Replication State: 436 R6: 438 Replication segment at R7: 440 Replication segment : 441 Replication SID: R-SID7 442 Replication State: 443 R7: 445 When a packet is steered into the Replication segment at R1: 447 o Since R1 is directly connected to R2, R1 performs PUSH operation 448 with just label for the replicated copy and sends it to 449 R2 on interface L12. R2, as Leaf, performs NEXT operation, pops 450 R-SID2 label and delivers the payload. 452 o R1 performs PUSH operation with label stack for 453 the replicated copy to R6 and sends it to R2, the nexthop on IGP 454 shortest path to R6. R2 performs CONTINUE operation on N-SID6 and 455 forwards it to R3. R3 is the penultimate hop for N-SID6; it 456 performs penultimate hop popping, which corresponds to the NEXT 457 operation and the packet is then sent to R6 with in the 458 label stack. R6, as Leaf, performs NEXT operation, pops R-SID6 459 label and delivers the payload. 461 o R1 performs PUSH operation with label 462 stack for the replicated copy to R7 and sends it to R2, the 463 nexthop on IGP shortest path to R4. R2 is the penultimate hop for 464 N-SID4; it performs penultimate hop popping, which corresponds to 465 the NEXT operation and the packet is then sent to R4 with 466 in the label stack. R4 performs NEXT operation, 467 pops A-SID47, and delivers packet to R7 with in the label 468 stack. R7, as Leaf, performs NEXT operation, pops R-SID7 label 469 and delivers the payload. 471 A.2. SRv6 473 For SRv6 , we use SID allocation scheme, reproduced below, from 474 Illustrations for SRv6 Network Programming 475 [I-D.filsfils-spring-srv6-net-pgm-illustration] 477 2001:db8::/32 is an IPv6 block allocated by a RIR to the operator 479 2001:db8:0::/48 is dedicated to the internal address space 481 2001:db8:cccc::/48 is dedicated to the internal SRv6 SID space 483 We assume a location expressed in 64 bits and a function expressed 484 in 16 bits 486 Node k has a classic IPv6 loopback address 2001:db8::k/128 which 487 is advertised in the IGP 489 Node k has 2001:db8:cccc:k::/64 for its local SID space. Its SIDs 490 will be explicitly assigned from that block 492 Node k advertises 2001:db8:cccc:k::/64 in its IGP 494 Function :1:: (function 1, for short) represents the End function 495 with PSP support 497 Function :Cn:: (function Cn, for short) represents the End.X 498 function from to Node n 500 Each node k has: 502 An explicit SID instantiation 2001:db8:cccc:k:1::/128 bound to an 503 End function with additional support for PSP 505 An explicit SID instantiation 2001:db8:cccc:k:Cj::/128 bound to an 506 End.X function to neighbor J with additional support for PSP 508 An explicit SID instantiation 2001:db8:cccc:k:Fk::/128 bound to an 509 End.Replcate function 511 Assume a Replication segment identified with R-ID at Replication Node 512 R1 and downstream Nodes R2, R6 and R7. The Replication SID at node 513 k, bound to an End.Replcate function, is 2001:db8:cccc:k:Fk::/128. A 514 packet replicated from R1 to R7 has to traverse R4. 516 The Replication segment state at nodes R1, R2, R6 and R7 is shown 517 below. Note nodes R3, R4 and R5 do not have state for the 518 Replication segment. 520 Replication segment at R1: 522 Replication segment : 523 Replication SID: 2001:db8:cccc:1:F1::0 524 Replication State: 525 R2: <2001:db8:cccc:2:F2::0->L12> 526 R6: <2001:db8:cccc:6:F6::0> 527 R7: <2001:db8:cccc:4:C7::0, 2001:db8:cccc:7:F7::0> 529 Replication to R2 steers packet directly to R2 on interface L12. 530 Replication to R6, using 2001:db8:cccc:6:F6::0, steers packet via IGP 531 shortest path to that node. Replication to R7 is steered via R4, 532 using End.X SID 2001:db8:cccc:4:C7::0 at R4 to R7. 534 Replication segment at R2: 536 Replication segment : 537 Replication SID: 2001:db8:cccc:2:F2::0 538 Replication State: 539 R2: 541 Replication segment at R6: 543 Replication segment : 544 Replication SID: 2001:db8:cccc:6:F6::0 545 Replication State: 546 R6: 548 Replication segment at R7: 550 Replication segment : 551 Replication SID: 2001:db8:cccc:7:F7::0 552 Replication State: 553 R7: 555 When a packet, (A,B2), is steered into the Replication segment at R1: 557 o Since R1 is directly connected to R2, R1 creates encapsulated 558 replicated copy (2001:db8::1, 2001:db8:cccc:2:F2::0) (A, B2), and 559 sends it to R2 on interface L12. R2, as Leaf, removes outer IPv6 560 header and delivers the payload. 562 o R1 creates encapsulated replicated copy (2001:db8::1, 563 2001:db8:cccc:6:F6::0) (A, B2) then forwards the resulting packet 564 on the shortest path to 2001:db8:cccc:6::/64. R2 and R3 forward 565 the packet using 2001:db8:cccc:6::/64. R6, as Leaf, removes outer 566 IPv6 header and delivers the payload. 568 o R1 creates encapsulated replicated copy (2001:db8::1, 569 2001:db8:cccc:4:C7::0) (2001:db8:cccc:7:F7::0; SL=1) (A, B2) and 570 sends it to R2, the nexthop on IGP shortest path to 571 2001:db8:cccc:4::/64. R2 forwards packet to R4 using 572 2001:db8:cccc:4::/64. R4 executes End.X function on 573 2001:db8:cccc:4:C7::0, performs PSP action, removes SRH and sends 574 resulting packet (2001:db8::1, 2001:db8:cccc:7:F7::0) (A, B2) to 575 R7. R7, as Leaf, removes outer IPv6 header and delivers the 576 payload. 578 Authors' Addresses 580 Daniel Voyer (editor) 581 Bell Canada 582 Montreal 583 CA 585 Email: daniel.voyer@bell.ca 587 Clarence Filsfils 588 Cisco Systems, Inc. 589 Brussels 590 BE 592 Email: cfilsfil@cisco.com 594 Rishabh Parekh 595 Cisco Systems, Inc. 596 San Jose 597 US 599 Email: riparekh@cisco.com 601 Hooman Bidgoli 602 Nokia 603 Ottawa 604 CA 606 Email: hooman.bidgoli@nokia.com 608 Zhaohui Zhang 609 Juniper Networks 611 Email: zzhang@juniper.net