idnits 2.17.1 draft-lp-idr-sr-path-protection-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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 152: '... reserved bits. SHOULD be unset on tr...' RFC 2119 keyword, line 153: '... and MUST be ignored on receipt....' RFC 2119 keyword, line 159: '... optional and it MUST NOT appear more ...' RFC 2119 keyword, line 186: '... reserved bits. SHOULD be unset on tr...' RFC 2119 keyword, line 187: '... and MUST be ignored on receipt....' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 19, 2021) is 1071 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 (-19) exists of draft-ietf-idr-te-lsp-distribution-14 == Outdated reference: A later version (-11) exists of draft-ietf-pce-multipath-00 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-11 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR WG Yao. Liu 3 Internet-Draft Shaofu. Peng 4 Intended status: Standards Track ZTE Corporation 5 Expires: November 20, 2021 May 19, 2021 7 BGP Extensions of SR Policy for Path Protection 8 draft-lp-idr-sr-path-protection-01 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 November 20, 2021. 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 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 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 . . . . . . . . . . . . . . . . . 3 55 2.2.1. List Protection Sub-TLV . . . . . . . . . . . . . . . 4 56 3. BGP-LS Extensions for Distributing Segment List States . . . 6 57 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 58 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 59 6. Normative References . . . . . . . . . . . . . . . . . . . . 7 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 62 1. Introduction 64 Segment Routing [RFC8402] allows a headend node to steer a packet 65 flow along any path. [I-D.ietf-spring-segment-routing-policy] 66 details the concept of SR Policy and steering into an SR Policy. An 67 SR Policy is a set of candidate paths, each consisting of one or more 68 segment lists. The headend of an SR Policy may learn multiple 69 candidate paths for an SR Policy. 71 Candidate path can be used for path protection, that is, the lower 72 preference candidate path may be designated as the backup for a 73 specific or all (active) candidate path(s). Backup candidate path 74 provide protection only when all the segment lists in the active CP 75 are invalid. 77 If a candidate path is associated with a set of Segment-Lists, each 78 Segment-List is associated with weight for weighted load balancing. 80 The protection mechanism for SR Policy is not flexible enough. For 81 example, there're three segment lists(SL1, SL2, SL3) in candidate 82 path 1, it may be desired that SL1 and SL2 are the primary path, SL3 83 are the backup path for SL1 and will be active only when SL1 fails. 85 [I-D.ietf-pce-multipath] proposes extensions to PCEP to specify the 86 protection relationship between segment lists in the candidate path. 88 [I-D.ietf-idr-segment-routing-te-policy] specifies BGP extensions for 89 the advertisement of SR Policies and each candidate path is carried 90 in an NLRI. This document proposes extensions of BGP in order to 91 provide protection information of segment lists when delivering SR 92 policy. 94 [I-D.ietf-idr-te-lsp-distribution] describes a mechanism to collect 95 the SR policy information that is locally available in a node and 96 advertise it into BGP Link State (BGP-LS) updates. This document 97 also extends it to provide some extra information of the segment list 98 in a candidate path in the BGP-LS advertisement. 100 2. BGP Extensions for Advertising Segment List 102 2.1. Extensions of Segment List sub-TLV 104 Segment List sub-TLV is introduced in 105 [I-D.ietf-idr-segment-routing-te-policy] and it includes the elements 106 of the paths (i.e., segments). 108 This document introduces a one-bit flag in the RESERVED field. 110 0 1 2 3 111 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 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 | Type | Length |B| RESERVED | 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 // sub-TLVs // 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 Figure 1: Segment List sub-TLV 120 B-Flag(Backup Flag): one bit. When set to 0, it indicates that the 121 segment list acts as the active member in the candidate path. When 122 set to 1, it indicates that the segment list acts as the backup path 123 in the candidate path. 125 Using segment lists for path protection can be compatible with using 126 candidate paths. When a path fails, the backup segment list within 127 the same candidate path is used preferentially for path protection. 128 If the backup list is also invalid, then other candidate path can be 129 enabled for protection. 131 2.2. List Identifier Sub-TLV 133 This document introduces a new sub-sub-tlv of Segment List sub-TLV, 134 where, 135 0 1 2 3 136 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 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | Type | Length | RESERVED | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | List Identifier | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 ~ Optional sub-TLVs ~ 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 Figure 2: List Identifier Sub-TLV 147 Type: 1 octet. TBD. 149 Length: 1 octet, specifies the length of the value field not 150 including Type and Length fields. 152 RESERVED: 2 octet of reserved bits. SHOULD be unset on transmission 153 and MUST be ignored on receipt. 155 List Identifier: 4 octets. It is the identifier of the corresponding 156 segment list, so that the segment list can be operated according to 157 the specified Segment List identifier. 159 This sub-TLV is optional and it MUST NOT appear more than once inside 160 the Segment List sub-TLV. 162 2.2.1. List Protection Sub-TLV 164 The List Protection Info sub-TLV is an optional sub-TLV of List 165 Identifier sub-TLV, where: 167 0 1 2 3 168 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 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Type | Length | RESERVED | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | Backup List ID 1 | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | ... | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Backup List ID N | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 Figure 3: List Protection Info Sub-TLV 181 Type: 1 octet. TBD. 183 Length: 1 octet, specifies the length of the value field not 184 including Type and Length fields. 186 RESERVED: 2 octet of reserved bits. SHOULD be unset on transmission 187 and MUST be ignored on receipt. 189 Backup List ID: 4 octets. It is the List Identifier of the backup 190 segment list that protects this segment list. If there're multiple 191 backup paths, the list ID of each path should be included in the TLV. 193 As defined in [I-D.ietf-idr-segment-routing-te-policy], the SR Policy 194 encoding structure is as follows: 196 SR Policy SAFI NLRI: 197 Attributes: 198 Tunnel Encaps Attribute (23) 199 Tunnel Type: SR Policy 200 Binding SID 201 Preference 202 Priority 203 Policy Name 204 Explicit NULL Label Policy (ENLP) 205 Segment List 206 Weight 207 Segment 208 Segment 209 ... 210 Segment List 211 ... 212 ... 214 The new SR Policy encoding structure with List Identifier sub-TLV is 215 shown as below: 217 SR Policy SAFI NLRI: 218 Attributes: 219 Tunnel Encaps Attribute (23) 220 Tunnel Type: SR Policy 221 Binding SID 222 SRv6 Binding SID 223 Preference 224 Priority 225 Policy Name 226 Policy Candidate Path Name 227 Explicit NULL Label Policy (ENLP) 228 Segment List 229 List Identifier 230 List Protection Info 231 Weight 232 Segment 233 Segment 234 ... 235 Segment List 236 ... 237 ... 239 3. BGP-LS Extensions for Distributing Segment List States 241 [I-D.ietf-idr-te-lsp-distribution] describes a mechanism to collect 242 the SR Policy information that is locally available in a node and 243 advertise it into BGP Link State (BGP-LS) updates. The SR Policy 244 information includes status of the candidate path, e.g, whether the 245 candidate path is administrative shut or not. 247 SR Segment List TLV is defined in [I-D.ietf-idr-te-lsp-distribution] 248 to to report the SID-List(s) of a candidate path. Figure 4 shows the 249 flags in SR Segment List TLV. 251 0 1 252 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 |D|E|C|V|R|F|A|T|M|S|B| | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 Figure 4: Flag Field of SR Segment List TLV 259 The D,E,C,V,R,F,A,M flags are defined in 260 [I-D.ietf-idr-te-lsp-distribution]. 262 This document introduces two new flags, where, 263 S-Flag : Indicates the segment list is in administrative shut state 264 when set. 266 B-Flag : Indicates the segment list is the backup path within the 267 candidate path when set, otherwise it is the active path. 269 4. Security Considerations 271 Procedures and protocol extensions defined in this document do not 272 affect the security considerations discussed in 273 [I-D.ietf-idr-segment-routing-te-policy] and 274 [I-D.ietf-idr-te-lsp-distribution]. 276 5. IANA Considerations 278 TBD 280 6. Normative References 282 [I-D.ietf-idr-segment-routing-te-policy] 283 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 284 Rosen, E., Jain, D., and S. Lin, "Advertising Segment 285 Routing Policies in BGP", draft-ietf-idr-segment-routing- 286 te-policy-11 (work in progress), November 2020. 288 [I-D.ietf-idr-te-lsp-distribution] 289 Previdi, S., Talaulikar, K., Dong, J., Chen, M., Gredler, 290 H., and J. Tantsura, "Distribution of Traffic Engineering 291 (TE) Policies and State using BGP-LS", draft-ietf-idr-te- 292 lsp-distribution-14 (work in progress), October 2020. 294 [I-D.ietf-pce-multipath] 295 Koldychev, M., Sivabalan, S., Saad, T., Beeram, V. P., 296 Bidgoli, H., Yadav, B., and S. Peng, "PCEP Extensions for 297 Signaling Multipath Information", draft-ietf-pce- 298 multipath-00 (work in progress), May 2021. 300 [I-D.ietf-spring-segment-routing-policy] 301 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 302 P. Mattes, "Segment Routing Policy Architecture", draft- 303 ietf-spring-segment-routing-policy-11 (work in progress), 304 April 2021. 306 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 307 Decraene, B., Litkowski, S., and R. Shakir, "Segment 308 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 309 July 2018, . 311 Authors' Addresses 313 Liu Yao 314 ZTE Corporation 315 Nanjing 316 China 318 Email: liu.yao71@zte.com.cn 320 Peng Shaofu 321 ZTE Corporation 322 Nanjing 323 China 325 Email: peng.shaofu@zte.com.cn