idnits 2.17.1 draft-voyer-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 (October 11, 2019) is 1631 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 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: April 13, 2020 R. Parekh 6 Cisco Systems, Inc. 7 H. Bidgoli 8 Nokia 9 Z. Zhang 10 Juniper Networks 11 October 11, 2019 13 SR Replication Segment for Multi-point Service Delivery 14 draft-voyer-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 April 13, 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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 66 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 67 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 4 68 7. Normative References . . . . . . . . . . . . . . . . . . . . 5 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 71 1. Introduction 73 We define a new type of segment for Segment Routing [RFC8402], called 74 Replication segment, which allows a node (henceforth called as 75 Replication node) to replicate packets to a set of other nodes 76 (called Downstream nodes) in a Segment Routing Domain. Replication 77 segments provide building blocks for Point-to-Multi-point Service 78 delivery. A Replication segment at ingress node of Multi-point 79 service replicates packets directly to each egress node of the 80 service, without need for any state in the core of SR domain. 81 Multiple Replication segments can be stitched together to build a 82 tree in SR domain for Multi-point service; this is outside the scope 83 of this document. 85 2. Replication segment 87 In a Segment Routing Domain, a Replication segment is a logical 88 segment which connects a Replication node to a set of Downstream 89 nodes. A Replication segment can be either provisioned locally on a 90 node or programmed by a PCE. Replication segments apply equally to 91 both SR-MPLS and SRv6 instantiations of Segment Routing. 93 A Replication segment is identified by the tuple , where: 96 o Replication-ID: An identifier for a Replication segment that is 97 unique in context of the Replication node. This is an unsigned 98 32-bit number. 100 o Node-ID: The address of a node at which a Replication segment is 101 instantiated. Replication segment is instantiated at Downstream 102 nodes and at the Replication node. 104 The Replicaion-ID can be extended or modified as required based on 105 specific use of a Replication segment. 107 A Replication segment is defined by following elements: 109 o Replication SID: The Segment Identifier of a Replication Segment. 110 This is a SR-MPLS label or a SRv6 SID [RFC8402]. 112 o Downstream Nodes: Set of nodes in Segment Routing domain to which 113 a packet is replicated by the Replication segment. 115 o Replication State: See below. 117 Replication state is a list of Replication branches to the Downstream 118 nodes. In this document, each branch is abstracted to a tuple. A Replication branch to a 120 particular Downstream Node could be represented by the node's Node 121 SID (i.e. it does not matter how traffic gets to the Downstream node, 122 whether it's directly connected or not), or in case of a directly 123 connected node it could be represented by the Adjacency SID (for the 124 interface connecting to the directly connected Leaf Node). 125 Alternatively, the Downstream Node could also be expanded to a SID- 126 list that partially/fully specifies the explicit path to it. A 127 Replication branch can also use a Segment Routing Policy 128 [I-D.ietf-spring-segment-routing-policy], if available, from the 129 Replication node to the Downstream node. 131 Replication SID identifies the Replication Segment in the forwarding 132 plane. The Replication SID SHOULD be considered to be the equivalent 133 of Binding SID [I-D.ietf-spring-segment-routing-policy] of a Segment 134 Routing Policy, when Replication Segment is instantiated at Ingress 135 node of a Multi-point service. At Downstream nodes, the Replication 136 SID MAY be used to identify the Multi-point service. 138 A packet steered into a Replication Segment at a node is replicated 139 to each Downstream node with the Downstream Replication SID that is 140 relevant at that node . A packet is steered into a Replication 141 Segment in two ways: 143 o Based on a local policy-based routing at Replication node. 145 o When the Active Segment [RFC8402] at Replication node is the 146 Replication SID. 148 3. IANA Considerations 150 This document makes no request of IANA. 152 4. Security Considerations 154 There are no additional security risks introduced by this design. 156 5. Acknowledgements 158 The authors would like to acknowledge Siva Sivabalan, Mike Koldychev 159 and Vishnu Pavan Beeram for their valuable inputs. 161 6. Contributors 163 Clayton Hassen 164 Bell Canada 165 Vancouver 166 Canada 168 Email: clayton.hassen@bell.ca 170 Kurtis Gillis 171 Bell Canada 172 Halifax 173 Canada 175 Email: kurtis.gillis@bell.ca 177 Arvind Venkateswaran 178 Cisco Systems, Inc. 179 San Jose 180 US 182 Email: arvvenka@cisco.com 184 Zafar Ali 185 Cisco Systems, Inc. 186 US 187 Email: zali@cisco.com 189 Swadesh Agrawal 190 Cisco Systems, Inc. 191 San Jose 192 US 194 Email: swaagraw@cisco.com 196 Jayant Kotalwar 197 Nokia 198 Mountain View 199 US 201 Email: jayant.kotalwar@nokia.com 203 Tanmoy Kundu 204 Nokia 205 Mountain View 206 US 208 Email: tanmoy.kundu@nokia.com 210 Tarek Saad 211 Juniper Networks 212 Canada 214 Email:tsaad@juniper.net 216 7. Normative References 218 [I-D.ietf-spring-segment-routing-policy] 219 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 220 bogdanov@google.com, b., and P. Mattes, "Segment Routing 221 Policy Architecture", draft-ietf-spring-segment-routing- 222 policy-03 (work in progress), May 2019. 224 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 225 Requirement Levels", BCP 14, RFC 2119, 226 DOI 10.17487/RFC2119, March 1997, 227 . 229 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 230 Decraene, B., Litkowski, S., and R. Shakir, "Segment 231 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 232 July 2018, . 234 Authors' Addresses 236 Daniel Voyer (editor) 237 Bell Canada 238 Montreal 239 CA 241 Email: daniel.voyer@bell.ca 243 Clarence Filsfils 244 Cisco Systems, Inc. 245 Brussels 246 BE 248 Email: cfilsfil@cisco.com 250 Rishabh Parekh 251 Cisco Systems, Inc. 252 San Jose 253 US 255 Email: riparekh@cisco.com 257 Hooman Bidgoli 258 Nokia 259 Ottawa 260 CA 262 Email: hooman.bidgoli@nokia.com 264 Zhaohui Zhang 265 Juniper Networks 267 Email: zzhang@juniper.net