idnits 2.17.1 draft-geng-spring-redundancy-policy-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 (March 23, 2020) is 1492 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC8402' is defined on line 205, but no explicit reference was found in the text == 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 24, 2020 March 23, 2020 7 Redundancy Policy for Redundant Protection 8 draft-geng-spring-redundancy-policy-01 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 replicaiton, elimination and ordering. This document 15 defines redundancy policy as an extension to the current SR policy to 16 support redundancy 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 24, 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. Redudancy Policy . . . . . . . . . . . . . . . . . . . . . . 3 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 65 8. Normative References . . . . . . . . . . . . . . . . . . . . 5 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 68 1. Introduction 70 Redundancy protection is a method of providing 1+1 protection by 71 sending copies of the same packets of one flow over multiple paths, 72 which includes packet replication, elimination and ordering. This 73 document defines redundancy policy to support redundancy protection. 75 2. Terminology and Conventions 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in [RFC2119]. 81 Redundancy Node: the start point of redundancy protection, which is a 82 network device that could implement packet replication. 84 Merging Node: the end point of redundancy protection, which is a 85 network node that could implement packet elimination and 86 ordering(optionally). 88 Redundancy Policy: an extended sr policy which includes more than one 89 active segment lists to support redundancy protection. 91 Editor's Note: Similar mechanism is defined as "Service Protection" 92 in the [RFC8655]. In this document, we define a new term "Redundancy 93 Protection" to distinguish with other service protection method. 94 Some of the terms are the similar as [RFC8655]. 96 3. Redundancy Protection Introduction 98 The figure shows how to provide redundancy protection in an Segment 99 Routing Domain. 101 | | 102 |<---------------SR Domain--------------->| 103 | | 104 | +------+T2+----+ | 105 +---+ +---+ +-+-+ +-+-+ +---+ +---+ 106 | E1+----| In|--+T1+--+Red| |Mer|--+T4+--| Eg+----+ E2| 107 +---+ +---+ +-+-+ +-+-+ +---+ +---+ 108 +-----+T3+-----+ 110 The process of redundancy protection is as follows: 1) The flow is 111 replicated in Reb(Redundancy Node); 2) Tow replicated flows go 112 through different paths till Mer (Merging Node); When there is any 113 failures happened in one the path, the service continues to deliver 114 through the other path without break; 3) The first received packet of 115 the flow is transmitted from Mer (Merging Node) to Eg(Egress), and 116 the redundant packets are eliminated. 4) Sometimes, the packet will 117 arrive out of order because of redundancy protection, the function of 118 reordering may be necessary in the Merging Node. 120 In this document, we introduces Redundancy Policy as a variation of 121 Segment Routing Policy defined in 122 [I-D.ietf-spring-segment-routing-policy] to support redundancy 123 protection. Redundancy policy applys equally to both SR-MPLS and 124 SRv6. 126 4. Redudancy Policy 128 Redundancy Policy is used to enable packet replication and 129 instantiation more than one ordered lists of segments between 130 replication node and merging node to steer the same flow through 131 different paths in an SR domain. 133 A Redundancy Policy is identified through the tuple . Redundancy node is specified as 135 IPv4/IPv6 address of the head end, which is able to do packet 136 replication. Merging node is specified as IPv4/IPv6 address of the 137 end point, which is able to do packet elimination and 138 ordering(optional). Replication ID could be a specified value of 139 "color" define in section 2.1 of 140 [I-D.ietf-spring-segment-routing-policy], which indicates the sr 141 policy as a redundancy policy. Replication ID could also be used to 142 distinguish redundancy policy sharing the same redundancy node and 143 merging node. 145 The following elements are extended in Redundancy Policy: 147 o Redundancy ID: is used to distinguish different redundancy policy 149 o Redundancy SID: is variation of Binding SID for Redundancy policy. 150 Redundancy SID will be instantiated as Redundancy Policy in 151 redundancy node. Redundancy SID is define in draft-geng-spring- 152 redundancy-protection-sid-00 154 o Candidate path: more than one candidate paths are included in 155 redundancy policy. In each candidate path, the last segment 156 SHOULD be merging SID. Merging SID is defined in draft-geng- 157 spring-redundancy-protection-sid-00. The preference of the 158 candidate path is used to select the best candidate path for an SR 159 Policy. The preference of candidate paths in redundancy policy 160 SHOULD be the same . 162 A packet is steered into a Redundancy policy at a redundancy node in 163 similar ways of SR policy defined in section 8 of 164 [I-D.ietf-spring-segment-routing-policy]: 166 o Incoming packets have an active SID matching the redundancy SID at 167 the redundancy node; 169 o Incoming packets match a BGP/Service route which recurses on an SR 170 policy (BGP should be extended to support matching to a redundancy 171 policy, which is supposed to be covered in the following work); 173 o Per-flow Steering: incoming packets match or recurse on a 174 forwarding array of where some of the entries are Replication 175 Policy. 177 o Policy-based Steering: incoming packets match a routing policy 178 which directs them on a redundancy policy. 180 5. IANA Considerations 182 TBD 184 6. Security Considerations 186 TBD 188 7. Acknowledgements 190 Thank you for valuable comments from James Guichard and Andrew Mail 192 8. Normative References 194 [I-D.ietf-spring-segment-routing-policy] 195 Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and 196 P. Mattes, "Segment Routing Policy Architecture", draft- 197 ietf-spring-segment-routing-policy-06 (work in progress), 198 December 2019. 200 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 201 Requirement Levels", BCP 14, RFC 2119, 202 DOI 10.17487/RFC2119, March 1997, 203 . 205 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 206 Decraene, B., Litkowski, S., and R. Shakir, "Segment 207 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 208 July 2018, . 210 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 211 "Deterministic Networking Architecture", RFC 8655, 212 DOI 10.17487/RFC8655, October 2019, 213 . 215 Authors' Addresses 217 Xuesong Geng 218 Huawei 220 Email: gengxuesong@huawei.com 222 Mach(Guoyi) Chen 223 Huawei 225 Email: mach.chen@huawei.com