idnits 2.17.1 draft-ietf-idr-bgp-ls-app-specific-attr-15.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 25, 2022) is 670 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 27, 2022 Cisco Systems 6 J. Tantsura 7 Microsoft 8 June 25, 2022 10 Application-Specific Attributes Advertisement with BGP Link-State 11 draft-ietf-idr-bgp-ls-app-specific-attr-15 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 27, 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 . . . . . . . . . . . . . . . . 11 65 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 66 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 67 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 69 10.2. Informative References . . . . . . . . . . . . . . . . . 13 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 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. We start 365 with this set: 367 a. An IS-IS ASLA sub-TLV with S, F, and X bits set on it carrying 368 certain application-specific link attributes 370 b. An IS-IS Application-Specific SRLG TLV with zero-length bit masks 371 with a set of application-specific SRLGs 373 c. An IS-IS Application-Specific SRLG TLV with the X bit set on it 374 with a set of application-specific SRLGs 376 The corresponding BGP-LS advertisements for that link are determined 377 as follows: 379 First, based on rule (1), the advertisements are conveyed to BGP-LS 380 to get the following "updated set": 382 1. ASLA with S, F, and X bits set on it carrying link attributes 383 from IS-IS advertisement (a) 385 2. ASLA SRLG with zero-length bit masks with a set of SRLGs from IS- 386 IS advertisement (b) 388 3. ASLA SRLG with the X bit set on it with a set of SRLGs from IS-IS 389 advertisement (c) 391 Next, we apply the rules from (2) to this "updated set", because all 392 of them were sourced from IS-IS, to derive a new set. 394 The next rule that applies is (2)(c) and it is determined that 395 collation is required for applications S and F; therefore, we get the 396 following "final set": 398 1. ASLA with the S 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 S based on (2)(c)) 402 2. ASLA with the F bit set on it carrying link attributes from IS-IS 403 advertisement (a) and SRLGs from IS-IS advertisement (b) (this is 404 collation for application F based on (2)(c)) 406 3. ASLA with the X bit set on it carrying link attributes from IS-IS 407 advertisement (a) (remaining application not affected by 408 collation based on (2)(c)) 410 4. ASLA SRLG with zero-length bit masks with SRLGs from IS-IS 411 advertisement (b) (not affected by (2)(c) and therefore carried 412 forward unchanged from the "updated set") 414 5. ASLA SRLG with the X bit set on it with SRLGs from IS-IS 415 advertisement (c) (not affected by (2)(c) and therefore carried 416 forward unchanged from the "updated set") 418 Implementations may optionally perform further consolidation by 419 processing the "final set" above based on (2)(d) to determine the 420 following "consolidated final set": 422 1. ASLA with S and F bits set on it carrying application-specific 423 link attributes from IS-IS advertisement (a) and SRLGs from IS-IS 424 advertisement (b) (this is the consolidation of items 1 and 2 of 425 the "final set" based on (2)(d)) 427 2. ASLA with the X bit set on it carrying certain application- 428 specific link attributes from IS-IS advertisement (a) (it is 429 unaffected by this consolidation) 431 3. ASLA SRLG with zero-length bit masks with a set of application- 432 specific SRLGs from IS-IS advertisement (b) (this is retained 433 based on (2)(e) and is unaffected by any further consolidation) 435 4. ASLA SRLG with the X bit set on it with a set of application- 436 specific SRLGs from IS-IS advertisement (c) (it is unaffected by 437 this consolidation) 439 Further optimization (e.g., combining (2) and (4) from the 440 "consolidated final set" above into a single BGP-LS ASLA TLV) may be 441 possible while ensuring that the semantics are preserved between the 442 IS-IS and BGP-LS advertisements. Such optimizations are outside the 443 scope of this document. 445 5. Deployment Considerations 447 BGP-LS sources the link-state topology information (including the 448 extensions introduced by this document) from the underlying link- 449 state IGP protocols. The various deployment aspects related to the 450 advertisement and use of application-specific link attributes are 451 discussed in the Deployment Considerations sections of [RFC8920] and 452 [RFC8919]. The IGP backward compatibility aspects described in those 453 documents associated with application-specific link attributes along 454 with the BGP-LS procedures specified in this document enable backward 455 compatibility in deployments of existing implementations of [RFC7752] 456 [RFC8571] [RFC9104] for applications such as RSVP-TE, SR Policy, and 457 LFA. 459 It is recommended that only nodes supporting this specification are 460 selected as originators of BGP-LS information when advertising the 461 link-state information from the IGPs in deployments supporting 462 application-specific link attributes. 464 BGP-LS consumers that do not support this specification can continue 465 to use the existing top-level TLVs for link attributes for existing 466 applications as discussed above. They would, however, be able to 467 support neither the application-specific link attributes nor newer 468 applications that may be encoded only using the ASLA TLV. 470 6. IANA Considerations 472 IANA has assigned, through the early allocation process, the 473 following code-point from the "BGP-LS Node Descriptor, Link 474 Descriptor, Prefix Descriptor, and Attribute TLVs" registry. This 475 document requests that the allocation be made permanent. The column 476 "IS-IS TLV/Sub-TLV" defined in the registry does not require any 477 value and should be left empty. 479 +------------+--------------------------------------+---------------+ 480 | Code Point | Description | Reference | 481 +------------+--------------------------------------+---------------+ 482 | 1122 | Application-Specific Link Attributes | this document | 483 +------------+--------------------------------------+---------------+ 485 Table 2: ASLA TLV Code-Point Allocation 487 7. Manageability Considerations 489 The protocol extensions introduced in this document augment the 490 existing IGP topology information defined in [RFC7752]. Procedures 491 and protocol extensions defined in this document do not affect the 492 BGP protocol operations and management other than as discussed in the 493 Manageability Considerations section of [RFC7752]. Specifically, the 494 malformed NLRIs attribute tests in the Fault Management section of 495 [RFC7752] now encompasses the BGP-LS TLVs defined in this document. 497 The extensions specified in this document do not specify any new 498 configuration or monitoring aspects in BGP or BGP-LS. The 499 specification of BGP models is an ongoing work based on 500 [I-D.ietf-idr-bgp-model]. 502 8. Security Considerations 504 Security considerations for acquiring and distributing BGP-LS 505 information are discussed in [RFC7752]. Specifically, the 506 considerations related to topology information related to traffic 507 engineering apply. 509 The TLVs introduced in this document are used to propagate the 510 application-specific link attributes IGP extensions defined in 511 [RFC8919] and [RFC8920]. It is assumed that the IGP instances 512 originating these TLVs will support all the required security (as 513 described in [RFC8919] and [RFC8920]). 515 This document defines a new way to advertise link attributes. 516 Tampering with the information defined in this document may affect 517 applications using it, including impacting traffic engineering, which 518 uses various link attributes for its path computation. As the 519 advertisements defined in this document limit the scope to specific 520 applications, the impact of tampering is similarly limited in scope. 521 The advertisement of the link attribute information defined in this 522 document presents no significant additional risk beyond that 523 associated with the existing link attribute information already 524 supported in [RFC7752]. 526 9. Acknowledgements 528 The authors would like to thank Les Ginsberg, Baalajee S, Amalesh 529 Maity, Acee Lindem, Keyur Patel, Paul Wouters, Rudy Selderslaghs, and 530 Kristy Paine for their review and feedback on this document. The 531 authors would like to thank Alvaro Retana for his very detailed AD 532 review and comments for improving this document. The authors would 533 also like to thank John Scudder for his detailed review and feedback 534 on clarifying the procedures along with the example in Section 4. 536 10. References 538 10.1. Normative References 540 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 541 Requirement Levels", BCP 14, RFC 2119, 542 DOI 10.17487/RFC2119, March 1997, 543 . 545 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 546 S. Ray, "North-Bound Distribution of Link-State and 547 Traffic Engineering (TE) Information Using BGP", RFC 7752, 548 DOI 10.17487/RFC7752, March 2016, 549 . 551 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 552 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 553 May 2017, . 555 [RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and 556 C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of 557 IGP Traffic Engineering Performance Metric Extensions", 558 RFC 8571, DOI 10.17487/RFC8571, March 2019, 559 . 561 [RFC8919] Ginsberg, L., Psenak, P., Previdi, S., Henderickx, W., and 562 J. Drake, "IS-IS Application-Specific Link Attributes", 563 RFC 8919, DOI 10.17487/RFC8919, October 2020, 564 . 566 [RFC8920] Psenak, P., Ed., Ginsberg, L., Henderickx, W., Tantsura, 567 J., and J. Drake, "OSPF Application-Specific Link 568 Attributes", RFC 8920, DOI 10.17487/RFC8920, October 2020, 569 . 571 [RFC9104] Tantsura, J., Wang, Z., Wu, Q., and K. Talaulikar, 572 "Distribution of Traffic Engineering Extended 573 Administrative Groups Using the Border Gateway Protocol - 574 Link State (BGP-LS)", RFC 9104, DOI 10.17487/RFC9104, 575 August 2021, . 577 10.2. Informative References 579 [I-D.ietf-idr-bgp-model] 580 Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP 581 YANG Model for Service Provider Networks", draft-ietf-idr- 582 bgp-model-13 (work in progress), March 2022. 584 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 585 dual environments", RFC 1195, DOI 10.17487/RFC1195, 586 December 1990, . 588 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 589 DOI 10.17487/RFC2328, April 1998, 590 . 592 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 593 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 594 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 595 . 597 [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions 598 in Support of Generalized Multi-Protocol Label Switching 599 (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, 600 . 602 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 603 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 604 DOI 10.17487/RFC5286, September 2008, 605 . 607 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 608 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 609 . 611 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 612 Decraene, B., Litkowski, S., and R. Shakir, "Segment 613 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 614 July 2018, . 616 Authors' Addresses 618 Ketan Talaulikar (editor) 619 Arrcus Inc 620 India 622 Email: ketant.ietf@gmail.com 624 Peter Psenak 625 Cisco Systems 626 Slovakia 628 Email: ppsenak@cisco.com 630 Jeff Tantsura 631 Microsoft 633 Email: jefftant.ietf@gmail.com