idnits 2.17.1 draft-ietf-idr-bgp-ls-app-specific-attr-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 (March 8, 2021) is 1138 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) ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) ** Obsolete normative reference: RFC 8919 (Obsoleted by RFC 9479) ** Obsolete normative reference: RFC 8920 (Obsoleted by RFC 9492) == Outdated reference: A later version (-19) exists of draft-ietf-idr-eag-distribution-13 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-13 Summary: 3 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 K. Talaulikar, Ed. 3 Internet-Draft P. Psenak 4 Intended status: Standards Track Cisco Systems 5 Expires: September 9, 2021 J. Tantsura 6 Apstra 7 March 8, 2021 9 Application-Specific Attributes Advertisement with BGP Link-State 10 draft-ietf-idr-bgp-ls-app-specific-attr-05 12 Abstract 14 Various link attributes have been defined in link-state routing 15 protocols like OSPF and IS-IS in the context of the MPLS Traffic 16 Engineering (TE) and GMPLS. BGP Link-State (BGP-LS) extensions have 17 been defined to distribute these attributes along with other topology 18 information from these link-state routing protocols. Many of these 19 link attributes can be used for applications other than MPLS-TE or 20 GMPLS. 22 Extensions to link-state routing protocols have been defined for such 23 link attributes that enable distribution of their application- 24 specific values. This document defines extensions to BGP-LS address- 25 family to enable advertisement of these application-specific 26 attributes as a part of the topology information from the network. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 9, 2021. 45 Copyright Notice 47 Copyright (c) 2021 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 64 2. Application Specific Link Attributes TLV . . . . . . . . . . 3 65 3. Application Specific Link Attributes . . . . . . . . . . . . 5 66 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 9 68 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 9 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 70 8. Manageability Considerations . . . . . . . . . . . . . . . . 10 71 8.1. Operational Considerations . . . . . . . . . . . . . . . 10 72 8.2. Management Considerations . . . . . . . . . . . . . . . . 10 73 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 74 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 75 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 77 11.2. Informative References . . . . . . . . . . . . . . . . . 11 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 80 1. Introduction 82 Various link attributes have been defined in link-state routing 83 protocols (viz., IS-IS [RFC1195], OSPFv2 [RFC2328] and OSPFv3 84 [RFC5340] ) in the context of the MPLS traffic engineering and GMPLS. 85 All these attributes are distributed by these protocols using TLVs 86 that were originally defined for traditional MPLS Traffic Engineering 87 (i.e., using RSVP-TE [RFC3209]) or GMPLS [RFC4202] applications. 89 In recent years new applications have been introduced that have use 90 cases for many of the link attributes historically used by RSVP-TE 91 and GMPLS. Such applications include Segment Routing (SR) [RFC8402] 92 and Loop Free Alternates (LFA) [RFC5286]. This has introduced 93 ambiguity in that if a deployment includes a mix of RSVP-TE support 94 and SR support (for example) it is not possible to unambiguously 95 indicate which advertisements are to be used by RSVP-TE and which 96 advertisements are to be used by SR. If the topologies are fully 97 congruent this may not be an issue, but any incongruence leads to 98 ambiguity. An additional issue arises in cases where both 99 applications are supported on a link but the link attribute values 100 associated with each application differ. Current advertisements do 101 not support advertising application-specific values for the same 102 attribute on a specific link. IGP Flexible Algorithm 103 [I-D.ietf-lsr-flex-algo] is one such application use case that MAY 104 use application-specific link attributes. 106 [RFC8920] and [RFC8919] define extensions for OSPF and IS-IS 107 respectively that address these issues. Also, as evolution of use 108 cases for link attributes can be expected to continue in the years to 109 come, these documents define a solution that is easily extensible to 110 the introduction of new applications and new use cases. 112 BGP Link-State extensions [RFC7752] have been specified to enable 113 distribution of the link-state topology information from the IGPs to 114 an application like a controller or Path Computation Engine (PCE) via 115 BGP. The controller/PCE gets the end-to-end topology information 116 across IGP domains so it can perform path computations for use cases 117 like end-to-end traffic engineering (TE) using RSVP-TE or SR-based 118 mechanisms. A similar challenge to what was described above is hence 119 also faced by such centralized computation entities. 121 There is thus a need for BGP-LS extensions to also report link 122 attributes on a per-application basis on the same lines as introduced 123 in the link-state routing protocols. This document defines these 124 BGP-LS extensions and also covers the backward compatibility issues 125 related to existing BGP-LS deployments. 127 1.1. Requirements Language 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 131 "OPTIONAL" in this document are to be interpreted as described in BCP 132 14 [RFC2119] [RFC8174] when, and only when, they appear in all 133 capitals, as shown here. 135 2. Application Specific Link Attributes TLV 137 The BGP-LS [RFC7752] specifies the Link NLRI for advertisement of 138 links and their attributes using the BGP-LS Attribute. The 139 Application-Specific Link Attributes (ASLA) TLV is a new optional 140 top-level BGP-LS Attribute TLV that is introduced for Link NLRIs. It 141 is defined such that it may act as a container for certain existing 142 and future link attributes that require application-specific 143 definition. 145 The format of this TLV is as follows and is similar to the 146 corresponding ASLA sub-TLVs defined for OSPF and IS-IS in [RFC8920] 147 and [RFC8919] respectively. 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 | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | SABML | UDABML | Reserved | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Standard Application Identifier Bit Mask (variable) // 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | User-Defined Application Identifier Bit Mask (variable) // 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Link Attribute sub-TLVs // 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 Figure 1: Application-Specific Link Attributes TLV 165 where: 167 o Type: 1122 169 o Length: variable. 171 o SABML : Standard Application Identifier Bit Mask Length in octets. 172 The values MUST be 0, 4, or 8. If the Standard Application 173 Identifier Bit Mask is not present, the SABML MUST be set to 0. 175 o UDABML : User-Defined Application Identifier Bit Mask Length in 176 octets. The values MUST be 0, 4, or 8. If the User-Defined 177 Application Identifier Bit Mask is not present, the UDABML MUST be 178 set to 0. 180 o Standard Application Identifier Bit Mask : of size 0, 4, or 8 181 octets as indicated by the SABML. Optional set of bits, where 182 each bit represents a single standard application. The bits are 183 defined in the IANA "IGP Parameters" registries under the "Link 184 Attribute Applications" registry [RFC8919]. 186 o User-Defined Application Identifier Bit Mask : of size 0, 4, or 8 187 octets as indicated by the UDABML. Optional set of bits, where 188 each bit represents a single user-defined application. The bits 189 are not managed or assigned by IANA or any other standards body 190 and definition is left to the implementation. 192 o sub-TLVs : BGP-LS Attribute TLVs corresponding to the Link NLRI 193 that are application-specific (as specified in Section 3) are 194 included as sub-TLVs of the ASLA TLV. 196 An ASLA TLV with both the SABML and UDABML set to 0 (i.e. without any 197 application identifier bit masks) indicates that the link attribute 198 sub-TLVs that it encloses are applicable for all applications. 200 The ASLA TLV and its sub-TLVs can only be added to the BGP-LS 201 Attribute associated with the Link NLRI of the node that originates 202 the underlying IGP link attribute TLVs/sub-TLVs. The procedures for 203 originating link attributes in the ASLA TLV from underlying IGPs are 204 specified in Section 4. 206 When the node is not running any of the IGPs but running a protocol 207 like BGP, then the link attributes for the node's local links MAY be 208 originated as part of the BGP-LS Attribute using the ASLA TLV and its 209 sub-TLVs within the Link NLRI corresponding to the local node. 211 3. Application Specific Link Attributes 213 Several BGP-LS Attribute TLVs corresponding to the Link NLRI are 214 defined in BGP-LS and more may be added in the future. The following 215 types of link attributes are required to be considered as application 216 specific. 218 o those that have different values for different applications (e.g., 219 a different TE metric value used for RSVP-TE than for SR TE) 221 o those that are applicable to multiple applications but need to be 222 used only by specific application (e.g., certain SRLG values are 223 configured on a node for LFA but the same do not need to be used 224 for RSVP-TE) 226 The following table lists the currently defined BGP-LS Attributes 227 TLVs corresponding to Link NLRI that have application-specific 228 semantics. They were originally defined with semantics for RSVP-TE 229 and GMPLS applications. 231 +----------+----------------------+---------------------------------+ 232 | TLV Code | Description | Reference Document | 233 | Point | | | 234 +----------+----------------------+---------------------------------+ 235 | 1088 | Administrative group | [RFC7752] | 236 | | (color) | | 237 | 1092 | TE Metric | [RFC7752] | 238 | 1096 | SRLG | [RFC7752] | 239 | 1114 | Unidirectional link | [RFC8571] | 240 | | delay | | 241 | 1115 | Min/Max | [RFC8571] | 242 | | Unidirectional link | | 243 | | delay | | 244 | 1116 | Unidirectional link | [RFC8571] | 245 | | delay variation | | 246 | 1117 | Unidirectional | [RFC8571] | 247 | | packet loss | | 248 | 1118 | Unidirectional | [RFC8571] | 249 | | residual bandwidth | | 250 | 1119 | Unidirectional | [RFC8571] | 251 | | available bandwidth | | 252 | 1120 | Unidirectional | [RFC8571] | 253 | | bandwidth | | 254 | | utilization | | 255 | 1173 | Extended | [I-D.ietf-idr-eag-distribution] | 256 | | Administrative group | | 257 | | (color) | | 258 +----------+----------------------+---------------------------------+ 260 Table 1: BGP-LS Attribute TLVs also used as sub-TLVs of ASLA TLV 262 All the BGP-LS Attribute TLVs defined in the table above are 263 RECOMMENDED to continue to be advertised at the top-level in the BGP- 264 LS Attribute for carrying attributes specific to RSVP-TE without the 265 use of the ASLA TLV. 267 When a new link attribute is introduced, it may be thought of as 268 being specific to only a single application. However, subsequently, 269 it may be also shared by other applications and/or require 270 application-specific values. In such cases, it is RECOMMENDED to err 271 on the side of caution and define such attributes as application- 272 specific to ensure flexibility in the future. 274 BGP-LS Attribute TLVs corresponding to Link NLRI that are defined in 275 the future MUST specify if they are application-specific and hence 276 are REQUIRED to be encoded within an ASLA TLV. 278 Only application-specific link attributes need to be advertised 279 within the ASLA TLV. Link attributes that do not have application- 280 specific semantics SHOULD NOT be advertised within the ASLA TLV. 281 Receivers SHOULD ignore any non-application-specific attribute sub- 282 TLVs within the ASLA TLV. 284 When the same application-specific link attributes are advertised 285 both within the ASLA TLV and as top-level TLVs in the BGP-LS 286 Attribute, the attributes advertised within the ASLA TLV take 287 precedence for the applications indicated in the ASLA TLV encoding. 289 4. Procedures 291 The procedures described in this section apply to networks where all 292 BGP-LS originators and consumers support this specification. The 293 backward compatibility aspects and operations in deployments where 294 there are some BGP-LS originators or consumers that do not support 295 this specification are described further in Section 6. 297 The BGP-LS originator learns of the association of an application- 298 specific attribute to one or more applications from either the 299 underlying IGP protocol LSA/LSPs from which it is advertising the 300 topology information or from the local node configuration when 301 advertising attributes for the local node only. 303 The association of an application-specific link attribute with a 304 specific application context when advertising attributes for the 305 local node only (e.g., when running BGP as the only routing protocol) 306 is an implementation specific matter and outside the scope of this 307 document. 309 [RFC8920] and [RFC8919] specify the mechanisms for advertising 310 application-specific link attributes in OSPFv2/v3 and IS-IS 311 respectively. These IGP specifications also describe the backward 312 compatibility aspects and the existing RSVP-TE/GMPLS specific TLV 313 encoding mechanisms in the respective protocols. 315 A BGP-LS originator node that is advertising link-state information 316 from the underlying IGP determines the protocol encoding of 317 application-specific link attributes based on the following rules: 319 1. Application-specific link attributes received from an IGP node 320 using existing RSVP-TE/GMPLS encodings MUST be encoded using the 321 respective BGP-LS top-level TLVs listed in Table 1. 323 2. Application-specific link attributes received from an IGP node 324 using ASLA sub-TLV MUST be encoded in the BGP-LS ASLA TLV as sub- 325 TLVs. 327 3. In case of IS-IS, the following specific procedures are to be 328 followed: 330 * When application-specific link attributes are received from a 331 node with the L bit set in the ASLA sub-TLV AND application 332 bits other than RSVP-TE are set in the application bit masks 333 then the application-specific link attributes advertised in 334 the corresponding legacy IS-IS TLVs/sub-TLVs MUST be encoded 335 within the BGP-LS ASLA TLV as sub-TLVs with the application 336 bits, other than the RSVP-TE bit, copied from the IS-IS ASLA 337 sub-TLV. The link attributes advertised in the legacy IS-IS 338 TLVs/sub-TLVs are also advertised in BGP-LS top-level TLVs 339 listed in Table 1. Note that this is true regardless of 340 whether the RSVP-TE bit was set in the IS-IS ASLA TLV/sub-TLV. 342 * When the ASLA sub-TLV has the RSVP-TE application bit set, 343 then the link attributes for the corresponding ASLA sub-TLV 344 MUST be encoded using the respective BGP-LS top-level TLVs 345 listed in Table 1. 347 * [RFC8919] allows the advertisement of the Maximum Link 348 Bandwidth within an ASLA sub-TLV even though it is not an 349 application-specific attribute. However, when originating the 350 Maximum Link Bandwidth into BGP-LS, the attribute MUST be 351 encoded only in the top-level BGP-LS Maximum Link Bandwidth 352 TLV (1089) and the receiver MUST ignore them when advertised 353 within the BGP-LS ASLA TLV. 355 * [RFC8919] also allows the advertisement of the Maximum 356 Reservable Link Bandwidth and the Unreserved Bandwidth within 357 an ASLA sub-TLV even though these attributes are specific to 358 RSVP-TE application. However, when originating the Maximum 359 Reservable Link Bandwidth and Unreserved Bandwidth into BGP- 360 LS, these attributes MUST be encoded only in the BGP-LS top- 361 level Maximum Reservable Link Bandwidth TLV (1090) and 362 Unreserved Bandwidth TLV (1091) respectively and not within 363 the BGP-LS ASLA TLV. 365 These rules ensure that a BGP-LS originator performs the 366 advertisement for all application-specific link attributes from the 367 IGP nodes that support or do not support the ASLA extension. 368 Furthermore, it also ensures that the top-level BGP-LS TLVs defined 369 for RSVP-TE and GMPLS applications continue to be used for 370 advertisement of their application-specific attributes. 372 A BGP-LS consumer node would normally receive all the application- 373 specific link attributes corresponding to RSVP-TE and GMPLS 374 applications as existing top-level BGP-LS TLVs while for other 375 applications they are encoded in ASLA TLV(s) with appropriate 376 applicable bit mask setting. A BGP-LS consumer that implements this 377 specification SHOULD prefer the application-specific attribute value 378 received via sub-TLVs within the ASLA TLV over the value received via 379 the top level TLVs. 381 5. Deployment Considerations 383 SR-TE and LFA applications have been deployed in some networks using 384 the IGP link attributes defined originally for RSVP-TE as discussed 385 in [RFC8920] and [RFC8919]. The corresponding BGP-LS top-level link 386 attribute TLVs originally defined for RSVP-TE have also been 387 similarly used for SR-TE and LFA applications by BGP-LS consumers. 388 Such usage MAY continue without requiring the support of the 389 application-specific link attribute encodings described in this 390 document as long as the following conditions are met: 392 o The application is SRTE or LFA and RSVP-TE is not deployed 393 anywhere in the network 395 o The application is SRTE or LFA, RSVP-TE is deployed in the 396 network, and both the set of links on which SRTE and/or LFA 397 advertisements are required and the attribute values used by SRTE 398 and/or LFA on all such links is fully congruent with the links and 399 attribute values used by RSVP-TE 401 6. Backward Compatibility 403 The backward compatibility aspects for BGP-LS are associated with the 404 originators (i.e., nodes) and consumers (e.g., PCE, controllers, 405 applications, etc.) of the topology information. BGP-LS 406 implementations have been originating link attributes and consuming 407 them without any application-specific scoping prior to the extensions 408 specified in this document. 410 IGP backwards compatibility aspects associated with application- 411 specific link attributes for RSVP-TE, SRTE and LFA applications are 412 discussed in the Backward Compatibility sections of [RFC8920] and 413 [RFC8919]. While the backwards compatibility aspects ensure 414 compatibility of IGP advertisements, they also serve to ensure the 415 backward compatibility of the BGP-LS advertisements used by BGP-LS 416 consumers. In deployments where the BGP-LS originators or consumers 417 do not support the extensions specified in this document, the IGPs 418 need to continue to advertise link attributes intended for use by 419 SRTE and LFA applications using the RSVP-TE/GMPLS encodings. This 420 allows BGP-LS advertisements to be consistent with the behavior prior 421 to the extensions defined in this document 422 It is RECOMMENDED that nodes that support this specification are 423 selected as originators of BGP-LS information when advertising the 424 link-state information from the IGPs. 426 7. IANA Considerations 428 This document requests assignment of code-points from the registry 429 "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and 430 Attribute TLVs" based on table below which reflects the values 431 assigned via the early allocation process. The column "IS-IS TLV/ 432 Sub-TLV" defined in the registry does not require any value and 433 should be left empty. 435 +------------+------------------------------------------+----------+ 436 | Code Point | Description | Length | 437 +------------+------------------------------------------+----------+ 438 | 1122 | Application-Specific Link Attributes TLV | variable | 439 +------------+------------------------------------------+----------+ 441 8. Manageability Considerations 443 This section is structured as recommended in [RFC5706]. 445 The new protocol extensions introduced in this document augment the 446 existing IGP topology information defined in [RFC7752]. Procedures 447 and protocol extensions defined in this document do not affect the 448 BGP protocol operations and management other than as discussed in the 449 Manageability Considerations section of [RFC7752]. Specifically, the 450 malformed NLRIs attribute tests in the Fault Management section of 451 [RFC7752] now encompass the BGP-LS TLVs defined in this document. 453 8.1. Operational Considerations 455 No additional operation considerations are defined in this document. 457 8.2. Management Considerations 459 No additional management considerations are defined in this document. 461 9. Security Considerations 463 The new protocol extensions introduced in this document augment the 464 existing IGP topology information defined in [RFC7752]. Procedures 465 and protocol extensions defined in this document do not affect the 466 BGP security model other than as discussed in the Security 467 Considerations section of [RFC7752]. 469 10. Acknowledgements 471 The authors would like to thank Les Ginsberg, Baalajee S, Amalesh 472 Maity, and Acee Lindem for their review and feedback on this 473 document. 475 11. References 477 11.1. Normative References 479 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 480 Requirement Levels", BCP 14, RFC 2119, 481 DOI 10.17487/RFC2119, March 1997, 482 . 484 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 485 S. Ray, "North-Bound Distribution of Link-State and 486 Traffic Engineering (TE) Information Using BGP", RFC 7752, 487 DOI 10.17487/RFC7752, March 2016, 488 . 490 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 491 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 492 May 2017, . 494 [RFC8919] Ginsberg, L., Psenak, P., Previdi, S., Henderickx, W., and 495 J. Drake, "IS-IS Application-Specific Link Attributes", 496 RFC 8919, DOI 10.17487/RFC8919, October 2020, 497 . 499 [RFC8920] Psenak, P., Ed., Ginsberg, L., Henderickx, W., Tantsura, 500 J., and J. Drake, "OSPF Application-Specific Link 501 Attributes", RFC 8920, DOI 10.17487/RFC8920, October 2020, 502 . 504 11.2. Informative References 506 [I-D.ietf-idr-eag-distribution] 507 Wang, Z., WU, Q., Tantsura, J., and K. Talaulikar, 508 "Distribution of Traffic Engineering Extended Admin Groups 509 using BGP-LS", draft-ietf-idr-eag-distribution-13 (work in 510 progress), November 2020. 512 [I-D.ietf-lsr-flex-algo] 513 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 514 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 515 algo-13 (work in progress), October 2020. 517 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 518 dual environments", RFC 1195, DOI 10.17487/RFC1195, 519 December 1990, . 521 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 522 DOI 10.17487/RFC2328, April 1998, 523 . 525 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 526 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 527 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 528 . 530 [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions 531 in Support of Generalized Multi-Protocol Label Switching 532 (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, 533 . 535 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 536 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 537 DOI 10.17487/RFC5286, September 2008, 538 . 540 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 541 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 542 . 544 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 545 Management of New Protocols and Protocol Extensions", 546 RFC 5706, DOI 10.17487/RFC5706, November 2009, 547 . 549 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 550 Decraene, B., Litkowski, S., and R. Shakir, "Segment 551 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 552 July 2018, . 554 [RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and 555 C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of 556 IGP Traffic Engineering Performance Metric Extensions", 557 RFC 8571, DOI 10.17487/RFC8571, March 2019, 558 . 560 Authors' Addresses 561 Ketan Talaulikar (editor) 562 Cisco Systems 563 India 565 Email: ketant@cisco.com 567 Peter Psenak 568 Cisco Systems 569 Slovakia 571 Email: ppsenak@cisco.com 573 Jeff Tantsura 574 Apstra 576 Email: jefftant.ietf@gmail.com