idnits 2.17.1 draft-ietf-lsr-isis-rfc7810bis-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 2, 2018) is 2034 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) ** Obsolete normative reference: RFC 5316 (Obsoleted by RFC 9346) ** Obsolete normative reference: RFC 7810 (Obsoleted by RFC 8570) == Outdated reference: A later version (-18) exists of draft-ietf-idr-te-pm-bgp-10 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Link State Routing L. Ginsberg, Ed. 3 Internet-Draft Cisco Systems, Inc. 4 Obsoletes: 7810 (if approved) S. Previdi, Ed. 5 Intended status: Standards Track Huawei 6 Expires: March 6, 2019 S. Giacolone 7 Microsoft 8 D. Ward 9 Cisco Systems, Inc. 10 J. Drake 11 Juniper Networks 12 Q. Wu 13 Huawei 14 September 2, 2018 16 IS-IS Traffic Engineering (TE) Metric Extensions 17 draft-ietf-lsr-isis-rfc7810bis-02 19 Abstract 21 In certain networks, such as, but not limited to, financial 22 information networks (e.g., stock market data providers), network- 23 performance criteria (e.g., latency) are becoming as critical to 24 data-path selection as other metrics. 26 This document describes extensions to IS-IS Traffic Engineering 27 Extensions (RFC 5305) such that network-performance information can 28 be distributed and collected in a scalable fashion. The information 29 distributed using IS-IS TE Metric Extensions can then be used to make 30 path-selection decisions based on network performance. 32 Note that this document only covers the mechanisms with which 33 network-performance information is distributed. The mechanisms for 34 measuring network performance or acting on that information, once 35 distributed, are outside the scope of this document. 37 This document obsoletes RFC 7810. 39 Requirements Language 41 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 42 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 43 "OPTIONAL" in this document are to be interpreted as described in BCP 44 14 [RFC2119] [RFC8174] when, and only when, they appear in all 45 capitals, as shown here. 47 Status of This Memo 49 This Internet-Draft is submitted in full conformance with the 50 provisions of BCP 78 and BCP 79. 52 Internet-Drafts are working documents of the Internet Engineering 53 Task Force (IETF). Note that other groups may also distribute 54 working documents as Internet-Drafts. The list of current Internet- 55 Drafts is at https://datatracker.ietf.org/drafts/current/. 57 Internet-Drafts are draft documents valid for a maximum of six months 58 and may be updated, replaced, or obsoleted by other documents at any 59 time. It is inappropriate to use Internet-Drafts as reference 60 material or to cite them other than as "work in progress." 62 This Internet-Draft will expire on March 6, 2019. 64 Copyright Notice 66 Copyright (c) 2018 IETF Trust and the persons identified as the 67 document authors. All rights reserved. 69 This document is subject to BCP 78 and the IETF Trust's Legal 70 Provisions Relating to IETF Documents 71 (https://trustee.ietf.org/license-info) in effect on the date of 72 publication of this document. Please review these documents 73 carefully, as they describe your rights and restrictions with respect 74 to this document. Code Components extracted from this document must 75 include Simplified BSD License text as described in Section 4.e of 76 the Trust Legal Provisions and are provided without warranty as 77 described in the Simplified BSD License. 79 Table of Contents 81 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 82 2. TE Metric Extensions to IS-IS . . . . . . . . . . . . . . . . 4 83 3. Interface and Neighbor Addresses . . . . . . . . . . . . . . 5 84 4. Sub-TLV Details . . . . . . . . . . . . . . . . . . . . . . . 6 85 4.1. Unidirectional Link Delay Sub-TLV . . . . . . . . . . . . 6 86 4.2. Min/Max Unidirectional Link Delay Sub-TLV . . . . . . . . 6 87 4.3. Unidirectional Delay Variation Sub-TLV . . . . . . . . . 8 88 4.4. Unidirectional Link Loss Sub-TLV . . . . . . . . . . . . 8 89 4.5. Unidirectional Residual Bandwidth Sub-TLV . . . . . . . . 9 90 4.6. Unidirectional Available Bandwidth Sub-TLV . . . . . . . 10 91 4.7. Unidirectional Utilized Bandwidth Sub-TLV . . . . . . . . 11 92 5. Announcement Thresholds and Filters . . . . . . . . . . . . . 12 93 6. Announcement Suppression . . . . . . . . . . . . . . . . . . 13 94 7. Network Stability and Announcement Periodicity . . . . . . . 13 95 8. Enabling and Disabling Sub-TLVs . . . . . . . . . . . . . . . 14 96 9. Static Metric Override . . . . . . . . . . . . . . . . . . . 14 97 10. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 14 98 11. Security Considerations . . . . . . . . . . . . . . . . . . . 14 99 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 100 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 101 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 102 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 103 15.1. Normative References . . . . . . . . . . . . . . . . . . 16 104 15.2. Informative References . . . . . . . . . . . . . . . . . 17 105 Appendix A. Changes from RFC 7810 . . . . . . . . . . . . . . . 17 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 108 1. Introduction 110 In certain networks, such as, but not limited to, financial 111 information networks (e.g., stock market data providers), network- 112 performance information (e.g., latency) is becoming as critical to 113 data-path selection as other metrics. 115 In these networks, extremely large amounts of money rest on the 116 ability to access market data in "real time" and to predictably make 117 trades faster than the competition. Because of this, using metrics 118 such as hop count or cost as routing metrics is becoming only 119 tangentially important. Rather, it would be beneficial to be able to 120 make path-selection decisions based on performance data (such as 121 latency) in a cost-effective and scalable way. 123 This document describes extensions (hereafter called "IS-IS TE Metric 124 Extensions") to the IS-IS Extended Reachability TLV defined in 125 [RFC5305], that can be used to distribute network-performance 126 information (such as link delay, delay variation, packet loss, 127 residual bandwidth, and available bandwidth). 129 The data distributed by the IS-IS TE Metric Extensions proposed in 130 this document is meant to be used as part of the operation of the 131 routing protocol (e.g., by replacing cost with latency or considering 132 bandwidth as well as cost), to enhance Constrained-SPF (CSPF), or for 133 other uses such as supplementing the data used by an ALTO server 134 [RFC7285]. With respect to CSPF, the data distributed by IS-IS TE 135 Metric Extensions can be used to set up, fail over, and fail back 136 data paths using protocols such as RSVP-TE [RFC3209]. 138 Note that the mechanisms described in this document only disseminate 139 performance information. The methods for initially gathering that 140 performance information, such as described in [RFC6375], or acting on 141 it once it is distributed are outside the scope of this document. 142 Example mechanisms to measure latency, delay variation, and loss in 143 an MPLS network are given in [RFC6374]. While this document does not 144 specify how the performance information should be obtained, the 145 measurement of delay SHOULD NOT vary significantly based upon the 146 offered traffic load. Thus, queuing delays SHOULD NOT be included in 147 the delay measurement. For links such as Forwarding Adjacencies, 148 care must be taken that measurement of the associated delay avoids 149 significant queuing delay; that could be accomplished in a variety of 150 ways, including either by measuring with a traffic class that 151 experiences minimal queuing or by summing the measured link delays of 152 the components of the link's path. 154 2. TE Metric Extensions to IS-IS 156 This document registers new IS-IS TE sub-TLVs that can be announced 157 in the "Sub-TLVs for TLVs 22, 23, 141, 222, and 223" registry in 158 order to distribute network-performance information. The extensions 159 in this document build on the ones provided in IS-IS TE [RFC5305] and 160 GMPLS [RFC4203]. 162 IS-IS Extended Reachability TLV 22 (defined in [RFC5305]), Inter-AS 163 Reachability Information TLV 141 (defined in [RFC5316]), and MT-ISIS 164 TLV 222 (defined in [RFC5120]) have nested sub-TLVs that permit the 165 TLVs to be readily extended. This document registers several sub- 166 TLVs: 168 Type Description 169 ---------------------------------------------------- 170 33 Unidirectional Link Delay 172 34 Min/Max Unidirectional Link Delay 174 35 Unidirectional Delay Variation 176 36 Unidirectional Link Loss 178 37 Unidirectional Residual Bandwidth 180 38 Unidirectional Available Bandwidth 182 39 Unidirectional Utilized Bandwidth 184 As can be seen in the list above, the sub-TLVs described in this 185 document carry different types of network-performance information. 186 The new sub-TLVs include a bit called the Anomalous (or "A") bit. 187 When the A bit is clear (or when the sub-TLV does not include an A 188 bit), the sub-TLV describes steady-state link performance. This 189 information could conceivably be used to construct a steady-state 190 performance topology for initial tunnel-path computation, or to 191 verify alternative failover paths. 193 When network performance violates configurable link-local thresholds, 194 a sub-TLV with the A bit set is advertised. These sub-TLVs could be 195 used by the receiving node to determine whether to fail traffic to a 196 backup path or whether to calculate an entirely new path. From an 197 MPLS perspective, the intent of the A bit is to permit label switched 198 path ingress nodes to determine whether the link referenced in the 199 sub-TLV affects any of the label switched paths for which it is 200 ingress. If they are affected, then they can determine whether those 201 label switched paths still meet end-to-end performance objectives. 202 If not, then the node could conceivably move affected traffic to a 203 pre-established protection label switched path or establish a new 204 label switched path and place the traffic in it. 206 If link performance then improves beyond a configurable minimum value 207 (reuse threshold), that sub-TLV can be re-advertised with the A bit 208 cleared. In this case, a receiving node can conceivably do whatever 209 re-optimization (or failback) it wishes to do (including nothing). 211 Note that when a sub-TLV does not include the A bit, that sub-TLV 212 cannot be used for failover purposes. The A bit was intentionally 213 omitted from some sub-TLVs to help mitigate oscillations. See 214 Section 5 for more information. 216 Consistent with existing IS-IS TE specification [RFC5305], the 217 bandwidth advertisements defined in this document MUST be encoded as 218 IEEE floating-point values. The delay and delay-variation 219 advertisements defined in this document MUST be encoded as integer 220 values. Delay values MUST be quantified in units of microseconds, 221 packet loss MUST be quantified as a percentage of packets sent, and 222 bandwidth MUST be sent as bytes per second. All values (except 223 residual bandwidth) MUST be calculated as rolling averages where the 224 averaging period MUST be a configurable period of time. See 225 Section 5 for more information. 227 3. Interface and Neighbor Addresses 229 The use of IS-IS TE Metric Extensions sub-TLVs is not confined to the 230 TE context. In other words, IS-IS TE Metric Extensions sub-TLVs 231 defined in this document can also be used for computing paths in the 232 absence of a TE subsystem. 234 However, as for the TE case, Interface Address and Neighbor Address 235 sub-TLVs (IPv4 or IPv6) MUST be present. The encoding is defined in 236 [RFC5305] for IPv4 and in [RFC6119] for IPv6. 238 4. Sub-TLV Details 240 4.1. Unidirectional Link Delay Sub-TLV 242 This sub-TLV advertises the average link delay between two directly 243 connected IS-IS neighbors. The delay advertised by this sub-TLV MUST 244 be the delay from the local neighbor to the remote one (i.e., the 245 forward-path latency). The format of this sub-TLV is shown in the 246 following diagram: 248 0 1 2 3 249 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 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Type | Length | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 |A| RESERVED | Delay | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 Figure 1 258 where: 260 Type: 33 262 Length: 4 264 A bit: The A bit represents the Anomalous (A) bit. The A bit is set 265 when the measured value of this parameter exceeds its configured 266 maximum threshold. The A bit is cleared when the measured value 267 falls below its configured reuse threshold. If the A bit is clear, 268 the sub-TLV represents steady-state link performance. 270 RESERVED: This field is reserved for future use. It MUST be set to 0 271 when sent and MUST be ignored when received. 273 Delay: This 24-bit field carries the average link delay over a 274 configurable interval in microseconds, encoded as an integer value. 275 When set to the maximum value 16,777,215 (16.777215 sec), then the 276 delay is at least that value and may be larger. 278 4.2. Min/Max Unidirectional Link Delay Sub-TLV 280 This sub-TLV advertises the minimum and maximum delay values between 281 two directly connected IS-IS neighbors. The delay advertised by this 282 sub-TLV MUST be the delay from the local neighbor to the remote one 283 (i.e., the forward-path latency). The format of this sub-TLV is 284 shown in the following diagram: 286 0 1 2 3 287 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 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Type | Length | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 |A| RESERVED | Min Delay | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | RESERVED | Max Delay | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 Figure 2 298 where: 300 Type: 34 302 Length: 8 304 A bit: This field represents the Anomalous (A) bit. The A bit is set 305 when one or more measured values exceed a configured maximum 306 threshold. The A bit is cleared when the measured value falls below 307 its configured reuse threshold. If the A bit is clear, the sub-TLV 308 represents steady-state link performance. 310 RESERVED: This field is reserved for future use. It MUST be set to 0 311 when sent and MUST be ignored when received. 313 Min Delay: This 24-bit field carries the minimum measured link delay 314 value (in microseconds) over a configurable interval, encoded as an 315 integer value. 317 Max Delay: This 24-bit field carries the maximum measured link delay 318 value (in microseconds) over a configurable interval, encoded as an 319 integer value. 321 Implementations MAY also permit the configuration of an offset value 322 (in microseconds) to be added to the measured delay value, to 323 facilitate the communication of operator-specific delay constraints. 325 It is possible for the Min and Max delay to be the same value. 327 When the delay value (Min or Max) is set to the maximum value 328 16,777,215 (16.777215 sec), then the delay is at least that value and 329 may be larger. 331 4.3. Unidirectional Delay Variation Sub-TLV 333 This sub-TLV advertises the average link delay variation between two 334 directly connected IS-IS neighbors. The delay variation advertised 335 by this sub-TLV MUST be the delay from the local neighbor to the 336 remote one (i.e., the forward-path latency). The format of this sub- 337 TLV is shown in the following diagram: 339 0 1 2 3 340 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 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | Type | Length | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | RESERVED | Delay Variation | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 Figure 3 349 where 351 Type: 35 353 Length: 4 355 RESERVED: This field is reserved for future use. It MUST be set to 0 356 when sent and MUST be ignored when received. 358 Delay Variation: This 24-bit field carries the average link delay 359 variation over a configurable interval in microseconds, encoded as an 360 integer value. When set to 0, it has not been measured. When set to 361 the maximum value 16,777,215 (16.777215 sec), then the delay is at 362 least that value and may be larger. 364 4.4. Unidirectional Link Loss Sub-TLV 366 This sub-TLV advertises the loss (as a packet percentage) between two 367 directly connected IS-IS neighbors. The link loss advertised by this 368 sub-TLV MUST be the packet loss from the local neighbor to the remote 369 one (i.e., the forward-path loss). The format of this sub-TLV is 370 shown in the following diagram: 372 0 1 2 3 373 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 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Type | Length | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 |A| RESERVED | Link Loss | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 Figure 4 382 where: 384 Type: 36 386 Length: 4 388 A bit: The A bit represents the Anomalous (A) bit. The A bit is set 389 when the measured value of this parameter exceeds its configured 390 maximum threshold. The A bit is cleared when the measured value 391 falls below its configured reuse threshold. If the A bit is clear, 392 the sub-TLV represents steady-state link performance. 394 RESERVED: This field is reserved for future use. It MUST be set to 0 395 when sent and MUST be ignored when received. 397 Link Loss: This 24-bit field carries link packet loss as a percentage 398 of the total traffic sent over a configurable interval. The basic 399 unit is 0.000003%, where (2^24 - 2) is 50.331642%. This value is the 400 highest packet-loss percentage that can be expressed (the assumption 401 being that precision is more important on high-speed links than the 402 ability to advertise loss rates greater than this, and that high- 403 speed links with over 50% loss are unusable). Therefore, measured 404 values that are larger than the field maximum SHOULD be encoded as 405 the maximum value. 407 4.5. Unidirectional Residual Bandwidth Sub-TLV 409 This sub-TLV advertises the residual bandwidth between two directly 410 connected IS-IS neighbors. The residual bandwidth advertised by this 411 sub-TLV MUST be the residual bandwidth from the system originating 412 the Link State Advertisement (LSA) to its neighbor. 414 0 1 2 3 415 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 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | Type | Length | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Residual Bandwidth | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 Figure 5 424 where: 426 Type: 37 428 Length: 4 430 Residual Bandwidth: This field carries the residual bandwidth on a 431 link, forwarding adjacency [RFC4206], or bundled link in IEEE 432 floating-point format with units of bytes per second. For a link or 433 forwarding adjacency, residual bandwidth is defined to be the Maximum 434 Bandwidth [RFC5305] minus the bandwidth currently allocated to RSVP- 435 TE label switched paths. For a bundled link, residual bandwidth is 436 defined to be the sum of the component link residual bandwidths. 438 The calculation of residual bandwidth is different than that of 439 unreserved bandwidth [RFC5305]. Residual bandwidth subtracts tunnel 440 reservations from maximum bandwidth (i.e., the link capacity) 441 [RFC5305] and provides an aggregated remainder across priorities. 442 Unreserved bandwidth, on the other hand, is subtracted from the 443 maximum reservable bandwidth (the bandwidth that can theoretically be 444 reserved) and provides per-priority remainders. Residual bandwidth 445 and unreserved bandwidth [RFC5305] can be used concurrently and each 446 has a separate use case (e.g., the former can be used for 447 applications like Weighted ECMP while the latter can be used for call 448 admission control). 450 4.6. Unidirectional Available Bandwidth Sub-TLV 452 This sub-TLV advertises the available bandwidth between two directly 453 connected IS-IS neighbors. The available bandwidth advertised by 454 this sub-TLV MUST be the available bandwidth from the system 455 originating this sub-TLV. The format of this sub-TLV is shown in the 456 following diagram: 458 0 1 2 3 459 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 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | Type | Length | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Available Bandwidth | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 Figure 6 468 where: 470 Type: 38 472 Length: 4 474 Available Bandwidth: This field carries the available bandwidth on a 475 link, forwarding adjacency, or bundled link in IEEE floating-point 476 format with units of bytes per second. For a link or forwarding 477 adjacency, available bandwidth is defined to be residual bandwidth 478 (see Section 4.5) minus the measured bandwidth used for the actual 479 forwarding of non-RSVP-TE label switched path packets. For a bundled 480 link, available bandwidth is defined to be the sum of the component 481 link residual bandwidths (see Section 4.5) minus the sum of the 482 measured bandwidth used for the actual forwarding of non-RSVP-TE 483 label switched path packets on all component links. 485 4.7. Unidirectional Utilized Bandwidth Sub-TLV 487 This sub-TLV advertises the bandwidth utilization between two 488 directly connected IS-IS neighbors. The bandwidth utilization 489 advertised by this sub-TLV MUST be the bandwidth from the system 490 originating this sub-TLV. The format of this sub-TLV is shown in the 491 following diagram: 493 0 1 2 3 494 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 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Type | Length | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | Utilized Bandwidth | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 Figure 7 503 where: 505 Type: 39 506 Length: 4 508 Utilized Bandwidth: This field carries the bandwidth utilization on a 509 link, forwarding adjacency, or bundled link in IEEE floating-point 510 format with units of bytes per second. For a link or forwarding 511 adjacency, bandwidth utilization represents the actual utilization of 512 the link (i.e., as measured by the advertising node). For a bundled 513 link, bandwidth utilization is defined to be the sum of the component 514 link bandwidth utilizations. 516 5. Announcement Thresholds and Filters 518 The values advertised in all sub-TLVs (except min/max delay and 519 residual bandwidth) MUST represent an average over a period or be 520 obtained by a filter that is reasonably representative of an average. 521 For example, a rolling average is one such filter. 523 Min and max delay MUST each be derived in one of the following ways: 524 by taking the lowest and/or highest measured value over a measurement 525 interval or by making use of a filter or other technique to obtain a 526 reasonable representation of a min and max value representative of 527 the interval, with compensation for outliers. 529 The measurement interval, any filter coefficients, and any 530 advertisement intervals MUST be configurable per sub-TLV. 532 In addition to the measurement intervals governing re-advertisement, 533 implementations SHOULD provide configurable accelerated advertisement 534 thresholds per sub-TLV, such that: 536 1. If the measured parameter falls outside a configured upper bound 537 for all but the minimum delay metric (or lower bound for minimum 538 delay metric only) and the advertised sub-TLV is not already 539 outside that bound or, 541 2. If the difference between the last advertised value and current 542 measured value exceeds a configured threshold then, 544 3. The advertisement is made immediately. 546 4. For sub-TLVs that include an A bit, an additional threshold 547 SHOULD be included corresponding to the threshold for which the 548 performance is considered anomalous (and sub-TLVs with the A bit 549 are sent). The A bit is cleared when the sub-TLV's performance 550 has been below (or re-crosses) this threshold for an 551 advertisement interval(s) to permit fail back. 553 To prevent oscillations, only the high threshold or the low threshold 554 (but not both) may be used to trigger any given sub-TLV that supports 555 both. 557 Additionally, once outside the bounds of the threshold, any re- 558 advertisement of a measurement within the bounds would remain 559 governed solely by the measurement interval for that sub-TLV. 561 6. Announcement Suppression 563 When link-performance values change by small amounts that fall under 564 thresholds that would cause the announcement of a sub-TLV, 565 implementations SHOULD suppress sub-TLV re-advertisement and/or 566 lengthen the period within which they are refreshed. 568 Only the accelerated advertisement threshold mechanism described in 569 Section 5 may shorten the re-advertisement interval. All suppression 570 and re-advertisement interval backoff timer features SHOULD be 571 configurable. 573 7. Network Stability and Announcement Periodicity 575 Sections 5 and 6 provide configurable mechanisms to bound the number 576 of re-advertisements. Instability might occur in very large networks 577 if measurement intervals are set low enough to overwhelm the 578 processing of flooded information at some of the routers in the 579 topology. Therefore, care should be taken in setting these values. 581 Additionally, the default measurement interval for all sub-TLVs 582 SHOULD be 30 seconds. 584 Announcements MUST also be able to be throttled using configurable 585 inter-update throttle timers. The minimum announcement periodicity 586 is 1 announcement per second. The default value SHOULD be set to 120 587 seconds. 589 Implementations SHOULD NOT permit the inter-update timer to be lower 590 than the measurement interval. 592 Furthermore, it is RECOMMENDED that any underlying performance- 593 measurement mechanisms not include any significant buffer delay, any 594 significant buffer-induced delay variation, or any significant loss 595 due to buffer overflow or due to active queue management. 597 8. Enabling and Disabling Sub-TLVs 599 Implementations MUST make it possible to individually enable or 600 disable each sub-TLV based on configuration. 602 9. Static Metric Override 604 Implementations SHOULD permit static configuration and/or manual 605 override of dynamic measurements for each sub-TLV in order to 606 simplify migration and to mitigate scenarios where dynamic 607 measurements are not possible. 609 10. Compatibility 611 As per [RFC5305], unrecognized sub-TLVs should be silently ignored. 613 11. Security Considerations 615 The sub-TLVs introduced in this document allow an operator to 616 advertise state information of links (bandwidth, delay) that could be 617 sensitive and that an operator may not want to disclose. 619 Section 7 describes a mechanism to ensure network stability when the 620 new sub-TLVs defined in this document are advertised. Implementation 621 SHOULD follow the described guidelines to mitigate the instability 622 risk. 624 [RFC5304] describes an authentication method for IS-IS Link State 625 PDUs that allows cryptographic authentication of IS-IS Link State 626 PDUs. 628 It is anticipated that in most deployments, the IS-IS protocol is 629 used within an infrastructure entirely under control of the same 630 operator. However, it is worth considering that the effect of 631 sending IS-IS Traffic Engineering sub-TLVs over insecure links could 632 result in a man-in-the-middle attacker delaying real-time data to a 633 given site or destination, which could negatively affect the value of 634 the data for that site or destination. The use of Link State PDU 635 cryptographic authentication allows mitigation the risk of man-in- 636 the-middle attack. 638 12. IANA Considerations 640 IANA maintains the registry for the sub-TLVs. IANA has registered 641 the following sub-TLVs in the "Sub-TLVs for TLVs 22, 23, 141, 222, 642 and 223" registry: 644 Type Description 645 ---------------------------------------------------- 646 33 Unidirectional Link Delay 648 34 Min/Max Unidirectional Link Delay 650 35 Unidirectional Delay Variation 652 36 Unidirectional Link Loss 654 37 Unidirectional Residual Bandwidth 656 38 Unidirectional Available Bandwidth 658 39 Unidirectional Utilized Bandwidth 660 13. Acknowledgements 662 For the original version of this document the authors recognized 663 Ayman Soliman, Nabil Bitar, David McDysan, Edward Crabbe, Don Fedyk, 664 Hannes Gredler, Uma Chunduri, Alvaro Retana, Brian Weis, and Barry 665 Leiba for their contribution and review of this document. 667 The authors also recognized Curtis Villamizar for significant 668 comments and direct content collaboration. 670 For the second version of this document the authors thank Jeff Haas 671 for identifying and reporting the incorrect encoding of the bandwidth 672 related sub-TLVs. 674 14. Contributors 676 The following people contributed substantially to the content of this 677 document and should be considered co-authors: 679 Alia Atlas 680 Juniper Networks 681 United States 683 Email: akatlas@juniper.net 685 Clarence Filsfils 686 Cisco Systems Inc. 687 Belgium 689 Email: cfilsfil@cisco.com 691 15. References 693 15.1. Normative References 695 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 696 Requirement Levels", BCP 14, RFC 2119, 697 DOI 10.17487/RFC2119, March 1997, 698 . 700 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 701 Hierarchy with Generalized Multi-Protocol Label Switching 702 (GMPLS) Traffic Engineering (TE)", RFC 4206, 703 DOI 10.17487/RFC4206, October 2005, 704 . 706 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 707 Topology (MT) Routing in Intermediate System to 708 Intermediate Systems (IS-ISs)", RFC 5120, 709 DOI 10.17487/RFC5120, February 2008, 710 . 712 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 713 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 714 2008, . 716 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 717 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 718 2008, . 720 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 721 Support of Inter-Autonomous System (AS) MPLS and GMPLS 722 Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, 723 December 2008, . 725 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 726 Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, 727 February 2011, . 729 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 730 Previdi, "OSPF Traffic Engineering (TE) Metric 731 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 732 . 734 [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and 735 Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", 736 RFC 7810, DOI 10.17487/RFC7810, May 2016, 737 . 739 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 740 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 741 May 2017, . 743 15.2. Informative References 745 [I-D.ietf-idr-te-pm-bgp] 746 Ginsberg, L., Previdi, S., Wu, Q., Tantsura, J., and C. 747 Filsfils, "BGP-LS Advertisement of IGP Traffic Engineering 748 Performance Metric Extensions", draft-ietf-idr-te-pm- 749 bgp-10 (work in progress), March 2018. 751 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 752 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 753 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 754 . 756 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in 757 Support of Generalized Multi-Protocol Label Switching 758 (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, 759 . 761 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 762 Measurement for MPLS Networks", RFC 6374, 763 DOI 10.17487/RFC6374, September 2011, 764 . 766 [RFC6375] Frost, D., Ed. and S. Bryant, Ed., "A Packet Loss and 767 Delay Measurement Profile for MPLS-Based Transport 768 Networks", RFC 6375, DOI 10.17487/RFC6375, September 2011, 769 . 771 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 772 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 773 "Application-Layer Traffic Optimization (ALTO) Protocol", 774 RFC 7285, DOI 10.17487/RFC7285, September 2014, 775 . 777 Appendix A. Changes from RFC 7810 779 Errata ID: 5293 (https://www.rfc-editor.org/ 780 errata_search.php?rfc=7810) correctly identified that in [RFC7810] 781 the length associated with the following sub-TLVs did not match the 782 figures associated with each: 784 37 Unidirectional Residual Bandwidth 786 38 Unidirectional Available Bandwidth 788 39 Unidirectional Utilized Bandwidth 790 The length specified was 4 which did not include the RESERVED field 791 shown in the figures. Subsequent investigation revealed that some 792 implementations had used the specified length (4) and omitted the 793 RESERVED field while other implementations included the specified 794 RESERVED field and used a length of 5. 796 Because these different implementation choices are not interoperable, 797 it was decided that a bis version should be generated which resolved 798 the ambiguity. 800 The choice made here is to omit the unused RESERVED field from these 801 sub-TLVs and use the length of 4. This matches the corresponding 802 advertisements specified in the equivalent OSPF specification 803 [RFC7471] and the corresponding BGP-LS specification 804 [I-D.ietf-idr-te-pm-bgp]. 806 Some minor editorial corrections have also been made. 808 As a means of interoperating with implementations which do not 809 conform to the corrections defined in this document, implementers may 810 wish to consider temporarily supporting sending and/or receiving the 811 form of the sub-TLVs using a length of 5 and including the RESERVED 812 field. However, the intent of this revision is to specify one and 813 only one normative behavior. Any existing implementations which 814 encode the sub-TLVs using a length of 5 are expected to be revised to 815 conform to the normative behavior specified in this document. 817 Errata ID: 5486 (https://www.rfc-editor.org/errata/eid5486) 818 identified that in [RFC7810] Section 4.6 the definition of available 819 bandwidth on bundled links used a circular definition i.e., it used 820 "sum of the component link available bandwidths" when it should have 821 used "sum of the component link residual bandwidths". This has been 822 corrected and clarified. 824 Authors' Addresses 826 Les Ginsberg (editor) 827 Cisco Systems, Inc. 829 Email: ginsberg@cisco.com 830 Stefano Previdi (editor) 831 Huawei 833 Email: stefano@previdi.net 835 Spencer Giacolone 836 Microsoft 838 Email: spencer.giacalone@gmail.com 840 Dave Ward 841 Cisco Systems, Inc. 843 Email: wardd@cisco.com 845 John Drake 846 Juniper Networks 847 1194 N. Matilda Ace. 848 Sunnyvale, C 94089 849 United States 851 Email: jdrake@juniper.net 853 Qin Wu 854 Huawei 855 101 Software Avenue, Yuhua District 856 Nanjing, Jiangsu 210012 857 China 859 Email: sunseawq@huawei.com