idnits 2.17.1 draft-ietf-idr-bgp-ls-flex-algo-08.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 (November 10, 2021) is 898 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-08 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-18 ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) == Outdated reference: A later version (-17) exists of draft-ietf-idr-bgp-model-12 == Outdated reference: A later version (-14) exists of draft-ietf-idr-bgpls-srv6-ext-09 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-14 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: May 14, 2022 S. Zandi 6 G. Dawra 7 LinkedIn 8 November 10, 2021 10 Flexible Algorithm Definition Advertisement with BGP Link-State 11 draft-ietf-idr-bgp-ls-flex-algo-08 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 May 14, 2022. 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 . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . . . . 15 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 [RFC9085] and 134 [I-D.ietf-idr-bgpls-srv6-ext]. They include the 136 o SR Algorithm TLV to indicate the participation of a node in a flex 137 algorithm computation 139 o Prefix SID TLV to indicate the association of the Prefix-SIDs to a 140 specific flex algorithm for SR-MPLS forwarding 142 o SRv6 Locator TLV to indicate the Locator for specific flex 143 algorithm for SRv6 forwarding 145 Thus a controller or a Path Computation Engine (PCE) is aware of the 146 IGP topology across multiple domains which includes the above 147 information related to the flexible algorithm. This draft defines 148 extensions to BGP-LS for carrying the FAD information so that it 149 enables the controller/PCE to learn the mapping of the flex algorithm 150 number to its definition in each area/domain of the underlying IGP. 151 The controller/PCE also learns the type of computation used and the 152 constraints for the same. This information can then be leveraged by 153 it for setting up SR Policy paths end to end across domains by 154 leveraging the appropriate Flex Algorithm specific SIDs in its 155 Segment List [I-D.ietf-spring-segment-routing-policy]. e.g. picking 156 the Flex Algorithm Prefix SID (in case of SR-MPLS) or End SID (in 157 case of SRv6) of ABRs/ASBRs corresponding to a definition that 158 optimizes on the delay metric enables the PCE/controller to build an 159 end to end low latency path across IGP domains with minimal SIDs in 160 the SID list. 162 1.1. Requirements Language 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 166 "OPTIONAL" in this document are to be interpreted as described in BCP 167 14 [RFC2119] [RFC8174] when, and only when, they appear in all 168 capitals, as shown here. 170 2. BGP-LS Extensions for Flex Algo 172 The BGP-LS [RFC7752] specifies the Node NLRI for the advertisement of 173 nodes along with their attributes using the BGP-LS Attribute, the 174 Link NLRI for the advertisement of links along with their attributes 175 using the BGP-LS Attribute and the Prefix NLRI for the advertisement 176 of prefixes along with their attributes using the BGP-LS Attribute. 178 The FAD advertised by a node is considered as its node level 179 attributes and advertised as such. 181 Various link attributes like affinities and SRLGs used during the 182 Flex-Algorithm path calculations in IS-IS and OSPF are advertised in 183 those protocols using the Application Specific Link Attribute (ASLA) 184 advertisements as described in [I-D.ietf-lsr-flex-algo]. The BGP-LS 185 extensions for ASLA advertisements 186 [I-D.ietf-idr-bgp-ls-app-specific-attr] MUST be used for the 187 advertisement of these Flex-Algorithm application-specific link 188 attributes from the underlying IGP protocols using the Flexible 189 Algorithm application specific bit defined in 190 [I-D.ietf-lsr-flex-algo]. 192 The Flexible Algorithm Prefix Metric (FAPM) are considered as prefix 193 attributes and advertised as such. 195 3. Flexible Algorithm Definition 197 This document defines a new optional BGP-LS Attribute TLV associated 198 with the Node NLRI called the Flexible Algorithm Definition (FAD) TLV 199 and its format is as follows: 201 0 1 2 3 202 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 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Type | Length | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 |Flex-Algorithm | Metric-Type | Calc-Type | Priority | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | sub-TLVs ... // 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 Figure 1: Flex Algorithm Definition TLV 213 where: 215 o Type: 1039 217 o Length: variable. Minimum of 4 octets. 219 o Flex-Algorithm : 1 octet value in the range between 128 and 255 220 inclusive which is the range defined for Flexible Algorithms in 221 the IANA "IGP Parameters" registries under the "IGP Algorithm 222 Types" registry [I-D.ietf-lsr-flex-algo]. 224 o Metric-Type : 1 octet value indicating the type of metric used in 225 the computation. Values allowed come from the IANA "IGP 226 Parameters" registries under the "Flexible Algorithm Definition 227 Metric-Type" registry [I-D.ietf-lsr-flex-algo]. 229 o Calculation-Type : 1 octet value in the range between 0 and 127 230 inclusive which is the range defined for the standard algorithms 231 in the IANA "IGP Parameters" registries under the "IGP Algorithm 232 Types" registry [I-D.ietf-lsr-flex-algo]. 234 o Priority : 1 octet value between 0 and 255 inclusive that 235 specifies the priority of the FAD. 237 o sub-TLVs : zero or more sub-TLVs may be included as described 238 further in this section. 240 The FAD TLV can only be added to the BGP-LS Attribute of the Node 241 NLRI if the corresponding node originates the underlying IGP TLV/sub- 242 TLV as described below. This information is derived from the 243 protocol specific advertisements as below. 245 o IS-IS, as defined by the ISIS Flexible Algorithm Definition sub- 246 TLV in [I-D.ietf-lsr-flex-algo]. 248 o OSPFv2/OSPFv3, as defined by the OSPF Flexible Algorithm 249 Definition TLV in [I-D.ietf-lsr-flex-algo]. 251 The BGP-LS Attribute associated with a Node NLRI MAY include one or 252 more FAD TLVs corresponding to the FAD for each algorithm that the 253 particular node is advertising. 255 The following sub-sections define the sub-TLVs for the FAD TLV. 257 3.1. Flex Algo Exclude Any Affinity 259 The Flex Algo Exclude Any Affinity sub-TLV is an optional sub-TLV 260 that is used to carry the affinity constraints [RFC2702] associated 261 with the FAD and enable the exclusion of links carrying any of the 262 specified affinities from the computation of the specific algorithm 263 as described in [I-D.ietf-lsr-flex-algo]. The affinity is expressed 264 in terms of Extended Admin Group (EAG) as defined in [RFC7308]. 266 The sub-TLV has the following format: 268 0 1 2 3 269 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 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Type | Length | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | Exclude-Any EAG (variable) // 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 where: 278 o Type: 1040 280 o Length: variable, dependent on the size of the Extended Admin 281 Group. MUST be a multiple of 4 octets. 283 o Exclude-Any EAG : the bitmask used to represent the affinities to 284 be excluded. 286 The information in the Flex Algo Exclude Any Affinity sub-TLV is 287 derived from the IS-IS and OSPF protocol specific Flexible Algorithm 288 Exclude Admin Group sub-TLV as defined in [I-D.ietf-lsr-flex-algo]. 290 3.2. Flex Algo Include Any Affinity 292 The Flex Algo Include Any Affinity sub-TLV is an optional sub-TLV 293 that is used to carry the affinity constraints [RFC2702] associated 294 with the FAD and enable the inclusion of links carrying any of the 295 specified affinities in the computation of the specific algorithm as 296 described in [I-D.ietf-lsr-flex-algo]. The affinity is expressed in 297 terms of Extended Admin Group (EAG) as defined in [RFC7308]. 299 The sub-TLV has the following format: 301 0 1 2 3 302 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 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Type | Length | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Include-Any EAG (variable) // 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 where: 311 o Type: 1041 313 o Length: variable, dependent on the size of the Extended Admin 314 Group. MUST be a multiple of 4 octets. 316 o Include-Any EAG : the bitmask used to represent the affinities to 317 be included. 319 The information in the Flex Algo Include Any Affinity sub-TLV is 320 derived from the IS-IS and OSPF protocol specific Flexible Algorithm 321 Include-Any Admin Group sub-TLV as defined in 322 [I-D.ietf-lsr-flex-algo]. 324 3.3. Flex Algo Include All Affinity 326 The Flex Algo Include All Affinity sub-TLV is an optional sub-TLV 327 that is used to carry the affinity constraints [RFC2702] associated 328 with the FAD and enable the inclusion of links carrying all of the 329 specified affinities in the computation of the specific algorithm as 330 described in [I-D.ietf-lsr-flex-algo]. The affinity is expressed in 331 terms of Extended Admin Group (EAG) as defined in [RFC7308]. 333 The sub-TLV has the following format: 335 0 1 2 3 336 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 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Type | Length | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Include-All EAG (variable) // 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 where: 345 o Type: 1042 347 o Length: variable, dependent on the size of the Extended Admin 348 Group. MUST be a multiple of 4 octets. 350 o Include-All EAG : the bitmask used to represent the affinities to 351 be included. 353 The information in the Flex Algo Include All Affinity sub-TLV is 354 derived from the IS-IS and OSPF protocol specific Flexible Algorithm 355 Include-All Admin Group sub-TLV as defined in 356 [I-D.ietf-lsr-flex-algo]. 358 3.4. Flex Algo Definition Flags 360 The Flex Algo Definition Flags sub-TLV is an optional sub-TLV that is 361 used to carry the flags associated with the FAD that are used in the 362 computation of the specific algorithm as described in 363 [I-D.ietf-lsr-flex-algo]. 365 The sub-TLV has the following format: 367 0 1 2 3 368 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 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Type | Length | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | Flags (variable) // 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 where: 377 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. 480 This serves as an indication that the FAD information in BGP-LS is 481 incomplete and is not usable for computation purposes. When 482 advertising the Flex Algo Unknown sub-TLV, the protocol specific sub- 483 TLV types that are unsupported or unknown SHOULD be included. This 484 information serves as a diagnostic aid. 486 4. Flex Algorithm Prefix Metric 488 This document defines a new optional BGP-LS Attribute TLV associated 489 with the Prefix NLRI called the Flexible Algorithm Prefix Metric 490 (FAPM) TLV and its format is as follows: 492 0 1 2 3 493 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 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | Type | Length | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 |Flex-Algorithm | Flags | Reserved | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | Metric | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 where: 504 o Type: 1044 506 o Length: 8 octets. 508 o Flex-Algorithm : 1 octet value in the range between 128 and 255 509 inclusive which is the range defined for Flexible Algorithms in 510 the IANA "IGP Parameters" registries under the "IGP Algorithm 511 Types" registry [I-D.ietf-lsr-flex-algo]. 513 o Flags: single octet value and only applicable for OSPF as defined 514 in [I-D.ietf-lsr-flex-algo]. The value MUST be set to 0 for ISIS 515 and ignored by the receiver. 517 o Reserved : 2 octet value that SHOULD be set to 0 by the originator 518 and MUST be ignored by the receiver. 520 o Metric : 4 octets field to carry the metric information. 522 The FAPM TLV can be added to the BGP-LS Attribute of the Prefix NLRI 523 originated by a node, only if the corresponding node originates the 524 Prefix in along with the underlying IGP TLV/sub-TLV as described 525 below. This information is derived from the protocol specific 526 advertisements as below. 528 o IS-IS, as defined by the ISIS Flexible Algorithm Prefix Metric 529 sub-TLV in [I-D.ietf-lsr-flex-algo]. 531 o OSPFv2/OSPFv3, as defined by the OSPF Flexible Algorithm Prefix 532 Metric sub-TLV in [I-D.ietf-lsr-flex-algo]. 534 The BGP-LS Attribute associated with a Prefix NLRI MAY include one or 535 more FAPM TLVs corresponding to the Flexible Algorithm Prefix Metric 536 for each algorithm associated with that particular prefix. 538 5. IANA Considerations 540 This document requests assigning code-points from the registry "BGP- 541 LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute 542 TLVs" based on the table below which reflects the values 545 assigned via the early allocation process. The column "IS-IS TLV/ 546 Sub-TLV" defined in the registry does not require any value and 547 should be left empty. 549 +------------+----------------------------------------+----------+ 550 | Code Point | Description | Length | 551 +------------+----------------------------------------+----------+ 552 | 1039 | Flex Algorithm Definition TLV | variable | 553 | 1040 | Flex Algo Exclude Any Affinity sub-TLV | variable | 554 | 1041 | Flex Algo Include Any Affinity sub-TLV | variable | 555 | 1042 | Flex Algo Include All Affinity sub-TLV | variable | 556 | 1043 | Flex Algo Definition Flags sub-TLV | variable | 557 | 1044 | Flex Algorithm Prefix Metric TLV | variable | 558 | 1045 | Flex Algorithm Exclude SRLG sub-TLV | variable | 559 | TBD | Flex Algorithm Unknown sub-TLV | variable | 560 +------------+----------------------------------------+----------+ 562 6. Manageability Considerations 564 The new protocol extensions introduced in this document augment the 565 existing IGP topology information that was distributed via [RFC7752]. 566 Procedures and protocol extensions defined in this document do not 567 affect the BGP protocol operations and management other than as 568 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 their reviews and contributions to this work. The authors 600 would also like to thanks Jie Dong for his shepherd review. 602 9. References 604 9.1. Normative References 606 [I-D.ietf-idr-bgp-ls-app-specific-attr] 607 Talaulikar, K., Psenak, P., and J. Tantsura, "Application- 608 Specific Attributes Advertisement with BGP Link-State", 609 draft-ietf-idr-bgp-ls-app-specific-attr-08 (work in 610 progress), November 2021. 612 [I-D.ietf-lsr-flex-algo] 613 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 614 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 615 algo-18 (work in progress), October 2021. 617 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 618 Requirement Levels", BCP 14, RFC 2119, 619 DOI 10.17487/RFC2119, March 1997, 620 . 622 [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions 623 in Support of Generalized Multi-Protocol Label Switching 624 (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, 625 . 627 [RFC7308] Osborne, E., "Extended Administrative Groups in MPLS 628 Traffic Engineering (MPLS-TE)", RFC 7308, 629 DOI 10.17487/RFC7308, July 2014, 630 . 632 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 633 S. Ray, "North-Bound Distribution of Link-State and 634 Traffic Engineering (TE) Information Using BGP", RFC 7752, 635 DOI 10.17487/RFC7752, March 2016, 636 . 638 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 639 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 640 May 2017, . 642 9.2. Informative References 644 [I-D.ietf-idr-bgp-model] 645 Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP 646 YANG Model for Service Provider Networks", draft-ietf-idr- 647 bgp-model-12 (work in progress), October 2021. 649 [I-D.ietf-idr-bgpls-srv6-ext] 650 Dawra, G., Filsfils, C., Talaulikar, K., Chen, M., 651 Bernier, D., and B. Decraene, "BGP Link State Extensions 652 for SRv6", draft-ietf-idr-bgpls-srv6-ext-09 (work in 653 progress), November 2021. 655 [I-D.ietf-spring-segment-routing-policy] 656 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 657 P. Mattes, "Segment Routing Policy Architecture", draft- 658 ietf-spring-segment-routing-policy-14 (work in progress), 659 October 2021. 661 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 662 McManus, "Requirements for Traffic Engineering Over MPLS", 663 RFC 2702, DOI 10.17487/RFC2702, September 1999, 664 . 666 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 667 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 668 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 669 . 671 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 672 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 673 DOI 10.17487/RFC4271, January 2006, 674 . 676 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 677 RFC 4272, DOI 10.17487/RFC4272, January 2006, 678 . 680 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 681 BGP, LDP, PCEP, and MSDP Issues According to the Keying 682 and Authentication for Routing Protocols (KARP) Design 683 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 684 . 686 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 687 Decraene, B., Litkowski, S., and R. Shakir, "Segment 688 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 689 July 2018, . 691 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 692 Decraene, B., Litkowski, S., and R. Shakir, "Segment 693 Routing with the MPLS Data Plane", RFC 8660, 694 DOI 10.17487/RFC8660, December 2019, 695 . 697 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 698 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 699 (SRv6) Network Programming", RFC 8986, 700 DOI 10.17487/RFC8986, February 2021, 701 . 703 [RFC9085] Previdi, S., Talaulikar, K., Ed., Filsfils, C., Gredler, 704 H., and M. Chen, "Border Gateway Protocol - Link State 705 (BGP-LS) Extensions for Segment Routing", RFC 9085, 706 DOI 10.17487/RFC9085, August 2021, 707 . 709 Authors' Addresses 711 Ketan Talaulikar (editor) 712 Cisco Systems 713 India 715 Email: ketant.ietf@gmail.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