idnits 2.17.1 draft-ietf-idr-bgp-ls-app-specific-attr-07.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, 2021) is 1030 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-10 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 P. Psenak 4 Intended status: Standards Track Cisco Systems 5 Expires: December 27, 2021 J. Tantsura 6 Microsoft 7 June 25, 2021 9 Application-Specific Attributes Advertisement with BGP Link-State 10 draft-ietf-idr-bgp-ls-app-specific-attr-07 12 Abstract 14 Various link attributes have been defined in link-state routing 15 protocols like OSPF and IS-IS in the context of the MPLS Traffic 16 Engineering (TE) and GMPLS. BGP Link-State (BGP-LS) extensions have 17 been defined to distribute these attributes along with other topology 18 information from these link-state routing protocols. Many of these 19 link attributes can be used for applications other than MPLS-TE or 20 GMPLS. 22 Extensions to link-state routing protocols have been defined for such 23 link attributes that enable distribution of their application- 24 specific values. This document defines extensions to BGP-LS address- 25 family to enable advertisement of these application-specific 26 attributes as a part of the topology information from the network. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on December 27, 2021. 45 Copyright Notice 47 Copyright (c) 2021 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 . . . . . . . . . . . . . . . . . . . 10 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 70 8. Manageability Considerations . . . . . . . . . . . . . . . . 11 71 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 72 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 75 11.2. Informative References . . . . . . . . . . . . . . . . . 12 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 78 1. Introduction 80 Various link attributes have been defined in link-state routing 81 protocols (viz., IS-IS [RFC1195], OSPFv2 [RFC2328] and OSPFv3 82 [RFC5340] ) in the context of the MPLS traffic engineering and GMPLS. 83 All these attributes are distributed by these protocols using TLVs 84 that were originally defined for traditional MPLS Traffic Engineering 85 (i.e., using RSVP-TE [RFC3209]) or GMPLS [RFC4202] applications. 87 In recent years new applications have been introduced that have use 88 cases for many of the link attributes historically used by RSVP-TE 89 and GMPLS. Such applications include Segment Routing (SR) Policy 90 [RFC8402] and Loop Free Alternates (LFA) [RFC5286]. This has 91 introduced ambiguity in that if a deployment includes a mix of RSVP- 92 TE support and SR Policy support (for example) it is not possible to 93 unambiguously indicate which advertisements are to be used by RSVP-TE 94 and which advertisements are to be used by SR Policy. If the 95 topologies are fully congruent this may not be an issue, but any 96 incongruence leads to ambiguity. An additional issue arises in cases 97 where both applications are supported on a link but the link 98 attribute values associated with each application differ. Current 99 advertisements do not support advertising application-specific values 100 for the same attribute on a specific link. 102 [RFC8920] and [RFC8919] define extensions for OSPF and IS-IS 103 respectively that address these issues. Also, as the evolution of 104 use cases for link attributes can be expected to continue in the 105 years to come, these documents define an easily extensible solution 106 for the introduction of new applications and new use cases. 108 BGP Link-State extensions [RFC7752] have been specified to enable 109 distribution of the link-state topology information from the IGPs to 110 an application like a controller or Path Computation Engine (PCE) via 111 BGP. The controller/PCE gets the end-to-end topology information 112 across IGP domains so it can perform path computations for use cases 113 like end-to-end traffic engineering (TE) using RSVP-TE or SR Policy 114 mechanisms. A similar challenge to what was described above is hence 115 also faced by such centralized computation entities. 117 There is thus a need for BGP-LS extensions to also report link 118 attributes on a per-application basis on the same lines as introduced 119 in the link-state routing protocols. This document defines these 120 BGP-LS extensions and also covers the backward compatibility issues 121 related to existing BGP-LS deployments. 123 1.1. Requirements Language 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 127 "OPTIONAL" in this document are to be interpreted as described in BCP 128 14 [RFC2119] [RFC8174] when, and only when, they appear in all 129 capitals, as shown here. 131 2. Application Specific Link Attributes TLV 133 The BGP-LS [RFC7752] specifies the Link NLRI for the advertisement of 134 links and their attributes using the BGP-LS Attribute. The 135 Application-Specific Link Attributes (ASLA) TLV is a new optional 136 top-level BGP-LS Attribute TLV that is introduced for Link NLRIs. It 137 is defined such that it may act as a container for certain existing 138 and future link attributes that require application-specific 139 definition. 141 The format of this TLV is as follows and is similar to the 142 corresponding ASLA sub-TLVs defined for OSPF and IS-IS in [RFC8920] 143 and [RFC8919] respectively. 145 0 1 2 3 146 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 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | Type | Length | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | SABM Length | UDABM Length | Reserved | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Standard Application Identifier Bit Mask (variable) // 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | User-Defined Application Identifier Bit Mask (variable) // 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Link Attribute sub-TLVs // 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 Figure 1: Application-Specific Link Attributes TLV 161 where: 163 o Type: 1122 165 o Length: variable. 167 o SABM Length : Standard Application Identifier Bit Mask Length in 168 octets. The values MUST be 0, 4, or 8. If the Standard 169 Application Identifier Bit Mask is not present, the value MUST be 170 set to 0. 172 o UDABM Length : User-Defined Application Identifier Bit Mask Length 173 in octets. The values MUST be 0, 4, or 8. If the User-Defined 174 Application Identifier Bit Mask is not present, the value MUST be 175 set to 0. 177 o Standard Application Identifier Bit Mask : of size 0, 4, or 8 178 octets as indicated by the SABML. An optional set of bits, where 179 each bit represents a single standard application. The bits are 180 defined in the IANA "IGP Parameters" registries under the "Link 181 Attribute Applications" registry [RFC8919]. 183 o User-Defined Application Identifier Bit Mask : of size 0, 4, or 8 184 octets as indicated by the UDABML. An optional set of bits, where 185 each bit represents a single user-defined application. The bits 186 are not managed or assigned by IANA or any other standards body 187 and definition is left to the implementation. 189 o sub-TLVs : BGP-LS Attribute TLVs corresponding to the Link NLRI 190 that are application-specific (as specified in Section 3) are 191 included as sub-TLVs of the ASLA TLV. 193 An ASLA TLV with both the SABM and UDABM lengths set to 0 (i.e. 194 without any application identifier bit masks) indicates that the link 195 attribute sub-TLVs that it encloses are applicable for all 196 applications. However, the link attributes advertised within an ASLA 197 TLV with such a zero-length application bit mask MUST NOT be 198 considered by BGP-LS consumers for those applications for which at 199 least one instance of ASLA TLV is present in the same advertisement 200 with their specific application bit set. 202 The ASLA TLV and its sub-TLVs can only be added to the BGP-LS 203 Attribute associated with the Link NLRI of the node that originates 204 the underlying IGP link attribute TLVs/sub-TLVs. The procedures for 205 originating link attributes in the ASLA TLV from underlying IGPs are 206 specified in Section 4. 208 When the node is not running any of the IGPs but running a protocol 209 like BGP, then the link attributes for the node's local links MAY be 210 originated as part of the BGP-LS Attribute using the ASLA TLV and its 211 sub-TLVs within the Link NLRI corresponding to the local node. 213 3. Application-Specific Link Attributes 215 Several BGP-LS Attribute TLVs corresponding to the Link NLRI are 216 defined in BGP-LS and more may be added in the future. The following 217 types of link attributes are required to be considered 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 Policy 223 o those that apply to multiple applications but need to be used only 224 by a specific application e.g., certain Shared Risk Link Group 225 (SRLG) values are configured on a node for LFA but the same do not 226 need to be used for RSVP-TE 228 The following table lists the currently defined BGP-LS Attributes 229 TLVs corresponding to Link NLRI that have application-specific 230 semantics. These 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 | [RFC7752] | 238 | | group (color) | | 239 | 1092 | TE Default Metric | [RFC7752] | 240 | 1096 | Shared Risk Link | [RFC7752] | 241 | | Group | | 242 | 1114 | Unidirectional Link | [RFC8571] | 243 | | Delay | | 244 | 1115 | Min/Max | [RFC8571] | 245 | | Unidirectional Link | | 246 | | Delay | | 247 | 1116 | Unidirectional | [RFC8571] | 248 | | Delay Variation | | 249 | 1117 | Unidirectional Link | [RFC8571] | 250 | | Loss | | 251 | 1118 | Unidirectional | [RFC8571] | 252 | | Residual Bandwidth | | 253 | 1119 | Unidirectional | [RFC8571] | 254 | | Available Bandwidth | | 255 | 1120 | Unidirectional | [RFC8571] | 256 | | Utilized Bandwidth | | 257 | 1173 | Extended | [I-D.ietf-idr-eag-distribution] | 258 | | Administrative | | 259 | | Group | | 260 +-----------+---------------------+---------------------------------+ 262 Table 1: BGP-LS Attribute TLVs also used as sub-TLVs of ASLA TLV 264 All the BGP-LS Attribute TLVs defined in the table above are 265 RECOMMENDED to continue to be advertised at the top-level in the BGP- 266 LS Attribute for carrying attributes specific to RSVP-TE without the 267 use of the ASLA TLV. 269 When a new link attribute is introduced, it may be thought of as 270 being specific to only a single application. However, subsequently, 271 it may be also shared by other applications and/or require 272 application-specific values. In such cases, it is RECOMMENDED to err 273 on the side of caution and define such attributes as application- 274 specific to ensure flexibility in the future. 276 BGP-LS Attribute TLVs corresponding to Link NLRI that are defined in 277 the future MUST specify if they are application-specific and hence 278 are REQUIRED to be encoded within an ASLA TLV. 280 Only application-specific link attributes need to be advertised 281 within the ASLA TLV. Link attributes that do not have application- 282 specific semantics MUST NOT be advertised within the ASLA TLV. 283 Receivers MUST ignore any non-application-specific attribute sub-TLVs 284 within the ASLA TLV. 286 When the same application-specific link attributes are advertised 287 both within the ASLA TLV and as top-level TLVs in the BGP-LS 288 Attribute, the attributes advertised within the ASLA TLV take 289 precedence for the applications indicated in the ASLA TLV encoding. 291 4. Procedures 293 The procedures described in this section apply to networks where all 294 BGP-LS originators and consumers support this specification. The 295 backward compatibility aspects and operations in deployments where 296 there are some BGP-LS originators or consumers that do not support 297 this specification are described further in Section 6. 299 The BGP-LS originator learns of the association of an application- 300 specific attribute to one or more applications from either the 301 underlying IGP protocol LSA/LSPs from which it is advertising the 302 topology information or from the local node configuration when 303 advertising attributes for the local node only. 305 The association of an application-specific link attribute with a 306 specific application context when advertising attributes for the 307 local node only (e.g., when running BGP as the only routing protocol) 308 is an implementation-specific matter and outside the scope of this 309 document. 311 [RFC8920] and [RFC8919] specify the mechanisms for advertising 312 application-specific link attributes in OSPFv2/v3 and IS-IS 313 respectively. These IGP specifications also describe the backward 314 compatibility aspects and the existing RSVP-TE/GMPLS specific TLV 315 encoding mechanisms in the respective protocols. 317 A BGP-LS originator node that is advertising link-state information 318 from the underlying IGP determines the protocol encoding of 319 application-specific link attributes based on the following rules: 321 1. Application-specific link attributes received from an IGP node 322 using existing RSVP-TE/GMPLS encodings MUST be encoded using the 323 respective BGP-LS top-level TLVs listed in Table 1. 325 2. Application-specific link attributes received from an OSPF node 326 using ASLA sub-TLV or from an IS-IS node using either ASLA sub- 327 TLV or ASLA SRLG TLV MUST be encoded in the BGP-LS ASLA TLV as 328 sub-TLVs. 330 3. In the case of IS-IS, the following specific procedures are to be 331 followed: 333 A. When application-specific link attributes are received from a 334 node with the L bit set in the ASLA sub-TLV and application 335 bits other than RSVP-TE are set in the application bit masks 336 then the application-specific link attributes advertised in 337 the corresponding legacy IS-IS TLVs/sub-TLVs MUST be encoded 338 within the BGP-LS ASLA TLV as sub-TLVs with the application 339 bits, other than the RSVP-TE bit, copied from the IS-IS ASLA 340 sub-TLV. The link attributes advertised in the legacy IS-IS 341 TLVs/sub-TLVs are also advertised in BGP-LS top-level TLVs 342 listed in Table 1. Note that this is true regardless of 343 whether the RSVP-TE bit was set in the IS-IS ASLA TLV/sub- 344 TLV. The same procedure also applies for the advertisement 345 of the SRLG values from the IS-IS ASLA SRLG TLV within the 346 BGP-LS SRLG TLV (1096) both at the top-level and within the 347 BGP-LS ASLA TLV. 349 B. When the ASLA sub-TLV has the RSVP-TE application bit set, 350 then the link attributes for the corresponding ASLA sub-TLV 351 MUST be encoded using the respective BGP-LS top-level TLVs 352 listed in Table 1. Similarly, when the ASLA SRLG TLV has the 353 RSVP-TE application bit set, then the SRLG values within it 354 MUST be encoded using the top-level BGP-LS SRLG TLV (1096). 356 C. A merge of the SRLG values advertised in IS-IS SRLG ASLA TLVs 357 and the other link attributes advertised in IS-IS ASLA sub- 358 TLVs, on a per-application basis, is REQUIRED for all 359 applications that have their bit set in the SABM/UDABM in at 360 least one of the aforementioned TLV types. When performing 361 this merge, only the TLVs with the application's bit set in 362 SABM/UDABM MUST be used when such TLVs are available from 363 either TLV types. If the bit for an application is set in 364 the SABM/UDABM of only one of the TLV types, then the 365 attributes from the other TLV type with zero-length 366 application bit mask MUST be also selected for that 367 application, if such TLV is available. Such merged link 368 attributes are advertised in a per application instance of 369 the BGP-LS ASLA TLV. 371 D. If the resulting set of merged link attributes and SRLG 372 values is common across multiple applications, they MAY be 373 advertised in a common BGP-LS ASLA TLV instance where the 374 bits for all such applications would be set in the 375 application bit mask. 377 E. Both the SRLG values from IS-IS ASLA SRLG TLVs and the link 378 attributes from IS-IS ASLA sub-TLVs, with the zero-length 379 application bit mask, MUST be advertised into a BGP-LS ASLA 380 TLV with a zero-length application bit mask, independent of 381 the merging described above. 383 F. [RFC8919] allows the advertisement of the Maximum Link 384 Bandwidth within an ASLA sub-TLV even though it is not an 385 application-specific attribute. However, when originating 386 the Maximum Link Bandwidth into BGP-LS, the attribute MUST be 387 encoded only in the top-level BGP-LS Maximum Link Bandwidth 388 TLV (1089) and the receiver MUST ignore them when advertised 389 within the BGP-LS ASLA TLV. 391 G. [RFC8919] also allows the advertisement of the Maximum 392 Reservable Link Bandwidth and the Unreserved Bandwidth within 393 an ASLA sub-TLV even though these attributes are specific to 394 RSVP-TE application. However, when originating the Maximum 395 Reservable Link Bandwidth and Unreserved Bandwidth into BGP- 396 LS, these attributes MUST be encoded only in the BGP-LS top- 397 level Maximum Reservable Link Bandwidth TLV (1090) and 398 Unreserved Bandwidth TLV (1091) respectively and not within 399 the BGP-LS ASLA TLV. 401 These rules ensure that a BGP-LS originator performs the 402 advertisement for all application-specific link attributes from the 403 IGP nodes that support or do not support the ASLA extension. 404 Furthermore, it also ensures that the top-level BGP-LS TLVs defined 405 for RSVP-TE and GMPLS applications continue to be used for 406 advertisement of their application-specific attributes. 408 A BGP-LS consumer node would normally receive all the application- 409 specific link attributes corresponding to RSVP-TE and GMPLS 410 applications as existing top-level BGP-LS TLVs while for other 411 applications they are encoded in ASLA TLV(s) with appropriate 412 applicable bit mask setting. A BGP-LS consumer that supports this 413 specification SHOULD prefer the application-specific attribute value 414 received via sub-TLVs within the ASLA TLV over the value received via 415 the top-level TLVs. 417 5. Deployment Considerations 419 SR Policy and LFA applications have been deployed in some networks 420 using the IGP link attributes defined originally for RSVP-TE as 421 discussed in [RFC8920] and [RFC8919]. The corresponding BGP-LS top- 422 level link attribute TLVs originally defined for RSVP-TE have also 423 been similarly used for SR Policy and LFA applications by BGP-LS 424 consumers. Such usage MAY continue without requiring the support of 425 the application-specific link attribute encodings described in this 426 document as long as the following conditions are met: 428 o The application is SR Policy or LFA and RSVP-TE is not deployed 429 anywhere in the network 431 o The application is SR Policy or LFA, RSVP-TE is deployed in the 432 network, and both the set of links on which SR Policy and/or LFA 433 advertisements are required and the attribute values used by SR 434 Policy and/or LFA on all such links is fully congruent with the 435 links and attribute values used by RSVP-TE 437 6. Backward Compatibility 439 The backward compatibility aspects for BGP-LS are associated with the 440 originators (i.e., nodes) and consumers (e.g., PCE, controllers, 441 applications, etc.) of the topology information. BGP-LS 442 implementations have been originating link attributes and consuming 443 them without any application-specific scoping prior to the extensions 444 specified in this document. 446 IGP backward compatibility aspects associated with application- 447 specific link attributes for RSVP-TE, SR Policy, and LFA applications 448 are discussed in the Backward Compatibility sections of [RFC8920] and 449 [RFC8919]. While those backward compatibility aspects ensure 450 compatibility of IGP advertisements, they also serve to ensure the 451 backward compatibility of the BGP-LS advertisements used by BGP-LS 452 consumers. In deployments where the BGP-LS originators or consumers 453 do not support the extensions specified in this document, the IGPs 454 need to continue to advertise link attributes intended for use by SR 455 Policy and LFA applications using the RSVP-TE/GMPLS encodings. This 456 allows BGP-LS advertisements to be consistent with the behavior prior 457 to the extensions defined in this document 459 It is RECOMMENDED that nodes that support this specification are 460 selected as originators of BGP-LS information when advertising the 461 link-state information from the IGPs. 463 7. IANA Considerations 465 This document requests assignment of code-points from the registry 466 "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and 467 Attribute TLVs" based on the table below which reflects the values 468 assigned via the early allocation process. The column "IS-IS TLV/ 469 Sub-TLV" defined in the registry does not require any value and 470 should be left empty. 472 +------------+------------------------------------------+----------+ 473 | Code Point | Description | Length | 474 +------------+------------------------------------------+----------+ 475 | 1122 | Application-Specific Link Attributes TLV | variable | 476 +------------+------------------------------------------+----------+ 478 8. Manageability Considerations 480 The new protocol extensions introduced in this document augment the 481 existing IGP topology information defined in [RFC7752]. Procedures 482 and protocol extensions defined in this document do not affect the 483 BGP protocol operations and management other than as discussed in the 484 Manageability Considerations section of [RFC7752]. Specifically, the 485 malformed NLRIs attribute tests in the Fault Management section of 486 [RFC7752] now encompasses the BGP-LS TLVs defined in this document. 488 The extensions specified in this document do not specify any new 489 configuration or monitoring aspects in BGP or BGP-LS. The 490 specification of BGP models is an ongoing work based on 491 [I-D.ietf-idr-bgp-model]. 493 9. Security Considerations 495 The procedures and protocol extensions defined in this document do 496 not affect the BGP security model. See the "Security Considerations" 497 section of [RFC4271] for a discussion of BGP security. Also, refer 498 to [RFC4272] and [RFC6952] for analyses of security issues for BGP. 499 Security considerations for acquiring and distributing BGP-LS 500 information are discussed in [RFC7752]. The TLVs introduced in this 501 document are used to propagate the application-specific link 502 attributes IGP extensions defined in [RFC8919] and [RFC8920]. It is 503 assumed that the IGP instances originating these TLVs will support 504 all the required security (as described in [RFC8919] and [RFC8920]) 505 in order to prevent any security issues when propagating the TLVs 506 into BGP-LS. The advertisement of the link attribute information 507 defined in this document presents no significant additional risk 508 beyond that associated with the existing link attribute information 509 already supported in [RFC7752]. 511 10. Acknowledgements 513 The authors would like to thank Les Ginsberg, Baalajee S, Amalesh 514 Maity, Acee Lindem, Keyur Patel, Paul Wouters, and Rudy Selderslaghs 515 for their review and feedback on this document. 517 11. References 519 11.1. Normative References 521 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 522 Requirement Levels", BCP 14, RFC 2119, 523 DOI 10.17487/RFC2119, March 1997, 524 . 526 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 527 S. Ray, "North-Bound Distribution of Link-State and 528 Traffic Engineering (TE) Information Using BGP", RFC 7752, 529 DOI 10.17487/RFC7752, March 2016, 530 . 532 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 533 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 534 May 2017, . 536 [RFC8919] Ginsberg, L., Psenak, P., Previdi, S., Henderickx, W., and 537 J. Drake, "IS-IS Application-Specific Link Attributes", 538 RFC 8919, DOI 10.17487/RFC8919, October 2020, 539 . 541 [RFC8920] Psenak, P., Ed., Ginsberg, L., Henderickx, W., Tantsura, 542 J., and J. Drake, "OSPF Application-Specific Link 543 Attributes", RFC 8920, DOI 10.17487/RFC8920, October 2020, 544 . 546 11.2. Informative References 548 [I-D.ietf-idr-bgp-model] 549 Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP 550 YANG Model for Service Provider Networks", draft-ietf-idr- 551 bgp-model-10 (work in progress), November 2020. 553 [I-D.ietf-idr-eag-distribution] 554 Tantsura, J., Wang, Z., Wu, Q., and K. Talaulikar, 555 "Distribution of Traffic Engineering Extended 556 Administrative Groups using BGP-LS", draft-ietf-idr-eag- 557 distribution-19 (work in progress), June 2021. 559 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 560 dual environments", RFC 1195, DOI 10.17487/RFC1195, 561 December 1990, . 563 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 564 DOI 10.17487/RFC2328, April 1998, 565 . 567 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 568 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 569 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 570 . 572 [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions 573 in Support of Generalized Multi-Protocol Label Switching 574 (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, 575 . 577 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 578 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 579 DOI 10.17487/RFC4271, January 2006, 580 . 582 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 583 RFC 4272, DOI 10.17487/RFC4272, January 2006, 584 . 586 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 587 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 588 DOI 10.17487/RFC5286, September 2008, 589 . 591 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 592 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 593 . 595 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 596 BGP, LDP, PCEP, and MSDP Issues According to the Keying 597 and Authentication for Routing Protocols (KARP) Design 598 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 599 . 601 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 602 Decraene, B., Litkowski, S., and R. Shakir, "Segment 603 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 604 July 2018, . 606 [RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and 607 C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of 608 IGP Traffic Engineering Performance Metric Extensions", 609 RFC 8571, DOI 10.17487/RFC8571, March 2019, 610 . 612 Authors' Addresses 614 Ketan Talaulikar (editor) 615 Cisco Systems 616 India 618 Email: ketant@cisco.com 620 Peter Psenak 621 Cisco Systems 622 Slovakia 624 Email: ppsenak@cisco.com 626 Jeff Tantsura 627 Microsoft 629 Email: jefftant.ietf@gmail.com