idnits 2.17.1 draft-ietf-lsr-flex-algo-bw-con-00.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 19 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 (May 30, 2021) is 1033 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: 'RFC8919' is mentioned on line 397, but not defined ** Obsolete undefined reference: RFC 8919 (Obsoleted by RFC 9479) == Missing Reference: 'RFC 8919' is mentioned on line 944, but not defined ** Obsolete undefined reference: RFC 8919 (Obsoleted by RFC 9479) == Missing Reference: 'RFC 5305' is mentioned on line 946, but not defined == Missing Reference: 'RFC 8570' is mentioned on line 397, but not defined == Missing Reference: 'RFC 8920' is mentioned on line 467, 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 (~~), 8 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: December 1, 2021 Juniper Networks Inc. 6 B. Decraene 7 Orange 8 P. Psenak 9 Cisco Systems 10 T. Li 11 Arista Networks 12 May 30, 2021 14 Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints 15 draft-ietf-lsr-flex-algo-bw-con-00 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 December 1, 2021. 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 3. FAD constraint sub-TLVs . . . . . . . . . . . . . . . . . . . 7 71 3.1. ISIS FAD constraint sub-TLVs . . . . . . . . . . . . . . 7 72 3.1.1. ISIS Exclude Minimum Bandwidth sub-TLV . . . . . . . 7 73 3.1.2. ISIS Exclude Maximum Delay sub-TLV . . . . . . . . . 8 74 3.2. OSPF FAD constraint sub-TLVs . . . . . . . . . . . . . . 9 75 3.2.1. OSPF Exclude Minimum Bandwidth sub-TLV . . . . . . . 9 76 3.2.2. OSPF Exclude Maximum Delay sub-TLV . . . . . . . . . 10 77 4. Bandwidth Metric Advertisement . . . . . . . . . . . . . . . 11 78 4.1. Automatic Metric Calculation . . . . . . . . . . . . . . 12 79 4.1.1. Automatic Metric Calculation Modes . . . . . . . . . 12 80 4.1.2. Automatic Metric Calculation Methods . . . . . . . . 13 81 4.1.3. ISIS FAD constraint sub-TLVs for automatic metric 82 calculation . . . . . . . . . . . . . . . . . . . . . 14 83 4.1.4. OSPF FAD constraint sub-TLVs for automatic metric 84 calculation . . . . . . . . . . . . . . . . . . . . . 18 85 5. Bandwidth metric considerations . . . . . . . . . . . . . . . 22 86 6. Calculation of Flex-Algorithm paths . . . . . . . . . . . . . 22 87 7. Backward Compatibility . . . . . . . . . . . . . . . . . . . 23 88 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 89 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 90 9.1. IGP Metric-Type Registry . . . . . . . . . . . . . . . . 23 91 9.2. ISIS Sub-Sub-TLVs for Flexible Algorithm Definition Sub- 92 TLV . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 93 9.3. OSPF Sub-TLVs for Flexible Algorithm Definition Sub-TLV . 24 94 9.4. Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223 . . . . . 24 95 9.5. Sub-sub-TLV Codepoints for Application-Specific Link 96 Attributes . . . . . . . . . . . . . . . . . . . . . . . 24 98 9.6. OSPFv2 Extended Link TLV Sub-TLVs . . . . . . . . . . . . 25 99 9.7. Types for sub-TLVs of TE Link TLV (Value 2) . . . . . . . 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. The Generic Metric sub-TLV is advertised in the TLVs/ 196 sub-TLVs below: 198 TLV-22 (Extended IS reachability) [RFC5305] 200 TLV-222 (MT-ISN) [RFC5120] 202 TLV-23 (IS Neighbor Attribute) [RFC5311] 204 TLV-223 (MT IS Neighbor Attribute) [RFC5311] 206 TLV-141 (inter-AS reachability information) [RFC5316] 208 sub-TLV 16 (Application-Specific Link Attributes) of TLV 209 22/222/23/223/141 [RFC8919] 211 0 1 2 3 212 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 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Type | Length | metric-type | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Value | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 Type : TBD (To be assigned by IANA) 220 Length: 4 octets 221 metric-type: A value from the IGP metric-type registry 222 Value : metric value range (1 - 16,777,215) 224 Figure 1: ISIS Generic Metric sub-TLV 226 The Generic Metric sub-TLV MAY be advertised multiple times. For a 227 particular metric type, the Generic Metric sub-TLV MUST be advertised 228 only once for a link when advertised in TLV 22,222,23,223 and 141. 229 When Generic metric sub-TLV is advertised in ASLA, each metric type 230 MUST be advertised only once per-application for a link. If there 231 are multiple Generic Metric sub-TLVs advertised for a link for same 232 metric type (and same application in case of ASLA) in one or more 233 received LSPDUs, the first one MUST be used and the subsequent ones 234 MUST be ignored.If the metric type indicates a standard metric type 235 for which there are other advertisement mechanisms (e.g., the IGP 236 metric, the Min Unidirectional Link Delay, or the Traffic Engineering 237 Default Metric, as of this writing), the Generic Metric advertisement 238 MUST be ignored. 240 2.2. OSPF Generic Metric sub-TLV 242 The OSPF Generic Metric sub-TLV specifies the link metric for a given 243 metric type. Typically, this metric is assigned by a network 244 administrator. The Generic Metric sub-TLV is advertised in the TLVs 245 below: 247 sub-TLV of the OSPF Link TLV of OSPF extended Link LSA [RFC7684]. 249 sub-TLV of TE Link TLV (2) of OSPF TE LSA [RFC3630]. 251 sub-sub-TLV of Application-Specific Link Attributes sub-TLV [RFC 252 8920] 254 The Generic Metric sub-TLV is TLV type TBD (IANA), and is eight 255 octets in length. 257 0 1 2 3 258 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 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Type | Length | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | metric-type | Reserved | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Value | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 Type : TBD (To be assigned by IANA) 268 Length: 8 octets 269 metric-type = A value from the IGP metric type registry 271 Value : metric value (1- 4,294,967,295) 273 Figure 2: OSPF Generic Metric sub-TLV 275 The Generic Metric sub-TLV MAY be advertised multiple times. For a 276 particular metric type, the Genreric Metric sub-TLV MUST be 277 advertised only once for a link when advertised in OSPF Link TLV of 278 Extended Link LSA and Link TLV of TE LSA. When Genreric Metric sub- 279 TLV is advertised as sub-sub-TLV of ASLA, it MUST be advertised only 280 once per-application for a link. If there are multiple Genreric 281 Metric sub-TLVs advertised for a link for the same metric type and 282 for same application in one or more received LSPDUs, the first one 283 MUST be used and the subsequent ones MUST be ignored.If the metric 284 type indicates a standard metric type for which there are other 285 advertisement mechanisms (e.g., the IGP metric, the Min 286 Unidirectional Link Delay, or the Traffic Engineering Default Metric, 287 as of this writing), the Generic Metric advertisement MUST be 288 ignored. 290 3. FAD constraint sub-TLVs 292 In networks that carry elephant flows, directing an elephant flow 293 down a low-bandwidth link would be catastrophic. Thus, in the 294 context of Flex-Algorithm, it would be useful to be able to constrain 295 the topology to only those links capable of supporting a minimum 296 amount of bandwidth. 298 If the capacity of a link is constant, this can already be achived 299 through the use of administrative groups. However, when a Layer 3 300 link is actually a collection of Layer 2 links (LAG/Layer 2 Bundle), 301 the link bandwidth will vary based on the set of active constituent 302 links. This could be automated by having an implementation vary the 303 advertised administrative groups based on bandwidth, but this seems 304 unnecessarily complex and expressing this requirement as a direct 305 constraint on the topology seems simpler. This is also advantageous 306 if the minimum required bandwidth changes, as this constraint would 307 provide a single centralized, coordinated point of control. 309 To implement this idea, this document defines a new Exclude Minimum 310 Bandwidth constraint. When this constraint is advertised in a FAD, a 311 link will be pruned from the Flex-Algorithm topology if the link's 312 advertised Maximum Link Bandwidth is below the advertised Minimum 313 Bandwidth value. 315 Similarly, this document defines a Exclude Maximum Link Delay 316 constraint. Delay is an important consideration in High Frequency 317 Trading applications, networks with transparent L2 link recovery, or 318 in satellite networks, where link delay may fluctuate. Mechanisms 319 already exist to measure the link delay dynamically and advertised it 320 in the IGP. Networks that employ dynamic link delay measurement, may 321 want to exclude links that have a delay over a given threshold. 323 3.1. ISIS FAD constraint sub-TLVs 325 3.1.1. ISIS Exclude Minimum Bandwidth sub-TLV 327 ISIS Flex-Algorithm Exclude Minimum Bandwidth sub-TLV (FAEMB) is a 328 sub-TLV of the ISIS FAD sub-TLV. It has the following format: 330 0 1 2 3 331 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 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Type | Length | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Min Bandwidth | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 where: 339 Type: TBA 341 Length: 4 octets. 343 Min Bandwidth: The link bandwidth is encoded in 32 bits in IEEE 344 floating point format. The units are bytes per second. 346 Figure 3: ISIS FAEMB sub-TLV 348 The FAEMB sub-TLV MUST appear at most once in the FAD sub-TLV. If it 349 appears more than once, the ISIS FAD Sub-TLV MUST be ignored by the 350 receiver. 352 The Minimum bandwidth advertised in FAEMB sub-TLV MUST be compared 353 with Maximum Link Bandwidth advertised in sub-sub-TLV 9 of ASLA sub- 354 TLV [RFC 8919]. If L-Flag is set in the ASLA sub-TLV, the Minimum 355 bandwidth advertised in FAEMB sub-TLV MUST be compared with Maximum 356 Link Bandwidth as advertised by the sub-TLV 9 of the TLV 357 22/222/23/223/141 [RFC 5305] as defined in [RFC8919] Section 4.2. 359 If the Maximum Link Bandwidth is lower than the Minimum link 360 bandwidth advertised in FAEMB sub-TLV, the link MUST be excluded from 361 the Flex-Algorithm topology. If a link does not have the Maximum 362 Link Bandwidth advertised but the FAD contains this sub-TLV, then 363 that link then the link MUST NOT be excluded from the topology based 364 on the Minimum Bandwidth constraint. 366 3.1.2. ISIS Exclude Maximum Delay sub-TLV 368 ISIS Flex-Algorithm Exclude Maximum Delay sub-TLV (FAEMD) is a sub- 369 TLV of the ISIS FAD sub-TLV. It has the following format. 371 0 1 2 3 372 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 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Type | Length | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | max link delay | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 where: 380 Type: TBD 382 Length: 3 octets 384 Max link delay: Maximum link delay in microseconds 386 Figure 4: ISIS FAEMD sub-TLV 388 The FAEMD sub-TLV MUST appear only once in the FAD sub-TLV. If it 389 appears more than once, the ISIS FAD Sub-TLV MUST be ignored by the 390 receiver. 392 The Maximum link delay advertised in FAEMD sub-TLV MUST be compared 393 with Min Unidirectional Link Delay advertised in sub-sub-TLV 34 of 394 ASLA sub-TLV [RFC 8919]. If L-Flag is set in the ASLA sub-TLV, the 395 Maximum link delay advertised in FAEMD sub-TLV MUST be compared with 396 Min Unidirectional Link Delay as advertised by the sub-TLV 34 of the 397 TLV 22/222/23/223/141 [RFC 8570] as defined in [RFC8919] Section 4.2. 399 If the Min Unidirectional Link Delay value is higher than the Maximum 400 link delay advertised in FAEMD sub-TLV, the link MUST be excluded 401 from the Flex-Algorithm topology. If a link does not have the Min 402 Unidirectional Link Delay advertised but the FAD contains this sub- 403 TLV, then that link MUST NOT be excluded from the topology based on 404 the Maximum Delay constraint. 406 3.2. OSPF FAD constraint sub-TLVs 408 3.2.1. OSPF Exclude Minimum Bandwidth sub-TLV 410 OSPF Flex-Algorithm Exclude Minimum Bandwidth sub-TLV (FAEMB) is a 411 sub-TLV of the OSPF FAD TLV. It has the following format. 413 0 1 2 3 414 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 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Type | Length | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Min Bandwidth | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 where: 422 Type: TBD 424 Length: 4 octets. 426 Min Bandwidth: link bandwidth is encoded in 32 bits in IEEE 427 floating point format. The units are bytes per second. 429 Figure 5: OSPF FAEMB sub-TLV 431 The FAEMB sub-TLV MUST appear only once in the FAD sub-TLV. If it 432 appears more than once, the OSPF FAD TLV MUST be ignored by the 433 receiver. The Maximum Link Bandwidth as advertised by the sub-sub- 434 TLV 23 of ASLA [RFC 8920] MUST be compared against the Minimum 435 bandwidth advertised in FAEMB sub-TLV. If the link bandwidth is 436 lower than the Minimum bandwidth advertised in FAEMB sub-TLV, the 437 link MUST be excluded from the Flex-Algorithm topology. If a link 438 does not have the Maximum Link Bandwidth advertised but the FAD 439 contains this sub-TLV, then that link MUST be included in the 440 topology and proceed to apply further pruning rules for the link. 442 3.2.2. OSPF Exclude Maximum Delay sub-TLV 444 OSPF Flex-Algorithm Exclude Maximum Delay sub-TLV (FAEMD) is a sub- 445 TLV of the OSPF FAD TLV. It has the following format. 447 0 1 2 3 448 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 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Type | Length | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Max Delay | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 where: 456 Type: TBD 458 Length: 3 octets 460 Max link delay: Maximum link delay in microseconds 462 Figure 6: OSPF FAEMD sub-TLV 464 The FAEMD sub-TLV MUST appear only once in the OSPF FAD TLV. If it 465 appears more than once, the OSPF FAD TLV MUST be ignored by the 466 receiver. The Min Unidirectional Link Delay as advertised by sub- 467 sub-TLV 12 of ASLA sub-TLV [RFC 8920], MUST be compared against the 468 Maximum delay advertised in FAEMD sub-TLV. If the Min Unidirectional 469 Link Delay is higher than the Maximum delay advertised in FAEMD sub- 470 TLV, the link MUST be excluded from the Flex-Algorithm topology If a 471 link does not have the Min Unidirectional Link Delay advertised but 472 the FAD contains this sub-TLV, then then that link MUST NOT be 473 excluded from the topology based on the Maximum Delay constraint. 475 4. Bandwidth Metric Advertisement 477 Historically, IGP implementations have made default metric 478 assignments based on link bandwidth. This has proven to be useful, 479 but has suffered from having different defaults across 480 implementations and from the rapid growth of link bandwidths. With 481 Flex-Algorithm, the network administrator can define a function that 482 will produce a metric for each link have each node automatically 483 compute each link's metric based its bandwidth. 485 This document defines a new standard metric type for this purpose 486 called the "Bandwidth Metric". The Bandwidth Metric MAY be 487 advertised in the Generic Metric sub-TLV with the metric type set to 488 "Bandwidth Metric". ISIS and OSPF will advertise this new type of 489 metric in their link advertisements. Bandwidth metric is a link 490 attribute and for advertisement and processing of this attribute for 491 Flex-algorithm purposes, MUST follow the the section 12 of 492 [I-D.ietf-lsr-flex-algo] 493 Flex-Algorithm uses this metric type by specifying the bandwidth 494 metric as the metric type in a FAD TLV. A FAD TLV may also specify 495 an automatic computation of the bandwidth metric based on a links 496 advertised bandwidth. An explicit advertisement of a link's 497 bandwidth metric using the Generic Metric sub-TLV overrides this 498 automatic computation. The automatic bandwidth metric calculation 499 sub-TLVs are advertised in FAD TLV and these parameters are 500 applicable to applications such as Flex-algorithm that make use of 501 the FAD TLV. 503 4.1. Automatic Metric Calculation 505 Networks which are designed to be highly regular and follow uniform 506 metric assignment may want to simplify their operations by 507 automatically calculating the bandwidth metric. When a FAD 508 advertises the metric type as Bandwidth Metric and the link does not 509 have the Bandwidth Metric advertised, automatic metric derivation can 510 be used with additional FAD constraint advertisements as described in 511 this section. 513 If a link's bandwidth changes, then the delay in learning about the 514 change may create the possibility of micro-loops in the topology. 515 This is no different from the IGP's susceptibility to micro-loops 516 during a metric change. The micro-loop avoidance procedures 517 described in [I-D.bashandy-rtgwg-segment-routing-uloop] can be used 518 to avoid micro-loops when the automatic metric calculation is 519 deployed. 521 Computing the metric between adjacent systems based on bandwidth 522 becomes more complex in the face of parallel adjacencies. If there 523 are parallel adjacnecies between systems, then the bandwidth between 524 the systems is the sum of the bandwidth of the parallel links. This 525 is somewhat more complex to deal with, so there is an optional mode 526 for computing the aggregate bandwidth. 528 4.1.1. Automatic Metric Calculation Modes 530 4.1.1.1. Simple Mode 532 In simple mode, the Maximum Link Bandwidth of a single Layer 3 link 533 is used to derive the metric. This mode is suitable for deployments 534 that do not use parallel Layer 3 links. In this case, the 535 computation of the metric is straightforward. If a layer 3 link is 536 composed of a layer 2 bundle, then the link bandwidth is the sum of 537 the bandwidths of the working components and may vary with layer 2 538 link failures. 540 4.1.1.2. Interface Group Mode 542 The simple mode of metric calculation may not work well when there 543 are multiple parallel layer 3 interfaces between two nodes. Ideally, 544 the metric between two systems should be the same given the same 545 bandwidth, whether the bandwidth is provided by parallel layer 2 546 links or parallel layer 3 links. To address this, in Interface Group 547 Mode, nodes MUST compute the aggregate bandwidth of all parallel 548 adjacencies, MUST derive the metric based on the aggregate bandwidth, 549 and MUST apply the resulting metric to each of the parallel 550 adjacencies. 552 A------B====C====F====D 553 | | 554 ------E------- 556 Figure 7: Parallel interfaces 558 For exmple, in the above diagram, there are two parallel links 559 between B->C, C->F, F->D. Let us assume the link bandwidth is 560 uniform 10Gbps on all links and the metric for each link will be the 561 same. Traffic from B to D will be forwarded B->E->D. Since the 562 bandwidth is higher on the B->C->F->D path, the metric for that path 563 should be lower, and that path should be selected. Interface Group 564 Mode is preferred in cases where there are parallel layer 3 links. 566 In the interface group mode, every node MUST identify the set of 567 parallel links between a pair of nodes based on IGP link 568 advertisements and MUST consider cumulative bandwidth of the parallel 569 links while arriving at the metric of each link. 571 4.1.2. Automatic Metric Calculation Methods 573 In automatic metric calculation for simple and interface group mode, 574 Maximum Link Bandwidth of the links is used to derive the metric. 575 There are two types of automatic metric derivation methods. 577 1. Reference bandwidth method 579 2. Bandwidth thresholds method 581 4.1.2.1. Reference Bandwidth method 583 In many networks, the metric is inversely proportional to the link 584 bandwidth. The administrator or implementation selects a reference 585 bandwdith and the metric is derived by dividing the reference 586 bandwidth by the advertised Maximum Link Bandwidth. Advertising the 587 reference bandwidth in the FAD constraints allows the metric 588 computation to be done automatically. Centralized control of this 589 reference bandwidth simplifies management in the case that the 590 reference bandwidth changes. In order to ensure that small bandwidth 591 changes do not change the link metric, it is useful to define the 592 granularity of the bandwidth that is of interest. The link bandwidth 593 will be truncated to this granularity before deriving the metric. 595 For example, 597 reference bandwidth = 1000G 599 Granularity = 20G 601 The derived metric is 10 for link bandwidth in the range 100G to 602 119G 604 4.1.2.2. Bandwidth Thresholds method 606 The reference bandwidth approach described above provides a uniform 607 metric value for a range of link bandwidths. In certain cases there 608 may be a need to define non-proportional metric values for the 609 varying ranges of link bandwidth. For example, bandwidths from 10G 610 to 30G are assigned metric value 100, bandwidth from 30G to 70G get a 611 metric value of 50, and bandwidths greater than 70G have a metric of 612 10. In order to support this, a staircase mapping based on bandwidth 613 thresholds is supported in the FAD. This advertisement contains a 614 set of threshold values and associated metrics. 616 4.1.3. ISIS FAD constraint sub-TLVs for automatic metric calculation 618 4.1.3.1. Reference Bandwidth sub-TLV 620 This section provides FAD constraint advertisement details for the 621 reference bandwidth method of metric calculation as described in 622 Section 4.1.2.1. The Flexible Algorithm Definition Reference 623 Bandwidth Sub-TLV (FADRB Sub-TLV) is a Sub-TLV of the ISIS FAD sub- 624 TLV. It has the following format: 626 0 1 2 3 627 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 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | Type | Length | Flags | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | Reference Bandwidth | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 | Granularity Bandwidth | 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 where: 638 Type: TBD 640 Length: 9 octets. 641 Reference Bandwidth: Bandwidth encoded in 32 bits in IEEE floating point 642 format. The units are in bytes per second. 643 Granularity Bandwidth: Bandwidth encoded in 32 bits in IEEE floating point 644 format. The units are in bytes per second. 646 Flags: 648 0 1 2 3 4 5 6 7 649 +-+-+-+-+-+-+-+-+ 650 |G| | | | 651 +-+-+-+-+-+-+-+-+ 653 G-flag: when set, interface group Mode MUST be used to derive total link bandwidth. 655 Metric calculation: (Reference_bandwidth) / 656 (Total_link_bandwidth - 657 (Modulus of(Total_link_bandwidth,granularity_bw))) 659 Figure 8: ISIS FADRB sub-TLV 661 Granularity Bandwidth value ensures that the metric does not change 662 when there is a small change in the link bandwidth. The ISIS FADRB 663 Sub-TLV MUST NOT appear more than once in an ISIS FAD sub-TLV. If it 664 appears more than once, the ISIS FAD sub-TLV MUST be ignored by the 665 receiver. If a Generic Metric sub-TLV with Bandwidth metric type is 666 advertised for a link, the Flex-Algorithm calculation MUST use the 667 advertised Bandwidth Metric, and MUST NOT use the automatically 668 derived metric for that link. 670 4.1.3.2. Bandwidth Thresholds sub-TLV 672 This section provides FAD constraint advertisement details for the 673 Bandwidth Thresholds method of metric calculation as described in 674 Section 4.1.2.2. The Flexible Algorithm Definition Bandwidth 675 Threshold Sub-TLV (FADBT Sub-TLV) is a Sub-TLV of the ISIS FAD sub- 676 TLV. It has the following format: 678 0 1 2 3 679 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 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | Type | Length | Flags | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | Bandwidth Threshold 1 | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | Threshold Metric 1 | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | Bandwidth Threshold 1 | 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | Threshold Metric 2 | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 | Bandwidth Threshold 2 | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 ..... 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 | Threshold Metric n-1 | 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | Bandwidth Threshold n-1 | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | Threshold Metric n | 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 where: 704 Type: TBD 706 Length: 1 + n*7 octets. Here n is equal to number of Threshold Metrics specified. 707 n MUST be greater than or equal to 1. 709 Flags: 711 0 1 2 3 4 5 6 7 712 +-+-+-+-+-+-+-+-+ 713 |G| | | | 714 +-+-+-+-+-+-+-+-+ 716 G-flag: when set, interface group Mode MUST be used to derive total link bandwidth. 718 Staircase bandwidth threshold and associated metric values. 719 Bandwidth Threshold 1: Minimum Link Bandwidth is encoded in 32 bits in IEEE 720 floating point format. The units are bytes per second. 721 Bandwidth Threshold 2: Maximum Link Bandwidth is encoded in 32 bits in IEEE 722 floating point format. The units are bytes per second. 723 Threshold Metric 1 : metric value range (1 - 4,261,412,864) 725 Figure 9: ISIS FADBT sub-TLV 727 When G-flag is set, the cumulative bandwidth of the parallel links is 728 computed as described in section Section 4.1.1.2. If G-flag is not 729 set, the advertised Maximum Link Bandwidth is used. 731 When the computed link bandwidth is less than Bandwidth Threshold 1, 732 the MAX_METRIC value of 4,261,412,864 MUST be assigned as the 733 Bandwidth Metric on the link during Flex-Algorithm SPF calculation. 735 When the computed link bandwidth is greater than or equal to 736 Bandwidth Threshold 1 and less than Bandwidth Threshold 1, Threshold 737 Metric 1 MUST be assigned as the Bandwidth Metric on the link during 738 Flex-Algorithm SPF calculation. 740 Similarly, when the computed link bandwidth is greater than or equal 741 to Bandwidth Threshold 1 and less than Bandwidth Threshold 2, 742 Threshold Metric 2 MUST be assigned as the Bandwidth Metric on the 743 link during Flex-Algorithm SPF calculation. 745 In general, when the computed link bandwidth is greater than or equal 746 to Bandwidth Threshold X AND less than Bandwidth Threshold X+1, 747 Threshold Metric X MUST be assigned as the Bandwidth Metric on the 748 link during Flex-Algorithm SPF calculation. 750 Finally, when the computed link bandwidth is greater than or equal to 751 Bandwidth Threshold n, then Threshold Metric n MUST be assigned as 752 the Bandwidth Metric on the link during Flex-Algorithm SPF 753 calculation. 755 The ISIS FADBT Sub-TLV MUST NOT appear more than once in an ISIS FAD 756 sub-TLV. If it appears more than once, the ISIS FAD sub-TLV MUST 757 MUST stop participating in such flex-algorithm. 759 A FAD MUST NOT contain both FADBT sub-TLV and FADRB sub-TLV. If both 760 these sub-TLVs are advertised in the same FAD for a Flexible 761 Algorithm, the FAD MUST be ignored by the receiver. 763 If a Generic Metric sub-TLV with Bandwidth metric type is advertised 764 for a link, the Flex-Algorithm calculation MUST use the Bandwidth 765 Metric advertised on the link, and MUST NOT use the automatically 766 derived metric for that link. 768 4.1.4. OSPF FAD constraint sub-TLVs for automatic metric calculation 770 4.1.4.1. Reference Bandwidth sub-TLV 772 The Flexible Algorithm Definition Reference Bandwidth Sub-TLV (FADRB 773 Sub-TLV) is a Sub-TLV of the OSPF FAD TLV. It has the following 774 format: 776 0 1 2 3 777 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 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | Type | Length | 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 | Flags | Reserved | 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 | Reference Bandwidth | 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 | Granularity Bandwidth | 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 where: 790 Type: TBD 792 Length: 14 octets. 793 Reference Bandwidth: Bandwidth encoded in 32 bits in IEEE floating point 794 format. The units are in bytes per second. 795 Granularity Bandwidth: Bandwidth encoded in 32 bits in IEEE floating point 796 format. The units are in bytes per second. 798 Flags: 800 0 1 2 3 4 5 6 7 801 +-+-+-+-+-+-+-+-+ 802 |G| | | | 803 +-+-+-+-+-+-+-+-+ 805 G-flag: when set, interface group Mode MUST be used 806 to derive total link bandwidth. 808 Metric calculation: (Reference_bandwidth) / 809 (Total_link_bandwidth - 810 (Modulus of(Total_link_bandwidth, Granularity_bw))) 812 Figure 10: OSPF FADRB sub-TLV 814 Granularity Bandwidth value is used to ensure that the metric does 815 not change when there is a small change in the link bandwidth. The 816 OSPF FADRB Sub-TLV MUST NOT appear more than once in an OSPF FAD TLV. 817 If it appears more than once, the OSPF FAD TLV MUST be ignored by the 818 receiver. If a Generic Metric sub-TLV with Bandwidth metric type is 819 advertised for a link, the Flex-Algorithm calculation MUST use the 820 advertised Bandwidth Metric on the link, and MUST NOT use the 821 automatically derived metric for that link. 823 4.1.4.2. Bandwidth Threshold sub-TLV 825 The Flexible Algorithm Definition Bandwidth Thresholds Sub-TLV (FADBT 826 Sub-TLV) is a Sub-TLV of the OSPF FAD TLV. It has the following 827 format: 829 0 1 2 3 830 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 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 | Type | Length | 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 | Flags | Reserved | 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 | Bandwidth Threshold 1 | 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 838 | Threshold Metric 1 | 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 | Bandwidth Threshold 2 | 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 | Threshold Metric 2 | 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 | Bandwidth Threshold 3 | 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 ..... 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 | Threshold Metric n-1 | 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 | Bandwidth Threshold n | 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 | Threshold Metric n | 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 where: 857 Type: TBD 859 Length: 2 + n*8 octets. Here n is equal to number of Threshold Metrics specified. 860 n MUST be greater than or equal to 1. 862 Flags: 864 0 1 2 3 4 5 6 7 865 +-+-+-+-+-+-+-+-+ 866 |G| | | | 867 +-+-+-+-+-+-+-+-+ 869 G-flag: when set, interface group Mode MUST be used to derive total link bandwidth. 871 Staircase bandwidth threshold and associated metric values. 872 Bandwidth Threshold 1: Minimum Link Bandwidth is encoded in 32 bits in IEEE 873 floating point format. The units are bytes per second. 874 Bandwidth Threshold 2: Maximum Link Bandwidth is encoded in 32 bits in IEEE 875 floating point format. The units are bytes per second. 876 Threshold Metric 1 : metric value range (1 - 4,294,967,296) 878 Figure 11: OSPF FADBT sub-TLV 880 When G-flag is set, the cumulative bandwidth of the parallel links is 881 computed as described in section Section 4.1.1.2. If G-flag is not 882 set, the advertised Maximum Link Bandwidth is used. 884 When the computed link bandwidth is less than Bandwidth Threshold 1 , 885 the MAX_METRIC value of 4,294,967,296 MUST be assigned as the 886 Bandwidth Metric on the link during Flex-Algorithm SPF calculation. 888 When the computed link bandwidth is greater than or equal to 889 Bandwidth Threshold 1 and less than Bandwidth Threshold 1, Threshold 890 Metric 1 MUST be assigned as the Bandwidth Metric on the link during 891 Flex-Algorithm SPF calculation. 893 Similarly, when the computed link bandwidth is greater than or equal 894 to Bandwidth Threshold 1 and less than Bandwidth Threshold 2, 895 Threshold Metric 2 MUST be assigned as the Bandwidth Metric on the 896 link during Flex-Algorithm SPF calculation. 898 In general, when the computed link bandwidth is greater than or equal 899 to Bandwidth Threshold X AND less than Bandwidth Threshold X+1, 900 Threshold Metric X MUST be assigned as the Bandwidth Metric on the 901 link during Flex-Algorithm SPF calculation. 903 Finally, when the computed link bandwidth is greater than or equal to 904 Bandwidth Threshold n, then Threshold Metric n MUST be assigned as 905 the Bandwidth Metric on the link during Flex-Algorithm SPF 906 calculation. 908 The ISIS FADBT Sub-TLV MUST NOT appear more than once in an ISIS FAD 909 sub-TLV. If it appears more than once, the ISIS FAD sub-TLV MUST 910 stop participating in such flex-algorithm. 912 A FAD MUST NOT contain both FADBT sub-TLV and FADRB sub-TLV. If both 913 these sub-TLVs are advertised in the same FAD for a Flexible 914 Algorithm, the FAD MUST be ignored by the receiver. 916 If a Generic Metric sub-TLV with Bandwidth metric type is advertised 917 for a link, the Flex-Algorithm calculation MUST use the Bandwidth 918 Metric advertised on the link, and MUST NOT use the automatically 919 derived metric for that link. 921 5. Bandwidth metric considerations 923 This section specifies the rules of deriving the Bandwidth Metric if 924 and only if the winning FAD for the Flex-Algorithm specifies the 925 metric-type as "Bandwidth Metric". 927 1. If the the Generic Metric sub-TLV with Bandwidth metric type 928 is advertised for the link as described in Section 4, it MUST be 929 used during the Flex-Algorithm calculation. 931 2. If the Generic Metric sub-TLV with Bandwidth metric type is 932 not advertised for the link and the winning FAD for the Flex- 933 Algorithm does not specify the automatic bandwidth metric 934 calculation (as defined in Section 4.1 ), the Bandwidth Metric is 935 considered as not being advertised for the link. 937 3. If the Generic Metric sub-TLV with Bandwidth metric type is 938 not advertised for the link and the winning FAD for the Flex- 939 Algorithm specifies the automatic bandwidth metric calculation (as 940 defined in Section 4.1), the Bandwidth Metric metric MUST be 941 automatically calculated as per the procedures defined in 942 Section 4.1. If the Bandwidth Metric can not be calculated due to 943 lack of Flex-Algorithm specific ASLA advertisement of sub-sub-TLV 944 9 [RFC 8919], or in case of IS-IS, in presence of the L-Flag in 945 the Flex-Algorithm specific ASLA advertisement the lack of sub-TLV 946 9 in the TLV 22/222/23/223/141 [RFC 5305], the Bandwidth Metric is 947 considered as not being advertised for the link. 949 6. Calculation of Flex-Algorithm paths 951 Two new additional rules are added to the existing rules in the Flex- 952 rules specified in sec 13 of [I-D.ietf-lsr-flex-algo]. 954 6. Check if any exclude FAEMB rule is part of the Flex-Algorithm 955 definition. If such exclude rule exists and the link has Maximum 956 Link Bandwidth advertised, check if the link bandwidth satisfies 957 the FAEMB rule. If the link does not satisfy the FAEMB rule, the 958 link MUST be pruned from the computation. 960 7. Check if any exclude FAEMD rule is part of the Flex-Algorithm 961 definition. If such exclude rule exists and the link has Min 962 Unidirectional link delay advertised, check if the link delay 963 satisfies the FAEMD rule. If the link does not satisfy the FAEMD 964 rule, the link MUST be pruned from the computation. 966 7. Backward Compatibility 968 8. Security Considerations 970 TBD 972 9. IANA Considerations 974 9.1. IGP Metric-Type Registry 976 Type: Suggested 3 (TBA) 978 Description: Bandwidth metric 980 Reference: This document 982 Type: 128 to 255(TBA) 984 Description: User defned metric 986 Reference: This document 988 9.2. ISIS Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV 990 Type: Suggested 6 (TBA) 992 Description: ISIS Exclude Minimum Bandwidth sub-TLV 994 Reference: This document Section 3.1.1 996 Type: Suggested 7 (TBA) 998 Description: ISIS Exclude Maximum Delay sub-TLV 1000 Reference: This document Section 3.1.2 1002 Type: Suggested 8 (TBA) 1004 Description: ISIS Reference Bandwidth sub-TLV 1006 Reference: This document Section 4.1.3.1 1007 Type: Suggested 9 (TBA) 1009 Description: ISIS Threshold Metric sub-TLV 1011 Reference: This document Section 4.1.3.2 1013 9.3. OSPF Sub-TLVs for Flexible Algorithm Definition Sub-TLV 1015 Type: Suggested 6 (TBA) 1017 Description: OSPF Exclude Minimum Bandwidth sub-TLV 1019 Reference: This document Section 3.2.1 1021 Type: Suggested 7 (TBA) 1023 Description: OSPF Exclude Maximum Delay sub-TLV 1025 Reference: This document Section 3.2.2 1027 Type: Suggested 8 (TBA) 1029 Description: OSPF Reference Bandwidth sub-TLV 1031 Reference: This document Section 4.1.4.1 1033 Type: Suggested 9 (TBA) 1035 Description: OSPF Threshold Metric sub-TLV 1037 Reference: This document Section 4.1.4.2 1039 9.4. Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223 1041 Type: Suggested 45 (TBA) 1043 Description: Generic metric 1045 Reference: This document Section 2.1 1047 9.5. Sub-sub-TLV Codepoints for Application-Specific Link Attributes 1049 Type: Suggested 45 (TBA) 1051 Description: Generic metric 1053 Reference: This document Section 2.1 1055 9.6. OSPFv2 Extended Link TLV Sub-TLVs 1057 Type: Suggested 45 (TBA) 1059 Description: Generic metric 1061 Reference: This document Section 2.2 1063 9.7. Types for sub-TLVs of TE Link TLV (Value 2) 1065 Type: Suggested 45 (TBA) 1067 Description: Generic metric 1069 Reference: This document Section 2.2 1071 10. Acknowledgements 1073 Many thanks to Chris Bowers, Krzysztof Szarcowitz, Julian Lucek, Ram 1074 Santhanakrishnan for discussions and inputs. 1076 11. Contributors 1078 1. Salih K A 1080 Juniper Networks 1082 salih@juniper.net 1084 12. References 1086 12.1. Normative References 1088 [I-D.ietf-lsr-flex-algo] 1089 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 1090 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 1091 algo-15 (work in progress), April 2021. 1093 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1094 Requirement Levels", BCP 14, RFC 2119, 1095 DOI 10.17487/RFC2119, March 1997, 1096 . 1098 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1099 (TE) Extensions to OSPF Version 2", RFC 3630, 1100 DOI 10.17487/RFC3630, September 2003, 1101 . 1103 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1104 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 1105 2008, . 1107 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 1108 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 1109 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 1110 2015, . 1112 12.2. Informative References 1114 [I-D.bashandy-rtgwg-segment-routing-uloop] 1115 Bashandy, A., Filsfils, C., Litkowski, S., Decraene, B., 1116 Francois, P., and P. Psenak, "Loop avoidance using Segment 1117 Routing", draft-bashandy-rtgwg-segment-routing-uloop-10 1118 (work in progress), December 2020. 1120 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 1121 Topology (MT) Routing in Intermediate System to 1122 Intermediate Systems (IS-ISs)", RFC 5120, 1123 DOI 10.17487/RFC5120, February 2008, 1124 . 1126 [RFC5311] McPherson, D., Ed., Ginsberg, L., Previdi, S., and M. 1127 Shand, "Simplified Extension of Link State PDU (LSP) Space 1128 for IS-IS", RFC 5311, DOI 10.17487/RFC5311, February 2009, 1129 . 1131 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 1132 Support of Inter-Autonomous System (AS) MPLS and GMPLS 1133 Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, 1134 December 2008, . 1136 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 1137 Previdi, "OSPF Traffic Engineering (TE) Metric 1138 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 1139 . 1141 [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, 1142 D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) 1143 Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 1144 2019, . 1146 Authors' Addresses 1147 Shraddha Hegde 1148 Juniper Networks Inc. 1149 Exora Business Park 1150 Bangalore, KA 560103 1151 India 1153 Email: shraddha@juniper.net 1155 William Britto A J 1156 Juniper Networks Inc. 1158 Email: bwilliam@juniper.net 1160 Rajesh Shetty 1161 Juniper Networks Inc. 1163 Email: mrajesh@juniper.net 1165 Bruno Decraene 1166 Orange 1168 Email: bruno.decraene@orange.com 1170 Peter Psenak 1171 Cisco Systems 1173 Email: ppsenak@cisco.com 1175 Tony Li 1176 Arista Networks 1178 Email: tony.li@tony.li