idnits 2.17.1 draft-geng-spring-redundancy-protection-sid-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 09, 2020) is 1501 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-06 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 X. Geng 3 Internet-Draft M. Chen 4 Intended status: Experimental Huawei 5 Expires: September 10, 2020 March 09, 2020 7 Redundancy SID and Merging SID for Redundancy Protection 8 draft-geng-spring-redundancy-protection-sid-00 10 Abstract 12 Redundancy protection is a method of service protection by sending 13 copies of the same packets of one flow over multiple paths, which 14 includes packet replication, elimination and ordering. This document 15 defines Redundancy SID and Merging SID to support redundancy 16 protection. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in . 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 10, 2020. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 2 60 3. Redundancy Protection Introduction . . . . . . . . . . . . . 3 61 4. Redundancy SID . . . . . . . . . . . . . . . . . . . . . . . 3 62 5. Merging SID . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4 65 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 66 9. Normative References . . . . . . . . . . . . . . . . . . . . 4 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 69 1. Introduction 71 Redundancy protection is a method of providing 1+1 protection by 72 sending copies of the same packets of one flow over multiple paths, 73 which includes packet replication, elimination and ordering. This 74 document defines Redundancy SID and Merging SID to support redundancy 75 protection. 77 2. Terminology and Conventions 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in [RFC2119]. 83 Redundancy Node: the start point of redundancy protection, which is a 84 network device that could implement packet replication. 86 Merging Node: the end point of redundancy protection, which is a 87 network node that could implement packet elimination and ordering 88 (optionally). 90 Editor's Note: Similar mechanism is defined as "Service Protection" 91 in the [RFC8655]. In this document, we define a new term "Redundancy 92 Protection" to distinguish with other service protection method. 93 Some of the terms are the similar as [RFC8655]. 95 3. Redundancy Protection Introduction 97 The figure shows how to provide redundancy protection in an Segment 98 Routing Domain. 100 | | 101 |<---------------SR Domain--------------->| 102 | | 103 | +------+T2+----+ | 104 +---+ +---+ +-+-+ +-+-+ +---+ +---+ 105 | E1+----| In|--+T1+--+Red| |Mer|--+T4+--| Eg+----+ E2| 106 +---+ +---+ +-+-+ +-+-+ +---+ +---+ 107 +-----+T3+-----+ 109 The process of redundancy protection is as follows: 1) The flow is 110 replicated in Red(Redundancy Node); 2) Tow replicated flows go 111 through different paths till Mer (Merging Node); When there is any 112 failures happened in one the path, the service continues to deliver 113 through the other path without break; 3) The first received packet of 114 the flow is transmitted from Mer (Merging Node) to Eg(Egress), and 115 the redundant packets are eliminated. 4) Sometimes, the packet will 116 arrive out of order because of redundancy protection, the function of 117 reordering may be necessary in the Merging Node. 119 In this document, we introduces Redundancy SID and Merging SID to 120 implement redundancy protection. The newly defined SIDs apply 121 equally to both SR-MPLS and SRv6. 123 4. Redundancy SID 125 Redundancy SID is a variation of binding SID defined in 126 [I-D.ietf-spring-segment-routing-policy] 128 Redundancy SID indicates the following operations: 130 o Steering the packet into the corresponding redundancy policy 132 o Packet replication based on the redundancy policy, e.g., the 133 number of replication copies 135 o Encapsulate the packet with necessary meta data (e.g., flow 136 identification, sequence number) if it is not included in the 137 original packet 139 5. Merging SID 141 Merging SID indicates the following operations: 143 o Packet elimination: forward the first received packets and 144 eliminate the redundant packets. 146 o Packet ordering(optional): reorder the packets if the packet 147 arrives out of order 149 6. IANA Considerations 151 TBD 153 7. Security Considerations 155 TBD 157 8. Acknowledgements 159 Thank you for valuable comments from James Guichard and Andrew Mail 161 9. Normative References 163 [I-D.ietf-spring-segment-routing-policy] 164 Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and 165 P. Mattes, "Segment Routing Policy Architecture", draft- 166 ietf-spring-segment-routing-policy-06 (work in progress), 167 December 2019. 169 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 170 Requirement Levels", BCP 14, RFC 2119, 171 DOI 10.17487/RFC2119, March 1997, 172 . 174 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 175 "Deterministic Networking Architecture", RFC 8655, 176 DOI 10.17487/RFC8655, October 2019, 177 . 179 Authors' Addresses 181 Xuesong Geng 182 Huawei 184 Email: gengxuesong@huawei.com 185 Mach(Guoyi) Chen 186 Huawei 188 Email: mach.chen@huawei.com