idnits 2.17.1 draft-ietf-idr-bgp-ls-app-specific-attr-14.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 (June 17, 2022) is 678 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 (-17) exists of draft-ietf-idr-bgp-model-13 Summary: 3 errors (**), 0 flaws (~~), 2 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 Arrcus Inc 4 Intended status: Standards Track P. Psenak 5 Expires: December 19, 2022 Cisco Systems 6 J. Tantsura 7 Microsoft 8 June 17, 2022 10 Application-Specific Attributes Advertisement with BGP Link-State 11 draft-ietf-idr-bgp-ls-app-specific-attr-14 13 Abstract 15 Extensions have been defined for link-state routing protocols that 16 enable distribution of application-specific link attributes for 17 existing as well as newer applications such as Segment Routing. This 18 document defines extensions to BGP-LS to enable the advertisement of 19 these application-specific attributes as a part of the topology 20 information from the network. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on December 19, 2022. 39 Copyright Notice 41 Copyright (c) 2022 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 2. Application Specific Link Attributes TLV . . . . . . . . . . 3 59 3. Application-Specific Link Attributes . . . . . . . . . . . . 4 60 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4.1. Illustration for IS-IS . . . . . . . . . . . . . . . . . 8 62 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 10 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 64 7. Manageability Considerations . . . . . . . . . . . . . . . . 10 65 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 66 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 67 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 69 10.2. Informative References . . . . . . . . . . . . . . . . . 12 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 72 1. Introduction 74 BGP Link-State [RFC7752] enables the distribution of the link-state 75 topology information from link-state routing protocols (viz., IS-IS 76 [RFC1195], OSPFv2 [RFC2328] and OSPFv3 [RFC5340]) to an application 77 like a controller or Path Computation Engine (PCE) via BGP. The 78 controller/PCE gets the end-to-end topology information across IGP 79 domains so it can perform path computations for use cases like end- 80 to-end traffic engineering (TE). 82 The link-state topology information distributed via BGP-LS includes 83 link attributes that were originally defined for MPLS Traffic 84 Engineering (i.e., using RSVP-TE [RFC3209]) or GMPLS [RFC4202]) 85 applications. In recent years applications, such as Segment Routing 86 (SR) Policy [RFC8402] and Loop-Free Alternates (LFA) [RFC5286], which 87 also make use of link attributes have been introduced. [RFC8919] and 88 [RFC8920] define extensions for IS-IS and OSPF respectively that 89 enable advertising application-specific link attributes for these and 90 other future applications. This has resulted in the need for a 91 similar BGP-LS extension to include this additional link-state 92 topology information from the link-state routing protocols. 94 This document defines the BGP-LS extensions for the advertisement of 95 application-specific link attributes. It describes the advertisement 96 of these link attributes as top-level TLVs (i.e., as TLVs of the BGP- 97 LS Attribute) and as sub-TLVs of the (top-level) Application Specific 98 Link Attributes TLV. The document also describes the procedures for 99 the advertisement of these attributes from the underlying IGPs and 100 discusses their deployment aspects. 102 1.1. Requirements Language 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 106 "OPTIONAL" in this document are to be interpreted as described in BCP 107 14 [RFC2119] [RFC8174] when, and only when, they appear in all 108 capitals, as shown here. 110 2. Application Specific Link Attributes TLV 112 The BGP-LS [RFC7752] specifies the Link Network Layer Reachability 113 Information (NLRI) for the advertisement of links and their 114 attributes using the BGP-LS Attribute. The Application-Specific Link 115 Attributes (ASLA) TLV is an optional top-level BGP-LS Attribute TLV 116 that is introduced for Link NLRIs. It is defined such that it may 117 act as a container for certain existing and future link attributes 118 that require application-specific definition. 120 The format of this TLV is as follows and is similar to the 121 corresponding ASLA sub-TLVs defined for OSPF and IS-IS in [RFC8920] 122 and [RFC8919] respectively. 124 0 1 2 3 125 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 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | Type | Length | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | SABM Length | UDABM Length | Reserved | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | Standard Application Identifier Bit Mask (variable) // 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | User-Defined Application Identifier Bit Mask (variable) // 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | Link Attribute sub-TLVs // 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 Figure 1: Application-Specific Link Attributes TLV 140 where: 142 o Type: 1122 144 o Length: variable. 146 o SABM Length : 1 octet field carrying the Standard Application 147 Identifier Bit Mask Length in octets as defined in [RFC8920]. 149 o UDABM Length : 1 octet field carrying the User-Defined Application 150 Identifier Bit Mask Length in octets as defined in [RFC8920]. 152 o Reserved: 2 octet field that MUST be set to zero on transmission 153 and MUST be ignored on reception. 155 o Standard Application Identifier Bit Mask : An optional set of bits 156 (of size 0, 4, or 8 octets as indicated by the SABM Length), where 157 each bit represents a single standard application as defined in 158 [RFC8919]. 160 o User-Defined Application Identifier Bit Mask : An optional set of 161 bits (of size 0, 4, or 8 octets as indicated by the UDABM Length), 162 where each bit represents a single user-defined application as 163 defined in [RFC8919] [RFC8920].. 165 o Link Attribute sub-TLVs : BGP-LS Attribute TLVs corresponding to 166 the Link NLRI that are application-specific (including existing 167 ones as specified in Section 3) are included as sub-TLVs of the 168 ASLA TLV. 170 The semantics associated with the standard and user-defined bit masks 171 as well as the encoding scheme for application-specific attributes 172 are as specified in [RFC8920]. 174 The ASLA TLV and its sub-TLVs can only be added to the BGP-LS 175 Attribute associated with the Link NLRI of the node that originates 176 the underlying IGP link attribute TLVs/sub-TLVs. The procedures for 177 originating link attributes in the ASLA TLV from underlying IGPs are 178 specified in Section 4. 180 3. Application-Specific Link Attributes 182 Several BGP-LS Attribute TLVs corresponding to the Link NLRI are 183 defined in BGP-LS and more may be added in the future. Those 184 attributes that have been determined to be, and advertised as 185 application-specific in the underlying IGPs are also encoded 186 similarly in BGP-LS. 188 The following table lists the currently defined BGP-LS Attributes 189 TLVs corresponding to Link NLRI that can have application-specific 190 semantics based on the underlying IGP specifications [RFC8919] 191 [RFC8920]. These were originally defined with semantics for RSVP-TE 192 and GMPLS applications in BGP-LS by the respective reference 193 documents. 195 +---------------+-------------------------------+-------------------+ 196 | TLV Code | Description | Reference | 197 | Point | | Document | 198 +---------------+-------------------------------+-------------------+ 199 | 1088 | Administrative group (color) | [RFC7752] | 200 | 1092 | TE Default Metric | [RFC7752] | 201 | 1096 | Shared Risk Link Group | [RFC7752] | 202 | 1114 | Unidirectional Link Delay | [RFC8571] | 203 | 1115 | Min/Max Unidirectional Link | [RFC8571] | 204 | | Delay | | 205 | 1116 | Unidirectional Delay | [RFC8571] | 206 | | Variation | | 207 | 1117 | Unidirectional Link Loss | [RFC8571] | 208 | 1118 | Unidirectional Residual | [RFC8571] | 209 | | Bandwidth | | 210 | 1119 | Unidirectional Available | [RFC8571] | 211 | | Bandwidth | | 212 | 1120 | Unidirectional Utilized | [RFC8571] | 213 | | Bandwidth | | 214 | 1173 | Extended Administrative Group | [RFC9104] | 215 +---------------+-------------------------------+-------------------+ 217 Table 1: Existing BGP-LS TLVs identified as Application-Specific 219 All the BGP-LS Attribute TLVs listed in the table above are REQUIRED 220 to be advertised as a top-level TLV in the BGP-LS Attribute when used 221 to carry link attributes specific to RSVP-TE. 223 BGP-LS Attribute TLVs corresponding to Link NLRI that are identified 224 as application-specific are REQUIRED to be encoded within an ASLA 225 TLV. 227 Link attributes that do not have application-specific semantics MUST 228 NOT be advertised within the ASLA TLV. 230 When the same application-specific link attributes are advertised 231 both within the ASLA TLV and as top-level TLVs in the BGP-LS 232 Attribute, the attributes advertised within the ASLA TLV take 233 precedence for the applications indicated in the ASLA TLV encoding. 235 4. Procedures 237 The BGP-LS originator learns of the association of an application- 238 specific attribute to one or more applications from the underlying 239 IGP protocol LSA/LSPs from which it is advertising the topology 240 information. [RFC8920] and [RFC8919] specify the mechanisms for 241 advertising application-specific link attributes in OSPF and IS-IS 242 respectively. 244 Application-specific link attributes received from an IGP node 245 without the use of ASLA encodings continue to be encoded using the 246 respective BGP-LS top-level TLVs listed in Table 1 as specified in 247 their respective reference documents. 249 While the ASLA encoding in OSPF is similar to that of BGP-LS, the 250 encoding in IS-IS differs and requires additional procedures when 251 conveying information into BGP-LS. One of these differences arises 252 from the presence of the L-flag in the IS-IS encoding. Another 253 difference arises due to the requirement to collate information from 254 two types of IS-IS encodings for application-specific link 255 information (i.e., the IS-IS ASLA sub-TLV and the ISIS Application- 256 Specific SRLG TLV) [RFC8919] and to carry them together in the BGP-LS 257 ASLA TLV. 259 A BGP-LS originator node that is advertising link-state information 260 from the underlying IGP using ASLA encodings determines their BGP-LS 261 encoding based on the following rules: 263 1. Application-specific link attributes received from an OSPF node 264 using ASLA sub-TLV or from an IS-IS node using either ASLA sub- 265 TLV or Application-Specific SRLG TLV MUST be encoded in the BGP- 266 LS ASLA TLV as sub-TLVs. Exceptions to this rule are specified 267 in (2)(F) and (2)(G) below. 269 2. In the case of IS-IS, the following specific procedures are to be 270 followed: 272 A. When application-specific link attributes are received from a 273 node with the L-flag set in the IS-IS ASLA sub-TLV and 274 application bits other than RSVP-TE are set in the 275 application bit masks then the application-specific link 276 attributes advertised in the corresponding legacy IS-IS TLVs/ 277 sub-TLVs MUST be encoded within the BGP-LS ASLA TLV as sub- 278 TLVs with the application bits, other than the RSVP-TE bit, 279 copied from the IS-IS ASLA sub-TLV. The link attributes 280 advertised in the legacy IS-IS TLVs/sub-TLVs are also 281 advertised in BGP-LS top-level TLVs as per [RFC7752] 282 [RFC8571] [RFC9104]. The same procedure also applies for the 283 advertisement of the SRLG values from the IS-IS Application- 284 Specific SRLG TLV. 286 B. When the IS-IS ASLA sub-TLV has the RSVP-TE application bit 287 set, then the link attributes for the corresponding IS-IS 288 ASLA sub-TLVs MUST be encoded using the respective BGP-LS 289 top-level TLVs as per [RFC7752] [RFC8571] [RFC9104]. 290 Similarly, when the IS-IS Application-Specific SRLG TLV has 291 the RSVP-TE application bit set, then the SRLG values within 292 it MUST be encoded using the top-level BGP-LS SRLG TLV (1096) 293 as per [RFC7752]. 295 C. The SRLGs advertised in IS-IS Application-Specific SRLG 296 TLV(s) and the other link attributes advertised in IS-IS ASLA 297 sub-TLV(s) are REQUIRED to be collated, on a per-application 298 basis, only for those applications that meet all the 299 following criteria: 301 + their bit is set in the SABM/UDABM in one of the two types 302 of IS-IS encodings 304 + the other encoding type has an advertisement with zero- 305 length application bit masks 307 + there is no corresponding advertisement of that other 308 encoding type with that specific application bit set 310 For each such application, its collated information MUST be 311 carried in a BGP-LS ASLA TLV with that application's bit set 312 in the SABM/UDABM. See illustration in Section 4.1. 314 D. If the resulting set of collated link attributes and SRLG 315 values is common across multiple applications, they MAY be 316 advertised in a common BGP-LS ASLA TLV instance where the 317 bits for all such applications would be set in the 318 application bit mask. 320 E. Both the SRLG values from IS-IS Application-Specific SRLG 321 TLVs and the link attributes from IS-IS ASLA sub-TLVs, with 322 the zero-length application bit mask, MUST be advertised into 323 a BGP-LS ASLA TLV with a zero-length application bit mask, 324 independent of the collation described above. 326 F. [RFC8919] allows the advertisement of the Maximum Link 327 Bandwidth within an IS-IS ASLA sub-TLV even though it is not 328 an application-specific attribute. However, when originating 329 the Maximum Link Bandwidth into BGP-LS, the attribute MUST be 330 encoded only in the top-level BGP-LS Maximum Link Bandwidth 331 TLV (1089) and MUST NOT be advertised within the BGP-LS ASLA 332 TLV. 334 G. [RFC8919] also allows the advertisement of the Maximum 335 Reservable Link Bandwidth and the Unreserved Bandwidth within 336 an IS-IS ASLA sub-TLV even though these attributes are 337 specific to RSVP-TE application. However, when originating 338 the Maximum Reservable Link Bandwidth and Unreserved 339 Bandwidth into BGP-LS, these attributes MUST be encoded only 340 in the BGP-LS top-level Maximum Reservable Link Bandwidth TLV 341 (1090) and Unreserved Bandwidth TLV (1091) respectively and 342 not within the BGP-LS ASLA TLV. 344 These rules ensure that a BGP-LS originator performs the 345 advertisement for all application-specific link attributes from the 346 IGP nodes that support the ASLA extension. Furthermore, it also 347 ensures that the top-level BGP-LS TLVs defined for RSVP-TE and GMPLS 348 applications continue to be used for advertisement of their 349 application-specific attributes. 351 A BGP-LS speaker would normally advertise all the application- 352 specific link attributes corresponding to RSVP-TE and GMPLS 353 applications as existing top-level BGP-LS TLVs while for other 354 applications they are encoded in ASLA TLV(s) with appropriate 355 applicable bit mask setting. An application-specific attribute value 356 received via a sub-TLV within the ASLA TLV has precedence over the 357 value received via a top-level TLV. 359 4.1. Illustration for IS-IS 361 This section illustrates the procedure for the advertisement of 362 application-specific link attributes from IS-IS into BGP-LS. 364 Consider the following advertisements for a link in IS-IS: 366 a. An IS-IS ASLA sub-TLV with S, F, and X bits set on it carrying 367 certain application-specific link attributes 369 b. An IS-IS Application-Specific SRLG TLV with zero-length bit masks 370 with a set of application-specific SRLGs 372 c. An IS-IS Application-Specific SRLG TLV with the X bit set on it 373 with a set of application-specific SRLGs 375 The corresponding BGP-LS advertisements for that link are determined 376 as follows: 378 First, based on rule (1), the advertisements are conveyed to BGP-LS 379 to get the following: 381 1. ASLA with S, F, and X bits set on it carrying link attributes 382 from IS-IS advertisement (a) 384 2. ASLA SRLG with zero-length bit masks with a set of SRLGs from IS- 385 IS advertisement (b) 387 3. ASLA SRLG with the X bit set on it with a set of SRLGs from IS-IS 388 advertisement (c) 390 The next rule that applies is (2)(c) and it is determined that 391 collation is required for applications S and F; therefore, we get the 392 following: 394 1. ASLA with the S bit set on it carrying link attributes from IS-IS 395 advertisement (a) and SRLGs from IS-IS advertisement (b) (this is 396 collation for application S based on (2)(c)) 398 2. ASLA with the F bit set on it carrying link attributes from IS-IS 399 advertisement (a) and SRLGs from IS-IS advertisement (b) (this is 400 collation for application F based on (2)(c)) 402 3. ASLA with the X bit set on it carrying link attributes from IS-IS 403 advertisement (a) (remaining application not affected by 404 collation based on (2)(c)) 406 4. ASLA SRLG with zero-length bit masks with SRLGs from IS-IS 407 advertisement (b) (not affected by (2)(c)) 409 5. ASLA SRLG with the X bit set on it with SRLGs from IS-IS 410 advertisement (c) (not affected by (2)(c)) 412 Implementations may optionally perform further consolidation as 413 follows: 415 1. ASLA with S and F bits set on it carrying application-specific 416 link attributes from IS-IS advertisement (a) and SRLGs from IS-IS 417 advertisement (b) (this is based on (2)(e)) 419 2. ASLA with the X bit set on it carrying certain application- 420 specific link attributes from IS-IS advertisement (a) 422 3. ASLA SRLG with zero-length bit masks with a set of application- 423 specific SRLGs from IS-IS advertisement (b) (this is retained 424 based on (2)(f)) 426 4. ASLA SRLG with the X bit set on it with a set of application- 427 specific SRLGs from IS-IS advertisement (c) 429 Further optimization (e.g., combining (2) and (4) from the final set 430 above into a single BGP-LS ASLA TLV) may be possible while ensuring 431 that the semantics are preserved between the IS-IS and BGP-LS 432 advertisements. Such optimizations are outside the scope of this 433 document. 435 5. Deployment Considerations 437 BGP-LS sources the link-state topology information (including the 438 extensions introduced by this document) from the underlying link- 439 state IGP protocols. The various deployment aspects related to the 440 advertisement and use of application-specific link attributes are 441 discussed in the Deployment Considerations sections of [RFC8920] and 442 [RFC8919]. The IGP backward compatibility aspects described in those 443 documents associated with application-specific link attributes along 444 with the BGP-LS procedures specified in this document enable backward 445 compatibility in deployments of existing implementations of [RFC7752] 446 [RFC8571] [RFC9104] for applications such as RSVP-TE, SR Policy, and 447 LFA. 449 It is recommended that only nodes supporting this specification are 450 selected as originators of BGP-LS information when advertising the 451 link-state information from the IGPs in deployments supporting 452 application-specific link attributes. 454 BGP-LS consumers that do not support this specification can continue 455 to use the existing top-level TLVs for link attributes for existing 456 applications as discussed above. They would, however, be able to 457 support neither the application-specific link attributes nor newer 458 applications that may be encoded only using the ASLA TLV. 460 6. IANA Considerations 462 IANA has assigned, through the early allocation process, the 463 following code-point from the "BGP-LS Node Descriptor, Link 464 Descriptor, Prefix Descriptor, and Attribute TLVs" registry. This 465 document requests that the allocation be made permanent. The column 466 "IS-IS TLV/Sub-TLV" defined in the registry does not require any 467 value and should be left empty. 469 +------------+--------------------------------------+---------------+ 470 | Code Point | Description | Reference | 471 +------------+--------------------------------------+---------------+ 472 | 1122 | Application-Specific Link Attributes | this document | 473 +------------+--------------------------------------+---------------+ 475 Table 2: ASLA TLV Code-Point Allocation 477 7. Manageability Considerations 479 The protocol extensions introduced in this document augment the 480 existing IGP topology information defined in [RFC7752]. Procedures 481 and protocol extensions defined in this document do not affect the 482 BGP protocol operations and management other than as discussed in the 483 Manageability Considerations section of [RFC7752]. Specifically, the 484 malformed NLRIs attribute tests in the Fault Management section of 485 [RFC7752] now encompasses the BGP-LS TLVs defined in this document. 487 The extensions specified in this document do not specify any new 488 configuration or monitoring aspects in BGP or BGP-LS. The 489 specification of BGP models is an ongoing work based on 490 [I-D.ietf-idr-bgp-model]. 492 8. Security Considerations 494 Security considerations for acquiring and distributing BGP-LS 495 information are discussed in [RFC7752]. Specifically, the 496 considerations related to topology information related to traffic 497 engineering apply. 499 The TLVs introduced in this document are used to propagate the 500 application-specific link attributes IGP extensions defined in 501 [RFC8919] and [RFC8920]. It is assumed that the IGP instances 502 originating these TLVs will support all the required security (as 503 described in [RFC8919] and [RFC8920]). 505 This document defines a new way to advertise link attributes. 506 Tampering with the information defined in this document may affect 507 applications using it, including impacting traffic engineering, which 508 uses various link attributes for its path computation. As the 509 advertisements defined in this document limit the scope to specific 510 applications, the impact of tampering is similarly limited in scope. 511 The advertisement of the link attribute information defined in this 512 document presents no significant additional risk beyond that 513 associated with the existing link attribute information already 514 supported in [RFC7752]. 516 9. Acknowledgements 518 The authors would like to thank Les Ginsberg, Baalajee S, Amalesh 519 Maity, Acee Lindem, Keyur Patel, Paul Wouters, Rudy Selderslaghs, and 520 Kristy Paine for their review and feedback on this document. The 521 authors would also like to thank Alvaro Retana for his very detailed 522 AD review and comments for improving this document. 524 10. References 525 10.1. Normative References 527 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 528 Requirement Levels", BCP 14, RFC 2119, 529 DOI 10.17487/RFC2119, March 1997, 530 . 532 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 533 S. Ray, "North-Bound Distribution of Link-State and 534 Traffic Engineering (TE) Information Using BGP", RFC 7752, 535 DOI 10.17487/RFC7752, March 2016, 536 . 538 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 539 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 540 May 2017, . 542 [RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and 543 C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of 544 IGP Traffic Engineering Performance Metric Extensions", 545 RFC 8571, DOI 10.17487/RFC8571, March 2019, 546 . 548 [RFC8919] Ginsberg, L., Psenak, P., Previdi, S., Henderickx, W., and 549 J. Drake, "IS-IS Application-Specific Link Attributes", 550 RFC 8919, DOI 10.17487/RFC8919, October 2020, 551 . 553 [RFC8920] Psenak, P., Ed., Ginsberg, L., Henderickx, W., Tantsura, 554 J., and J. Drake, "OSPF Application-Specific Link 555 Attributes", RFC 8920, DOI 10.17487/RFC8920, October 2020, 556 . 558 [RFC9104] Tantsura, J., Wang, Z., Wu, Q., and K. Talaulikar, 559 "Distribution of Traffic Engineering Extended 560 Administrative Groups Using the Border Gateway Protocol - 561 Link State (BGP-LS)", RFC 9104, DOI 10.17487/RFC9104, 562 August 2021, . 564 10.2. Informative References 566 [I-D.ietf-idr-bgp-model] 567 Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP 568 YANG Model for Service Provider Networks", draft-ietf-idr- 569 bgp-model-13 (work in progress), March 2022. 571 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 572 dual environments", RFC 1195, DOI 10.17487/RFC1195, 573 December 1990, . 575 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 576 DOI 10.17487/RFC2328, April 1998, 577 . 579 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 580 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 581 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 582 . 584 [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions 585 in Support of Generalized Multi-Protocol Label Switching 586 (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, 587 . 589 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 590 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 591 DOI 10.17487/RFC5286, September 2008, 592 . 594 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 595 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 596 . 598 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 599 Decraene, B., Litkowski, S., and R. Shakir, "Segment 600 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 601 July 2018, . 603 Authors' Addresses 605 Ketan Talaulikar (editor) 606 Arrcus Inc 607 India 609 Email: ketant.ietf@gmail.com 611 Peter Psenak 612 Cisco Systems 613 Slovakia 615 Email: ppsenak@cisco.com 616 Jeff Tantsura 617 Microsoft 619 Email: jefftant.ietf@gmail.com