idnits 2.17.1 draft-ietf-idr-bgp-ls-flex-algo-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 7, 2021) is 1052 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 (-16) exists of draft-ietf-idr-bgp-ls-app-specific-attr-06 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-16 ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) == Outdated reference: A later version (-17) exists of draft-ietf-idr-bgp-model-10 == Outdated reference: A later version (-14) exists of draft-ietf-idr-bgpls-srv6-ext-07 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-13 Summary: 1 error (**), 0 flaws (~~), 6 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 9, 2021 S. Zandi 6 G. Dawra 7 LinkedIn 8 June 7, 2021 10 Flexible Algorithm Definition Advertisement with BGP Link-State 11 draft-ietf-idr-bgp-ls-flex-algo-07 13 Abstract 15 Flexible Algorithm is a solution that allows routing protocols (viz. 16 OSPF and IS-IS) to compute paths over a network based on user-defined 17 (and hence, flexible) constraints and metrics. The computation is 18 performed by routers participating in the specific network in a 19 distribute manner using a Flex Algorithm definition. This definition 20 provisioned on one or more routers and propagated (viz. OSPF and IS- 21 IS flooding) through the network. 23 BGP Link-State (BGP-LS) enables the collection of various topology 24 information from the network. This draft defines extensions to BGP- 25 LS address-family to advertise the Flexible Algorithm Definition as a 26 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 9, 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 . . . . . . . . . . . . . . . . . . 4 64 2. BGP-LS Extensions for Flex Algo . . . . . . . . . . . . . . . 4 65 3. Flexible Algorithm Definition . . . . . . . . . . . . . . . . 5 66 3.1. Flex Algo Exclude Any Affinity . . . . . . . . . . . . . 6 67 3.2. Flex Algo Include Any Affinity . . . . . . . . . . . . . 7 68 3.3. Flex Algo Include All Affinity . . . . . . . . . . . . . 7 69 3.4. Flex Algo Definition Flags . . . . . . . . . . . . . . . 8 70 3.5. Flex Algo Exclude SRLG . . . . . . . . . . . . . . . . . 9 71 3.6. Flex Algo Unknown . . . . . . . . . . . . . . . . . . . . 10 72 4. Flex Algorithm Prefix Metric . . . . . . . . . . . . . . . . 11 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 74 6. Manageability Considerations . . . . . . . . . . . . . . . . 12 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 76 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 79 9.2. Informative References . . . . . . . . . . . . . . . . . 14 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 82 1. Introduction 84 IGP protocols (OSPF and IS-IS) traditionally compute best paths over 85 the network based on the IGP metric assigned to the links. Many 86 network deployments use RSVP-TE [RFC3209] based or Segment Routing 87 (SR) Policy [RFC8402] based solutions to enforce traffic over a path 88 that is computed using different metrics or constraints than the 89 shortest IGP path. [I-D.ietf-lsr-flex-algo] defines the Flexible 90 Algorithm solution that allows IGPs themselves to compute constraint 91 based paths over the network. 93 Flexible Algorithm is called so as it allows a user the flexibility 94 to define 96 o the type of calculation to be used (e.g. shortest path) 98 o the metric type to be used (e.g. IGP metric or TE metric) 100 o the set of constraints to be used (e.g. inclusion or exclusion of 101 certain links using affinities) 103 The operations of the flexible algorithm solution are described in 104 detail in [I-D.ietf-lsr-flex-algo] and a high-level summary of the 105 same is described here for clarity. The network operator enables the 106 participation of specific nodes in the network for a specific 107 algorithm and then provisions the definition of that flexible 108 algorithm on one or more of these nodes. The nodes where the 109 flexible algorithm definition (FAD) is advertised then flood these 110 definitions via respective IGP (IS-IS and OSPFv2/v3) mechanisms to 111 all other nodes in the network. The nodes select the definition for 112 each algorithm based on the flooded information in a deterministic 113 manner and thus all nodes participating in a flexible algorithm 114 computation arrive at a common understanding of the type of 115 calculation that they need to use. 117 When using Segment Routing (SR) [RFC8402] MPLS forwarding plane 118 [RFC8660], the result of a flex algorithm computation is the 119 provisioning of the Prefix SIDs associated with that algorithm with 120 paths based on the topology computed based on that algorithm's 121 definition. When using SR over IPv6 (SRv6) [RFC8986], the result of 122 a flex algorithm computation is the provisioning of the SRv6 Locators 123 associated with that algorithm with paths based on the topology 124 computed based on that algorithm. This flex algorithm computation is 125 within an IGP area or level similar to the default shortest path tree 126 (SPT) algorithm. 128 A flex algorithm specific metric MAY be advertised along with the 129 prefix as described in [I-D.ietf-lsr-flex-algo] to enable end-to-end 130 optimal path computation for prefixes across multiple areas/domains 131 in the flex algorithm computation for the SR-MPLS forwarding plane. 133 The BGP-LS extensions for SR are defined in 134 [I-D.ietf-idr-bgp-ls-segment-routing-ext] and 135 [I-D.ietf-idr-bgpls-srv6-ext]. They include the 137 o SR Algorithm TLV to indicate the participation of a node in a flex 138 algorithm computation 140 o Prefix SID TLV to indicate the association of the Prefix-SIDs to a 141 specific flex algorithm for SR-MPLS forwarding 143 o SRv6 Locator TLV to indicate the Locator for specific flex 144 algorithm for SRv6 forwarding 146 Thus a controller or a Path Computation Engine (PCE) is aware of the 147 IGP topology across multiple domains which includes the above 148 information related to the flexible algorithm. This draft defines 149 extensions to BGP-LS for carrying the FAD information so that it 150 enables the controller/PCE to learn the mapping of the flex algorithm 151 number to its definition in each area/domain of the underlying IGP. 152 The controller/PCE also learns the type of computation used and the 153 constraints for the same. This information can then be leveraged by 154 it for setting up SR Policy paths end to end across domains by 155 leveraging the appropriate Flex Algorithm specific SIDs in its 156 Segment List [I-D.ietf-spring-segment-routing-policy]. e.g. picking 157 the Flex Algorithm Prefix SID (in case of SR-MPLS) or End SID (in 158 case of SRv6) of ABRs/ASBRs corresponding to a definition that 159 optimizes on the delay metric enables the PCE/controller to build an 160 end to end low latency path across IGP domains with minimal SIDs in 161 the SID list. 163 1.1. Requirements Language 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 167 "OPTIONAL" in this document are to be interpreted as described in BCP 168 14 [RFC2119] [RFC8174] when, and only when, they appear in all 169 capitals, as shown here. 171 2. BGP-LS Extensions for Flex Algo 173 The BGP-LS [RFC7752] specifies the Node NLRI for the advertisement of 174 nodes along with their attributes using the BGP-LS Attribute, the 175 Link NLRI for the advertisement of links along with their attributes 176 using the BGP-LS Attribute and the Prefix NLRI for the advertisement 177 of prefixes along with their attributes using the BGP-LS Attribute. 179 The FAD advertised by a node is considered as its node level 180 attributes and advertised as such. 182 Various link attributes like affinities and SRLGs used during the 183 Flex-Algorithm path calculations in IS-IS and OSPF are advertised in 184 those protocols using the Application Specific Link Attribute (ASLA) 185 advertisements as described in [I-D.ietf-lsr-flex-algo]. The BGP-LS 186 extensions for ASLA advertisements 187 [I-D.ietf-idr-bgp-ls-app-specific-attr] MUST be used for the 188 advertisement of these Flex-Algorithm application-specific link 189 attributes from the underlying IGP protocols using the Flexible 190 Algorithm application specific bit defined in 191 [I-D.ietf-lsr-flex-algo]. 193 The Flexible Algorithm Prefix Metric (FAPM) are considered as prefix 194 attributes and advertised as such. 196 3. Flexible Algorithm Definition 198 This document defines a new optional BGP-LS Attribute TLV associated 199 with the Node NLRI called the Flexible Algorithm Definition (FAD) TLV 200 and its format is as follows: 202 0 1 2 3 203 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 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Type | Length | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 |Flex-Algorithm | Metric-Type | Calc-Type | Priority | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | sub-TLVs ... // 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 Figure 1: Flex Algorithm Definition TLV 214 where: 216 o Type: 1039 218 o Length: variable. Minimum of 4 octets. 220 o Flex-Algorithm : 1 octet value in the range between 128 and 255 221 inclusive which is the range defined for Flexible Algorithms in 222 the IANA "IGP Parameters" registries under the "IGP Algorithm 223 Types" registry [I-D.ietf-lsr-flex-algo]. 225 o Metric-Type : 1 octet value indicating the type of metric used in 226 the computation. Values allowed come from the IANA "IGP 227 Parameters" registries under the "Flexible Algorithm Definition 228 Metric-Type" registry [I-D.ietf-lsr-flex-algo]. 230 o Calculation-Type : 1 octet value in the range between 0 and 127 231 inclusive which is the range defined for the standard algorithms 232 in the IANA "IGP Parameters" registries under the "IGP Algorithm 233 Types" registry [I-D.ietf-lsr-flex-algo]. 235 o Priority : 1 octet value between 0 and 255 inclusive that 236 specifies the priority of the FAD. 238 o sub-TLVs : zero or more sub-TLVs may be included as described 239 further in this section. 241 The FAD TLV can only be added to the BGP-LS Attribute of the Node 242 NLRI if the corresponding node originates the underlying IGP TLV/sub- 243 TLV as described below. This information is derived from the 244 protocol specific advertisements as below. 246 o IS-IS, as defined by the ISIS Flexible Algorithm Definition sub- 247 TLV in [I-D.ietf-lsr-flex-algo]. 249 o OSPFv2/OSPFv3, as defined by the OSPF Flexible Algorithm 250 Definition TLV in [I-D.ietf-lsr-flex-algo]. 252 The BGP-LS Attribute associated with a Node NLRI MAY include one or 253 more FAD TLVs corresponding to the FAD for each algorithm that the 254 particular node is advertising. 256 The following sub-sections define the sub-TLVs for the FAD TLV. 258 3.1. Flex Algo Exclude Any Affinity 260 The Flex Algo Exclude Any Affinity sub-TLV is an optional sub-TLV 261 that is used to carry the affinity constraints [RFC2702] associated 262 with the FAD and enable the exclusion of links carrying any of the 263 specified affinities from the computation of the specific algorithm 264 as described in [I-D.ietf-lsr-flex-algo]. The affinity is expressed 265 in terms of Extended Admin Group (EAG) as defined in [RFC7308]. 267 The sub-TLV has the following format: 269 0 1 2 3 270 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 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Type | Length | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Exclude-Any EAG (variable) // 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 where: 279 o Type: 1040 281 o Length: variable, dependent on the size of the Extended Admin 282 Group. MUST be a multiple of 4 octets. 284 o Exclude-Any EAG : the bitmask used to represent the affinities to 285 be excluded. 287 The information in the Flex Algo Exclude Any Affinity sub-TLV is 288 derived from the IS-IS and OSPF protocol specific Flexible Algorithm 289 Exclude Admin Group sub-TLV as defined in [I-D.ietf-lsr-flex-algo]. 291 3.2. Flex Algo Include Any Affinity 293 The Flex Algo Include Any Affinity sub-TLV is an optional sub-TLV 294 that is used to carry the affinity constraints [RFC2702] associated 295 with the FAD and enable the inclusion of links carrying any of the 296 specified affinities in the computation of the specific algorithm as 297 described in [I-D.ietf-lsr-flex-algo]. The affinity is expressed in 298 terms of Extended Admin Group (EAG) as defined in [RFC7308]. 300 The sub-TLV has the following format: 302 0 1 2 3 303 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 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Type | Length | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Include-Any EAG (variable) // 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 where: 312 o Type: 1041 314 o Length: variable, dependent on the size of the Extended Admin 315 Group. MUST be a multiple of 4 octets. 317 o Include-Any EAG : the bitmask used to represent the affinities to 318 be included. 320 The information in the Flex Algo Include Any Affinity sub-TLV is 321 derived from the IS-IS and OSPF protocol specific Flexible Algorithm 322 Include-Any Admin Group sub-TLV as defined in 323 [I-D.ietf-lsr-flex-algo]. 325 3.3. Flex Algo Include All Affinity 327 The Flex Algo Include All Affinity sub-TLV is an optional sub-TLV 328 that is used to carry the affinity constraints [RFC2702] associated 329 with the FAD and enable the inclusion of links carrying all of the 330 specified affinities in the computation of the specific algorithm as 331 described in [I-D.ietf-lsr-flex-algo]. The affinity is expressed in 332 terms of Extended Admin Group (EAG) as defined in [RFC7308]. 334 The sub-TLV has the following format: 336 0 1 2 3 337 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 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Type | Length | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Include-All EAG (variable) // 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 where: 346 o Type: 1042 348 o Length: variable, dependent on the size of the Extended Admin 349 Group. MUST be a multiple of 4 octets. 351 o Include-All EAG : the bitmask used to represent the affinities to 352 be included. 354 The information in the Flex Algo Include All Affinity sub-TLV is 355 derived from the IS-IS and OSPF protocol specific Flexible Algorithm 356 Include-All Admin Group sub-TLV as defined in 357 [I-D.ietf-lsr-flex-algo]. 359 3.4. Flex Algo Definition Flags 361 The Flex Algo Definition Flags sub-TLV is an optional sub-TLV that is 362 used to carry the flags associated with the FAD that are used in the 363 computation of the specific algorithm as described in 364 [I-D.ietf-lsr-flex-algo]. 366 The sub-TLV has the following format: 368 0 1 2 3 369 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 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | Type | Length | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Flags (variable) // 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 where: 378 o Type: 1043 379 o Length: variable. MUST be a multiple of 4 octets. 381 o Flags : the bitmask used to represent the flags for the FAD as 382 introduced by [I-D.ietf-lsr-flex-algo] and listed in the "Flex- 383 Algorithm Definition Flags" registry under the "Interior Gateway 384 Protocol (IGP) Parameters" IANA registry. 386 The information in the Flex Algo Definition Flags sub-TLV is derived 387 from the IS-IS and OSPF protocol specific Flexible Algorithm 388 Definition Flags sub-TLV as defined in [I-D.ietf-lsr-flex-algo]. 390 3.5. Flex Algo Exclude SRLG 392 The Flex Algo Exclude SRLG sub-TLV is an optional sub-TLV that is 393 used to carry the shared risk link group (SRLG) [RFC4202] information 394 associated with the FAD and enable the exclusion of links that are 395 associated with any of the specified SRLG in the computation of the 396 specific algorithm as described in [I-D.ietf-lsr-flex-algo]. The 397 SRLGs associated with a link are carried in the BGP-LS Shared Link 398 Risk Group (TLV 1096) [RFC7752]. 400 The sub-TLV has the following format: 402 0 1 2 3 403 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 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | Type | Length | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Shared Risk Link Group Values (variable) // 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 where: 412 o Type: 1045 414 o Length: variable, dependent on the number of SRLG values. MUST be 415 a multiple of 4 octets. 417 o SRLG Values : One or more SRLG values, each of 4 octet size, as 418 defined in [RFC4202]. 420 The information in the Flex Algo SRLG Exclude sub-TLV is derived from 421 the IS-IS and OSPF protocol specific Flexible Algorithm Exclude SRLG 422 sub-TLV as defined in [I-D.ietf-lsr-flex-algo]. 424 3.6. Flex Algo Unknown 426 The OSPF and ISIS signaling for FAD allows for extensions via new 427 sub-TLVs under the respective IGP's Flex Algorithm Definition TLV. 428 As specified in section 5.3 of [I-D.ietf-lsr-flex-algo], it is 429 important that the entire FAD be understood by anyone using it for 430 computation purposes. Therefore the FAD is different from most other 431 protocol extensions where the skipping or ignoring of unknown or 432 unsupported sub-TLV information does not affect the base behavior. 434 The Flex Algo Unknown sub-TLV is an optional sub-TLV that is used to 435 indicate the presence of unknown or unsupported FAD sub-TLVs. The 436 need for this sub-TLV arises when the BGP-LS implementation on the 437 advertising node does not support one or more of the FAD sub-TLVs 438 present in the IGP advertisement. 440 The sub-TLV has the following format: 442 0 1 2 3 443 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 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | Type | Length | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | Protocol-ID | sub-TLV types (variable) ... 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 where: 452 o Type: TBD 454 o Length: variable 456 o Protocol-ID: Indicates the BGP-LS Protocol-ID of the protocol from 457 which the FAD is being advertised via BGP-LS. The values are from 458 the "BGP-LS Protocol-IDs" registry under the IANA BGP-LS 459 Parameters registry. 461 o Sub-TLV Types : Zero or more sub-TLV types that are unknown or 462 unsupported by the node originating the BGP-LS advertisement. The 463 size of each sub-TLV type depends on the protocol indicated by the 464 Protocol-ID field e.g., for ISIS each sub-TLV type would be of 465 size 1 byte while for OSPF each sub-TLV type would be of size 2 466 bytes. 468 The discussion on the use of the FAD information by the consumers of 469 the BGP-LS information is beyond the scope of this document. 470 However, it is RECOMMENDED that the choice of the node used for 471 originating the IGP topology information into BGP-LS be made such 472 that the advertising node supports all the FAD extensions in use in 473 its part of the network. This avoids the scenario where an 474 incomplete FAD gets advertised via BGP-LS. 476 The node originating the advertisement SHOULD include the Flex Algo 477 Unknown sub-TLV when it comes across an unsupported or unknown sub- 478 TLV in the corresponding FAD in the IS-IS and OSPF advertisement. 479 This serves as an indication that the FAD information in BGP-LS is 480 incomplete and is not usable for computation purposes. When 481 advertising the Flex Algo Unknown sub-TLV, the protocol specific sub- 482 TLV types that are unsupported or unknown SHOULD be included. This 483 information serves as a diagnostic aid. 485 4. Flex Algorithm Prefix Metric 487 This document defines a new optional BGP-LS Attribute TLV associated 488 with the Prefix NLRI called the Flexible Algorithm Prefix Metric 489 (FAPM) TLV and its format is as follows: 491 0 1 2 3 492 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 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Type | Length | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 |Flex-Algorithm | Flags | Reserved | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | Metric | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 where: 503 o Type: 1044 505 o Length: 8 octets. 507 o Flex-Algorithm : 1 octet value in the range between 128 and 255 508 inclusive which is the range defined for Flexible Algorithms in 509 the IANA "IGP Parameters" registries under the "IGP Algorithm 510 Types" registry [I-D.ietf-lsr-flex-algo]. 512 o Flags: single octet value and only applicable for OSPF as defined 513 in [I-D.ietf-lsr-flex-algo]. The value MUST be set to 0 for ISIS 514 and ignored by the receiver. 516 o Reserved : 2 octet value that SHOULD be set to 0 by the originator 517 and MUST be ignored by the receiver. 519 o Metric : 4 octets field to carry the metric information. 521 The FAPM TLV can be added to the BGP-LS Attribute of the Prefix NLRI 522 originated by a node, only if the corresponding node originates the 523 Prefix in along with the underlying IGP TLV/sub-TLV as described 524 below. This information is derived from the protocol specific 525 advertisements as below. 527 o IS-IS, as defined by the ISIS Flexible Algorithm Prefix Metric 528 sub-TLV in [I-D.ietf-lsr-flex-algo]. 530 o OSPFv2/OSPFv3, as defined by the OSPF Flexible Algorithm Prefix 531 Metric sub-TLV in [I-D.ietf-lsr-flex-algo]. 533 The BGP-LS Attribute associated with a Prefix NLRI MAY include one or 534 more FAPM TLVs corresponding to the Flexible Algorithm Prefix Metric 535 for each algorithm associated with that particular prefix. 537 5. IANA Considerations 539 This document requests assigning code-points from the registry "BGP- 540 LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute 541 TLVs" based on the table below which reflects the values 544 assigned via the early allocation process. The column "IS-IS TLV/ 545 Sub-TLV" defined in the registry does not require any value and 546 should be left empty. 548 +------------+----------------------------------------+----------+ 549 | Code Point | Description | Length | 550 +------------+----------------------------------------+----------+ 551 | 1039 | Flex Algorithm Definition TLV | variable | 552 | 1040 | Flex Algo Exclude Any Affinity sub-TLV | variable | 553 | 1041 | Flex Algo Include Any Affinity sub-TLV | variable | 554 | 1042 | Flex Algo Include All Affinity sub-TLV | variable | 555 | 1043 | Flex Algo Definition Flags sub-TLV | variable | 556 | 1044 | Flex Algorithm Prefix Metric TLV | variable | 557 | 1045 | Flex Algorithm Exclude SRLG sub-TLV | variable | 558 | TBD | Flex Algorithm Unknown sub-TLV | variable | 559 +------------+----------------------------------------+----------+ 561 6. Manageability Considerations 563 The new protocol extensions introduced in this document augment the 564 existing IGP topology information that was distributed via [RFC7752]. 565 Procedures and protocol extensions defined in this document do not 566 affect the BGP protocol operations and management other than as 567 discussed in the Manageability Considerations section of [RFC7752]. 569 Specifically, the malformed NLRIs attribute tests in the Fault 570 Management section of [RFC7752] now encompass the new TLVs for the 571 BGP-LS NLRI in this document. 573 The extensions specified in this document do not specify any new 574 configuration or monitoring aspects in BGP or BGP-LS. The 575 specification of BGP models is an ongoing work based on 576 [I-D.ietf-idr-bgp-model]. 578 7. Security Considerations 580 The procedures and protocol extensions defined in this document do 581 not affect the BGP security model. See the "Security Considerations" 582 section of [RFC4271] for a discussion of BGP security. Also, refer 583 to [RFC4272] and [RFC6952] for analyses of security issues for BGP. 584 Security considerations for acquiring and distributing BGP-LS 585 information are discussed in [RFC7752]. The TLVs introduced in this 586 document are used to propagate the IGP Flexible Algorithm extensions 587 defined in [I-D.ietf-lsr-flex-algo]. It is assumed that the IGP 588 instances originating these TLVs will support all the required 589 security (as described in [I-D.ietf-lsr-flex-algo]) in order to 590 prevent any security issues when propagating the TLVs into BGP-LS. 591 The advertisement of the node and prefix attribute information 592 defined in this document presents no significant additional risk 593 beyond that associated with the existing node and prefix attribute 594 information already supported in [RFC7752]. 596 8. Acknowledgements 598 The authors would like to thank Les Ginsberg, Amalesh Maity and Y F 599 Siu for his reviews and contributions to this work. 601 9. References 603 9.1. Normative References 605 [I-D.ietf-idr-bgp-ls-app-specific-attr] 606 Talaulikar, K., Psenak, P., and J. Tantsura, "Application- 607 Specific Attributes Advertisement with BGP Link-State", 608 draft-ietf-idr-bgp-ls-app-specific-attr-06 (work in 609 progress), May 2021. 611 [I-D.ietf-lsr-flex-algo] 612 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 613 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 614 algo-16 (work in progress), May 2021. 616 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 617 Requirement Levels", BCP 14, RFC 2119, 618 DOI 10.17487/RFC2119, March 1997, 619 . 621 [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions 622 in Support of Generalized Multi-Protocol Label Switching 623 (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, 624 . 626 [RFC7308] Osborne, E., "Extended Administrative Groups in MPLS 627 Traffic Engineering (MPLS-TE)", RFC 7308, 628 DOI 10.17487/RFC7308, July 2014, 629 . 631 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 632 S. Ray, "North-Bound Distribution of Link-State and 633 Traffic Engineering (TE) Information Using BGP", RFC 7752, 634 DOI 10.17487/RFC7752, March 2016, 635 . 637 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 638 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 639 May 2017, . 641 9.2. Informative References 643 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 644 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 645 and M. Chen, "BGP Link-State extensions for Segment 646 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-18 647 (work in progress), April 2021. 649 [I-D.ietf-idr-bgp-model] 650 Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP 651 YANG Model for Service Provider Networks", draft-ietf-idr- 652 bgp-model-10 (work in progress), November 2020. 654 [I-D.ietf-idr-bgpls-srv6-ext] 655 Dawra, G., Filsfils, C., Talaulikar, K., Chen, M., 656 Bernier, D., and B. Decraene, "BGP Link State Extensions 657 for SRv6", draft-ietf-idr-bgpls-srv6-ext-07 (work in 658 progress), March 2021. 660 [I-D.ietf-spring-segment-routing-policy] 661 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 662 P. Mattes, "Segment Routing Policy Architecture", draft- 663 ietf-spring-segment-routing-policy-13 (work in progress), 664 May 2021. 666 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 667 McManus, "Requirements for Traffic Engineering Over MPLS", 668 RFC 2702, DOI 10.17487/RFC2702, September 1999, 669 . 671 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 672 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 673 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 674 . 676 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 677 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 678 DOI 10.17487/RFC4271, January 2006, 679 . 681 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 682 RFC 4272, DOI 10.17487/RFC4272, January 2006, 683 . 685 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 686 BGP, LDP, PCEP, and MSDP Issues According to the Keying 687 and Authentication for Routing Protocols (KARP) Design 688 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 689 . 691 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 692 Decraene, B., Litkowski, S., and R. Shakir, "Segment 693 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 694 July 2018, . 696 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 697 Decraene, B., Litkowski, S., and R. Shakir, "Segment 698 Routing with the MPLS Data Plane", RFC 8660, 699 DOI 10.17487/RFC8660, December 2019, 700 . 702 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 703 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 704 (SRv6) Network Programming", RFC 8986, 705 DOI 10.17487/RFC8986, February 2021, 706 . 708 Authors' Addresses 710 Ketan Talaulikar (editor) 711 Cisco Systems 712 India 714 Email: ketant@cisco.com 716 Peter Psenak 717 Cisco Systems 718 Slovakia 720 Email: ppsenak@cisco.com 722 Shawn Zandi 723 LinkedIn 724 USA 726 Email: szandi@linkedin.com 728 Gaurav Dawra 729 LinkedIn 730 USA 732 Email: gdawra.ietf@gmail.com