idnits 2.17.1 draft-voyer-spring-sr-replication-segment-01.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 (November 19, 2019) is 1582 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 == Outdated reference: A later version (-02) exists of draft-voyer-pim-sr-p2mp-policy-00 Summary: 0 errors (**), 0 flaws (~~), 3 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 22, 2020 R. Parekh 6 Cisco Systems, Inc. 7 H. Bidgoli 8 Nokia 9 Z. Zhang 10 Juniper Networks 11 November 19, 2019 13 SR Replication Segment for Multi-point Service Delivery 14 draft-voyer-spring-sr-replication-segment-01 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 22, 2020. 45 Copyright Notice 47 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . 2 64 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 67 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 68 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 5 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 71 8.2. Informative References . . . . . . . . . . . . . . . . . 6 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 74 1. Introduction 76 We define a new type of segment for Segment Routing [RFC8402], called 77 Replication segment, which allows a node (henceforth called as 78 Replication node) to replicate packets to a set of other nodes 79 (called Downstream nodes) in a Segment Routing Domain. Replication 80 segments provide building blocks for Point-to-Multi-point Service 81 delivery. A Replication segment at ingress node of Multi-point 82 service could replicates packets directly to each egress node of the 83 service (without need for any state on the internal routers), or it 84 could be stitched to other Replication segments to build a tree in SR 85 domain for Multi-point service. The latter is outside the scope of 86 this document but specified in [I-D.voyer-pim-sr-p2mp-policy]. 88 2. Replication segment 90 In a Segment Routing Domain, a Replication segment is a logical 91 segment which connects a Replication node to a set of Downstream 92 nodes. A Replication segment can be either provisioned locally on a 93 node or programmed by a PCE. Replication segments apply equally to 94 both SR-MPLS and SRv6 instantiations of Segment Routing. 96 A Replication segment is identified by the tuple , where: 99 o Replication-ID: An identifier for a Replication segment that is 100 unique in context of the Replication node. This is an unsigned 101 32-bit number. 103 o Node-ID: The address of a node at which a Replication segment is 104 instantiated. Replication segment is instantiated at Downstream 105 nodes and at the replication nodes. Note that the root of a 106 Multi-point service is also a replication node. 108 The Replicaion-ID can be extended or modified as required based on 109 specific use of a Replication segment. 111 A Replication segment is defined by following elements: 113 o Replication SID: The Segment Identifier of a Replication Segment. 114 This is a SR-MPLS label or a SRv6 SID [RFC8402]. 116 o Downstream Nodes: Set of nodes in Segment Routing domain to which 117 a packet is replicated by the Replication segment. 119 o Replication State: See below. 121 Replication state is a list of Replication branches to the Downstream 122 nodes. In this document, each branch is abstracted to a tuple. A Replication branch to a 124 particular Downstream Node could be represented by the node's Node 125 SID (i.e. it does not matter how traffic gets to the Downstream node, 126 whether it's directly connected or not), or in case of a directly 127 connected node it could be represented by the Adjacency SID (for the 128 interface connecting to the directly connected Leaf Node). 129 Alternatively, the Downstream Node could also be expanded to a SID- 130 list that partially/fully specifies the explicit path to it. A 131 Replication branch can also use a Segment Routing Policy 132 [I-D.ietf-spring-segment-routing-policy], if available, from the 133 Replication node to the Downstream node. 135 Replication SID identifies the Replication Segment in the forwarding 136 plane. The Replication SID SHOULD be considered to be the equivalent 137 of Binding SID [I-D.ietf-spring-segment-routing-policy] of a Segment 138 Routing Policy, when Replication Segment is instantiated at Ingress 139 node of a Multi-point service. At Downstream nodes, the Replication 140 SID MAY be used to identify the Multi-point service. 142 A packet steered into a Replication Segment at a node is replicated 143 to each Downstream node with the Downstream Replication SID that is 144 relevant at that node. A packet is steered into a Replication 145 Segment in two ways: 147 o When the Active Segment [RFC8402] is the Replication SID. In this 148 case, the operation for a replicated copy is CONTINUE. 150 o On the root of a Multi-point service, based on local policy-based 151 routing. In this case, the operation for a replicated copy is 152 PUSH. 154 Replication segments are instantiated for both a replication node 155 itself and the downstream nodes of the Replication segment. If a 156 downstream node is an egress (aka leaf) of the Multi-point service, 157 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. Notice that the segment on the leaf node is still 160 referred to as a Replication segment for the purpose of 161 generalization. 163 3. Use Cases 165 In the simplest use case, a replication segment is instantiated on 166 the root node of a Multi-point service, with all the downstream nodes 167 being the egress/leaf nodes of the the service. This achieves 168 Ingress Replication [RFC7988] that has been widely used for MVPN 169 [RFC6513] and EVPN [RFC7432] BUM (Broadcast, Unknown and Multicast) 170 traffic. 172 Replication segments can also be used as building blocks for 173 replication trees when replication segments on the root, intermediate 174 replication nodes and leaf nodes are stitched together to achieve 175 efficient replciation. That is outside the scope of this document 176 but specified in [I-D.voyer-pim-sr-p2mp-policy]. 178 4. IANA Considerations 180 This document makes no request of IANA. 182 5. Security Considerations 184 There are no additional security risks introduced by this design. 186 6. Acknowledgements 188 The authors would like to acknowledge Siva Sivabalan, Mike Koldychev, 189 Vishnu Pavan Beeram and Alexander Vainshtein for their valuable 190 inputs. 192 7. Contributors 194 Clayton Hassen 195 Bell Canada 196 Vancouver 197 Canada 199 Email: clayton.hassen@bell.ca 201 Kurtis Gillis 202 Bell Canada 203 Halifax 204 Canada 206 Email: kurtis.gillis@bell.ca 208 Arvind Venkateswaran 209 Cisco Systems, Inc. 210 San Jose 211 US 213 Email: arvvenka@cisco.com 215 Zafar Ali 216 Cisco Systems, Inc. 217 US 219 Email: zali@cisco.com 221 Swadesh Agrawal 222 Cisco Systems, Inc. 223 San Jose 224 US 226 Email: swaagraw@cisco.com 228 Jayant Kotalwar 229 Nokia 230 Mountain View 231 US 233 Email: jayant.kotalwar@nokia.com 234 Tanmoy Kundu 235 Nokia 236 Mountain View 237 US 239 Email: tanmoy.kundu@nokia.com 241 Tarek Saad 242 Juniper Networks 243 Canada 245 Email:tsaad@juniper.net 247 8. References 249 8.1. Normative References 251 [I-D.ietf-spring-segment-routing-policy] 252 Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and 253 P. Mattes, "Segment Routing Policy Architecture", draft- 254 ietf-spring-segment-routing-policy-03 (work in progress), 255 May 2019. 257 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 258 Requirement Levels", BCP 14, RFC 2119, 259 DOI 10.17487/RFC2119, March 1997, 260 . 262 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 263 Decraene, B., Litkowski, S., and R. Shakir, "Segment 264 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 265 July 2018, . 267 8.2. Informative References 269 [I-D.voyer-pim-sr-p2mp-policy] 270 Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z. 271 Zhang, "Segment Routing Point-to-Multipoint Policy", 272 draft-voyer-pim-sr-p2mp-policy-00 (work in progress), 273 October 2019. 275 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 276 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 277 2012, . 279 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 280 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 281 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 282 2015, . 284 [RFC7988] Rosen, E., Ed., Subramanian, K., and Z. Zhang, "Ingress 285 Replication Tunnels in Multicast VPN", RFC 7988, 286 DOI 10.17487/RFC7988, October 2016, 287 . 289 Authors' Addresses 291 Daniel Voyer (editor) 292 Bell Canada 293 Montreal 294 CA 296 Email: daniel.voyer@bell.ca 298 Clarence Filsfils 299 Cisco Systems, Inc. 300 Brussels 301 BE 303 Email: cfilsfil@cisco.com 305 Rishabh Parekh 306 Cisco Systems, Inc. 307 San Jose 308 US 310 Email: riparekh@cisco.com 312 Hooman Bidgoli 313 Nokia 314 Ottawa 315 CA 317 Email: hooman.bidgoli@nokia.com 319 Zhaohui Zhang 320 Juniper Networks 322 Email: zzhang@juniper.net