idnits 2.17.1 draft-tokar-pce-sid-algo-05.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 (4 October 2021) is 934 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 (-25) exists of draft-ietf-pce-segment-routing-ipv6-09 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group A. Tokar 3 Internet-Draft S. Sidor 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: 7 April 2022 S. Peng 6 ZTE Corporation 7 S. Sivabalan 8 Ciena 9 T. Saad 10 Juniper Networks 11 S. Peng 12 Huawei Technologies 13 M. Negi 14 RtBrick Inc 15 4 October 2021 17 Carrying SID Algorithm information in PCE-based Networks. 18 draft-tokar-pce-sid-algo-05 20 Abstract 22 The Algorithm associated with a prefix Segment-ID (SID) defines the 23 path computation Algorithm used by Interior Gateway Protocols (IGPs). 24 This information is available to controllers such as the Path 25 Computation Element (PCE) via topology learning. This document 26 proposes an approach for informing headend routers regarding the 27 Algorithm associated with each prefix SID used in PCE-computed paths, 28 as well as signalling a specific SID algorithm as a constraint to the 29 PCE. 31 Requirements Language 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 35 "OPTIONAL" in this document are to be interpreted as described in BCP 36 14 [RFC2119] [RFC8174] when, and only when, they appear in all 37 capitals, as shown here. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at https://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on 7 April 2022. 56 Copyright Notice 58 Copyright (c) 2021 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 63 license-info) in effect on the date of publication of this document. 64 Please review these documents carefully, as they describe your rights 65 and restrictions with respect to this document. Code Components 66 extracted from this document must include Simplified BSD License text 67 as described in Section 4.e of the Trust Legal Provisions and are 68 provided without warranty as described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 74 3. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 4 75 3.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 4 76 3.1.1. SR PCE Capability Sub-TLV . . . . . . . . . . . . . . 4 77 3.1.2. SRv6 PCE Capability sub-TLV . . . . . . . . . . . . . 4 78 3.2. SR-ERO Subobject . . . . . . . . . . . . . . . . . . . . 5 79 3.3. SRv6-ERO Subobject . . . . . . . . . . . . . . . . . . . 5 80 3.4. LSPA Object . . . . . . . . . . . . . . . . . . . . . . . 6 81 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 7 82 4.1. SR-ERO and SRv6-ERO Encoding . . . . . . . . . . . . . . 7 83 4.2. SID Algorithm Constraint . . . . . . . . . . . . . . . . 7 84 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 86 6.1. SR Capability Flag . . . . . . . . . . . . . . . . . . . 8 87 6.2. SRv6 PCE Capability Flag . . . . . . . . . . . . . . . . 8 88 6.3. SR-ERO Flag . . . . . . . . . . . . . . . . . . . . . . . 8 89 6.4. SRv6-ERO Flag . . . . . . . . . . . . . . . . . . . . . . 9 90 6.5. PCEP TLV Types . . . . . . . . . . . . . . . . . . . . . 9 91 7. Normative References . . . . . . . . . . . . . . . . . . . . 9 92 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 10 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 95 1. Introduction 97 A PCE can compute SR-TE paths using SIDs with different Algorithms 98 depending on the use-case, constraints, etc. While this information 99 is available on the PCE, there is no method of conveying this 100 information to the headend router. 102 Similarly, the headend can also compute SR-TE paths using different 103 Algorithms, and this information also needs to be conveyed to the PCE 104 for collection or troubleshooting purposes. In addition, in the case 105 of multiple (redundant) PCEs, when the headend receives a path from 106 the primary PCE, it needs to be able to report the complete path 107 information - including the Algorithm - to the backup PCE so that in 108 HA scenarios, the backup PCE can verify the prefix SIDs 109 appropriately. 111 An operator may also want to constrain the path computed by the PCE 112 to a specific SID Algorithm, for example, in order to only use SID 113 Algorithms for a low-latency path. A new TLV is introduced for this 114 purpose. 116 Refer to [RFC8665] and [RFC8667] for details about the prefix SID 117 Algorithm. 119 This document is extending: 121 * the SR PCE Capability Sub-TLV and the SR-ERO subobject - defined 122 in [RFC8664] 124 * the SRv6 PCE Capability sub-TLV and the SRv6-ERO subobject - 125 defined in [I-D.ietf-pce-segment-routing-ipv6] 127 A new TLV for signalling SID Algorithm constraint to the PCE is also 128 introduced, to be carried inside the LSPA object, which is defined in 129 [RFC5440]. 131 The mechanisms described in this document are equally applicable to 132 both SR-MPLS and SRv6. 134 2. Terminology 136 The following terminologies are used in this document: 138 ERO: Explicit Route Object 140 IGP: Interior Gateway Protocol 142 NAI: Node or Adjacency Identifier. 144 PCE: Path Computation Element 146 PCEP: Path Computation Element Protocol. 148 SID: Segment Identifier. 150 SR: Segment Routing. 152 SR-TE: Segment Routing Traffic Engineering. 154 LSP: Label Switched Path. 156 LSPA: Label Switched Path Attributes. 158 3. Object Formats 160 3.1. OPEN Object 162 3.1.1. SR PCE Capability Sub-TLV 164 A new flag S is proposed in the SR PCE Capability Sub-TLV introduced 165 in Section 4.1.2 of [RFC8664] in Path Computation Element 166 Communication Protocol (PCEP) to indicate support for SID Algorithm 167 field in the SR-ERO subobject. 169 0 1 2 3 170 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 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | Type=26 | Length=4 | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Reserved | Flags |S|N|X| MSD | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 3.1.2. SRv6 PCE Capability sub-TLV 179 A new flag S is proposed in the SRv6 PCE Capability sub-TLV 180 introduced in 4.1.1 of [I-D.ietf-pce-segment-routing-ipv6] in Path 181 Computation Element Communication Protocol (PCEP) to indicate support 182 for SID Algorithm field in the SRv6-ERO subobject. 184 0 1 2 3 185 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 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Type=TBD1 | Length | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Reserved | Flags |S|N|X| 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | MSD-Type | MSD-Value | MSD-Type | MSD-Value | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 // ... // 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | MSD-Type | MSD-Value | Padding | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 3.2. SR-ERO Subobject 200 The SR-ERO subobject encoding is extended with new flag "A" to 201 indicate if the Algorithm field is included after other optional 202 fields. 204 0 1 2 3 205 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 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 |L| Type=36 | Length | NT | Flags |A|V|F|S|C|M| 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | SID (optional) | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 // NAI (variable, optional) // 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Reserved | Algorithm | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 3.3. SRv6-ERO Subobject 218 The SRv6-ERO subobject encoding is extended with new flag "A" to 219 indicate if the Algorithm field is included after other optional 220 fields. 222 0 1 2 3 223 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 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 |L| Type=TBD3 | Length | NT | Flags |A|V|T|F|S| 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Reserved | Endpoint Behavior | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | | 230 | SRv6 SID (optional) | 231 | (128-bit) | 232 | | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 // NAI (variable, optional) // 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | SID Structure (optional) | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Reserved | Algorithm | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 3.4. LSPA Object 243 A new TLV for the LSPA Object with TLV type=TBD3 is introduced to 244 carry the SID Algorithm constraint. This TLV SHOULD only be used 245 when PST (Path Setup type) = SR or SRv6. 247 The format of the SID Algorithm TLV is as follows: 249 0 1 2 3 250 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 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Type=TBD3 | Length=4 | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Reserved | Flags |L| Algorithm | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 Figure 1: SID Algorithm TLV Format 259 The code point for the TLV type is TBD3. The TLV length is 4 octets. 261 The 32-bit value is formatted as follows. 263 Reserved: MUST be set to zero by the sender and MUST be ignored by 264 the receiver. 266 Flags: This document defines the following flag bits. The other 267 bits MUST be set to zero by the sender and MUST be ignored by the 268 receiver. 270 * L (Loose): If set to 1, the PCE MAY insert SIDs with a 271 different Algorithm, but it MUST prefer the specified Algorithm 272 whenever possible. 274 Algorithm: SID Algorithm the PCE MUST take into acount while 275 computing a path for the LSP. 277 4. Operation 279 4.1. SR-ERO and SRv6-ERO Encoding 281 PCEP speaker MAY set the A flag and include the Algorithm field in 282 SR-ERO or SRv6-ERO subobject if the S flag was advertised by both 283 PCEP speakers. 285 If PCEP peer receives SR-ERO subobject with the A flag set or with 286 the SID Algorithm included, but the S flag was not advertised, then 287 such PCEP message must be rejected with PCError as described in 288 Section 7.2 of [RFC5440] 290 The Algorithm field MUST be included after optional SID, NAI or SID 291 structure and length of SR-ERO or SRv6-ERO subobject MUST be 292 increased with additional 4 bytes for Reserved and Algorithm field. 294 4.2. SID Algorithm Constraint 296 In order to signal a specific SID Algorithm constraint to the PCE, 297 the headend MUST encode the SID ALGORITHM TLV inside the LSPA object. 299 When the PCE receives a SID Algorithm constraint, it MUST only take 300 prefix SIDs with the specified Algorithm into account during path 301 computation. However, if the L flag is set in the SID Algorithm TLV, 302 the PCE MAY insert prefix SIDs with a different Algorithm in order to 303 successfully compute a path. 305 If the PCE is unable to find a path with the given SID Algorithm 306 constraint, it MUST bring the LSP down. 308 SID Algorithm does not replace the Objective Function defined in 309 [RFC5541]. The SID Algorithm constraint acts as a filter, 310 restricting which SIDs may be used as a result of the path 311 computation function. 313 5. Security Considerations 315 No additional security measure is required. 317 6. IANA Considerations 319 6.1. SR Capability Flag 321 IANA maintains a sub-registry, named "SR Capability Flag Field", 322 within the "Path Computation Element Protocol (PCEP) Numbers" 323 registry to manage the Flags field of the SR-PCE-CAPABILITY TLV. 324 IANA is requested to make the following assignment: 326 +=======+==========================+===============+ 327 | Value | Description | Reference | 328 +=======+==========================+===============+ 329 +-------+--------------------------+---------------+ 330 | TBD1 | SID Algorithm Capability | This document | 331 +-------+--------------------------+---------------+ 333 Table 1 335 6.2. SRv6 PCE Capability Flag 337 IANA was requested in [I-D.ietf-pce-segment-routing-ipv6] to create a 338 sub-registry, named "SRv6 PCE Capability Flags", within the "Path 339 Computation Element Protocol (PCEP) Numbers" registry to manage the 340 Flags field of SRv6-PCE-CAPABILITY sub-TLV. IANA is requested to 341 make the following assignment: 343 +=======+==========================+===============+ 344 | Value | Description | Reference | 345 +=======+==========================+===============+ 346 +-------+--------------------------+---------------+ 347 | TBD2 | SID Algorithm Capability | This document | 348 +-------+--------------------------+---------------+ 350 Table 2 352 6.3. SR-ERO Flag 354 IANA maintains a sub-registry, named "SR-ERO Flag Field", within the 355 "Path Computation Element Protocol (PCEP) Numbers" registry to manage 356 the Flags field of the SR-ERO Subobject. IANA is requested to make 357 the following assignment: 359 +=======+====================+===============+ 360 | Value | Description | Reference | 361 +=======+====================+===============+ 362 +-------+--------------------+---------------+ 363 | TBD3 | SID Algorithm Flag | This document | 364 +-------+--------------------+---------------+ 366 Table 3 368 6.4. SRv6-ERO Flag 370 IANA was requested in [I-D.ietf-pce-segment-routing-ipv6], named 371 "SRv6-ERO Flag Field", within the "Path Computation Element Protocol 372 (PCEP) Numbers" registry to manage the Flags field of the SRv6-ERO 373 subobject. IANA is requested to make the following assignment: 375 +=======+====================+===============+ 376 | Value | Description | Reference | 377 +=======+====================+===============+ 378 +-------+--------------------+---------------+ 379 | TBD4 | SID Algorithm Flag | This document | 380 +-------+--------------------+---------------+ 382 Table 4 384 6.5. PCEP TLV Types 386 IANA is requested to allocate a new TLV type for the new LSPA TLV 387 specified in this document. 389 +=======+===============+===============+ 390 | Value | Description | Reference | 391 +=======+===============+===============+ 392 +-------+---------------+---------------+ 393 | TBD5 | SID Algorithm | This document | 394 +-------+---------------+---------------+ 396 Table 5 398 7. Normative References 400 [I-D.ietf-pce-segment-routing-ipv6] 401 Li, C., Negi, M., Sivabalan, S., Koldychev, M., 402 Kaladharan, P., and Y. Zhu, "PCEP Extensions for Segment 403 Routing leveraging the IPv6 data plane", Work in Progress, 404 Internet-Draft, draft-ietf-pce-segment-routing-ipv6-09, 27 405 May 2021, . 408 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 409 Requirement Levels", BCP 14, RFC 2119, 410 DOI 10.17487/RFC2119, March 1997, 411 . 413 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 414 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 415 DOI 10.17487/RFC5440, March 2009, 416 . 418 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of 419 Objective Functions in the Path Computation Element 420 Communication Protocol (PCEP)", RFC 5541, 421 DOI 10.17487/RFC5541, June 2009, 422 . 424 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 425 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 426 May 2017, . 428 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 429 and J. Hardwick, "Path Computation Element Communication 430 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 431 DOI 10.17487/RFC8664, December 2019, 432 . 434 [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, 435 H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 436 Extensions for Segment Routing", RFC 8665, 437 DOI 10.17487/RFC8665, December 2019, 438 . 440 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 441 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 442 Extensions for Segment Routing", RFC 8667, 443 DOI 10.17487/RFC8667, December 2019, 444 . 446 Appendix A. Contributors 448 Mike Koldychev 449 Cisco Systems 450 Kanata, Ontario 451 Canada 453 Email: mkoldych@cisco.com 455 Authors' Addresses 457 Alex Tokar 458 Cisco Systems, Inc. 459 Eurovea Central 3. 460 Pribinova 10 461 811 09 Bratislava 462 Slovakia 464 Email: atokar@cisco.com 466 Samuel Sidor 467 Cisco Systems, Inc. 468 Eurovea Central 3. 469 Pribinova 10 470 811 09 Bratislava 471 Slovakia 473 Email: ssidor@cisco.com 475 Shaofu Peng 476 ZTE Corporation 477 No.50 Software Avenue 478 Nanjing 479 Jiangsu, 210012 480 China 482 Email: peng.shaofu@zte.com.cn 484 Siva Sivabalan 485 Ciena 486 385 Terry Fox Drive 487 Kanata Ontario K2K 0L1 488 Canada 490 Email: msiva282@gmail.com 492 Tarek Saad 493 Juniper Networks 495 Email: tsaad@juniper.net 496 Shuping Peng 497 Huawei Technologies 498 Huawei Campus, No. 156 Beiqing Rd. 499 Beijing 500 100095 501 China 503 Email: pengshuping@huawei.com 505 Mahendra Singh Negi 506 RtBrick Inc 507 Bangalore 508 Karnataka 509 India 511 Email: mahend.ietf@gmail.com