idnits 2.17.00 (12 Aug 2021) /tmp/idnits22408/draft-lp-idr-sr-path-protection-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 copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (19 December 2021) is 146 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 (-17) exists of draft-ietf-idr-segment-routing-te-policy-14 == Outdated reference: A later version (-17) exists of draft-ietf-idr-te-lsp-distribution-16 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-14 == Outdated reference: A later version (-05) exists of draft-ietf-pce-multipath-03 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR WG Y. Liu 3 Internet-Draft S. Peng 4 Intended status: Standards Track ZTE 5 Expires: 22 June 2022 19 December 2021 7 BGP Extensions of SR Policy for Path Protection 8 draft-lp-idr-sr-path-protection-02 10 Abstract 12 This document proposes extensions of BGP to provide protection 13 information of segment lists within a candidate path when delivering 14 SR policy. And it also extends BGP-LS to provide some extra 15 information of the segment list in the advertisement. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on 22 June 2022. 34 Copyright Notice 36 Copyright (c) 2021 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 41 license-info) in effect on the date of publication of this document. 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. Code Components 44 extracted from this document must include Revised BSD License text as 45 described in Section 4.e of the Trust Legal Provisions and are 46 provided without warranty as described in the Revised BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 52 2. BGP Extensions for Advertising Segment List . . . . . . . . . 3 53 2.1. Extensions of Segment List sub-TLV . . . . . . . . . . . 3 54 2.2. List Identifier Sub-TLV . . . . . . . . . . . . . . . . . 4 55 2.2.1. List Protection Sub-TLV . . . . . . . . . . . . . . . 4 56 3. BGP-LS Extensions for Distributing Segment List States . . . 7 57 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 58 4.1. New Registry: Flag Field of Segment List sub-TLV . . . . 7 59 4.2. Existing Registry: BGP Tunnel Encapsulation Attribute 60 sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . 7 61 4.3. New Registry: List Identifier Sub-TLVs . . . . . . . . . 8 62 4.4. Existing Registry: Flag Field of SR Segment List TLV . . 8 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 64 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 66 6.2. Informative References . . . . . . . . . . . . . . . . . 9 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 69 1. Introduction 71 Segment Routing [RFC8402] allows a headend node to steer a packet 72 flow along any path. [I-D.ietf-spring-segment-routing-policy] 73 details the concept of SR Policy and steering into an SR Policy. An 74 SR Policy is a set of candidate paths, each consisting of one or more 75 segment lists. The headend of an SR Policy may learn multiple 76 candidate paths for an SR Policy. 78 Candidate path can be used for path protection, that is, the lower 79 preference candidate path may be designated as the backup for a 80 specific or all (active) candidate path(s). Backup candidate path 81 provide protection only when all the segment lists in the active CP 82 are invalid. 84 If a candidate path is associated with a set of Segment-Lists, each 85 Segment-List is associated with weight for weighted load balancing. 87 The protection mechanism for SR Policy is not flexible enough. For 88 example, there're three segment lists(SL1, SL2, SL3) in candidate 89 path 1, it may be desired that SL1 and SL2 are the primary path, SL3 90 are the backup path for SL1 and will be active only when SL1 fails. 92 [I-D.ietf-pce-multipath] proposes extensions to PCEP to specify the 93 protection relationship between segment lists in the candidate path. 95 [I-D.ietf-idr-segment-routing-te-policy] specifies BGP extensions for 96 the advertisement of SR Policies and each candidate path is carried 97 in an NLRI. This document proposes extensions of BGP in order to 98 provide protection information of segment lists when delivering SR 99 policy. 101 [I-D.ietf-idr-te-lsp-distribution] describes a mechanism to collect 102 the SR policy information that is locally available in a node and 103 advertise it into BGP Link State (BGP-LS) updates. This document 104 also extends it to provide some extra information of the segment list 105 in a candidate path in the BGP-LS advertisement. 107 1.1. Requirements Language 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 [RFC2119]. 113 2. BGP Extensions for Advertising Segment List 115 2.1. Extensions of Segment List sub-TLV 117 Segment List sub-TLV is introduced in 118 [I-D.ietf-idr-segment-routing-te-policy] and it includes the elements 119 of the paths (i.e., segments). 121 This document introduces a one-bit flag in the RESERVED field. 123 0 1 2 3 124 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 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | Type | Length |B| RESERVED | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 // sub-TLVs // 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 Figure 1: Segment List sub-TLV 133 B-Flag(Backup Flag): one bit. When set to 0, it indicates that the 134 segment list acts as the active member in the candidate path. When 135 set to 1, it indicates that the segment list acts as the backup path 136 in the candidate path. 138 Using segment lists for path protection can be compatible with using 139 candidate paths. When a path fails, the backup segment list within 140 the same candidate path is used preferentially for path protection. 141 If the backup list is also invalid, then other candidate path can be 142 enabled for protection. 144 2.2. List Identifier Sub-TLV 146 This document introduces a new sub-sub-tlv of Segment List sub-TLV, 147 where, 149 0 1 2 3 150 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 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Type | Length | RESERVED | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | List Identifier | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 ~ Optional sub-TLVs ~ 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 Figure 2: List Identifier Sub-TLV 161 * Type: 1 octet. TBD. 163 * Length: 1 octet, specifies the length of the value field not 164 including Type and Length fields. 166 * RESERVED: 2 octet of reserved bits. SHOULD be unset on 167 transmission and MUST be ignored on receipt. 169 * List Identifier: 4 octets. It is the identifier of the 170 corresponding segment list, so that the segment list can be 171 operated according to the specified Segment List identifier. 173 * This sub-TLV is optional and it MUST NOT appear more than once 174 inside the Segment List sub-TLV. 176 2.2.1. List Protection Sub-TLV 178 The List Protection Info sub-TLV is an optional sub-TLV of List 179 Identifier sub-TLV, where: 181 0 1 2 3 182 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 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Type | Length | RESERVED | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Backup List ID 1 | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | ... | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Backup List ID N | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 Figure 3: List Protection Info Sub-TLV 195 * Type: 1 octet. TBD. 197 * Length: 1 octet, specifies the length of the value field not 198 including Type and Length fields. 200 * RESERVED: 2 octet of reserved bits. SHOULD be unset on 201 transmission and MUST be ignored on receipt. 203 * Backup List ID: 4 octets. It is the List Identifier of the backup 204 segment list that protects this segment list. If there're 205 multiple backup paths, the list ID of each path should be included 206 in the TLV. 208 As defined in [I-D.ietf-idr-segment-routing-te-policy], the SR Policy 209 encoding structure is as follows: 211 SR Policy SAFI NLRI: 212 Attributes: 213 Tunnel Encaps Attribute (23) 214 Tunnel Type: SR Policy 215 Binding SID 216 Preference 217 Priority 218 Policy Name 219 Explicit NULL Label Policy (ENLP) 220 Segment List 221 Weight 222 Segment 223 Segment 224 ... 225 Segment List 226 ... 227 ... 229 The new SR Policy encoding structure with List Identifier sub-TLV is 230 shown as below: 232 SR Policy SAFI NLRI: 233 Attributes: 234 Tunnel Encaps Attribute (23) 235 Tunnel Type: SR Policy 236 Binding SID 237 SRv6 Binding SID 238 Preference 239 Priority 240 Policy Name 241 Policy Candidate Path Name 242 Explicit NULL Label Policy (ENLP) 243 Segment List 244 List Identifier 245 List Protection Info 246 Weight 247 Segment 248 Segment 249 ... 250 Segment List 251 ... 252 ... 254 3. BGP-LS Extensions for Distributing Segment List States 256 [I-D.ietf-idr-te-lsp-distribution] describes a mechanism to collect 257 the SR Policy information that is locally available in a node and 258 advertise it into BGP Link State (BGP-LS) updates. The SR Policy 259 information includes status of the candidate path, e.g, whether the 260 candidate path is administrative shut or not. 262 SR Segment List TLV is defined in [I-D.ietf-idr-te-lsp-distribution] 263 to to report the SID-List(s) of a candidate path. Figure 4 shows the 264 flags in SR Segment List TLV. 266 0 1 267 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 |D|E|C|V|R|F|A|T|M|S|B| | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 Figure 4: Flag Field of SR Segment List TLV 274 The D,E,C,V,R,F,A,M flags are defined in 275 [I-D.ietf-idr-te-lsp-distribution]. 277 This document introduces two new flags, where, 279 * S-Flag : Indicates the segment list is in administrative shut 280 state when set. 282 * B-Flag : Indicates the segment list is the backup path within the 283 candidate path when set, otherwise it is the active path. 285 4. IANA Considerations 287 4.1. New Registry: Flag Field of Segment List sub-TLV 289 This document introduces a one-bit flag field in the Segment List 290 sub-TLV [I-D.ietf-idr-segment-routing-te-policy] for the Backup Flag 291 (B-Flag). 293 4.2. Existing Registry: BGP Tunnel Encapsulation Attribute sub-TLVs 295 This document defines a new sub-TLV in the registry "SR Policy List 296 Sub-TLVs" [I-D.ietf-idr-segment-routing-te-policy] to be assigned by 297 IANA: 299 Codepoint Description Reference 300 ------------------------------------------------------------- 301 TBD List Identifier Sub-TLV This document 303 4.3. New Registry: List Identifier Sub-TLVs 305 This document requests the creation of a new registry called "List 306 Identifier Sub-TLVs" under the "BGP Tunnel Encapsulation" registry. 307 Following initial Sub-TLV codepoint are assigned by this document. 309 Codepoint Description Reference 310 ------------------------------------------------------------- 311 TBD List Protection Sub-TLV This document 313 4.4. Existing Registry: Flag Field of SR Segment List TLV 315 This document requests bit 9 and bit 10 in the flag field of "SR 316 Segment List TLV" [I-D.ietf-idr-te-lsp-distribution] under the "BGP- 317 LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute 318 TLVs" registry. 320 Bit Description Reference 321 ------------------------------------------------------------------ 322 9 Administrative Shut State Flag(S-Flag) This document 323 10 Backup Path State Flag(B-Flag) This document 325 5. Security Considerations 327 Procedures and protocol extensions defined in this document do not 328 affect the security considerations discussed in 329 [I-D.ietf-idr-segment-routing-te-policy] and 330 [I-D.ietf-idr-te-lsp-distribution]. 332 6. References 334 6.1. Normative References 336 [I-D.ietf-idr-segment-routing-te-policy] 337 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 338 Jain, D., and S. Lin, "Advertising Segment Routing 339 Policies in BGP", Work in Progress, Internet-Draft, draft- 340 ietf-idr-segment-routing-te-policy-14, 10 November 2021, 341 . 344 [I-D.ietf-idr-te-lsp-distribution] 345 Previdi, S., Talaulikar, K., Dong, J., Chen, M., Gredler, 346 H., and J. Tantsura, "Distribution of Traffic Engineering 347 (TE) Policies and State using BGP-LS", Work in Progress, 348 Internet-Draft, draft-ietf-idr-te-lsp-distribution-16, 22 349 October 2021, . 352 [I-D.ietf-spring-segment-routing-policy] 353 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 354 P. Mattes, "Segment Routing Policy Architecture", Work in 355 Progress, Internet-Draft, draft-ietf-spring-segment- 356 routing-policy-14, 25 October 2021, 357 . 360 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 361 Requirement Levels", BCP 14, RFC 2119, 362 DOI 10.17487/RFC2119, March 1997, 363 . 365 6.2. Informative References 367 [I-D.ietf-pce-multipath] 368 Koldychev, M., Sivabalan, S., Saad, T., Beeram, V. P., 369 Bidgoli, H., Yadav, B., and S. Peng, "PCEP Extensions for 370 Signaling Multipath Information", Work in Progress, 371 Internet-Draft, draft-ietf-pce-multipath-03, 25 October 372 2021, . 375 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 376 Decraene, B., Litkowski, S., and R. Shakir, "Segment 377 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 378 July 2018, . 380 Authors' Addresses 382 Yao Liu 383 ZTE 384 Nanjing 385 China 387 Email: liu.yao71@zte.com.cn 389 Shaofu Peng 390 ZTE 391 Nanjing 392 China 394 Email: peng.shaofu@zte.com.cn