idnits 2.17.1 draft-yang-idr-sr-candidate-path-switch-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 (February 2, 2021) is 1178 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 (-26) exists of draft-ietf-idr-segment-routing-te-policy-11 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-09 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Inter-Domain Routing Working Group L. Yang 3 Internet-Draft H. Li 4 Intended status: Standards Track Y. Wang 5 Expires: August 2, 2021 Y. Qiu 6 M. Chen 7 H3C Technologies 8 February 2, 2021 10 Segment Routing Candidate Path Hot-standby switch in BGP 11 draft-yang-idr-sr-candidate-path-switch-00 13 Abstract 15 Segment Routing is a source routing paradigm that explicitly 16 indicates the forwarding path for packets at the ingress node. An SR 17 policy is a set of candidate SR paths consisting of one or more 18 segment lists with necessary path attributes. If an SR policy has 19 multiple valid candidate paths, the device chooses the candidate path 20 with the greatest preference value. If the chosen path fails, the SR 21 policy must select another candidate path. During path reselection, 22 packet loss might occur and thus affect service continuity. Therefore 23 the candidate path hot-standby function occurs, the headend can 24 compute two candidate paths, one is master and the other is backup, 25 set them to the forwarding plane, and in this way, the switchover 26 time is reduced. 28 This document defines extensions to BGP to distribute hot-standby 29 switch within SR policies. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current 39 Internet-Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six 42 months and may be updated, replaced, or obsoleted by other documents 43 at any time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on June 1, 2021. 48 Copyright Notice 50 Copyright (c) 2021 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with 58 respect to this document. Code Components extracted from this 59 document must include Simplified BSD License text as described in 60 Section 4.e of the Trust Legal Provisions and are provided without 61 warranty as described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 68 3. SR Policy for Hot-standby . . . . . . . . . .. . . . . . . . 3 69 3.1. Path Hot-standby Sub-TLV . . . . . . . . . . . . . . . . . 4 70 4. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 6 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 74 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 7 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 77 9.2. Informative References . . . . . . . . . . . . . . . . . 8 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 80 1. Introduction 82 Segment routing (SR) [RFC8402] is a source routing paradigm that 83 explicitly indicates the forwarding path for packets at the ingress 84 node. The ingress node steers packets into a specific path 85 according to the Segment Routing Policy (SR Policy) as defined in 86 [I-D.ietf-spring-segment-routing-policy]. In order to distribute SR 87 policies to the headend, [I-D.ietf-idr-segment-routing-te-policy] 88 specifies a mechanism by using BGP. 90 An SR Policy includes multiple candidate paths, of which at any time 91 there is only one active candidate path that is provisioned in the 92 forwarding plane and used for traffic steering. However, when the 93 hot-standby is enabled on the policy, another candidate path (with 94 the secondary greatest preference value) MAY be designated as the 95 backup for the active candidate path. The active candidate path can 96 be called the primary candidate path. When the forwarding paths 97 corresponding to all SID lists of the primary path fails, the backup 98 path immediately takes over to minimize service interruption. 100 This document defines one extension to Border Gateway Protocol (BGP) 101 to distribute SR policies carrying hot-standby switch. 103 2. Terminology 105 2.1. Requirements Language 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 109 "OPTIONAL" in this document are to be interpreted as described in 110 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 111 capitals, as shown here. 113 3. SR Policy for hot-standby 115 As defined in [I-D.ietf-idr-segment-routing-te-policy], the SR 116 policy encoding structure is as follows: 118 SR Policy SAFI NLRI: 119 Attributes: 120 Tunnel Encaps Attribute (23) 121 Tunnel Type: SR Policy 122 Binding SID 123 SRv6 Binding SID 124 Preference 125 Priority 126 Policy Name 127 Policy Candidate Path Name 128 Explicit NULL Label Policy (ENLP) 129 Segment List 130 Weight 131 Segment 132 Segment 133 ... 134 ... 136 As introduced in Section 1, SR policy with hot-standby is expressed 137 as below: 139 SR Policy SAFI NLRI: 140 Attributes: 141 Tunnel Encaps Attribute (23) 142 Tunnel Type: SR Policy 143 Binding SID 144 SRv6 Binding SID 145 Preference 146 Priority 147 Policy Name 148 Path Hot-standby 149 Policy Candidate Path Name 150 Explicit NULL Label Policy (ENLP) 151 Segment List 152 Weight 153 Segment 154 Segment 155 ... 156 ... 158 3.1 Path Hot-standby Sub-TLV 160 A Hot-standby sub-TLV is an Optional sub-TLV. When it appears, it 161 MUST appear only once at most within a SR Policy SAFI NLRI. If 162 multiple Hot-standby sub-TLVs appear within a SR Policy SAFI NLRI, 163 the NLRI MUST be treated as a malformed NLRI. 165 As per [I-D.ietf-idr-segment-routing-te-policy], when the error 166 determined allows for the router to skip the malformed NLRI(s) and 167 continue processing of the rest of the update message, then it MUST 168 handle such malformed NLRIs as 'Treat-as-withdraw'. This document 169 does not define new error handling rules for Hot-standby sub-TLV, 170 and the error handling rules defined in 171 [I-D.ietf-idr-segment-routing-te-policy] apply to this document. 173 A Hot-standby sub-TLV associated with a SR policy, The Hot-standby 174 sub-TLV has the following format: 176 0 1 2 3 177 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Type | Length | Hot-standby | RESERVED | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 Figure 1. Hot-standby sub-TLV 182 Where: 184 Type: to be assigned by IANA. 186 Length: the total length of the value field not including Type and 187 Length fields. 189 Hot-standby: 1 octet of flags. Following flags are defined. Unused 190 bits in the Flag octet SHOULD be set to zero upon transmission and 191 MUST be ignored upon receipt. 193 0 1 2 3 4 5 6 7 194 +-+-+-+-+-+-+-+-+ 195 |E| | 196 +-+-+-+-+-+-+-+-+ 198 Where: 200 E-Flag: 1 bit. Indicates the Policy Candidate Path hot-standby 201 switch flag. 202 When E-Flag is set, it represents the switch has been enabled. 204 Reserved: 8 bits reserved and MUST be set to 0 on transmission and 205 MUST be ignored on receipt. 207 When the E-Flag of hot-standby changes, the selection process will 208 be re-executed, if E-Flag is present, the master and backup 209 candidate path selected set to data-plane. If E-Flag is absent, only 210 the master's candidate path will be set to data-plane. 212 4. Operations 214 The document does not bring new operation beyond the description of 215 operations defined in [I-D.ietf-idr-segment-routing-te-policy]. The 216 existing operations defined in 217 [I-D.ietf-idr-segment-routing-te-policy] can apply to this document 218 directly. 220 Typically but not limit to, the SR policies carrying Hot-standby are 221 configured by a controller. 223 After configuration, the SR policies carrying Hot-standby will be 224 advertised by BGP update messages. The operation of advertisement 225 is the same as defined in [I-D.ietf-idr-segment-routing-te-policy], 226 as well as the reception. 228 The consumer of the SR policies is not the BGP process. The 229 operation of sending information to consumers is out of scope of 230 this document. 232 5. Implementation Status 234 This section records the status of known implementations of the 235 protocol defined by this specification at the time of posting of 236 this Internet-Draft, and is based on a proposal described in 237 [RFC7942]. 239 The description of implementations in this section is intended to 240 assist the IETF in its decision processes in progressing drafts to 241 RFCs. Please note that the listing of any individual implementation 242 here does not imply endorsement by the IETF. Furthermore, no effort 243 has been spent to verify the information presented here that was 244 supplied by IETF contributors. This is not intended as, and must 245 not be construed to be, a catalog of available implementations or 246 their features. Readers are advised to note that other 247 implementations may exist. 249 According to [RFC7942], "this will allow reviewers and working 250 groups to assign due consideration to documents that have the 251 benefit of running code, which may serve as evidence of valuable 252 experimentation and feedback that have made the implemented 253 protocols more mature. It is up to the individual working groups 254 to use this information as they see fit". 256 6. IANA Considerations 258 This document defines a new Sub-TLV in registries "SR Policy List 259 Sub- TLVs" [I-D.ietf-idr-segment-routing-te-policy]: 261 Value Description Reference 262 --------------------------------------------------------------------- 263 TBA Hot-standby sub-TLV This document 265 7. Security Considerations 267 TBA 269 8. Acknowledgments 271 Authors would like to thank Changwang Lin for their paraprofessional 272 comments and help. 274 9. References 276 9.1. Normative References 278 [I-D.ietf-idr-segment-routing-te-policy] 279 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 280 Rosen, E., Jain, D., and S. Lin, "Advertising Segment 281 Routing Policies in BGP", draft-ietf-idr-segment-routing- 282 te-policy-11 (work in progress), May 2020. 284 [I-D.ietf-spring-segment-routing-policy] 285 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 286 P. Mattes, "Segment Routing Policy Architecture", draft- 287 ietf-spring-segment-routing-policy-09 (work in progress), 288 July 2020. 290 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 291 Requirement Levels", BCP 14, RFC 2119, 292 DOI 10.17487/RFC2119, March 1997, 293 . 295 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 296 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 297 May 2017, . 299 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 300 Decraene, B., Litkowski, S., and R. Shakir, "Segment 301 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 302 July 2018, . 304 9.2. Informative References 306 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 307 Code: The Implementation Status Section", BCP 205, 308 RFC 7942, DOI 10.17487/RFC7942, July 2016, 309 . 311 Authors' Addresses 313 Liping Yang 314 H3C Technologies 315 China 317 Email: liping_yang@h3c.com 319 Hao Li 320 H3C Technologies 321 China 323 Email: lihao@h3c.com 325 Yuanxiang Qiu 326 H3C Technologies 327 China 329 Email: qiuyuanxiang@h3c.com 331 Yang Wang 332 H3C Technologies 333 China 335 Email: wang.a.yang@h3c.com 337 Mengxiao Chen 338 H3C Technologies 339 China 341 Email: chen.mengxiao@h3c.com