idnits 2.17.00 (12 Aug 2021) /tmp/idnits15911/draft-geng-spring-redundancy-policy-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 document date (7 March 2022) is 68 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) == Unused Reference: 'RFC8174' is defined on line 244, but no explicit reference was found in the text == Unused Reference: 'RFC8964' is defined on line 254, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-sr-policy-yang' is defined on line 283, but no explicit reference was found in the text == Unused Reference: 'RFC8655' is defined on line 299, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-18 == Outdated reference: A later version (-17) exists of draft-ietf-idr-segment-routing-te-policy-14 == Outdated reference: A later version (-07) exists of draft-ietf-pce-segment-routing-policy-cp-06 Summary: 0 errors (**), 0 flaws (~~), 7 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: Standards Track F. Yang, Ed. 5 Expires: 8 September 2022 Huawei Technologies 6 7 March 2022 8 Redundancy Policy for Redundancy Protection 9 draft-geng-spring-redundancy-policy-02 11 Abstract 13 Redundancy Protection is a generalized protection mechanism to 14 achieve the high reliability of service transmission in Segment 15 Routing network. Specifically, packets of flows are replicated at a 16 network node into two or more copies, which are transported via 17 different and disjoint paths in parallel. To support redundancy 18 protection in Segment Routing domain, this document introduces 19 Redundancy Policy, as a variant of SR Policy, to intrust the 20 replication of service packets and the multiple ordered lists of 21 segments used for packet carrying. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in . 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on 8 September 2022. 46 Copyright Notice 48 Copyright (c) 2022 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 53 license-info) in effect on the date of publication of this document. 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. Code Components 56 extracted from this document must include Revised BSD License text as 57 described in Section 4.e of the Trust Legal Provisions and are 58 provided without warranty as described in the Revised BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 2 64 3. Redundancy Policy . . . . . . . . . . . . . . . . . . . . . . 3 65 3.1. Identification of Redundancy Policy . . . . . . . . . . . 3 66 3.2. Redundancy Policy Structure . . . . . . . . . . . . . . . 4 67 3.3. Behavior of Redundancy Policy . . . . . . . . . . . . . . 4 68 3.4. Association with Redundancy Segment . . . . . . . . . . . 5 69 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 71 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 74 7.2. Informative References . . . . . . . . . . . . . . . . . 6 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 77 1. Introduction 79 Redundancy protection [I-D.ietf-spring-sr-redundancy-protection] is a 80 generalized protection mechanism by replicating and transmitting 81 copies of flow packets on redundancy node over multiple different and 82 disjoint paths, and further eliminating the redundant packets at 83 merging node. This document introduces Redundancy Policy to support 84 redundancy protection, which is a variant of SR Policy 85 [I-D.ietf-spring-segment-routing-policy] . Redundancy Policy applys 86 equally to both MPLS data plane (SR-MPLS) [RFC8660] and Segment 87 Routing with IPv6 data plane (SRv6) [RFC8986]. 89 2. Terminology and Conventions 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in [RFC2119]. 95 Redundancy Node: the start point of Redundancy protection, where the 96 network node replicates the flow packets. 98 Merging Node: the end point of redundancy protection, where the 99 network node eliminates and ordering(optionally) the flow packets. 101 Redundancy Policy: an extended SR Policy which instructs more than 102 one active segment lists for the multiple paths to support redundant 103 transmission of flow packets. 105 3. Redundancy Policy 107 Redundancy Policy is used to enable packet replication and 108 instantiation more than one active ordered lists of segments between 109 redundancy node and merging node to steer the same flow through 110 different paths in an SR domain. 112 3.1. Identification of Redundancy Policy 114 A Redundancy Policy is identified through the tuple . Redundancy node is specified as IPv4/ 116 IPv6 address of headend of Redundancy Policy, which is the node to 117 perform packet replication. Merging node is specified as IPv4/IPv6 118 address of endpoint of Redundancy Policy, which is the node to 119 perform packet elimination. Redundancy ID could be a specified value 120 of "color" define in section 2.1 of 121 [I-D.ietf-spring-segment-routing-policy], which indicates the SR 122 policy as a redundancy policy. Redundancy ID could also be used to 123 distinguish redundancy policy sharing the same redundancy node and 124 merging node. 126 The following elements are extended in Redundancy Policy: 128 * Redundancy ID: is used to distinguish a redundancy policy or 129 different redundancy policies 131 * Redundancy SID: is the Binding SID for a redundancy policy and 132 defined in [I-D.ietf-spring-sr-redundancy-protection]. Redundancy 133 SID triggers the instantiation of a Redundancy Policy in the 134 forwarding plane of redundancy node. 136 * Candidate path: more than one candidate paths are included in 137 redundancy policy. In each candidate path, the last segment 138 SHOULD be the Merging SID defined in 139 [I-D.ietf-spring-sr-redundancy-protection]. The preference of 140 candidate paths in redundancy policy SHOULD be the same to 141 instantiate more than one active ordered segment lists. 143 3.2. Redundancy Policy Structure 145 Redundancy policy inherates the basic structure and elements of SR 146 Policy, the information model of Redundancy Policy is the following: 148 Redundany policy POL1 149 Candidate-path CP1 150 Preference 200 151 Priority 10 152 Weight W1, SID-List1 153 Weight W2, SID-List2 154 Candidate-path CP2 155 Preference 200 156 Priority 10 157 Weight W3, SID-List3 159 The Redundancy Policy POL1 is identified by the tuple , R1 is the redundancy node, and M1 161 is the merging node. Redundancy ID is used to identify as a 162 redundancy policy in the context of redundancy node. Two candidate- 163 paths CP1 and CP2 instruct the ordered segment lists, with the same 164 definition of SR policy. Preference is mandatory for each candidate 165 path and used to determine the parallel forwarding paths. Candidata 166 paths with the same preference value are chosen as the disjoint 167 forwarding path of redundancy protection. Since there is no tie- 168 breaking rules of the only one valid best path selection, atrributes 169 of protocol-origin and discriminator are not applicable in redundancy 170 policy. 172 3.3. Behavior of Redundancy Policy 174 In Redundancy Policy, the preference of candidate path is used to 175 select the valid active candidate paths. The preference of candidate 176 paths in redundancy policy SHOULD be the same. Different from SR 177 Policy, there is no tie-breaker comparison between candidate path 178 with equal preference values. Redundancy Policy has no limit on the 179 number of active CPs since more than one forwarding paths are 180 required in order to perform redundancy protection. Regarding the 181 instantiation of ordered lists of segments for candidate path, it 182 keeps the same forwarding instantiation and behavior defined for SR 183 policy. For example, traffic steered on POL1 is still flow-based 184 hashed on Segment-List1 with a ratio W1/(W1+W2), so 185 does Segment-List2. 187 A packet is steered into a Redundancy policy at a redundancy node in 188 following ways: 190 * Incoming packets have an active SID matching the Redundancy SID at 191 the redundancy node. 193 * Per-destination Steering: incoming packets match a BGP/Service 194 route which recurses on a Redundancy Policy. 196 * Per-flow Steering: incoming packets match or recurse on a 197 forwarding array of where some of the entries are Redundancy 198 Policy. 200 * Policy-based Steering: incoming packets match a routing policy 201 which directs them on a Redundancy Policy. 203 3.4. Association with Redundancy Segment 205 In Redundancy Policy, each candidate path must be associated with a 206 BSID. The endpoint behavior of BSID specifies the instantiation of 207 Redundancy Policy in forwarding plane and adopts the endpoint 208 behavior definition of Redundancy SID 209 [I-D.ietf-spring-sr-redundancy-protection] . The associated BSID of 210 Redundancy Policy and its endpoint behavior are signalled redundancy 211 node via BGP SR Policy [I-D.ietf-idr-segment-routing-te-policy] or 212 PCEP [RFC8664] [I-D.ietf-pce-segment-routing-policy-cp] or Netconf 213 YANG. 215 4. IANA Considerations 217 This document requires no new registration IANA. 219 5. Security Considerations 221 TBD 223 6. Acknowledgements 225 Thanks for the valuable comments from James Guichard and Andrew Mail. 227 7. References 229 7.1. Normative References 231 [I-D.ietf-spring-segment-routing-policy] 232 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 233 P. Mattes, "Segment Routing Policy Architecture", Work in 234 Progress, Internet-Draft, draft-ietf-spring-segment- 235 routing-policy-18, 17 February 2022, 236 . 239 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 240 Requirement Levels", BCP 14, RFC 2119, 241 DOI 10.17487/RFC2119, March 1997, 242 . 244 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 245 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 246 May 2017, . 248 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 249 Decraene, B., Litkowski, S., and R. Shakir, "Segment 250 Routing with the MPLS Data Plane", RFC 8660, 251 DOI 10.17487/RFC8660, December 2019, 252 . 254 [RFC8964] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., Bryant, 255 S., and J. Korhonen, "Deterministic Networking (DetNet) 256 Data Plane: MPLS", RFC 8964, DOI 10.17487/RFC8964, January 257 2021, . 259 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 260 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 261 (SRv6) Network Programming", RFC 8986, 262 DOI 10.17487/RFC8986, February 2021, 263 . 265 7.2. Informative References 267 [I-D.ietf-idr-segment-routing-te-policy] 268 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 269 Jain, D., and S. Lin, "Advertising Segment Routing 270 Policies in BGP", Work in Progress, Internet-Draft, draft- 271 ietf-idr-segment-routing-te-policy-14, 10 November 2021, 272 . 275 [I-D.ietf-pce-segment-routing-policy-cp] 276 Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H. 277 Bidgoli, "PCEP extension to support Segment Routing Policy 278 Candidate Paths", Work in Progress, Internet-Draft, draft- 279 ietf-pce-segment-routing-policy-cp-06, 22 October 2021, 280 . 283 [I-D.ietf-spring-sr-policy-yang] 284 Raza, K., Sawaya, R., Shunwan, Z., Voyer, D., Durrani, M., 285 Matsushima, S., and V. P. Beeram, "YANG Data Model for 286 Segment Routing Policy", Work in Progress, Internet-Draft, 287 draft-ietf-spring-sr-policy-yang-01, 7 April 2021, 288 . 291 [I-D.ietf-spring-sr-redundancy-protection] 292 Geng, X., Chen, M., Yang, F., Garvia, P. C., and G. 293 Mishra, "SRv6 for Redundancy Protection", Work in 294 Progress, Internet-Draft, draft-ietf-spring-sr-redundancy- 295 protection-01, 15 February 2022, 296 . 299 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 300 "Deterministic Networking Architecture", RFC 8655, 301 DOI 10.17487/RFC8655, October 2019, 302 . 304 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 305 and J. Hardwick, "Path Computation Element Communication 306 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 307 DOI 10.17487/RFC8664, December 2019, 308 . 310 Authors' Addresses 312 Xuesong Geng 313 Huawei Technologies 314 China 315 Email: gengxuesong@huawei.com 317 Mach(Guoyi) Chen 318 Huawei Technologies 319 China 320 Email: mach.chen@huawei.com 322 Fan Yang 323 Huawei Technologies 324 China 325 Email: shirley.yangfan@huawei.com