idnits 2.17.1 draft-ietf-idr-bgp-ls-flex-algo-04.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 (July 5, 2020) is 1384 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-02 == Outdated reference: A later version (-18) exists of draft-ietf-idr-bgp-ls-segment-routing-ext-16 == Outdated reference: A later version (-14) exists of draft-ietf-idr-bgpls-srv6-ext-02 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-07 ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-07 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-16 Summary: 1 error (**), 0 flaws (~~), 7 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: January 6, 2021 S. Zandi 6 G. Dawra 7 LinkedIn 8 July 5, 2020 10 Flexible Algorithm Definition Advertisement with BGP Link-State 11 draft-ietf-idr-bgp-ls-flex-algo-04 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 January 6, 2021. 45 Copyright Notice 47 Copyright (c) 2020 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 . . . . . . . . . . . . . 8 69 3.4. Flex Algo Definition Flags . . . . . . . . . . . . . . . 8 70 3.5. Flex Algo Exclude SRLG . . . . . . . . . . . . . . . . . 9 71 4. Flex Algorithm Prefix Metric . . . . . . . . . . . . . . . . 10 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 73 6. Manageability Considerations . . . . . . . . . . . . . . . . 11 74 6.1. Operational Considerations . . . . . . . . . . . . . . . 12 75 6.2. Management Considerations . . . . . . . . . . . . . . . . 12 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 77 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 80 9.2. Informative References . . . . . . . . . . . . . . . . . 13 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 83 1. Introduction 85 IGP protocols (OSPF and IS-IS) traditionally compute best paths over 86 the network based on the IGP metric assigned to the links. Many 87 network deployments use RSVP-TE [RFC3209] based or Segment Routing 88 (SR) Policy [I-D.ietf-spring-segment-routing-policy] based solutions 89 to enforce traffic over a path that is computed using different 90 metrics or constraints than the shortest IGP path. 91 [I-D.ietf-lsr-flex-algo] defines the Flexible Algorithm solution that 92 allows IGPs themselves to compute constraint based paths over the 93 network. 95 Flexible Algorithm is called so as it allows a user the flexibility 96 to define 98 o the type of calculation to be used (e.g. shortest path) 100 o the metric type to be used (e.g. IGP metric or TE metric) 102 o the set of constraints to be used (e.g. inclusion or exclusion of 103 certain links using affinities) 105 The operations of the flexible algorithm solution is described in 106 detail in [I-D.ietf-lsr-flex-algo] and a high level summary of the 107 same is described here for clarity. The network operator enables the 108 participation of specific nodes in the network for a specific 109 algorithm and then provisions the definition of that flexible 110 algorithm on one or more of these nodes. The nodes where the 111 flexible algorithm definition (FAD) is advertised then flood these 112 definitions via respective IGP (IS-IS and OSPFv2/v3) mechanisms to 113 all other nodes in the network. The nodes select the definition for 114 each algorithm based on the flooded information in a deterministic 115 manner and thus all nodes participating in a flexible algorithm 116 computation arrive at a common understanding of the type of 117 calculation that they need to use. 119 When using Segment Routing (SR) [RFC8402] MPLS forwarding plane 120 [RFC8660], the result of a flex algorithm computation is the 121 provisioning of the Prefix SIDs associated with that algorithm with 122 paths based on the topology computed based on that algorithm. When 123 using SR forwarding plane on IPv6 (SRv6) 124 [I-D.ietf-spring-srv6-network-programming], the result of a flex 125 algorithm computation is the provisioning of the SRv6 Locators 126 associated with that algorithm with paths based on the topology 127 computed based on that algorithm. This flex algorithm computation is 128 within an IGP area or level similar to the default shortest path tree 129 (SPT) algorithm. 131 A flex algorithm specific metric MAY be advertised along with the 132 prefix as described in [I-D.ietf-lsr-flex-algo] to enable end-to-end 133 optimal path computation for prefixes across multiple areas/domains 134 in the flex algorithm computation for the SR-MPLS forwarding plane. 136 The BGP-LS extensions for SR are defined in 137 [I-D.ietf-idr-bgp-ls-segment-routing-ext] and 138 [I-D.ietf-idr-bgpls-srv6-ext]. They include the 139 o SR Algorithm TLV to indicate the participation of a node in a flex 140 algorithm computation 142 o Prefix SID TLV to indicate the association of the Prefix-SIDs to a 143 specific flex algorithm for SR-MPLS forwarding 145 o SRv6 Locator TLV to indicate the Locator for specific flex 146 algorithm for SRv6 forwarding 148 Thus a controller or a Path Computation Engine (PCE) is aware of the 149 IGP topology across multiple domains which includes the above 150 information related to the flexible algorithm. This draft defines 151 extensions to BGP-LS for carrying the Flexible Algorithm Definition 152 information so that it enables the controller/PCE to learn the 153 mapping of the flex algorithm number to its definition in each area/ 154 domain of the underlying IGP. The controller/PCE also learns the 155 type of computation used and the constraints for the same. This 156 information can then be leveraged by it for setting up SR Policy 157 paths end to end across domains by leveraging the appropriate Flex 158 Algorithm specific SIDs in the in its Segment List 159 [I-D.ietf-spring-segment-routing-policy]. e.g. picking the Flex 160 Algorithm Prefix SID (in case of SR-MPLS) or End SID (in case of 161 SRv6) of ABRs/ASBRs corresponding to a definition that optimizes on 162 the delay metric enables the PCE/controller to build an end to end 163 low latency path across IGP domains with minimal SIDs in the SID 164 list. 166 1.1. Requirements Language 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 170 "OPTIONAL" in this document are to be interpreted as described in BCP 171 14 [RFC2119] [RFC8174] when, and only when, they appear in all 172 capitals, as shown here. 174 2. BGP-LS Extensions for Flex Algo 176 The BGP-LS [RFC7752] specifies the Node NLRI for advertisement of 177 nodes along with their attributes using the BGP-LS Attribute, the 178 Link NLRI for advertisement of links along with their attributes 179 using the BGP-LS Attribute and the Prefix NLRI for advertisement of 180 prefixes along with their attributes using the BGP-LS Attribute. 182 The Flexible Algorithm Definition (FAD) advertised by a node are 183 considered as its node level attributes and advertised as such. 185 Various link attributes like affinities and SRLGs used during the 186 Flex-Algorithm path calculations in IS-IS and OSPF are advertised in 187 those protocols using the Application Specific Link Attribute (ASLA) 188 advertisements as described in [I-D.ietf-lsr-flex-algo]. The BGP-LS 189 extensions for ASLA advertisements 190 [I-D.ietf-idr-bgp-ls-app-specific-attr] MUST be used for the 191 advertisement of these Flex-Algorithm application specific link 192 attributes from the underlying IGP protocols using the Flexible 193 Algorithm application specific bit defined in 194 [I-D.ietf-lsr-flex-algo]. 196 The Flexible Algorithm Prefix Metric (FAPM) are considered as prefix 197 attributes and advertised as such. 199 3. Flexible Algorithm Definition 201 This document defines a new optional BGP-LS Attribute TLV associated 202 with the Node NLRI called the Flexible Algorithm Definition (FAD) TLV 203 and its format is as follows: 205 0 1 2 3 206 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 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Type | Length | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 |Flex-Algorithm | Metric-Type | Calc-Type | Priority | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | sub-TLVs ... // 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 Figure 1: Flex Algorithm Definition TLV 217 where: 219 o Type: 1039 221 o Length: variable. Minimum of 4 octets. 223 o Flex-Algorithm : 1 octet value in the range between 128 and 255 224 inclusive which is the range defined for Flexible Algorithms in 225 the IANA "IGP Parameters" registries under the "IGP Algorithm 226 Types" registry [I-D.ietf-lsr-flex-algo]. 228 o Metric-Type : 1 octet value indicating the type of the metric used 229 in the computation. Values allowed come from the IANA "IGP 230 Parameters" registries under the "Flexible Algorithm Definition 231 Metric-Type" registry [I-D.ietf-lsr-flex-algo]. 233 o Calculation-Type : 1 octet value in the range between 0 and 127 234 inclusive which is the range defined for the standard algorithms 235 in the IANA "IGP Parameters" registries under the "IGP Algorithm 236 Types" registry [I-D.ietf-lsr-flex-algo]. 238 o Priority : 1 octet value between 0 and 255 inclusive that 239 specifies the priority of the FAD. 241 o sub-TLVs : zero or more sub-TLVs may be included as described 242 further in this section. 244 The FAD TLV can only be added to the BGP-LS Attribute of the Node 245 NLRI if the corresponding node originates the underlying IGP TLV/sub- 246 TLV as described below. This information is derived from the 247 protocol specific advertisements as below.. 249 o IS-IS, as defined by the ISIS Flexible Algorithm Definition sub- 250 TLV in [I-D.ietf-lsr-flex-algo]. 252 o OSPFv2/OSPFv3, as defined by the OSPF Flexible Algorithm 253 Definition TLV in [I-D.ietf-lsr-flex-algo]. 255 The BGP-LS Attribute associated with a Node NLRI MAY include one or 256 more FAD TLVs corresponding to the Flexibile Algorithm Definition for 257 each algorithm that the particular node is advertising. 259 The following sub-sections define the sub-TLVs for the FAD TLV. 261 3.1. Flex Algo Exclude Any Affinity 263 The Flex Algo Exclude Any Affinity sub-TLV is an optional sub-TLV 264 that is used to carry the affinity constraints [RFC2702] associated 265 with the flex algo definition and enable the exclusion of links 266 carrying any of the specified affinities from the computation of the 267 specific algorithm as described in [I-D.ietf-lsr-flex-algo]. The 268 affinity is expressed in terms of Extended Admin Group (EAG) as 269 defined in [RFC7308]. 271 The TLV has the following format: 273 0 1 2 3 274 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 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Type | Length | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Exclude-Any EAG (variable) // 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 where: 283 o Type: 1040 285 o Length: variable, dependent on the size of the Extended Admin 286 Group. MUST be a multiple of 4 octets. 288 o Exclude-Any EAG : the bitmask used to represent the affinities to 289 be excluded. 291 The information in the Flex Algo Exclude Any Affinity sub-TLV is 292 derived from the IS-IS and OSPF protocol specific Flexible Algorithm 293 Exclude Admin Group sub-TLV as defined in [I-D.ietf-lsr-flex-algo]. 295 3.2. Flex Algo Include Any Affinity 297 The Flex Algo Incude Any Affinity sub-TLV is an optional sub-TLV that 298 is used to carry the affinity constraints [RFC2702] associated with 299 the flex algo definition and enable the inclusion of links carrying 300 any of the specified affinities in the computation of the specific 301 algorithm as described in [I-D.ietf-lsr-flex-algo]. The affinity is 302 expressed in terms of Extended Admin Group (EAG) as defined in 303 [RFC7308]. 305 The TLV has the following format: 307 0 1 2 3 308 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 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Type | Length | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Include-Any EAG (variable) // 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 where: 317 o Type: 1041 319 o Length: variable, dependent on the size of the Extended Admin 320 Group. MUST be a multiple of 4 octets. 322 o Include-Any EAG : the bitmask used to represent the affinities to 323 be included. 325 The information in the Flex Algo Include Any Affinity sub-TLV is 326 derived from the IS-IS and OSPF protocol specific Flexible Algorithm 327 Include-Any Admin Group sub-TLV as defined in 328 [I-D.ietf-lsr-flex-algo]. 330 3.3. Flex Algo Include All Affinity 332 The Flex Algo Incude All Affinity sub-TLV is an optional sub-TLV that 333 is used to carry the affinity constraints [RFC2702] associated with 334 the flex algo definition and enable the inclusion of links carrying 335 all of the specified affinities in the computation of the specific 336 algorithm as described in [I-D.ietf-lsr-flex-algo]. The affinity is 337 expressed in terms of Extended Admin Group (EAG) as defined in 338 [RFC7308]. 340 The TLV has the following format: 342 0 1 2 3 343 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 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Type | Length | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Include-All EAG (variable) // 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 where: 352 o Type: 1042 354 o Length: variable, dependent on the size of the Extended Admin 355 Group. MUST be a multiple of 4 octets. 357 o Include-All EAG : the bitmask used to represent the affinities to 358 be included. 360 The information in the Flex Algo Include All Affinity sub-TLV is 361 derived from the IS-IS and OSPF protocol specific Flexible Algorithm 362 Include-All Admin Group sub-TLV as defined in 363 [I-D.ietf-lsr-flex-algo]. 365 3.4. Flex Algo Definition Flags 367 The Flex Algo Definition Flags sub-TLV is an optional sub-TLV that is 368 used to carry the flags associated with the flex algo definition that 369 are used in the computation of the specific algorithm as described in 370 [I-D.ietf-lsr-flex-algo]. 372 The TLV has the following format: 374 0 1 2 3 375 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 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Type | Length | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Flags (variable) // 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 where: 384 o Type: 1043 386 o Length: variable. MUST be a multiple of 4 octets. 388 o Flags : the bitmask used to represent the flags for the flex 389 algorithm definition as introduced by [I-D.ietf-lsr-flex-algo] and 390 listed in the "Flex-Algorithm Definition Flags" registry under the 391 "Interior Gateway Protocol (IGP) Parameters" IANA registry. 393 The information in the Flex Algo Definition Flags sub-TLV is derived 394 from the IS-IS and OSPF protocol specific Flexible Algorithm 395 Definition Flags sub-TLV as defined in [I-D.ietf-lsr-flex-algo]. 397 3.5. Flex Algo Exclude SRLG 399 The Flex Algo Exclude SRLG sub-TLV is an optional sub-TLV that is 400 used to carry the shared risk link group (SRLG) [RFC4202] information 401 associated with the flex algo definition and enable the exclusion of 402 links that are associated with any of the specified SRLG in the 403 computation of the specific algorithm as described in 404 [I-D.ietf-lsr-flex-algo]. The SRLGs associated with a link are 405 carried in the BGP-LS Shared Link Risk Group (TLV 1096) [RFC7752]. 407 The TLV has the following format: 409 0 1 2 3 410 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 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Type | Length | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Shared Risk Link Group Values (variable) // 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 where: 419 o Type: TBD 420 o Length: variable, depedent on the number of SRLG values. MUST be 421 a multiple of 4 octets. 423 o SRLG Values : One or more SRLG values, each of 4 octet size, as 424 defined in [RFC4202]. 426 The information in the Flex Algo SRLG Exclude sub-TLV is derived from 427 the IS-IS and OSPF protocol specific Flexible Algorithm Exclude SRLG 428 sub-TLV as defined in [I-D.ietf-lsr-flex-algo]. 430 4. Flex Algorithm Prefix Metric 432 This document defines a new optional BGP-LS Attribute TLV associated 433 with the Prefix NLRI called the Flexible Algorithm Prefix Metric 434 (FAPM) TLV and its format is as follows: 436 0 1 2 3 437 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 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Type | Length | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 |Flex-Algorithm | Reserved | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Metric | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 where: 448 o Type: 1044 450 o Length: 8 octets. 452 o Flex-Algorithm : 1 octet value in the range between 128 and 255 453 inclusive which is the range defined for Flexible Algorithms in 454 the IANA "IGP Parameters" registries under the "IGP Algorithm 455 Types" registry [I-D.ietf-lsr-flex-algo]. 457 o Reserved : 3 octet value that SHOULD be set to 0 by the originator 458 and MUST be ignored by the receiver. 460 o Metric : 4 octets field to carry the metric information. 462 The FAPM TLV can be added to the BGP-LS Attribute of the Prefix NLRI 463 orginated by a node, only if the corresponding node originates the 464 Prefix in along with the underlying IGP TLV/sub-TLV as described 465 below. This information is derived from the protocol specific 466 advertisements as below. 468 o IS-IS, as defined by the ISIS Flexible Algorithm Prefix Metric 469 sub-TLV in [I-D.ietf-lsr-flex-algo]. 471 o OSPFv2/OSPFv3, as defined by the OSPF Flexible Algorithm Prefix 472 Metric sub-TLV in [I-D.ietf-lsr-flex-algo]. 474 The BGP-LS Attribute associated with a Prefix NLRI MAY include one or 475 more FAPM TLVs corresponding to the Flexibile Algorithm Prefix Metric 476 for each algorithm associated with that the particular prefix. 478 5. IANA Considerations 480 This document requests assigning code-points from the registry "BGP- 481 LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute 482 TLVs" based on table below which reflects the values assigned via the 483 early allocation process. The column "IS-IS TLV/Sub-TLV" defined in 484 the registry does not require any value and should be left empty. 486 +------------+----------------------------------------+----------+ 487 | Code Point | Description | Length | 488 +------------+----------------------------------------+----------+ 489 | 1039 | Flex Algorithm Definition TLV | variable | 490 | 1040 | Flex Algo Exclude Any Affinity sub-TLV | variable | 491 | 1041 | Flex Algo Include Any Affinity sub-TLV | variable | 492 | 1042 | Flex Algo Include All Affinity sub-TLV | variable | 493 | 1043 | Flex Algo Definition Flags sub-TLV | variable | 494 | 1044 | Flex Algorithm Prefix Metric TLV | variable | 495 | TBD | Flex Algorithm Exclude SRLG TLV | variable | 496 +------------+----------------------------------------+----------+ 498 6. Manageability Considerations 500 This section is structured as recommended in [RFC5706]. 502 The new protocol extensions introduced in this document augment the 503 existing IGP topology information that was distributed via [RFC7752]. 504 Procedures and protocol extensions defined in this document do not 505 affect the BGP protocol operations and management other than as 506 discussed in the Manageability Considerations section of [RFC7752]. 507 Specifically, the malformed NLRIs attribute tests in the Fault 508 Management section of [RFC7752] now encompass the new TLVs for the 509 BGP-LS NLRI in this document. 511 6.1. Operational Considerations 513 No additional operation considerations are defined in this document. 515 6.2. Management Considerations 517 No additional management considerations are defined in this document. 519 7. Security Considerations 521 The new protocol extensions introduced in this document augment the 522 existing IGP topology information that was distributed via [RFC7752]. 523 Procedures and protocol extensions defined in this document do not 524 affect the BGP security model other than as discussed in the Security 525 Considerations section of [RFC7752]. 527 8. Acknowledgements 529 The authors would like to thank Les Ginsberg for his reviews and 530 contributions to this work. 532 9. References 534 9.1. Normative References 536 [I-D.ietf-idr-bgp-ls-app-specific-attr] 537 Talaulikar, K., Psenak, P., and J. Tantsura, "Application 538 Specific Attributes Advertisement with BGP Link-State", 539 draft-ietf-idr-bgp-ls-app-specific-attr-02 (work in 540 progress), May 2020. 542 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 543 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 544 and M. Chen, "BGP Link-State extensions for Segment 545 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-16 546 (work in progress), June 2019. 548 [I-D.ietf-idr-bgpls-srv6-ext] 549 Dawra, G., Filsfils, C., Talaulikar, K., Chen, M., 550 daniel.bernier@bell.ca, d., and B. Decraene, "BGP Link 551 State Extensions for SRv6", draft-ietf-idr-bgpls- 552 srv6-ext-02 (work in progress), January 2020. 554 [I-D.ietf-lsr-flex-algo] 555 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 556 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 557 algo-07 (work in progress), April 2020. 559 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 560 Requirement Levels", BCP 14, RFC 2119, 561 DOI 10.17487/RFC2119, March 1997, 562 . 564 [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions 565 in Support of Generalized Multi-Protocol Label Switching 566 (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, 567 . 569 [RFC7308] Osborne, E., "Extended Administrative Groups in MPLS 570 Traffic Engineering (MPLS-TE)", RFC 7308, 571 DOI 10.17487/RFC7308, July 2014, 572 . 574 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 575 S. Ray, "North-Bound Distribution of Link-State and 576 Traffic Engineering (TE) Information Using BGP", RFC 7752, 577 DOI 10.17487/RFC7752, March 2016, 578 . 580 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 581 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 582 May 2017, . 584 9.2. Informative References 586 [I-D.ietf-spring-segment-routing-policy] 587 Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and 588 P. Mattes, "Segment Routing Policy Architecture", draft- 589 ietf-spring-segment-routing-policy-07 (work in progress), 590 May 2020. 592 [I-D.ietf-spring-srv6-network-programming] 593 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 594 Matsushima, S., and Z. Li, "SRv6 Network Programming", 595 draft-ietf-spring-srv6-network-programming-16 (work in 596 progress), June 2020. 598 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 599 McManus, "Requirements for Traffic Engineering Over MPLS", 600 RFC 2702, DOI 10.17487/RFC2702, September 1999, 601 . 603 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 604 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 605 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 606 . 608 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 609 Management of New Protocols and Protocol Extensions", 610 RFC 5706, DOI 10.17487/RFC5706, November 2009, 611 . 613 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 614 Decraene, B., Litkowski, S., and R. Shakir, "Segment 615 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 616 July 2018, . 618 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 619 Decraene, B., Litkowski, S., and R. Shakir, "Segment 620 Routing with the MPLS Data Plane", RFC 8660, 621 DOI 10.17487/RFC8660, December 2019, 622 . 624 Authors' Addresses 626 Ketan Talaulikar (editor) 627 Cisco Systems 628 India 630 Email: ketant@cisco.com 632 Peter Psenak 633 Cisco Systems 634 Slovakia 636 Email: ppsenak@cisco.com 638 Shawn Zandi 639 LinkedIn 640 USA 642 Email: szandi@linkedin.com 644 Gaurav Dawra 645 LinkedIn 646 USA 648 Email: gdawra.ietf@gmail.com