idnits 2.17.1 draft-geng-spring-sr-redundancy-protection-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 : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 12 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (November 2, 2020) is 1261 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) == Missing Reference: 'SL' is mentioned on line 240, but not defined == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-24 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Working Group X. Geng 3 Internet-Draft M. Chen 4 Intended status: Standards Track F. Yang 5 Expires: May 6, 2021 Huawei Technologies 6 November 2, 2020 8 Segment Routing for Redundancy Protection 9 draft-geng-spring-sr-redundancy-protection-00 11 Abstract 13 Redundancy protection is one of the mechanisms to achieve service 14 protection, following the principle of PREOF (Packet Replication/ 15 Elimination/Ordering Function). To empower the Segment Routing with 16 the capability of redundancy protection, two types of Segment 17 including Redundancy Segment and Merging Segment are introduced. The 18 instantiation of Redundancy and Merging Segments can be applied to 19 both segment routing over MPLS (SR-MPLS) and segment routing over 20 IPv6 (SRv6). 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 . 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 6, 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. Terminology and Conventions . . . . . . . . . . . . . . . . . 3 64 3. Redundancy Protection in Segment Routing Scenario . . . . . . 3 65 4. Segment to Support Redundancy Protection . . . . . . . . . . 4 66 4.1. Redundancy Segment . . . . . . . . . . . . . . . . . . . 5 67 4.2. Merging Segment . . . . . . . . . . . . . . . . . . . . . 5 68 5. Meta Information to Support Redundancy Protection . . . . . . 6 69 6. Segment Routing Policy to Support Redundancy Protection . . . 6 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 72 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 75 10.2. Informative References . . . . . . . . . . . . . . . . . 7 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 78 1. Introduction 80 Service protection defined in [RFC8655] is initially required from 81 the use cases in a variety of industries described in [RFC8578]. 82 Together with other two techniques Resource allocation and Explicit 83 routes, targets to provide the deterministic flow transmission. 84 Meanwhile, with the emerge of Cloud VR, Cloud Game, HDV (high- 85 definition video) applications running in the Internet, SLA (Service 86 Level Agreement) guarantee becomes an important issue which requires 87 new technologies and solutions for network. 89 Redundancy Protection is one of the mechanisms to achieve service 90 protection, following the principle of PREOF (Packet Replication/ 91 Elimination/Ordering Function) defined in [RFC8655]. Specifically, 92 replicates the packets of flows into two or more copies, transports 93 different copies through different path in parallel, eliminates and 94 orders the packets at end to provide redundancy protection. 96 Segment Routing (SR) leverages the source routing paradigm. An 97 ingress node steers a packet through an ordered list of instructions, 98 called "segments". A segment can be associated to an arbitrary 99 processing of the packet in the node identified by the segment. 101 This document extends the capabilities in SR paradigm to support the 102 redundancy protection, including the definitions of new Segments and 103 a variation of Segment Routing Policy. The new mechanism applies 104 equally to both segment routing with MPLS data plane (SR-MPLS) and 105 segment routing with IPv6 data plane (SRv6). 107 2. Terminology and Conventions 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in 112 [I-D.ietf-spring-srv6-network-programming] and[RFC2119]. 114 Redundancy Node: the start point of redundancy protection, which is a 115 network device that could implement packet replication 117 Merging Node: the end point of redundancy protection, which is a 118 network node that could implement packet elimination and ordering 119 (optionally) 121 Redundancy Policy: an extended SR policy which includes more than one 122 active segment lists to support redundancy protection 124 Flow Identification: information in SR data service to indicate one 125 flow 127 Sequence Number: information in SR data service to indicate the 128 packet sequence of one flow 130 Editor's Note: Similar mechanism is defined as "Service Protection" 131 in the [RFC8655]. In this document, we define a new term "Redundancy 132 Protection" to distinguish with other service protection method. 133 Some of the terms are similar as [RFC8655]. 135 3. Redundancy Protection in Segment Routing Scenario 136 | | 137 |<-------------- SR Domain ------------->| 138 | | 139 | +-----+R3+-----+ | 140 +---+ +-+-+ +-+-+ +---+ 141 -------|R1 |--------|Red| |Mer|--------|R2 |------- 142 +---+ +-+-+ +-+-+ +---+ 143 +-----+R4+-----+ 145 Figure 1: Example Scenario of Redundancy Protection in SR Domain 147 This figure shows the process of redundancy protection when a flow is 148 sent into SR domain: 150 1) R1 receives the packet flow and encapsulates with segment to 151 destination R2, either instantiated in a stack of MPLS labels or 152 Segment Routing Extension Header (SRH) defined in [RFC8754]; 154 2) When the packet flow arrives in Red node, known as Redundancy 155 Node, one flow is replicated to two copies with the same flow 156 identifier; For each packet in one flow, sequence number is marked to 157 indicate the packet sequence; the flow identifier and sequence number 158 of each packet can alternatively be marked at the ingress edge R1 of 159 SR domain; 161 3) Two replicated flows go through different paths till Mer node, 162 known as Merging Node; When there is any failures happened in one 163 path, the service continues to deliver through the other path without 164 break; 166 4) The first received packet of the flow is transmitted from Merging 167 Node to R2, and the redundant packets are eliminated; 169 5) Sometimes, the packet will arrive out of order because of 170 redundancy protection, the function of reordering may be necessary in 171 the Merging Node; 173 In this example, service protection is supported by utilizing at 174 least two packet flows transmitted over two candidate paths. For a 175 unidirectional flow, Red node supports replication function, and Mer 176 node supports elimination and ordering functions. 178 4. Segment to Support Redundancy Protection 180 To achieve the Packet Replication/ Elimination/Ordering Function, 181 Redundancy Segment and Merging Segment are introduced. 183 4.1. Redundancy Segment 185 Redundancy Segment is associated with a Redundancy Policy on 186 redundancy node. Redundancy Segment is associated with service 187 instructions, indicating the following operations: 189 o Steering the packet into the corresponding redundancy policy 191 o Packet replication based on the redundancy policy, e.g., the 192 number of replication copies 194 o Encapsulate the packet with necessary meta data (e.g., flow 195 identification, sequence number) if it is not included in the 196 original packet 198 In the case of SRv6, a new behavior End.R for Redundancy Segment is 199 defined. 201 When N receives a packet whose IPv6 DA is S and S is a Redundancy 202 SID, N does: 204 S01. When an SRH is processed { 205 S02. If (Segments Left>0) { 206 S03. Create two headers IPv6+SRH-1 and IPv6+SRH-2 207 S04. Insert different policy-instructed segment lists into SRH-1 and SRH-2 208 S05. Add Flow Identification and Sequence Number to SRH-1 and SRH-2 209 S06. Remove the incoming outer IPv6+SRH header 210 S07. Create a duplication of the incoming packet payload 211 S08. Encapsulate the original packet with IPv6+SRH-1 header 212 S09. Encapsulate the duplicate packet with IPv6+SRH-2 header 213 S10. Set IPv6 SA as the local address of this node 214 S11. Set IPv6 DA of IPv6+SRH-1 to the first segment of SRv6 Policy in SRH-1 215 S12. Set IPv6 DA of IPv6+SRH-2 to the first segment of SRv6 Policy in SRH-2 216 S13. } 217 S14. ELSE { 218 S15. Drop the packet 219 S16. } 221 4.2. Merging Segment 223 Merging Segment is associated with service instructions, indicates 224 the following operations: 226 o Packet merging and elimination: forward the first received packets 227 and eliminate the redundant packets 229 o Packet ordering(optional): reorder the packets if the packet 230 arrives out of order 232 In the case of SRv6, a new behavior End.M for Merging Segment is 233 defined. 235 When N receives a packet whose IPv6 DA is S and S is a Merging SID, N 236 does: 238 S01. When an SRH is processed { 239 S02. If (Segments Left>0) & "the packet is not a redundant packet" { 240 S03. Do not decrement SL nor update the IPv6 DA with SRH[SL] 241 S04. Create a new outer IPv6+SRH-3 header 242 S05. Insert the policy-instructed segment lists in the newly created SRH-3 243 S06. Remove the incoming outer IPv6+SRH header 244 S07. Set IPv6 DA of IPv6+SRH-3 to the first segment of SRv6 Policy in SRH-3 245 S08. } 246 S09. ELSE { 247 S10. Drop the packet 248 S11. } 250 5. Meta Information to Support Redundancy Protection 252 To distinguish the different copies replicated at Redundancy node, 253 and distinguish the different packets in the same flow to perform 254 elimination and ordering, the definition of Flow Identification and 255 Sequence Number is required. 257 Flow Identification and Sequence Number can be defined as MPLS labels 258 in SR over MPLS data plane, or as option TLV in SRH header in SR over 259 IPv6 data plane. This information must be carried along the path to 260 Merging node. Merging node removes Flow Identifier and Sequence 261 Number once the elimination and ordering is accomplished. 263 6. Segment Routing Policy to Support Redundancy Protection 265 Redundancy Policy is a variation of SR Policy, which is identified 266 through the tuple . 267 Redundancy Policy extends SR policy to include more than one ordered 268 lists of segments between redundancy node and merging node to steer 269 the same flow through different paths in SR domain. In Redundancy 270 Policy, Redundancy Segment MUST be specified, and the last segment of 271 each ordered list of segments SHOULD be Merging Segment. 273 7. IANA Considerations 275 This document makes no request of IANA. 277 Note to RFC Editor: this section may be removed on publication as an 278 RFC. 280 8. Security Considerations 282 TBD 284 9. Acknowledgements 286 TBD 288 10. References 290 10.1. Normative References 292 [I-D.ietf-spring-srv6-network-programming] 293 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 294 Matsushima, S., and Z. Li, "SRv6 Network Programming", 295 draft-ietf-spring-srv6-network-programming-24 (work in 296 progress), October 2020. 298 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 299 Requirement Levels", BCP 14, RFC 2119, 300 DOI 10.17487/RFC2119, March 1997, 301 . 303 10.2. Informative References 305 [RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases", 306 RFC 8578, DOI 10.17487/RFC8578, May 2019, 307 . 309 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 310 "Deterministic Networking Architecture", RFC 8655, 311 DOI 10.17487/RFC8655, October 2019, 312 . 314 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 315 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 316 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 317 . 319 Authors' Addresses 321 Xuesong Geng 322 Huawei Technologies 324 Email: gengxuesong@huawei.com 325 Mach(Guoyi) Chen 326 Huawei Technologies 328 Email: mach.chen@huawei.com 330 Fan Yang 331 Huawei Technologies 333 Email: shirley.yangfan@huawei.com