idnits 2.17.1 draft-ietf-lsr-flex-algo-bw-con-01.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 : ---------------------------------------------------------------------------- ** There are 18 instances of too long lines in the document, the longest one being 20 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 12, 2021) is 1019 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) == Missing Reference: 'RFC8362' is mentioned on line 444, but not defined == Missing Reference: 'RFC 8919' is mentioned on line 955, but not defined ** Obsolete undefined reference: RFC 8919 (Obsoleted by RFC 9479) == Missing Reference: 'RFC 5305' is mentioned on line 957, but not defined == Missing Reference: 'RFC8919' is mentioned on line 405, but not defined ** Obsolete undefined reference: RFC 8919 (Obsoleted by RFC 9479) == Missing Reference: 'RFC 8570' is mentioned on line 405, but not defined == Missing Reference: 'RFC 8920' is mentioned on line 477, but not defined ** Obsolete undefined reference: RFC 8920 (Obsoleted by RFC 9492) == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-15 == Outdated reference: A later version (-16) exists of draft-bashandy-rtgwg-segment-routing-uloop-10 -- Obsolete informational reference (is this intentional?): RFC 5316 (Obsoleted by RFC 9346) Summary: 4 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING S. Hegde 3 Internet-Draft W. Britto 4 Intended status: Standards Track R. Shetty 5 Expires: January 13, 2022 Juniper Networks Inc. 6 B. Decraene 7 Orange 8 P. Psenak 9 Cisco Systems 10 T. Li 11 Arista Networks 12 July 12, 2021 14 Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints 15 draft-ietf-lsr-flex-algo-bw-con-01 17 Abstract 19 Many networks configure the link metric relative to the link 20 capacity. High bandwidth traffic gets routed as per the link 21 capacity. Flexible algorithms provides mechanisms to create 22 constraint based paths in IGP. This draft documents a generic metric 23 type and set of bandwidth related constraints to be used in Flexible 24 Algorithms. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in RFC 2119 [RFC2119]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on January 13, 2022. 49 Copyright Notice 51 Copyright (c) 2021 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Generic Metric Advertisement . . . . . . . . . . . . . . . . 4 68 2.1. ISIS Generic Metric sub-TLV . . . . . . . . . . . . . . . 5 69 2.2. OSPF Generic Metric sub-TLV . . . . . . . . . . . . . . . 6 70 2.3. Generic Metric applicability to Flexible Algorithms 71 Multi-domain/Multi-area networks . . . . . . . . . . . . 7 72 3. FAD constraint sub-TLVs . . . . . . . . . . . . . . . . . . . 7 73 3.1. ISIS FAD constraint sub-TLVs . . . . . . . . . . . . . . 8 74 3.1.1. ISIS Exclude Minimum Bandwidth sub-TLV . . . . . . . 8 75 3.1.2. ISIS Exclude Maximum Delay sub-TLV . . . . . . . . . 8 76 3.2. OSPF FAD constraint sub-TLVs . . . . . . . . . . . . . . 9 77 3.2.1. OSPF Exclude Minimum Bandwidth sub-TLV . . . . . . . 9 78 3.2.2. OSPF Exclude Maximum Delay sub-TLV . . . . . . . . . 10 79 4. Bandwidth Metric Advertisement . . . . . . . . . . . . . . . 11 80 4.1. Automatic Metric Calculation . . . . . . . . . . . . . . 12 81 4.1.1. Automatic Metric Calculation Modes . . . . . . . . . 12 82 4.1.2. Automatic Metric Calculation Methods . . . . . . . . 13 83 4.1.3. ISIS FAD constraint sub-TLVs for automatic metric 84 calculation . . . . . . . . . . . . . . . . . . . . . 14 85 4.1.4. OSPF FAD constraint sub-TLVs for automatic metric 86 calculation . . . . . . . . . . . . . . . . . . . . . 18 87 5. Bandwidth metric considerations . . . . . . . . . . . . . . . 22 88 6. Calculation of Flex-Algorithm paths . . . . . . . . . . . . . 22 89 7. Backward Compatibility . . . . . . . . . . . . . . . . . . . 23 90 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 91 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 92 9.1. IGP Metric-Type Registry . . . . . . . . . . . . . . . . 23 93 9.2. ISIS Sub-Sub-TLVs for Flexible Algorithm Definition Sub- 94 TLV . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 95 9.3. OSPF Sub-TLVs for Flexible Algorithm Definition Sub-TLV . 24 96 9.4. Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223 . . . . . 24 97 9.5. OSPFv2 Extended Link TLV Sub-TLVs . . . . . . . . . . . . 24 98 9.6. Types for sub-TLVs of TE Link TLV (Value 2) . . . . . . . 25 99 9.7. OSPFv3 Extended-LSA Sub-TLVs . . . . . . . . . . . . . . 25 100 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 101 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 102 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 103 12.1. Normative References . . . . . . . . . . . . . . . . . . 25 104 12.2. Informative References . . . . . . . . . . . . . . . . . 26 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 107 1. Introduction 109 High bandwidth traffic such as residential internet traffic and 110 machine to machine elephant flows benefit from using high capacity 111 links. Accordingly, many network operators define a link's metric 112 relative to its capacity to help direct traffic to higher bandwidth 113 links, but this is no guarantee that lower bandwidth links will be 114 avoided, especially in failure scenarios. To ensure that elephant 115 flows are only placed on high capacity links, it would be useful to 116 explicitly exclude the high bandwidth traffic from utilizing links 117 below a certain capacity. Flex-Algorithm [I-D.ietf-lsr-flex-algo] 118 has already defined as a set of parameters consisting of calculation- 119 type, metric-type and a set of constraints for allowing operators to 120 have more control over network path computation. In this document, 121 we define further extensions to Flex-Algorithm that will allow 122 operators additional control over their traffic, especially with 123 respect to constraints about bandwidth. 125 Historically, IGPs have done path computation by minimizing the sum 126 of the link metrics along the path from source to destination. While 127 the metric has been administratively defined, implementations have 128 defaulted to a metric that is inversely proportional to link 129 bandwidth. This has driven traffic to higher bandwidth links and has 130 required manual metric manipulation to achieve the desired loading of 131 the network. 133 Over time, with the addition of different traffic types, the need for 134 alternate types of metrics has become clear. Flex-Algorithm already 135 supports using the minimum link delay and the administratively 136 assigned traffic-engineering metrics in path computation. However, 137 it is clear that additional metrics may be of interest in different 138 situations. A network operator may seek to minimize their 139 operational costs and thus may want a metric that reflects the actual 140 fiscal costs of using a link. Other traffic may require low jitter, 141 leading to an entirely different set of metrics. With Flex- 142 Algorithm, all of these different metrics, and more, could be used 143 concurrently on the same network. 145 In some circumstances, path computation constraints, such as 146 administrative groups, can be used to ensure that traffic avoids 147 particular portions of the network. These strict constraints are 148 appropriate when there is an absolute requirement to avoid parts of 149 the topology, even in failure conditions. If, however, the 150 requirement is less strict, then using a high metric in a portion of 151 the topology may be more appropriate. 153 This document defines a family of generic metrics that can carry 154 various types of administratively assigned metrics. This document 155 proposes standard metric-types which require specific standard 156 document. This document also proposes user defined metric-types 157 where specifics are not defined, so that adminstrators are free to 158 assign semantics as they fit. This document also specifies a new 159 bandwidth based metric type to be used with Flex-Algorithm and other 160 applications in Section Section 4. Additional Flexible Algorithm 161 Definition (FAD) constraints are defined in Section Section 3 that 162 allow the network adminstrator to preclude the use of low bandwidth 163 links or high delay links. Section Section 4.1 defines mechanisms to 164 automatically calculate link metrics based on parameters defined in 165 the FAD and the advertised Maximum Link Bandwidth of each link. This 166 is advantageous because administrators can change their criteria for 167 metric assignment centrally, without individual modification of each 168 link metric throughout the network. 170 2. Generic Metric Advertisement 172 ISIS and OSPF advertise a metric for each link in their respective 173 link state advertisements. Multiple metric types are are already 174 supported. Administratively assigned metrics are described in the 175 original OSPF and ISIS specifications. The Traffic Engineering 176 Default Metric is defined in [RFC5305] and [RFC3630] and the Min 177 Unidirectional delay metric is defined in [RFC8570] and [RFC7471]. 178 Other metrics, such as jitter, reliability, and fiscal cost may be 179 helpful, depending on the traffic class. Rather than attempt to 180 enumerate all possible metrics of interest, this document specifies a 181 generic mechanism for advertising metrics. 183 Each generic metric advertisement is on a per-link and per metric 184 type basis. The metric advertisement consists of a metric type field 185 and a value for the metric. The metric type field is assigned by the 186 "IGP metric type" IANA registry. Metric types 0-127 are standard 187 metric types as assigned by IANA. This document further specifies a 188 user defined metric type space of metric types 128-255. These are 189 user defined and can be assigned by an operator for local use. 191 2.1. ISIS Generic Metric sub-TLV 193 The ISIS Generic Metric sub-TLV specifies the link metric for a given 194 metric type. Typically, this metric is assigned by a network 195 administrator. Generic metric is application-independent attribute 196 similar to igp-metric. The Generic Metric sub-TLV is advertised in 197 the TLVs/sub-TLVs below: 199 TLV-22 (Extended IS reachability) [RFC5305] 201 TLV-222 (MT-ISN) [RFC5120] 203 TLV-23 (IS Neighbor Attribute) [RFC5311] 205 TLV-223 (MT IS Neighbor Attribute) [RFC5311] 207 TLV-141 (inter-AS reachability information) [RFC5316] 209 0 1 2 3 210 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 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Type | Length | metric-type | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Value | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 Type : TBD (To be assigned by IANA) 218 Length: 4 octets 219 metric-type: A value from the IGP metric-type registry 220 Value : metric value range (1 - 16,777,215) 222 Figure 1: ISIS Generic Metric sub-TLV 224 The Generic Metric sub-TLV MAY be advertised multiple times. For a 225 particular metric type, the Generic Metric sub-TLV MUST be advertised 226 only once for a link when advertised in TLV 22,222,23,223 and 141. 227 If there are multiple Generic Metric sub-TLVs advertised for a link 228 for same metric type in one or more received LSPDUs, advertisement in 229 the lowest numbered fragment MUST be used and the subsequent ones 230 MUST be ignored.If the metric type indicates a standard metric type 231 for which there are other advertisement mechanisms (e.g., the IGP 232 metric, the Min Unidirectional Link Delay, or the Traffic Engineering 233 Default Metric, as of this writing), the Generic Metric advertisement 234 MUST be ignored. 236 2.2. OSPF Generic Metric sub-TLV 238 The OSPF Generic Metric sub-TLV specifies the link metric for a given 239 metric type. Typically, this metric is assigned by a network 240 administrator.Generic metric is application-independent attribute 241 similar to igp-metric. The Generic Metric sub-TLV is advertised in 242 the TLVs below: 244 sub-TLV of the OSPF Link TLV of OSPF extended Link LSA [RFC7684]. 246 sub-TLV of TE Link TLV (2) of OSPF TE LSA [RFC3630]. 248 sub-TLV of the Router-Link TLV in the E-Router-LSA in OSPFv3 249 [RFC8362]. 251 The Generic Metric sub-TLV is TLV type TBD (IANA), and is eight 252 octets in length. 254 0 1 2 3 255 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 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Type | Length | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | metric-type | Reserved | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Value | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 Type : TBD (To be assigned by IANA) 265 Length: 8 octets 266 metric-type = A value from the IGP metric type registry 268 Value : metric value (1- 4,294,967,295) 270 Figure 2: OSPF Generic Metric sub-TLV 272 The Generic Metric sub-TLV MAY be advertised multiple times. For a 273 particular metric type, the Genreric Metric sub-TLV MUST be 274 advertised only once for a link when advertised in OSPF Link TLV of 275 Extended Link LSA, Link TLV of TE LSA and sub-TLV of the Router-Link 276 TLV in the E-Router-LSA Router-Link TLV in OSPFv3. If there are 277 multiple Genreric Metric sub-TLVs advertised for a link for the same 278 metric type in a received LSA, the first one MUST be used and the 279 subsequent ones MUST be ignored.If the metric type indicates a 280 standard metric type for which there are other advertisement 281 mechanisms (e.g., the IGP metric, the Min Unidirectional Link Delay, 282 or the Traffic Engineering Default Metric, as of this writing), the 283 Generic Metric advertisement MUST be ignored. 285 2.3. Generic Metric applicability to Flexible Algorithms Multi-domain/ 286 Multi-area networks 288 Generic Metric can be used by Flex-Algorithms by specifying the 289 metric type in the Flexible Algorithm Definitions. When Flex- 290 Algorithms is used in a multi-area network, [I-D.ietf-lsr-flex-algo] 291 defines FAPM sub-TLV that carries the Flexible Algorithm specific 292 metric. Metric carried in FAPM will be equal to the metric to reach 293 the prefix for that Flex-Algorithm in its source area or domain. 294 When Flex-Algorithm uses Generic metric, the same procedures as 295 described in section 13 of [I-D.ietf-lsr-flex-algo] are used to send 296 and process FAPM sub-TLV. 298 3. FAD constraint sub-TLVs 300 In networks that carry elephant flows, directing an elephant flow 301 down a low-bandwidth link would be catastrophic. Thus, in the 302 context of Flex-Algorithm, it would be useful to be able to constrain 303 the topology to only those links capable of supporting a minimum 304 amount of bandwidth. 306 If the capacity of a link is constant, this can already be achived 307 through the use of administrative groups. However, when a Layer 3 308 link is actually a collection of Layer 2 links (LAG/Layer 2 Bundle), 309 the link bandwidth will vary based on the set of active constituent 310 links. This could be automated by having an implementation vary the 311 advertised administrative groups based on bandwidth, but this seems 312 unnecessarily complex and expressing this requirement as a direct 313 constraint on the topology seems simpler. This is also advantageous 314 if the minimum required bandwidth changes, as this constraint would 315 provide a single centralized, coordinated point of control. 317 To implement this idea, this document defines a new Exclude Minimum 318 Bandwidth constraint. When this constraint is advertised in a FAD, a 319 link will be pruned from the Flex-Algorithm topology if the link's 320 advertised Maximum Link Bandwidth is below the advertised Minimum 321 Bandwidth value. 323 Similarly, this document defines a Exclude Maximum Link Delay 324 constraint. Delay is an important consideration in High Frequency 325 Trading applications, networks with transparent L2 link recovery, or 326 in satellite networks, where link delay may fluctuate. Mechanisms 327 already exist to measure the link delay dynamically and advertised it 328 in the IGP. Networks that employ dynamic link delay measurement, may 329 want to exclude links that have a delay over a given threshold. 331 3.1. ISIS FAD constraint sub-TLVs 333 3.1.1. ISIS Exclude Minimum Bandwidth sub-TLV 335 ISIS Flex-Algorithm Exclude Minimum Bandwidth sub-TLV (FAEMB) is a 336 sub-TLV of the ISIS FAD sub-TLV. It has the following format: 338 0 1 2 3 339 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 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Type | Length | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Min Bandwidth | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 where: 347 Type: TBA 349 Length: 4 octets. 351 Min Bandwidth: The link bandwidth is encoded in 32 bits in IEEE 352 floating point format. The units are bytes per second. 354 Figure 3: ISIS FAEMB sub-TLV 356 The FAEMB sub-TLV MUST appear at most once in the FAD sub-TLV. If it 357 appears more than once, the ISIS FAD Sub-TLV MUST be ignored by the 358 receiver. 360 The Minimum bandwidth advertised in FAEMB sub-TLV MUST be compared 361 with Maximum Link Bandwidth advertised in sub-sub-TLV 9 of ASLA sub- 362 TLV [RFC 8919]. If L-Flag is set in the ASLA sub-TLV, the Minimum 363 bandwidth advertised in FAEMB sub-TLV MUST be compared with Maximum 364 Link Bandwidth as advertised by the sub-TLV 9 of the TLV 365 22/222/23/223/141 [RFC 5305] as defined in [RFC8919] Section 4.2. 367 If the Maximum Link Bandwidth is lower than the Minimum link 368 bandwidth advertised in FAEMB sub-TLV, the link MUST be excluded from 369 the Flex-Algorithm topology. If a link does not have the Maximum 370 Link Bandwidth advertised but the FAD contains this sub-TLV, then 371 that link MUST NOT be excluded from the topology based on the Minimum 372 Bandwidth constraint. 374 3.1.2. ISIS Exclude Maximum Delay sub-TLV 376 ISIS Flex-Algorithm Exclude Maximum Delay sub-TLV (FAEMD) is a sub- 377 TLV of the ISIS FAD sub-TLV. It has the following format. 379 0 1 2 3 380 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 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | Type | Length | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | max link delay | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 where: 388 Type: TBD 390 Length: 3 octets 392 Max link delay: Maximum link delay in microseconds 394 Figure 4: ISIS FAEMD sub-TLV 396 The FAEMD sub-TLV MUST appear only once in the FAD sub-TLV. If it 397 appears more than once, the ISIS FAD Sub-TLV MUST be ignored by the 398 receiver. 400 The Maximum link delay advertised in FAEMD sub-TLV MUST be compared 401 with Min Unidirectional Link Delay advertised in sub-sub-TLV 34 of 402 ASLA sub-TLV [RFC 8919]. If L-Flag is set in the ASLA sub-TLV, the 403 Maximum link delay advertised in FAEMD sub-TLV MUST be compared with 404 Min Unidirectional Link Delay as advertised by the sub-TLV 34 of the 405 TLV 22/222/23/223/141 [RFC 8570] as defined in [RFC8919] Section 4.2. 407 If the Min Unidirectional Link Delay value is higher than the Maximum 408 link delay advertised in FAEMD sub-TLV, the link MUST be excluded 409 from the Flex-Algorithm topology. If a link does not have the Min 410 Unidirectional Link Delay advertised but the FAD contains this sub- 411 TLV, then that link MUST NOT be excluded from the topology based on 412 the Maximum Delay constraint. 414 3.2. OSPF FAD constraint sub-TLVs 416 3.2.1. OSPF Exclude Minimum Bandwidth sub-TLV 418 OSPF Flex-Algorithm Exclude Minimum Bandwidth sub-TLV (FAEMB) is a 419 sub-TLV of the OSPF FAD TLV. It has the following format. 421 0 1 2 3 422 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 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Type | Length | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | Min Bandwidth | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 where: 430 Type: TBD 432 Length: 4 octets. 434 Min Bandwidth: link bandwidth is encoded in 32 bits in IEEE 435 floating point format. The units are bytes per second. 437 Figure 5: OSPF FAEMB sub-TLV 439 The FAEMB sub-TLV MUST appear only once in the FAD sub-TLV. If it 440 appears more than once, the OSPF FAD TLV MUST be ignored by the 441 receiver. The Maximum Link Bandwidth as advertised in Extended Link 442 TLV in the Extended Link Opaque LSA in OSPFv2 [RFC7684] or as a sub- 443 TLV of the Router-Link TLV in the E-Router-LSA Router-Link TLV in 444 OSPFv3 [RFC8362] MUST be compared against the Minimum bandwidth 445 advertised in FAEMB sub-TLV. If the link bandwidth is lower than the 446 Minimum bandwidth advertised in FAEMB sub-TLV, the link MUST be 447 excluded from the Flex-Algorithm topology. If a link does not have 448 the Maximum Link Bandwidth advertised but the FAD contains this sub- 449 TLV, then that link MUST be included in the topology and proceed to 450 apply further pruning rules for the link. 452 3.2.2. OSPF Exclude Maximum Delay sub-TLV 454 OSPF Flex-Algorithm Exclude Maximum Delay sub-TLV (FAEMD) is a sub- 455 TLV of the OSPF FAD TLV. It has the following format. 457 0 1 2 3 458 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 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Type | Length | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | Max Delay | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 where: 466 Type: TBD 468 Length: 3 octets 470 Max link delay: Maximum link delay in microseconds 472 Figure 6: OSPF FAEMD sub-TLV 474 The FAEMD sub-TLV MUST appear only once in the OSPF FAD TLV. If it 475 appears more than once, the OSPF FAD TLV MUST be ignored by the 476 receiver. The Min Unidirectional Link Delay as advertised by sub- 477 sub-TLV 12 of ASLA sub-TLV [RFC 8920], MUST be compared against the 478 Maximum delay advertised in FAEMD sub-TLV. If the Min Unidirectional 479 Link Delay is higher than the Maximum delay advertised in FAEMD sub- 480 TLV, the link MUST be excluded from the Flex-Algorithm topology If a 481 link does not have the Min Unidirectional Link Delay advertised but 482 the FAD contains this sub-TLV, then then that link MUST NOT be 483 excluded from the topology based on the Maximum Delay constraint. 485 4. Bandwidth Metric Advertisement 487 Historically, IGP implementations have made default metric 488 assignments based on link bandwidth. This has proven to be useful, 489 but has suffered from having different defaults across 490 implementations and from the rapid growth of link bandwidths. With 491 Flex-Algorithm, the network administrator can define a function that 492 will produce a metric for each link have each node automatically 493 compute each link's metric based its bandwidth. 495 This document defines a new standard metric type for this purpose 496 called the "Bandwidth Metric". The Bandwidth Metric MAY be 497 advertised in the Generic Metric sub-TLV with the metric type set to 498 "Bandwidth Metric". ISIS and OSPF will advertise this new type of 499 metric in their link advertisements. Bandwidth metric is a link 500 attribute and for advertisement and processing of this attribute for 501 Flex-algorithm purposes, MUST follow the the section 12 of 502 [I-D.ietf-lsr-flex-algo] 503 Flex-Algorithm uses this metric type by specifying the bandwidth 504 metric as the metric type in a FAD TLV. A FAD TLV may also specify 505 an automatic computation of the bandwidth metric based on a links 506 advertised bandwidth. An explicit advertisement of a link's 507 bandwidth metric using the Generic Metric sub-TLV overrides this 508 automatic computation. The automatic bandwidth metric calculation 509 sub-TLVs are advertised in FAD TLV and these parameters are 510 applicable to applications such as Flex-algorithm that make use of 511 the FAD TLV. 513 4.1. Automatic Metric Calculation 515 Networks which are designed to be highly regular and follow uniform 516 metric assignment may want to simplify their operations by 517 automatically calculating the bandwidth metric. When a FAD 518 advertises the metric type as Bandwidth Metric and the link does not 519 have the Bandwidth Metric advertised, automatic metric derivation can 520 be used with additional FAD constraint advertisements as described in 521 this section. 523 If a link's bandwidth changes, then the delay in learning about the 524 change may create the possibility of micro-loops in the topology. 525 This is no different from the IGP's susceptibility to micro-loops 526 during a metric change. The micro-loop avoidance procedures 527 described in [I-D.bashandy-rtgwg-segment-routing-uloop] can be used 528 to avoid micro-loops when the automatic metric calculation is 529 deployed. 531 Computing the metric between adjacent systems based on bandwidth 532 becomes more complex in the face of parallel adjacencies. If there 533 are parallel adjacnecies between systems, then the bandwidth between 534 the systems is the sum of the bandwidth of the parallel links. This 535 is somewhat more complex to deal with, so there is an optional mode 536 for computing the aggregate bandwidth. 538 4.1.1. Automatic Metric Calculation Modes 540 4.1.1.1. Simple Mode 542 In simple mode, the Maximum Link Bandwidth of a single Layer 3 link 543 is used to derive the metric. This mode is suitable for deployments 544 that do not use parallel Layer 3 links. In this case, the 545 computation of the metric is straightforward. If a layer 3 link is 546 composed of a layer 2 bundle, then the link bandwidth is the sum of 547 the bandwidths of the working components and may vary with layer 2 548 link failures. 550 4.1.1.2. Interface Group Mode 552 The simple mode of metric calculation may not work well when there 553 are multiple parallel layer 3 interfaces between two nodes. Ideally, 554 the metric between two systems should be the same given the same 555 bandwidth, whether the bandwidth is provided by parallel layer 2 556 links or parallel layer 3 links. To address this, in Interface Group 557 Mode, nodes MUST compute the aggregate bandwidth of all parallel 558 adjacencies, MUST derive the metric based on the aggregate bandwidth, 559 and MUST apply the resulting metric to each of the parallel 560 adjacencies. 562 A------B====C====F====D 563 | | 564 ------E------- 566 Figure 7: Parallel interfaces 568 For exmple, in the above diagram, there are two parallel links 569 between B->C, C->F, F->D. Let us assume the link bandwidth is 570 uniform 10Gbps on all links and the metric for each link will be the 571 same. Traffic from B to D will be forwarded B->E->D. Since the 572 bandwidth is higher on the B->C->F->D path, the metric for that path 573 should be lower, and that path should be selected. Interface Group 574 Mode is preferred in cases where there are parallel layer 3 links. 576 In the interface group mode, every node MUST identify the set of 577 parallel links between a pair of nodes based on IGP link 578 advertisements and MUST consider cumulative bandwidth of the parallel 579 links while arriving at the metric of each link. 581 4.1.2. Automatic Metric Calculation Methods 583 In automatic metric calculation for simple and interface group mode, 584 Maximum Link Bandwidth of the links is used to derive the metric. 585 There are two types of automatic metric derivation methods. 587 1. Reference bandwidth method 589 2. Bandwidth thresholds method 591 4.1.2.1. Reference Bandwidth method 593 In many networks, the metric is inversely proportional to the link 594 bandwidth. The administrator or implementation selects a reference 595 bandwdith and the metric is derived by dividing the reference 596 bandwidth by the advertised Maximum Link Bandwidth. Advertising the 597 reference bandwidth in the FAD constraints allows the metric 598 computation to be done automatically. Centralized control of this 599 reference bandwidth simplifies management in the case that the 600 reference bandwidth changes. In order to ensure that small bandwidth 601 changes do not change the link metric, it is useful to define the 602 granularity of the bandwidth that is of interest. The link bandwidth 603 will be truncated to this granularity before deriving the metric. 605 For example, 607 reference bandwidth = 1000G 609 Granularity = 20G 611 The derived metric is 10 for link bandwidth in the range 100G to 612 119G 614 4.1.2.2. Bandwidth Thresholds method 616 The reference bandwidth approach described above provides a uniform 617 metric value for a range of link bandwidths. In certain cases there 618 may be a need to define non-proportional metric values for the 619 varying ranges of link bandwidth. For example, bandwidths from 10G 620 to 30G are assigned metric value 100, bandwidth from 30G to 70G get a 621 metric value of 50, and bandwidths greater than 70G have a metric of 622 10. In order to support this, a staircase mapping based on bandwidth 623 thresholds is supported in the FAD. This advertisement contains a 624 set of threshold values and associated metrics. 626 4.1.3. ISIS FAD constraint sub-TLVs for automatic metric calculation 628 4.1.3.1. Reference Bandwidth sub-TLV 630 This section provides FAD constraint advertisement details for the 631 reference bandwidth method of metric calculation as described in 632 Section 4.1.2.1. The Flexible Algorithm Definition Reference 633 Bandwidth Sub-TLV (FADRB Sub-TLV) is a Sub-TLV of the ISIS FAD sub- 634 TLV. It has the following format: 636 0 1 2 3 637 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 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | Type | Length | Flags | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | Reference Bandwidth | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 | Granularity Bandwidth | 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 where: 648 Type: TBD 650 Length: 9 octets. 651 Reference Bandwidth: Bandwidth encoded in 32 bits in IEEE floating point 652 format. The units are in bytes per second. 653 Granularity Bandwidth: Bandwidth encoded in 32 bits in IEEE floating point 654 format. The units are in bytes per second. 656 Flags: 658 0 1 2 3 4 5 6 7 659 +-+-+-+-+-+-+-+-+ 660 |G| | | | 661 +-+-+-+-+-+-+-+-+ 663 G-flag: when set, interface group Mode MUST be used to derive total link bandwidth. 665 Metric calculation: (Reference_bandwidth) / 666 (Total_link_bandwidth - 667 (Modulus of(Total_link_bandwidth,granularity_bw))) 669 Figure 8: ISIS FADRB sub-TLV 671 Granularity Bandwidth value ensures that the metric does not change 672 when there is a small change in the link bandwidth. The ISIS FADRB 673 Sub-TLV MUST NOT appear more than once in an ISIS FAD sub-TLV. If it 674 appears more than once, the ISIS FAD sub-TLV MUST be ignored by the 675 receiver. If a Generic Metric sub-TLV with Bandwidth metric type is 676 advertised for a link, the Flex-Algorithm calculation MUST use the 677 advertised Bandwidth Metric, and MUST NOT use the automatically 678 derived metric for that link. 680 4.1.3.2. Bandwidth Thresholds sub-TLV 682 This section provides FAD constraint advertisement details for the 683 Bandwidth Thresholds method of metric calculation as described in 684 Section 4.1.2.2. The Flexible Algorithm Definition Bandwidth 685 Threshold Sub-TLV (FADBT Sub-TLV) is a Sub-TLV of the ISIS FAD sub- 686 TLV. It has the following format: 688 0 1 2 3 689 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 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 | Type | Length | Flags | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | Bandwidth Threshold 1 | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 | Threshold Metric 1 | 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | Bandwidth Threshold 1 | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | Threshold Metric 2 | 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 | Bandwidth Threshold 2 | 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 ..... 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | Threshold Metric n-1 | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | Bandwidth Threshold n-1 | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | Threshold Metric n | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 where: 714 Type: TBD 716 Length: 1 + n*7 octets. Here n is equal to number of Threshold Metrics specified. 717 n MUST be greater than or equal to 1. 719 Flags: 721 0 1 2 3 4 5 6 7 722 +-+-+-+-+-+-+-+-+ 723 |G| | | | 724 +-+-+-+-+-+-+-+-+ 726 G-flag: when set, interface group Mode MUST be used to derive total link bandwidth. 728 Staircase bandwidth threshold and associated metric values. 729 Bandwidth Threshold 1: Minimum Link Bandwidth is encoded in 32 bits in IEEE 730 floating point format. The units are bytes per second. 731 Bandwidth Threshold 2: Maximum Link Bandwidth is encoded in 32 bits in IEEE 732 floating point format. The units are bytes per second. 733 Threshold Metric 1 : metric value range (1 - 4,261,412,864) 735 Figure 9: ISIS FADBT sub-TLV 737 When G-flag is set, the cumulative bandwidth of the parallel links is 738 computed as described in section Section 4.1.1.2. If G-flag is not 739 set, the advertised Maximum Link Bandwidth is used. 741 When the computed link bandwidth is less than Bandwidth Threshold 1, 742 the MAX_METRIC value of 4,261,412,864 MUST be assigned as the 743 Bandwidth Metric on the link during Flex-Algorithm SPF calculation. 745 When the computed link bandwidth is greater than or equal to 746 Bandwidth Threshold 1 and less than Bandwidth Threshold 1, Threshold 747 Metric 1 MUST be assigned as the Bandwidth Metric on the link during 748 Flex-Algorithm SPF calculation. 750 Similarly, when the computed link bandwidth is greater than or equal 751 to Bandwidth Threshold 1 and less than Bandwidth Threshold 2, 752 Threshold Metric 2 MUST be assigned as the Bandwidth Metric on the 753 link during Flex-Algorithm SPF calculation. 755 In general, when the computed link bandwidth is greater than or equal 756 to Bandwidth Threshold X AND less than Bandwidth Threshold X+1, 757 Threshold Metric X MUST be assigned as the Bandwidth Metric on the 758 link during Flex-Algorithm SPF calculation. 760 Finally, when the computed link bandwidth is greater than or equal to 761 Bandwidth Threshold n, then Threshold Metric n MUST be assigned as 762 the Bandwidth Metric on the link during Flex-Algorithm SPF 763 calculation. 765 The ISIS FADBT Sub-TLV MUST NOT appear more than once in an ISIS FAD 766 sub-TLV. If it appears more than once, the ISIS FAD sub-TLV MUST 767 MUST stop participating in such flex-algorithm. 769 A FAD MUST NOT contain both FADBT sub-TLV and FADRB sub-TLV. If both 770 these sub-TLVs are advertised in the same FAD for a Flexible 771 Algorithm, the FAD MUST be ignored by the receiver. 773 If a Generic Metric sub-TLV with Bandwidth metric type is advertised 774 for a link, the Flex-Algorithm calculation MUST use the Bandwidth 775 Metric advertised on the link, and MUST NOT use the automatically 776 derived metric for that link. 778 4.1.4. OSPF FAD constraint sub-TLVs for automatic metric calculation 780 4.1.4.1. Reference Bandwidth sub-TLV 782 The Flexible Algorithm Definition Reference Bandwidth Sub-TLV (FADRB 783 Sub-TLV) is a Sub-TLV of the OSPF FAD TLV. It has the following 784 format: 786 0 1 2 3 787 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 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 | Type | Length | 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 | Flags | Reserved | 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 | Reference Bandwidth | 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 | Granularity Bandwidth | 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 where: 800 Type: TBD 802 Length: 14 octets. 803 Reference Bandwidth: Bandwidth encoded in 32 bits in IEEE floating point 804 format. The units are in bytes per second. 805 Granularity Bandwidth: Bandwidth encoded in 32 bits in IEEE floating point 806 format. The units are in bytes per second. 808 Flags: 810 0 1 2 3 4 5 6 7 811 +-+-+-+-+-+-+-+-+ 812 |G| | | | 813 +-+-+-+-+-+-+-+-+ 815 G-flag: when set, interface group Mode MUST be used 816 to derive total link bandwidth. 818 Metric calculation: (Reference_bandwidth) / 819 (Total_link_bandwidth - 820 (Modulus of(Total_link_bandwidth, Granularity_bw))) 822 Figure 10: OSPF FADRB sub-TLV 824 Granularity Bandwidth value is used to ensure that the metric does 825 not change when there is a small change in the link bandwidth. The 826 OSPF FADRB Sub-TLV MUST NOT appear more than once in an OSPF FAD TLV. 827 If it appears more than once, the OSPF FAD TLV MUST be ignored by the 828 receiver. If a Generic Metric sub-TLV with Bandwidth metric type is 829 advertised for a link, the Flex-Algorithm calculation MUST use the 830 advertised Bandwidth Metric on the link, and MUST NOT use the 831 automatically derived metric for that link. 833 4.1.4.2. Bandwidth Threshold sub-TLV 835 The Flexible Algorithm Definition Bandwidth Thresholds Sub-TLV (FADBT 836 Sub-TLV) is a Sub-TLV of the OSPF FAD TLV. It has the following 837 format: 839 0 1 2 3 840 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 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 | Type | Length | 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 | Flags | Reserved | 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | Bandwidth Threshold 1 | 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 | Threshold Metric 1 | 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 | Bandwidth Threshold 2 | 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 | Threshold Metric 2 | 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 | Bandwidth Threshold 3 | 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 ..... 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 | Threshold Metric n-1 | 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 | Bandwidth Threshold n | 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 | Threshold Metric n | 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 where: 867 Type: TBD 869 Length: 2 + n*8 octets. Here n is equal to number of 870 Threshold Metrics specified. 871 n MUST be greater than or equal to 1. 873 Flags: 875 0 1 2 3 4 5 6 7 876 +-+-+-+-+-+-+-+-+ 877 |G| | | | 878 +-+-+-+-+-+-+-+-+ 880 G-flag: when set, interface group Mode MUST be used to derive total link bandwidth. 882 Staircase bandwidth threshold and associated metric values. 883 Bandwidth Threshold 1: Minimum Link Bandwidth is encoded in 32 bits in IEEE 884 floating point format. The units are bytes per second. 885 Bandwidth Threshold 2: Maximum Link Bandwidth is encoded in 32 bits in IEEE 886 floating point format. The units are bytes per second. 887 Threshold Metric 1 : metric value range (1 - 4,294,967,296) 889 Figure 11: OSPF FADBT sub-TLV 891 When G-flag is set, the cumulative bandwidth of the parallel links is 892 computed as described in section Section 4.1.1.2. If G-flag is not 893 set, the advertised Maximum Link Bandwidth is used. 895 When the computed link bandwidth is less than Bandwidth Threshold 1 , 896 the MAX_METRIC value of 4,294,967,296 MUST be assigned as the 897 Bandwidth Metric on the link during Flex-Algorithm SPF calculation. 899 When the computed link bandwidth is greater than or equal to 900 Bandwidth Threshold 1 and less than Bandwidth Threshold 1, Threshold 901 Metric 1 MUST be assigned as the Bandwidth Metric on the link during 902 Flex-Algorithm SPF calculation. 904 Similarly, when the computed link bandwidth is greater than or equal 905 to Bandwidth Threshold 1 and less than Bandwidth Threshold 2, 906 Threshold Metric 2 MUST be assigned as the Bandwidth Metric on the 907 link during Flex-Algorithm SPF calculation. 909 In general, when the computed link bandwidth is greater than or equal 910 to Bandwidth Threshold X AND less than Bandwidth Threshold X+1, 911 Threshold Metric X MUST be assigned as the Bandwidth Metric on the 912 link during Flex-Algorithm SPF calculation. 914 Finally, when the computed link bandwidth is greater than or equal to 915 Bandwidth Threshold n, then Threshold Metric n MUST be assigned as 916 the Bandwidth Metric on the link during Flex-Algorithm SPF 917 calculation. 919 The ISIS FADBT Sub-TLV MUST NOT appear more than once in an ISIS FAD 920 sub-TLV. If it appears more than once, the ISIS FAD sub-TLV MUST 921 stop participating in such flex-algorithm. 923 A FAD MUST NOT contain both FADBT sub-TLV and FADRB sub-TLV. If both 924 these sub-TLVs are advertised in the same FAD for a Flexible 925 Algorithm, the FAD MUST be ignored by the receiver. 927 If a Generic Metric sub-TLV with Bandwidth metric type is advertised 928 for a link, the Flex-Algorithm calculation MUST use the Bandwidth 929 Metric advertised on the link, and MUST NOT use the automatically 930 derived metric for that link. 932 5. Bandwidth metric considerations 934 This section specifies the rules of deriving the Bandwidth Metric if 935 and only if the winning FAD for the Flex-Algorithm specifies the 936 metric-type as "Bandwidth Metric". 938 1. If the the Generic Metric sub-TLV with Bandwidth metric type 939 is advertised for the link as described in Section 4, it MUST be 940 used during the Flex-Algorithm calculation. 942 2. If the Generic Metric sub-TLV with Bandwidth metric type is 943 not advertised for the link and the winning FAD for the Flex- 944 Algorithm does not specify the automatic bandwidth metric 945 calculation (as defined in Section 4.1 ), the Bandwidth Metric is 946 considered as not being advertised for the link. 948 3. If the Generic Metric sub-TLV with Bandwidth metric type is 949 not advertised for the link and the winning FAD for the Flex- 950 Algorithm specifies the automatic bandwidth metric calculation (as 951 defined in Section 4.1), the Bandwidth Metric metric MUST be 952 automatically calculated as per the procedures defined in 953 Section 4.1. If the Bandwidth Metric can not be calculated due to 954 lack of Flex-Algorithm specific ASLA advertisement of sub-sub-TLV 955 9 [RFC 8919], or in case of IS-IS, in presence of the L-Flag in 956 the Flex-Algorithm specific ASLA advertisement the lack of sub-TLV 957 9 in the TLV 22/222/23/223/141 [RFC 5305], the Bandwidth Metric is 958 considered as not being advertised for the link. 960 6. Calculation of Flex-Algorithm paths 962 Two new additional rules are added to the existing rules in the Flex- 963 rules specified in sec 13 of [I-D.ietf-lsr-flex-algo]. 965 6. Check if any exclude FAEMB rule is part of the Flex-Algorithm 966 definition. If such exclude rule exists and the link has Maximum 967 Link Bandwidth advertised, check if the link bandwidth satisfies 968 the FAEMB rule. If the link does not satisfy the FAEMB rule, the 969 link MUST be pruned from the computation. 971 7. Check if any exclude FAEMD rule is part of the Flex-Algorithm 972 definition. If such exclude rule exists and the link has Min 973 Unidirectional link delay advertised, check if the link delay 974 satisfies the FAEMD rule. If the link does not satisfy the FAEMD 975 rule, the link MUST be pruned from the computation. 977 7. Backward Compatibility 979 8. Security Considerations 981 TBD 983 9. IANA Considerations 985 9.1. IGP Metric-Type Registry 987 Type: Suggested 3 (TBA) 989 Description: Bandwidth metric 991 Reference: This document 993 Type: 128 to 255(TBA) 995 Description: User defned metric 997 Reference: This document 999 9.2. ISIS Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV 1001 Type: Suggested 6 (TBA) 1003 Description: ISIS Exclude Minimum Bandwidth sub-TLV 1005 Reference: This document Section 3.1.1 1007 Type: Suggested 7 (TBA) 1009 Description: ISIS Exclude Maximum Delay sub-TLV 1011 Reference: This document Section 3.1.2 1013 Type: Suggested 8 (TBA) 1015 Description: ISIS Reference Bandwidth sub-TLV 1017 Reference: This document Section 4.1.3.1 1018 Type: Suggested 9 (TBA) 1020 Description: ISIS Threshold Metric sub-TLV 1022 Reference: This document Section 4.1.3.2 1024 9.3. OSPF Sub-TLVs for Flexible Algorithm Definition Sub-TLV 1026 Type: Suggested 6 (TBA) 1028 Description: OSPF Exclude Minimum Bandwidth sub-TLV 1030 Reference: This document Section 3.2.1 1032 Type: Suggested 7 (TBA) 1034 Description: OSPF Exclude Maximum Delay sub-TLV 1036 Reference: This document Section 3.2.2 1038 Type: Suggested 8 (TBA) 1040 Description: OSPF Reference Bandwidth sub-TLV 1042 Reference: This document Section 4.1.4.1 1044 Type: Suggested 9 (TBA) 1046 Description: OSPF Threshold Metric sub-TLV 1048 Reference: This document Section 4.1.4.2 1050 9.4. Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223 1052 Type: Suggested 45 (TBA) 1054 Description: Generic metric 1056 Reference: This document Section 2.1 1058 9.5. OSPFv2 Extended Link TLV Sub-TLVs 1060 Type: Suggested 45 (TBA) 1062 Description: Generic metric 1064 Reference: This document Section 2.2 1066 9.6. Types for sub-TLVs of TE Link TLV (Value 2) 1068 Type: Suggested 45 (TBA) 1070 Description: Generic metric 1072 Reference: This document Section 2.2 1074 9.7. OSPFv3 Extended-LSA Sub-TLVs 1076 Type: Suggested 45 (TBA) 1078 Description: Generic metric 1080 Reference: This document Section 2.2 1082 10. Acknowledgements 1084 Many thanks to Chris Bowers, Krzysztof Szarcowitz, Julian Lucek, Ram 1085 Santhanakrishnan, Ketan Talaulikar for discussions and inputs. 1087 11. Contributors 1089 1. Salih K A 1091 Juniper Networks 1093 salih@juniper.net 1095 12. References 1097 12.1. Normative References 1099 [I-D.ietf-lsr-flex-algo] 1100 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 1101 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 1102 algo-15 (work in progress), April 2021. 1104 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1105 Requirement Levels", BCP 14, RFC 2119, 1106 DOI 10.17487/RFC2119, March 1997, 1107 . 1109 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1110 (TE) Extensions to OSPF Version 2", RFC 3630, 1111 DOI 10.17487/RFC3630, September 2003, 1112 . 1114 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1115 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 1116 2008, . 1118 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 1119 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 1120 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 1121 2015, . 1123 12.2. Informative References 1125 [I-D.bashandy-rtgwg-segment-routing-uloop] 1126 Bashandy, A., Filsfils, C., Litkowski, S., Decraene, B., 1127 Francois, P., and P. Psenak, "Loop avoidance using Segment 1128 Routing", draft-bashandy-rtgwg-segment-routing-uloop-10 1129 (work in progress), December 2020. 1131 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 1132 Topology (MT) Routing in Intermediate System to 1133 Intermediate Systems (IS-ISs)", RFC 5120, 1134 DOI 10.17487/RFC5120, February 2008, 1135 . 1137 [RFC5311] McPherson, D., Ed., Ginsberg, L., Previdi, S., and M. 1138 Shand, "Simplified Extension of Link State PDU (LSP) Space 1139 for IS-IS", RFC 5311, DOI 10.17487/RFC5311, February 2009, 1140 . 1142 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 1143 Support of Inter-Autonomous System (AS) MPLS and GMPLS 1144 Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, 1145 December 2008, . 1147 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 1148 Previdi, "OSPF Traffic Engineering (TE) Metric 1149 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 1150 . 1152 [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, 1153 D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) 1154 Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 1155 2019, . 1157 Authors' Addresses 1158 Shraddha Hegde 1159 Juniper Networks Inc. 1160 Exora Business Park 1161 Bangalore, KA 560103 1162 India 1164 Email: shraddha@juniper.net 1166 William Britto A J 1167 Juniper Networks Inc. 1169 Email: bwilliam@juniper.net 1171 Rajesh Shetty 1172 Juniper Networks Inc. 1174 Email: mrajesh@juniper.net 1176 Bruno Decraene 1177 Orange 1179 Email: bruno.decraene@orange.com 1181 Peter Psenak 1182 Cisco Systems 1184 Email: ppsenak@cisco.com 1186 Tony Li 1187 Arista Networks 1189 Email: tony.li@tony.li