idnits 2.17.1 draft-ietf-idr-bgp-ls-app-specific-attr-02.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 (May 18, 2020) is 1439 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-12 == Outdated reference: A later version (-16) exists of draft-ietf-ospf-te-link-attr-reuse-11 ** 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-07 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: November 19, 2020 J. Tantsura 6 Apstra 7 May 18, 2020 9 Application Specific Attributes Advertisement with BGP Link-State 10 draft-ietf-idr-bgp-ls-app-specific-attr-02 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 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 November 19, 2020. 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 which 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 which address these 108 issues. Also, as evolution of use cases for link attributes can be 109 expected to continue in the years to come, these documents define a 110 solution which is easily extensible to the introduction of new 111 applications and 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 describe 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 to be defined in an 144 application specific scope. 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 SABML. Optional set of bits, where each 184 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 UDABML. Optional set of bits, where each 190 bit represents a single user defined application. The bits are 191 not managed or assigned by IANA or any other standards body and 192 are left to implementation specifics. 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 bitmasks) 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 is 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 which 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 be continued to be used at the top-level in the BGP-LS 266 Attribute for carrying attributes specific to RSVP-TE without the use 267 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, down the line, 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 which 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 is described further in Section 6. 294 The BGP-LS originator learns of the association of an application 295 specific attribute to one or more set of applications from either the 296 underlying IGP protocol LSA/LSPs from which it is sourcing 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 flooding of 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 respective protocols. 312 A BGP-LS originator node which is sourcing link-state information 313 from the underlying IGP determines the mechanism of flooding 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 bitmasks 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 this is true regardless of whether 337 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 then 340 the link attributes from such an ASLA sub-TLV MUST be encoded 341 using the respective BGP-LS top-level TLVs listed in Table 1. 343 * [I-D.ietf-isis-te-app] allows the advertisement of the Maximum 344 Link Bandwidth within an ASLA sub-TLV even though it is not an 345 application specific attribute. However, when originating the 346 Maximum Link Bandwidth into BGP-LS, the attribute MUST be 347 encoded only in the top-level Maximum Link Bandwidth TLV 1089 348 of BGP-LS and not within the BGP-LS ASLA TLV. 350 * [I-D.ietf-isis-te-app] also allows the advertisement of the 351 Maximum Reservable Link Bandwidth and the Unreserved Bandwidth 352 within an ASLA sub-TLV even though these attributes are 353 specific to RSVP-TE application. However, when originating 354 the Maximum Reservable Link Bandwidth and Unreserved Bandwidth 355 into BGP-LS, these attribute MUST be encoded only in the top- 356 level Maximum Reservable Link Bandwidth TLV 1090 and 357 Unreserved Bandwidth TLV 1091 respectively of BGP-LS and not 358 within the BGP-LS ASLA TLV. 360 These rules ensure that a BGP-LS originator performs the 361 advertisement for all application specific link attributes from the 362 IGP nodes that support or do not support the ASLA extension. 363 Furthermore, it also ensures that the top-level BGP-LS TLVs defined 364 for RSVP-TE and GMPLS applications continue to be used for 365 advertisement of their application specific attributes. 367 A BGP-LS consumer node would normally get all application specific 368 link attributes corresponding to RSVP-TE and GMPLS applications as 369 existing top-level BGP-LS TLVs while for other applications they are 370 encoded in ASLA TLV(s) with appropriate applicable bit mask setting. 371 A BGP-LS consumer which implements this specification SHOULD prefer 372 the application specific attribute value received via sub-TLVs within 373 the ASLA TLV over the value received via the top level TLVs. 375 5. Deployment Considerations 377 SR-TE and LFA applications have been deployed in some networks using 378 the IGP link attributes defined originally for RSVP-TE as discussed 379 in [I-D.ietf-ospf-te-link-attr-reuse] and [I-D.ietf-isis-te-app]. 380 The corresponding BGP-LS top-level link attribute TLVs originally 381 defined for RSVP-TE have also been similarly used for SR-TE and LFA 382 applications by BGP-LS consumers. Such usage MAY continue without 383 requiring the support of the application specific link attribute 384 encoding mechanism described in this document as long as the 385 following conditions are met: 387 o The application is SRTE or LFA and RSVP-TE is not deployed 388 anywhere in the network 390 o The application is SRTE or LFA, RSVP-TE is deployed in the 391 network, and both the set of links on which SRTE and/or LFA 392 advertisements are required and the attribute values used by SRTE 393 and/or LFA on all such links is fully congruent with the links and 394 attribute values used by RSVP-TE 396 6. Backward Compatibility 398 The backward compatibility aspects for BGP-LS are associated with the 399 originators (i.e. nodes) and consumers (e.g. PCE, controllers, 400 applications, etc.) of the topology information. BGP-LS 401 implementations have been originating link attributes and consuming 402 them without any application specific scoping prior to the extensions 403 specified in this document. 405 IGP backwards compatibility aspects associated with application 406 specific link attributes for RSVP-TE, SRTE and LFA applications are 407 discussed in the Backward Compatibility sections of 408 [I-D.ietf-ospf-te-link-attr-reuse] and [I-D.ietf-isis-te-app]. 409 Although the backwards compatibility aspects ensure compatibility of 410 IGP advertisements they also serve to ensure the backward 411 compatibility of the BGP-LS advertisements used by BGP-LS consumers. 412 In deployments where the BGP-LS originators or consumers do not 413 support the extensions specified in this document, the IGPs need to 414 continue to advertise link attributes intended for use by SRTE and 415 LFA applications using the RSVP-TE/GMPLS encodings. This allows BGP- 416 LS advertisements to be consistent with the behaviour prior to the 417 extensions defined in this document 419 It is RECOMMENDED that the nodes which support this specification are 420 selected as originators of BGP-LS information when sourcing the link- 421 state information from the IGPs. 423 7. IANA Considerations 425 This document requests assigning code-points from the registry "BGP- 426 LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute 427 TLVs" based on table below which reflects the values assigned via the 428 early allocation process. The column "IS-IS TLV/Sub-TLV" defined in 429 the registry does not require any value and should be left empty. 431 +------------+------------------------------------------+----------+ 432 | Code Point | Description | Length | 433 +------------+------------------------------------------+----------+ 434 | 1122 | Application Specific Link Attributes TLV | variable | 435 +------------+------------------------------------------+----------+ 437 8. Manageability Considerations 439 This section is structured as recommended in [RFC5706]. 441 The new protocol extensions introduced in this document augment the 442 existing IGP topology information that was distributed via [RFC7752]. 443 Procedures and protocol extensions defined in this document do not 444 affect the BGP protocol operations and management other than as 445 discussed in the Manageability Considerations section of [RFC7752]. 446 Specifically, the malformed NLRIs attribute tests in the Fault 447 Management section of [RFC7752] now encompass the new TLVs for the 448 BGP-LS NLRI in this document. 450 8.1. Operational Considerations 452 No additional operation considerations are defined in this document. 454 8.2. Management Considerations 456 No additional management considerations are defined in this document. 458 9. Security Considerations 460 The new protocol extensions introduced in this document augment the 461 existing IGP topology information that was distributed via [RFC7752]. 462 Procedures and protocol extensions defined in this document do not 463 affect the BGP security model other than as discussed in the Security 464 Considerations section of [RFC7752]. 466 10. Acknowledgements 468 The authors would like to thank Les Ginsberg, Baalajee S and Amalesh 469 Maity for their review and feedback on this document. 471 11. References 473 11.1. Normative References 475 [I-D.ietf-isis-te-app] 476 Ginsberg, L., Psenak, P., Previdi, S., Henderickx, W., and 477 J. Drake, "IS-IS TE Attributes per application", draft- 478 ietf-isis-te-app-12 (work in progress), March 2020. 480 [I-D.ietf-ospf-te-link-attr-reuse] 481 Psenak, P., Ginsberg, L., Henderickx, W., Tantsura, J., 482 and J. Drake, "OSPF Link Traffic Engineering Attribute 483 Reuse", draft-ietf-ospf-te-link-attr-reuse-11 (work in 484 progress), May 2020. 486 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 487 Requirement Levels", BCP 14, RFC 2119, 488 DOI 10.17487/RFC2119, March 1997, 489 . 491 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 492 S. Ray, "North-Bound Distribution of Link-State and 493 Traffic Engineering (TE) Information Using BGP", RFC 7752, 494 DOI 10.17487/RFC7752, March 2016, 495 . 497 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 498 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 499 May 2017, . 501 11.2. Informative References 503 [I-D.ietf-idr-eag-distribution] 504 Wang, Z., WU, Q., Tantsura, J., and K. Talaulikar, 505 "Distribution of Traffic Engineering Extended Admin Groups 506 using BGP-LS", draft-ietf-idr-eag-distribution-12 (work in 507 progress), May 2020. 509 [I-D.ietf-lsr-flex-algo] 510 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 511 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 512 algo-07 (work in progress), April 2020. 514 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 515 dual environments", RFC 1195, DOI 10.17487/RFC1195, 516 December 1990, . 518 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 519 DOI 10.17487/RFC2328, April 1998, 520 . 522 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 523 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 524 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 525 . 527 [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions 528 in Support of Generalized Multi-Protocol Label Switching 529 (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, 530 . 532 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 533 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 534 DOI 10.17487/RFC5286, September 2008, 535 . 537 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 538 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 539 . 541 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 542 Management of New Protocols and Protocol Extensions", 543 RFC 5706, DOI 10.17487/RFC5706, November 2009, 544 . 546 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 547 Decraene, B., Litkowski, S., and R. Shakir, "Segment 548 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 549 July 2018, . 551 [RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and 552 C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of 553 IGP Traffic Engineering Performance Metric Extensions", 554 RFC 8571, DOI 10.17487/RFC8571, March 2019, 555 . 557 Authors' Addresses 558 Ketan Talaulikar 559 Cisco Systems 561 Email: ketant@cisco.com 563 Peter Psenak 564 Cisco Systems 565 Slovakia 567 Email: ppsenak@cisco.com 569 Jeff Tantsura 570 Apstra 572 Email: jefftant.ietf@gmail.com