idnits 2.17.1 draft-ietf-idr-bgp-ls-app-specific-attr-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 : ---------------------------------------------------------------------------- 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 (November 16, 2019) is 1613 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 (-19) exists of draft-ietf-isis-te-app-09 == Outdated reference: A later version (-16) exists of draft-ietf-ospf-te-link-attr-reuse-10 ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) == Outdated reference: A later version (-19) exists of draft-ietf-idr-eag-distribution-09 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-04 Summary: 1 error (**), 0 flaws (~~), 5 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: May 19, 2020 J. Tantsura 6 Apstra 7 November 16, 2019 9 Application Specific Attributes Advertisement with BGP Link-State 10 draft-ietf-idr-bgp-ls-app-specific-attr-01 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 which 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 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 32 "OPTIONAL" in this document are to be interpreted as described in BCP 33 14 [RFC2119] [RFC8174] when, and only when, they appear in all 34 capitals, as shown here. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on May 19, 2020. 53 Copyright Notice 55 Copyright (c) 2019 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 71 2. Application Specific Link Attributes TLV . . . . . . . . . . 3 72 3. Application Specific Link Attributes . . . . . . . . . . . . 5 73 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 9 75 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 9 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 77 8. Manageability Considerations . . . . . . . . . . . . . . . . 10 78 8.1. Operational Considerations . . . . . . . . . . . . . . . 10 79 8.2. Management Considerations . . . . . . . . . . . . . . . . 10 80 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 81 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 82 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 84 11.2. Informative References . . . . . . . . . . . . . . . . . 11 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 87 1. Introduction 89 Various link attributes have been defined in link-state routing 90 protocols (viz. IS-IS [RFC1195], OSPFv2 [RFC2328] and OSPFv3 91 [RFC5340] ) in the context of the MPLS traffic engineering and GMPLS. 92 All these attributes are distributed by these protocols using TLVs 93 that were originally defined for traditional MPLS Traffic Engineering 94 (i.e. using RSVP-TE [RFC3209]) or GMPLS [RFC4202] applications. 96 In recent years new applications have been introduced which have use 97 cases for many of the link attributes historically used by RSVP-TE 98 and GMPLS. Such applications include Segment Routing (SR) [RFC8402] 99 and Loop Free Alternates (LFA) [RFC5286]. This has introduced 100 ambiguity in that if a deployment includes a mix of RSVP-TE support 101 and SR support (for example) it is not possible to unambiguously 102 indicate which advertisements are to be used by RSVP-TE and which 103 advertisements are to be used by SR. If the topologies are fully 104 congruent this may not be an issue, but any incongruence leads to 105 ambiguity. An additional issue arises in cases where both 106 applications are supported on a link but the link attribute values 107 associated with each application differ. Current advertisements do 108 not support advertising application specific values for the same 109 attribute on a specific link. IGP Flexible Algorithm 110 [I-D.ietf-lsr-flex-algo] is one such application use-case that MAY 111 use application specific link attributes. 113 [I-D.ietf-ospf-te-link-attr-reuse] and [I-D.ietf-isis-te-app] define 114 extensions for OSPF and IS-IS respectively which address these 115 issues. Also, as evolution of use cases for link attributes can be 116 expected to continue in the years to come, these documents define a 117 solution which is easily extensible to the introduction of new 118 applications and new use cases. 120 BGP Link-State extensions [RFC7752] have been specified to enable 121 distribution of the link-state topology information from the IGPs to 122 an application like a controller or Path Computation Engine (PCE) via 123 BGP. The controller/PCE gets the end to end topology information 124 across IGP domains so it can perform path computations for use-cases 125 like end to end traffic engineering (TE) using RSVP-TE or SR based 126 mechanisms. A similar challenge to what was describe above is hence 127 also faced by such centralized computation entities. 129 There is thus a need for BGP-LS extensions to also report link 130 attributes on a per application basis on the same lines as introduced 131 in the link-state routing protocols. This document defines these 132 BGP-LS extensions and also covers the backward compatibility issues 133 related to existing BGP-LS deployments. 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 to be defined in an 143 application specific scope. 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 147 [I-D.ietf-ospf-te-link-attr-reuse] and [I-D.ietf-isis-te-app] 148 respectively. 150 0 1 2 3 151 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 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | Type | Length | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | SABML | UDABML | Reserved | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Standard Application Bit-Mask (variable) // 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | User Defined Application Bit-Mask (variable) // 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Link Attribute sub-TLVs // 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 Figure 1: Application Specific Link Attributes TLV 166 where: 168 o Type: 1122 170 o Length: variable. 172 o SABML : 1 octet value carrying the Standard Application Bit-Mask 173 Length in multiples of 4 octets. If the Standard Application Bit- 174 Mask is not present, the SABML MUST be set to 0. 176 o UDABML : 1 octet value carrying the User Defined Application Bit- 177 Mask Length in multiples of 4 octets. If the User Defined 178 Application Bit-Mask is not present, the UDABML MUST be set to 0. 180 o Standard Application Bit-Mask : variable size in multiple of 4 181 octets and optional set of bits, where each bit represents a 182 single standard application. The bits are defined in the IANA 183 "IGP Parameters" registries under the "Link Attribute 184 Applications" registry [I-D.ietf-isis-te-app]. 186 o User Defined Application Bit-Mask : variable size in multiple of 4 187 octets and optional set of bits, where each bit represents a 188 single user defined application. The bits are not managed or 189 assigned by IANA or any other standards body and are left to 190 implementation specifics. 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 specific bitmasks) indicate that the link attribute sub- 198 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 is 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 which 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 be continued to be used at the top-level in the BGP-LS 264 Attribute for carrying attributes specific to RSVP-TE without the use 265 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, down the line, 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 which 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 4. Procedures 286 The procedures described in this section apply to networks where all 287 BGP-LS originators and consumers support this specification. The 288 backward compatibility aspects and operations in deployments where 289 there are some BGP-LS originators or consumers that do not support 290 this specification is described further in Section 6. 292 The BGP-LS originator learns of the association of an application 293 specific attribute to one or more set of applications from either the 294 underlying IGP protocol LSA/LSPs from which it is sourcing the 295 topology information or from the local node configuration when 296 advertising attributes for the local node only. 298 The association of an application specific link attribute with a 299 specific application context when advertising attributes for the 300 local node only (e.g. when running BGP as the only routing protocol) 301 is an implementation specific matter and outside the scope of this 302 document. 304 [I-D.ietf-ospf-te-link-attr-reuse] and [I-D.ietf-isis-te-app] specify 305 the mechanisms for flooding of application specific link attributes 306 in OSPFv2/v3 and IS-IS respectively. These IGP specifications also 307 describe the backward compatibility aspects and the existing RSVP-TE/ 308 GMPLS specific TLV encoding mechanisms in respective protocols. 310 A BGP-LS originator node which is sourcing link-state information 311 from the underlying IGP determines the mechanism of flooding 312 application specific link attributes based on the following rules: 314 1. Application specific link attributes received from an IGP node 315 using existing RSVP-TE/GMPLS encodings MUST be encoded using the 316 respective BGP-LS top-level TLVs listed in Table 1. 318 2. Application specific link attributes received from an IGP node 319 using ASLA sub-TLV MUST be encoded in the BGP-LS ASLA TLV as sub- 320 TLVs. 322 3. In case of IS-IS, the following specific procedures are to be 323 followed: 325 * When application specific link attributes are received from a 326 node with the L bit set in the ASLA sub-TLV AND application 327 bits other than RSVP-TE are set in the application bitmasks 328 then the application specific link attributes advertised in 329 the corresponding legacy IS-IS TLVs/sub-TLVs MUST be encoded 330 within the BGP-LS ASLA TLV as sub-TLVs with the application 331 bits, other than the RSVP-TE bit, copied from the IS-IS ASLA 332 sub-TLV. The link attributes advertised in the legacy IS-IS 333 TLVs/sub-TLVs are also advertised in BGP-LS top-level TLVs 334 listed in Table 1. Note this is true regardless of whether 335 the RSVP-TE bit was set in the IS-IS ASLA TLV/sub-TLV. 337 * When the ASLA sub-TLV has the RSVP-TE application bit set then 338 the link attributes from such an ASLA sub-TLV MUST be encoded 339 using the respective BGP-LS top-level TLVs listed in Table 1. 341 * [I-D.ietf-isis-te-app] allows the advertisement of the Maximum 342 Link Bandwidth within an ASLA sub-TLV even though it is not an 343 application specific attribute. However, when originating the 344 Maximum Link Bandwidth into BGP-LS, the attribute MUST be 345 encoded only in the top-level Maximum Link Bandwidth TLV 1089 346 of BGP-LS and not within the BGP-LS ASLA TLV. 348 * [I-D.ietf-isis-te-app] also allows the advertisement of the 349 Maximum Reservable Link Bandwidth and the Unreserved Bandwidth 350 within an ASLA sub-TLV even though these attributes are 351 specific to RSVP-TE application. However, when originating 352 the Maximum Reservable Link Bandwidth and Unreserved Bandwidth 353 into BGP-LS, these attribute MUST be encoded only in the top- 354 level Maximum Reservable Link Bandwidth TLV 1090 and 355 Unreserved Bandwidth TLV 1091 respectively of BGP-LS and not 356 within the BGP-LS ASLA TLV. 358 These rules ensure that a BGP-LS originator performs the 359 advertisement for all application specific link attributes from the 360 IGP nodes that support or do not support the ASLA extension. 361 Furthermore, it also ensures that the top-level BGP-LS TLVs defined 362 for RSVP-TE and GMPLS applications continue to be used for 363 advertisement of their application specific attributes. 365 A BGP-LS consumer node would normally get all application specific 366 link attributes corresponding to RSVP-TE and GMPLS applications as 367 existing top-level BGP-LS TLVs while for other applications they are 368 encoded in ASLA TLV(s) with appropriate applicable bit mask setting. 369 A BGP-LS consumer which implements this specification SHOULD prefer 370 the application specific attribute value received via sub-TLVs within 371 the ASLA TLV over the value received via the top level TLVs. 373 5. Deployment Considerations 375 SR-TE and LFA applications have been deployed in some networks using 376 the IGP link attributes defined originally for RSVP-TE as discussed 377 in [I-D.ietf-ospf-te-link-attr-reuse] and [I-D.ietf-isis-te-app]. 378 The corresponding BGP-LS top-level link attribute TLVs originally 379 defined for RSVP-TE have also been similarly used for SR-TE and LFA 380 applications by BGP-LS consumers. Such usage MAY continue without 381 requiring the support of the application specific link attribute 382 encoding mechanism described in this document as long as the 383 following conditions are met: 385 o The application is SRTE or LFA and RSVP-TE is not deployed 386 anywhere in the network 388 o The application is SRTE or LFA, RSVP-TE is deployed in the 389 network, and both the set of links on which SRTE and/or LFA 390 advertisements are required and the attribute values used by SRTE 391 and/or LFA on all such links is fully congruent with the links and 392 attribute values used by RSVP-TE 394 6. Backward Compatibility 396 The backward compatibility aspects for BGP-LS are associated with the 397 originators (i.e. nodes) and consumers (e.g. PCE, controllers, 398 applications, etc.) of the topology information. BGP-LS 399 implementations have been originating link attributes and consuming 400 them without any application specific scoping prior to the extensions 401 specified in this document. 403 IGP backwards compatibility aspects associated with application 404 specific link attributes for RSVP-TE, SRTE and LFA applications are 405 discussed in the Backward Compatibility sections of 406 [I-D.ietf-ospf-te-link-attr-reuse] and [I-D.ietf-isis-te-app]. 407 Although the backwards compatibility aspects ensure compatibility of 408 IGP advertisements they also serve to ensure the backward 409 compatibility of the BGP-LS advertisements used by BGP-LS consumers. 410 In deployments where the BGP-LS originators or consumers do not 411 support the extensions specified in this document, the IGPs need to 412 continue to advertise link attributes intended for use by SRTE and 413 LFA applications using the RSVP-TE/GMPLS encodings. This allows BGP- 414 LS advertisements to be consistent with the behaviour prior to the 415 extensions defined in this document 417 It is RECOMMENDED that the nodes which support this specification are 418 selected as originators of BGP-LS information when sourcing the link- 419 state information from the IGPs. 421 7. IANA Considerations 423 This document requests assigning code-points from the registry "BGP- 424 LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute 425 TLVs" based on table below which reflects the values assigned via the 426 early allocation process. The column "IS-IS TLV/Sub-TLV" defined in 427 the registry does not require any value and should be left empty. 429 +------------+------------------------------------------+----------+ 430 | Code Point | Description | Length | 431 +------------+------------------------------------------+----------+ 432 | 1122 | Application Specific Link Attributes TLV | variable | 433 +------------+------------------------------------------+----------+ 435 8. Manageability Considerations 437 This section is structured as recommended in [RFC5706]. 439 The new protocol extensions introduced in this document augment the 440 existing IGP topology information that was distributed via [RFC7752]. 441 Procedures and protocol extensions defined in this document do not 442 affect the BGP protocol operations and management other than as 443 discussed in the Manageability Considerations section of [RFC7752]. 444 Specifically, the malformed NLRIs attribute tests in the Fault 445 Management section of [RFC7752] now encompass the new TLVs for the 446 BGP-LS NLRI in this document. 448 8.1. Operational Considerations 450 No additional operation considerations are defined in this document. 452 8.2. Management Considerations 454 No additional management considerations are defined in this document. 456 9. Security Considerations 458 The new protocol extensions introduced in this document augment the 459 existing IGP topology information that was distributed via [RFC7752]. 460 Procedures and protocol extensions defined in this document do not 461 affect the BGP security model other than as discussed in the Security 462 Considerations section of [RFC7752]. 464 10. Acknowledgements 466 The authors would like to thank Les Ginsberg, Baalajee S and Amalesh 467 Maity for their review and feedback on this document. 469 11. References 471 11.1. Normative References 473 [I-D.ietf-isis-te-app] 474 Ginsberg, L., Psenak, P., Previdi, S., Henderickx, W., and 475 J. Drake, "IS-IS TE Attributes per application", draft- 476 ietf-isis-te-app-09 (work in progress), October 2019. 478 [I-D.ietf-ospf-te-link-attr-reuse] 479 Psenak, P., Ginsberg, L., Henderickx, W., Tantsura, J., 480 and J. Drake, "OSPF Link Traffic Engineering Attribute 481 Reuse", draft-ietf-ospf-te-link-attr-reuse-10 (work in 482 progress), October 2019. 484 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 485 Requirement Levels", BCP 14, RFC 2119, 486 DOI 10.17487/RFC2119, March 1997, 487 . 489 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 490 S. Ray, "North-Bound Distribution of Link-State and 491 Traffic Engineering (TE) Information Using BGP", RFC 7752, 492 DOI 10.17487/RFC7752, March 2016, 493 . 495 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 496 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 497 May 2017, . 499 11.2. Informative References 501 [I-D.ietf-idr-eag-distribution] 502 Wang, Z., WU, Q., and J. Tantsura, "Distribution of MPLS- 503 TE Extended admin Group Using BGP", draft-ietf-idr-eag- 504 distribution-09 (work in progress), October 2019. 506 [I-D.ietf-lsr-flex-algo] 507 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 508 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 509 algo-04 (work in progress), September 2019. 511 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 512 dual environments", RFC 1195, DOI 10.17487/RFC1195, 513 December 1990, . 515 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 516 DOI 10.17487/RFC2328, April 1998, 517 . 519 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 520 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 521 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 522 . 524 [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions 525 in Support of Generalized Multi-Protocol Label Switching 526 (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, 527 . 529 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 530 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 531 DOI 10.17487/RFC5286, September 2008, 532 . 534 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 535 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 536 . 538 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 539 Management of New Protocols and Protocol Extensions", 540 RFC 5706, DOI 10.17487/RFC5706, November 2009, 541 . 543 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 544 Decraene, B., Litkowski, S., and R. Shakir, "Segment 545 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 546 July 2018, . 548 [RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and 549 C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of 550 IGP Traffic Engineering Performance Metric Extensions", 551 RFC 8571, DOI 10.17487/RFC8571, March 2019, 552 . 554 Authors' Addresses 555 Ketan Talaulikar 556 Cisco Systems 558 Email: ketant@cisco.com 560 Peter Psenak 561 Cisco Systems 562 Slovakia 564 Email: ppsenak@cisco.com 566 Jeff Tantsura 567 Apstra 569 Email: jefftant.ietf@gmail.com