idnits 2.17.1 draft-ietf-idr-bgp-ls-app-specific-attr-03.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 (July 25, 2020) is 1361 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) == Outdated reference: A later version (-19) exists of draft-ietf-idr-eag-distribution-12 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-08 Summary: 1 error (**), 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 3 Internet-Draft P. Psenak 4 Intended status: Standards Track Cisco Systems 5 Expires: January 26, 2021 J. Tantsura 6 Apstra 7 July 25, 2020 9 Application-Specific Attributes Advertisement with BGP Link-State 10 draft-ietf-idr-bgp-ls-app-specific-attr-03 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 January 26, 2021. 45 Copyright Notice 47 Copyright (c) 2020 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 [I-D.ietf-ospf-te-link-attr-reuse] and [I-D.ietf-isis-te-app] define 107 extensions for OSPF and IS-IS respectively that address these issues. 108 Also, as evolution of use cases for link attributes can be expected 109 to continue in the years to come, these documents define a solution 110 that is easily extensible to the introduction of new applications and 111 new use cases. 113 BGP Link-State extensions [RFC7752] have been specified to enable 114 distribution of the link-state topology information from the IGPs to 115 an application like a controller or Path Computation Engine (PCE) via 116 BGP. The controller/PCE gets the end-to-end topology information 117 across IGP domains so it can perform path computations for use cases 118 like end-to-end traffic engineering (TE) using RSVP-TE or SR-based 119 mechanisms. A similar challenge to what was described above is hence 120 also faced by such centralized computation entities. 122 There is thus a need for BGP-LS extensions to also report link 123 attributes on a per-application basis on the same lines as introduced 124 in the link-state routing protocols. This document defines these 125 BGP-LS extensions and also covers the backward compatibility issues 126 related to existing BGP-LS deployments. 128 1.1. Requirements Language 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 132 "OPTIONAL" in this document are to be interpreted as described in BCP 133 14 [RFC2119] [RFC8174] when, and only when, they appear in all 134 capitals, as shown here. 136 2. Application Specific Link Attributes TLV 138 The BGP-LS [RFC7752] specifies the Link NLRI for advertisement of 139 links and their attributes using the BGP-LS Attribute. The 140 Application-Specific Link Attributes (ASLA) TLV is a new optional 141 top-level BGP-LS Attribute TLV that is introduced for Link NLRIs. It 142 is defined such that it may act as a container for certain existing 143 and future link attributes that require application-specific 144 definition. 146 The format of this TLV is as follows and is similar to the 147 corresponding ASLA sub-TLVs defined for OSPF and IS-IS in 148 [I-D.ietf-ospf-te-link-attr-reuse] and [I-D.ietf-isis-te-app] 149 respectively. 151 0 1 2 3 152 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 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Type | Length | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | SABML | UDABML | Reserved | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Standard Application Identifier Bit Mask (variable) // 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | User-Defined Application Identifier Bit Mask (variable) // 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Link Attribute sub-TLVs // 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 Figure 1: Application-Specific Link Attributes TLV 167 where: 169 o Type: 1122 171 o Length: variable. 173 o SABML : Standard Application Identifier Bit Mask Length in octets. 174 The values MUST be 0, 4, or 8. If the Standard Application 175 Identifier Bit Mask is not present, the SABML MUST be set to 0. 177 o UDABML : User-Defined Application Identifier Bit Mask Length in 178 octets. The values MUST be 0, 4, or 8. If the User-Defined 179 Application Identifier Bit Mask is not present, the UDABML MUST be 180 set to 0. 182 o Standard Application Identifier Bit Mask : of size 0, 4, or 8 183 octets as indicated by the SABML. Optional set of bits, where 184 each bit represents a single standard application. The bits are 185 defined in the IANA "IGP Parameters" registries under the "Link 186 Attribute Applications" registry [I-D.ietf-isis-te-app]. 188 o User-Defined Application Identifier Bit Mask : of size 0, 4, or 8 189 octets as indicated by the UDABML. Optional set of bits, where 190 each bit represents a single user-defined application. The bits 191 are not managed or assigned by IANA or any other standards body 192 and definition is left to the implementation. 194 o sub-TLVs : BGP-LS Attribute TLVs corresponding to the Link NLRI 195 that are application-specific (as specified in Section 3) are 196 included as sub-TLVs of the ASLA TLV. 198 An ASLA TLV with both the SABML and UDABML set to 0 (i.e. without any 199 application identifier bit masks) indicates that the link attribute 200 sub-TLVs that it encloses are applicable for all applications. 202 The ASLA TLV and its sub-TLVs can only be added to the BGP-LS 203 Attribute associated with the Link NLRI of the node that originates 204 the underlying IGP link attribute TLVs/sub-TLVs. The procedures for 205 originating link attributes in the ASLA TLV from underlying IGPs are 206 specified in Section 4. 208 When the node is not running any of the IGPs but running a protocol 209 like BGP, then the link attributes for the node's local links MAY be 210 originated as part of the BGP-LS Attribute using the ASLA TLV and its 211 sub-TLVs within the Link NLRI corresponding to the local node. 213 3. Application Specific Link Attributes 215 Several BGP-LS Attribute TLVs corresponding to the Link NLRI are 216 defined in BGP-LS and more may be added in the future. The following 217 types of link attributes are required to be considered as application 218 specific. 220 o those that have different values for different applications (e.g., 221 a different TE metric value used for RSVP-TE than for SR TE) 223 o those that are applicable to multiple applications but need to be 224 used only by specific application (e.g., certain SRLG values are 225 configured on a node for LFA but the same do not need to be used 226 for RSVP-TE) 228 The following table lists the currently defined BGP-LS Attributes 229 TLVs corresponding to Link NLRI that have application-specific 230 semantics. They were originally defined with semantics for RSVP-TE 231 and GMPLS applications. 233 +----------+----------------------+---------------------------------+ 234 | TLV Code | Description | Reference Document | 235 | Point | | | 236 +----------+----------------------+---------------------------------+ 237 | 1088 | Administrative group | [RFC7752] | 238 | | (color) | | 239 | 1092 | TE Metric | [RFC7752] | 240 | 1096 | SRLG | [RFC7752] | 241 | 1114 | Unidirectional link | [RFC8571] | 242 | | delay | | 243 | 1115 | Min/Max | [RFC8571] | 244 | | Unidirectional link | | 245 | | delay | | 246 | 1116 | Unidirectional link | [RFC8571] | 247 | | delay variation | | 248 | 1117 | Unidirectional | [RFC8571] | 249 | | packet loss | | 250 | 1118 | Unidirectional | [RFC8571] | 251 | | residual bandwidth | | 252 | 1119 | Unidirectional | [RFC8571] | 253 | | available bandwidth | | 254 | 1120 | Unidirectional | [RFC8571] | 255 | | bandwidth | | 256 | | utilization | | 257 | 1173 | Extended | [I-D.ietf-idr-eag-distribution] | 258 | | Administrative group | | 259 | | (color) | | 260 +----------+----------------------+---------------------------------+ 262 Table 1: BGP-LS Attribute TLVs also used as sub-TLVs of ASLA TLV 264 All the BGP-LS Attribute TLVs defined in the table above are 265 RECOMMENDED to continue to be advertised at the top-level in the BGP- 266 LS Attribute for carrying attributes specific to RSVP-TE without the 267 use of the ASLA TLV. 269 When a new link attribute is introduced, it may be thought of as 270 being specific to only a single application. However, subsequently, 271 it may be also shared by other applications and/or require 272 application-specific values. In such cases, it is RECOMMENDED to err 273 on the side of caution and define such attributes as application- 274 specific to ensure flexibility in the future. 276 BGP-LS Attribute TLVs corresponding to Link NLRI that are defined in 277 the future MUST specify if they are application-specific and hence 278 are REQUIRED to be encoded within an ASLA TLV. 280 Only application-specific link attributes need to be advertised 281 within the ASLA TLV. Link attributes that do not have application- 282 specific semantics SHOULD NOT be advertised within the ASLA TLV. 283 Receivers SHOULD ignore any non-application-specific attribute sub- 284 TLVs within the ASLA TLV. 286 4. Procedures 288 The procedures described in this section apply to networks where all 289 BGP-LS originators and consumers support this specification. The 290 backward compatibility aspects and operations in deployments where 291 there are some BGP-LS originators or consumers that do not support 292 this specification are described further in Section 6. 294 The BGP-LS originator learns of the association of an application- 295 specific attribute to one or more applications from either the 296 underlying IGP protocol LSA/LSPs from which it is advertising the 297 topology information or from the local node configuration when 298 advertising attributes for the local node only. 300 The association of an application-specific link attribute with a 301 specific application context when advertising attributes for the 302 local node only (e.g., when running BGP as the only routing protocol) 303 is an implementation specific matter and outside the scope of this 304 document. 306 [I-D.ietf-ospf-te-link-attr-reuse] and [I-D.ietf-isis-te-app] specify 307 the mechanisms for advertising application-specific link attributes 308 in OSPFv2/v3 and IS-IS respectively. These IGP specifications also 309 describe the backward compatibility aspects and the existing RSVP-TE/ 310 GMPLS specific TLV encoding mechanisms in the respective protocols. 312 A BGP-LS originator node that is advertising link-state information 313 from the underlying IGP determines the protocol encoding of 314 application-specific link attributes based on the following rules: 316 1. Application-specific link attributes received from an IGP node 317 using existing RSVP-TE/GMPLS encodings MUST be encoded using the 318 respective BGP-LS top-level TLVs listed in Table 1. 320 2. Application-specific link attributes received from an IGP node 321 using ASLA sub-TLV MUST be encoded in the BGP-LS ASLA TLV as sub- 322 TLVs. 324 3. In case of IS-IS, the following specific procedures are to be 325 followed: 327 * When application-specific link attributes are received from a 328 node with the L bit set in the ASLA sub-TLV AND application 329 bits other than RSVP-TE are set in the application bit masks 330 then the application-specific link attributes advertised in 331 the corresponding legacy IS-IS TLVs/sub-TLVs MUST be encoded 332 within the BGP-LS ASLA TLV as sub-TLVs with the application 333 bits, other than the RSVP-TE bit, copied from the IS-IS ASLA 334 sub-TLV. The link attributes advertised in the legacy IS-IS 335 TLVs/sub-TLVs are also advertised in BGP-LS top-level TLVs 336 listed in Table 1. Note that this is true regardless of 337 whether the RSVP-TE bit was set in the IS-IS ASLA TLV/sub-TLV. 339 * When the ASLA sub-TLV has the RSVP-TE application bit set, 340 then the link attributes for the corresponding ASLA sub-TLV 341 MUST be encoded using the respective BGP-LS top-level TLVs 342 listed in Table 1. 344 * [I-D.ietf-isis-te-app] allows the advertisement of the Maximum 345 Link Bandwidth within an ASLA sub-TLV even though it is not an 346 application-specific attribute. However, when originating the 347 Maximum Link Bandwidth into BGP-LS, the attribute MUST be 348 encoded only in the top-level BGP-LS Maximum Link Bandwidth 349 TLV (1089) and not within the BGP-LS ASLA TLV. 351 * [I-D.ietf-isis-te-app] also allows the advertisement of the 352 Maximum Reservable Link Bandwidth and the Unreserved Bandwidth 353 within an ASLA sub-TLV even though these attributes are 354 specific to RSVP-TE application. However, when originating 355 the Maximum Reservable Link Bandwidth and Unreserved Bandwidth 356 into BGP-LS, these attributes MUST be encoded only in the BGP- 357 LS top-level Maximum Reservable Link Bandwidth TLV (1090) and 358 Unreserved Bandwidth TLV (1091) respectively and not within 359 the BGP-LS ASLA TLV. 361 These rules ensure that a BGP-LS originator performs the 362 advertisement for all application-specific link attributes from the 363 IGP nodes that support or do not support the ASLA extension. 364 Furthermore, it also ensures that the top-level BGP-LS TLVs defined 365 for RSVP-TE and GMPLS applications continue to be used for 366 advertisement of their application-specific attributes. 368 A BGP-LS consumer node would normally receive all the application- 369 specific link attributes corresponding to RSVP-TE and GMPLS 370 applications as existing top-level BGP-LS TLVs while for other 371 applications they are encoded in ASLA TLV(s) with appropriate 372 applicable bit mask setting. A BGP-LS consumer that implements this 373 specification SHOULD prefer the application-specific attribute value 374 received via sub-TLVs within the ASLA TLV over the value received via 375 the top level TLVs. 377 5. Deployment Considerations 379 SR-TE and LFA applications have been deployed in some networks using 380 the IGP link attributes defined originally for RSVP-TE as discussed 381 in [I-D.ietf-ospf-te-link-attr-reuse] and [I-D.ietf-isis-te-app]. 382 The corresponding BGP-LS top-level link attribute TLVs originally 383 defined for RSVP-TE have also been similarly used for SR-TE and LFA 384 applications by BGP-LS consumers. Such usage MAY continue without 385 requiring the support of the application-specific link attribute 386 encodings described in this document as long as the following 387 conditions are met: 389 o The application is SRTE or LFA and RSVP-TE is not deployed 390 anywhere in the network 392 o The application is SRTE or LFA, RSVP-TE is deployed in the 393 network, and both the set of links on which SRTE and/or LFA 394 advertisements are required and the attribute values used by SRTE 395 and/or LFA on all such links is fully congruent with the links and 396 attribute values used by RSVP-TE 398 6. Backward Compatibility 400 The backward compatibility aspects for BGP-LS are associated with the 401 originators (i.e., nodes) and consumers (e.g., PCE, controllers, 402 applications, etc.) of the topology information. BGP-LS 403 implementations have been originating link attributes and consuming 404 them without any application-specific scoping prior to the extensions 405 specified in this document. 407 IGP backwards compatibility aspects associated with application- 408 specific link attributes for RSVP-TE, SRTE and LFA applications are 409 discussed in the Backward Compatibility sections of 410 [I-D.ietf-ospf-te-link-attr-reuse] and [I-D.ietf-isis-te-app]. While 411 the backwards compatibility aspects ensure compatibility of IGP 412 advertisements, they also serve to ensure the backward compatibility 413 of the BGP-LS advertisements used by BGP-LS consumers. In 414 deployments where the BGP-LS originators or consumers do not support 415 the extensions specified in this document, the IGPs need to continue 416 to advertise link attributes intended for use by SRTE and LFA 417 applications using the RSVP-TE/GMPLS encodings. This allows BGP-LS 418 advertisements to be consistent with the behavior prior to the 419 extensions defined in this document 420 It is RECOMMENDED that nodes that support this specification are 421 selected as originators of BGP-LS information when advertising the 422 link-state information from the IGPs. 424 7. IANA Considerations 426 This document requests assignment of code-points from the registry 427 "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and 428 Attribute TLVs" based on table below which reflects the values 429 assigned via the early allocation process. The column "IS-IS TLV/ 430 Sub-TLV" defined in the registry does not require any value and 431 should be left empty. 433 +------------+------------------------------------------+----------+ 434 | Code Point | Description | Length | 435 +------------+------------------------------------------+----------+ 436 | 1122 | Application-Specific Link Attributes TLV | variable | 437 +------------+------------------------------------------+----------+ 439 8. Manageability Considerations 441 This section is structured as recommended in [RFC5706]. 443 The new protocol extensions introduced in this document augment the 444 existing IGP topology information defined in [RFC7752]. Procedures 445 and protocol extensions defined in this document do not affect the 446 BGP protocol operations and management other than as discussed in the 447 Manageability Considerations section of [RFC7752]. Specifically, the 448 malformed NLRIs attribute tests in the Fault Management section of 449 [RFC7752] now encompass the BGP-LS TLVs defined in this document. 451 8.1. Operational Considerations 453 No additional operation considerations are defined in this document. 455 8.2. Management Considerations 457 No additional management considerations are defined in this document. 459 9. Security Considerations 461 The new protocol extensions introduced in this document augment the 462 existing IGP topology information defined in [RFC7752]. Procedures 463 and protocol extensions defined in this document do not affect the 464 BGP security model other than as discussed in the Security 465 Considerations section of [RFC7752]. 467 10. Acknowledgements 469 The authors would like to thank Les Ginsberg, Baalajee S, Amalesh 470 Maity, and Acee Lindem for their review and feedback on this 471 document. 473 11. References 475 11.1. Normative References 477 [I-D.ietf-isis-te-app] 478 Ginsberg, L., Psenak, P., Previdi, S., Henderickx, W., and 479 J. Drake, "IS-IS Application-Specific Link Attributes", 480 draft-ietf-isis-te-app-19 (work in progress), June 2020. 482 [I-D.ietf-ospf-te-link-attr-reuse] 483 Psenak, P., Ginsberg, L., Henderickx, W., Tantsura, J., 484 and J. Drake, "OSPF Application-Specific Link Attributes", 485 draft-ietf-ospf-te-link-attr-reuse-16 (work in progress), 486 June 2020. 488 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 489 Requirement Levels", BCP 14, RFC 2119, 490 DOI 10.17487/RFC2119, March 1997, 491 . 493 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 494 S. Ray, "North-Bound Distribution of Link-State and 495 Traffic Engineering (TE) Information Using BGP", RFC 7752, 496 DOI 10.17487/RFC7752, March 2016, 497 . 499 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 500 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 501 May 2017, . 503 11.2. Informative References 505 [I-D.ietf-idr-eag-distribution] 506 Wang, Z., WU, Q., Tantsura, J., and K. Talaulikar, 507 "Distribution of Traffic Engineering Extended Admin Groups 508 using BGP-LS", draft-ietf-idr-eag-distribution-12 (work in 509 progress), May 2020. 511 [I-D.ietf-lsr-flex-algo] 512 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 513 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 514 algo-08 (work in progress), July 2020. 516 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 517 dual environments", RFC 1195, DOI 10.17487/RFC1195, 518 December 1990, . 520 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 521 DOI 10.17487/RFC2328, April 1998, 522 . 524 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 525 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 526 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 527 . 529 [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions 530 in Support of Generalized Multi-Protocol Label Switching 531 (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, 532 . 534 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 535 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 536 DOI 10.17487/RFC5286, September 2008, 537 . 539 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 540 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 541 . 543 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 544 Management of New Protocols and Protocol Extensions", 545 RFC 5706, DOI 10.17487/RFC5706, November 2009, 546 . 548 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 549 Decraene, B., Litkowski, S., and R. Shakir, "Segment 550 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 551 July 2018, . 553 [RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and 554 C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of 555 IGP Traffic Engineering Performance Metric Extensions", 556 RFC 8571, DOI 10.17487/RFC8571, March 2019, 557 . 559 Authors' Addresses 560 Ketan Talaulikar 561 Cisco Systems 562 India 564 Email: ketant@cisco.com 566 Peter Psenak 567 Cisco Systems 568 Slovakia 570 Email: ppsenak@cisco.com 572 Jeff Tantsura 573 Apstra 575 Email: jefftant.ietf@gmail.com