idnits 2.17.1 draft-voyer-spring-sr-replication-segment-02.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 26, 2019) is 1585 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 29, 2020 R. Parekh 6 Cisco Systems, Inc. 7 H. Bidgoli 8 Nokia 9 Z. Zhang 10 Juniper Networks 11 November 26, 2019 13 SR Replication Segment for Multi-point Service Delivery 14 draft-voyer-spring-sr-replication-segment-02 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 29, 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 . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . 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. 102 o Node-ID: The address of the Replication Node that the Replication 103 segment is for. Note that the root of a multi-point service is 104 also a replication node. 106 In simplest case, Replication-ID can be a 32-bit number, but it can 107 be extended or modified as required based on specific use of a 108 Replication segment. When the PCE signals a Replication segment to 109 its node, the tuple identifies the segment. 110 Examples of such signaling and extension are described in 111 [I-D.voyer-pim-sr-p2mp-policy]. 113 A Replication segment includes the following elements: 115 o Replication SID: The Segment Identifier of a Replication segment. 116 This is a SR-MPLS label or a SRv6 SID [RFC8402]. 118 o Downstream Nodes: Set of nodes in Segment Routing domain to which 119 a packet is replicated by the Replication segment. 121 o Replication State: See below. 123 The Downstream Nodes and Replication State of a Replication segment 124 can change over time, depending on the network state and leaf nodes 125 of a multi-point service that the segment is part of. 127 Replication State is a list of replication branches to the Downstream 128 Nodes. In this document, each branch is abstracted to a tuple. A Downstream Node could be 130 represented by the node's Node SID (i.e. it does not matter how 131 traffic gets to the Downstream Node, whether it's directly connected 132 or not), or in case of a directly connected node it could be 133 represented by the Adjacency SID (for the interface connecting to the 134 directly connected Leaf Node). Alternatively, a Downstream Node 135 could be represented by a SID-list or a Segment Routing Policy 136 [I-D.ietf-spring-segment-routing-policy] that partially/fully 137 specifies the explicit path from the Replication Node to the 138 Downstream Node, or even represented by another Replication segment. 140 Replication SID identifies the Replication segment in the forwarding 141 plane. For the root of a multi-point service, the Replication SID 142 SHOULD be considered to be the equivalent of Binding SID 143 [I-D.ietf-spring-segment-routing-policy] of a Segment Routing Policy. 144 At a downstream node of the multi-point service, the Replication SID 145 MAY be used to identify that portion of the multi-point service. 147 A packet steered into a Replication segment at a node is replicated 148 to each Downstream Node with the Downstream Replication SID that is 149 relevant at that node. A packet is steered into a Replication 150 Segment in two ways: 152 o When the Active Segment [RFC8402] is the Replication SID. In this 153 case, the operation for a replicated copy is CONTINUE. 155 o On the root of a multi-point service, based on local policy-based 156 routing. In this case, the operation for a replicated copy is 157 PUSH. 159 If a Downstream Node is an egress (aka leaf) of the multi-point 160 service, i.e. no further replication is needed, then that leaf node's 161 Replication segment will not have any Replication State and the 162 operation is NEXT. Notice that the segment on the leaf node is still 163 referred to as a Replication segment for the purpose of 164 generalization. 166 A node can be a bud node, i.e. it is a replication node and a leaf 167 node of a multi-point service at the same time 168 [I-D.voyer-pim-sr-p2mp-policy]. In this case, the Replication 169 segment's Replication State includes a branch with the Downstream 170 Node being itself and the operation for the replicated copy is NEXT. 172 3. Use Cases 174 In the simplest use case, a single Replication segment includes the 175 root node of a multi-point service and the egress/leaf nodes of the 176 the service as all the Downstream Nodes. This achieves Ingress 177 Replication [RFC7988] that has been widely used for MVPN [RFC6513] 178 and EVPN [RFC7432] BUM (Broadcast, Unknown and Multicast) traffic. 180 Replication segments can also be used as building blocks for 181 replication trees when Replication segments on the root, intermediate 182 replication nodes and leaf nodes are stitched together to achieve 183 efficient replciation. That is specified in 184 [I-D.voyer-pim-sr-p2mp-policy]. 186 4. IANA Considerations 188 This document makes no request of IANA. 190 5. Security Considerations 192 There are no additional security risks introduced by this design. 194 6. Acknowledgements 196 The authors would like to acknowledge Siva Sivabalan, Mike Koldychev, 197 Vishnu Pavan Beeram and Alexander Vainshtein for their valuable 198 inputs. 200 7. Contributors 202 Clayton Hassen 203 Bell Canada 204 Vancouver 205 Canada 207 Email: clayton.hassen@bell.ca 209 Kurtis Gillis 210 Bell Canada 211 Halifax 212 Canada 214 Email: kurtis.gillis@bell.ca 216 Arvind Venkateswaran 217 Cisco Systems, Inc. 218 San Jose 219 US 221 Email: arvvenka@cisco.com 223 Zafar Ali 224 Cisco Systems, Inc. 225 US 227 Email: zali@cisco.com 229 Swadesh Agrawal 230 Cisco Systems, Inc. 231 San Jose 232 US 233 Email: swaagraw@cisco.com 235 Jayant Kotalwar 236 Nokia 237 Mountain View 238 US 240 Email: jayant.kotalwar@nokia.com 242 Tanmoy Kundu 243 Nokia 244 Mountain View 245 US 247 Email: tanmoy.kundu@nokia.com 249 Tarek Saad 250 Juniper Networks 251 Canada 253 Email:tsaad@juniper.net 255 8. References 257 8.1. Normative References 259 [I-D.ietf-spring-segment-routing-policy] 260 Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and 261 P. Mattes, "Segment Routing Policy Architecture", draft- 262 ietf-spring-segment-routing-policy-03 (work in progress), 263 May 2019. 265 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 266 Requirement Levels", BCP 14, RFC 2119, 267 DOI 10.17487/RFC2119, March 1997, 268 . 270 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 271 Decraene, B., Litkowski, S., and R. Shakir, "Segment 272 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 273 July 2018, . 275 8.2. Informative References 277 [I-D.voyer-pim-sr-p2mp-policy] 278 Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z. 279 Zhang, "Segment Routing Point-to-Multipoint Policy", 280 draft-voyer-pim-sr-p2mp-policy-00 (work in progress), 281 October 2019. 283 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 284 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 285 2012, . 287 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 288 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 289 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 290 2015, . 292 [RFC7988] Rosen, E., Ed., Subramanian, K., and Z. Zhang, "Ingress 293 Replication Tunnels in Multicast VPN", RFC 7988, 294 DOI 10.17487/RFC7988, October 2016, 295 . 297 Authors' Addresses 299 Daniel Voyer (editor) 300 Bell Canada 301 Montreal 302 CA 304 Email: daniel.voyer@bell.ca 306 Clarence Filsfils 307 Cisco Systems, Inc. 308 Brussels 309 BE 311 Email: cfilsfil@cisco.com 313 Rishabh Parekh 314 Cisco Systems, Inc. 315 San Jose 316 US 318 Email: riparekh@cisco.com 319 Hooman Bidgoli 320 Nokia 321 Ottawa 322 CA 324 Email: hooman.bidgoli@nokia.com 326 Zhaohui Zhang 327 Juniper Networks 329 Email: zzhang@juniper.net