idnits 2.17.1 draft-ietf-lsr-isis-rfc7810bis-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 29, 2018) is 1974 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-14 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: June 2, 2019 S. Giacolone 7 Microsoft 8 D. Ward 9 Cisco Systems, Inc. 10 J. Drake 11 Juniper Networks 12 Q. Wu 13 Huawei 14 November 29, 2018 16 IS-IS Traffic Engineering (TE) Metric Extensions 17 draft-ietf-lsr-isis-rfc7810bis-03 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 June 2, 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 . . . . . . . . . . . . . . . 13 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 available bandwidths. 483 4.7. Unidirectional Utilized Bandwidth Sub-TLV 485 This sub-TLV advertises the bandwidth utilization between two 486 directly connected IS-IS neighbors. The bandwidth utilization 487 advertised by this sub-TLV MUST be the bandwidth from the system 488 originating this sub-TLV. The format of this sub-TLV is shown in the 489 following diagram: 491 0 1 2 3 492 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 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Type | Length | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Utilized Bandwidth | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 Figure 7 501 where: 503 Type: 39 505 Length: 4 506 Utilized Bandwidth: This field carries the bandwidth utilization on a 507 link, forwarding adjacency, or bundled link in IEEE floating-point 508 format with units of bytes per second. For a link or forwarding 509 adjacency, bandwidth utilization represents the actual utilization of 510 the link (i.e., as measured by the advertising node). For a bundled 511 link, bandwidth utilization is defined to be the sum of the component 512 link bandwidth utilizations. 514 5. Announcement Thresholds and Filters 516 The values advertised in all sub-TLVs (except min/max delay and 517 residual bandwidth) MUST represent an average over a period or be 518 obtained by a filter that is reasonably representative of an average. 519 For example, a rolling average is one such filter. 521 Min and max delay MUST each be derived in one of the following ways: 522 by taking the lowest and/or highest measured value over a measurement 523 interval or by making use of a filter or other technique to obtain a 524 reasonable representation of a min and max value representative of 525 the interval, with compensation for outliers. 527 The measurement interval, any filter coefficients, and any 528 advertisement intervals MUST be configurable per sub-TLV. 530 In addition to the measurement intervals governing re-advertisement, 531 implementations SHOULD provide configurable accelerated advertisement 532 thresholds per sub-TLV, such that: 534 1. If the measured parameter falls outside a configured upper bound 535 for all but the minimum delay metric (or lower bound for minimum 536 delay metric only) and the advertised sub-TLV is not already 537 outside that bound or, 539 2. If the difference between the last advertised value and current 540 measured value exceeds a configured threshold then, 542 3. The advertisement is made immediately. 544 4. For sub-TLVs that include an A bit, an additional threshold 545 SHOULD be included corresponding to the threshold for which the 546 performance is considered anomalous (and sub-TLVs with the A bit 547 are sent). The A bit is cleared when the sub-TLV's performance 548 has been below (or re-crosses) this threshold for an 549 advertisement interval(s) to permit fail back. 551 To prevent oscillations, only the high threshold or the low threshold 552 (but not both) may be used to trigger any given sub-TLV that supports 553 both. 555 Additionally, once outside the bounds of the threshold, any re- 556 advertisement of a measurement within the bounds would remain 557 governed solely by the measurement interval for that sub-TLV. 559 6. Announcement Suppression 561 When link-performance values change by small amounts that fall under 562 thresholds that would cause the announcement of a sub-TLV, 563 implementations SHOULD suppress sub-TLV re-advertisement and/or 564 lengthen the period within which they are refreshed. 566 Only the accelerated advertisement threshold mechanism described in 567 Section 5 may shorten the re-advertisement interval. All suppression 568 and re-advertisement interval backoff timer features SHOULD be 569 configurable. 571 7. Network Stability and Announcement Periodicity 573 Sections 5 and 6 provide configurable mechanisms to bound the number 574 of re-advertisements. Instability might occur in very large networks 575 if measurement intervals are set low enough to overwhelm the 576 processing of flooded information at some of the routers in the 577 topology. Therefore, care should be taken in setting these values. 579 Additionally, the default measurement interval for all sub-TLVs 580 SHOULD be 30 seconds. 582 Announcements MUST also be able to be throttled using configurable 583 inter-update throttle timers. The minimum announcement periodicity 584 is 1 announcement per second. The default value SHOULD be set to 120 585 seconds. 587 Implementations SHOULD NOT permit the inter-update timer to be lower 588 than the measurement interval. 590 Furthermore, it is RECOMMENDED that any underlying performance- 591 measurement mechanisms not include any significant buffer delay, any 592 significant buffer-induced delay variation, or any significant loss 593 due to buffer overflow or due to active queue management. 595 8. Enabling and Disabling Sub-TLVs 597 Implementations MUST make it possible to individually enable or 598 disable each sub-TLV based on configuration. 600 9. Static Metric Override 602 Implementations SHOULD permit static configuration and/or manual 603 override of dynamic measurements for each sub-TLV in order to 604 simplify migration and to mitigate scenarios where dynamic 605 measurements are not possible. 607 10. Compatibility 609 As per [RFC5305], unrecognized sub-TLVs should be silently ignored. 611 11. Security Considerations 613 The sub-TLVs introduced in this document allow an operator to 614 advertise state information of links (bandwidth, delay) that could be 615 sensitive and that an operator may not want to disclose. 617 Section 7 describes a mechanism to ensure network stability when the 618 new sub-TLVs defined in this document are advertised. Implementation 619 SHOULD follow the described guidelines to mitigate the instability 620 risk. 622 [RFC5304] describes an authentication method for IS-IS Link State 623 PDUs that allows cryptographic authentication of IS-IS Link State 624 PDUs. 626 It is anticipated that in most deployments, the IS-IS protocol is 627 used within an infrastructure entirely under control of the same 628 operator. However, it is worth considering that the effect of 629 sending IS-IS Traffic Engineering sub-TLVs over insecure links could 630 result in a man-in-the-middle attacker delaying real-time data to a 631 given site or destination, which could negatively affect the value of 632 the data for that site or destination. The use of Link State PDU 633 cryptographic authentication allows mitigation the risk of man-in- 634 the-middle attack. 636 12. IANA Considerations 638 IANA maintains the registry for the sub-TLVs. IANA has registered 639 the following sub-TLVs in the "Sub-TLVs for TLVs 22, 23, 141, 222, 640 and 223" registry: 642 Type Description 643 ---------------------------------------------------- 644 33 Unidirectional Link Delay 646 34 Min/Max Unidirectional Link Delay 648 35 Unidirectional Delay Variation 650 36 Unidirectional Link Loss 652 37 Unidirectional Residual Bandwidth 654 38 Unidirectional Available Bandwidth 656 39 Unidirectional Utilized Bandwidth 658 13. Acknowledgements 660 For the original version of this document the authors recognized 661 Ayman Soliman, Nabil Bitar, David McDysan, Edward Crabbe, Don Fedyk, 662 Hannes Gredler, Uma Chunduri, Alvaro Retana, Brian Weis, and Barry 663 Leiba for their contribution and review of this document. 665 The authors also recognized Curtis Villamizar for significant 666 comments and direct content collaboration. 668 For the second version of this document the authors thank Jeff Haas 669 for identifying and reporting the incorrect encoding of the bandwidth 670 related sub-TLVs. 672 14. Contributors 674 The following people contributed substantially to the content of this 675 document and should be considered co-authors: 677 Alia Atlas 678 Juniper Networks 679 United States 681 Email: akatlas@juniper.net 683 Clarence Filsfils 684 Cisco Systems Inc. 685 Belgium 687 Email: cfilsfil@cisco.com 689 15. References 691 15.1. Normative References 693 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 694 Requirement Levels", BCP 14, RFC 2119, 695 DOI 10.17487/RFC2119, March 1997, 696 . 698 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 699 Hierarchy with Generalized Multi-Protocol Label Switching 700 (GMPLS) Traffic Engineering (TE)", RFC 4206, 701 DOI 10.17487/RFC4206, October 2005, 702 . 704 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 705 Topology (MT) Routing in Intermediate System to 706 Intermediate Systems (IS-ISs)", RFC 5120, 707 DOI 10.17487/RFC5120, February 2008, 708 . 710 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 711 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 712 2008, . 714 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 715 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 716 2008, . 718 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 719 Support of Inter-Autonomous System (AS) MPLS and GMPLS 720 Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, 721 December 2008, . 723 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 724 Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, 725 February 2011, . 727 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 728 Previdi, "OSPF Traffic Engineering (TE) Metric 729 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 730 . 732 [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and 733 Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", 734 RFC 7810, DOI 10.17487/RFC7810, May 2016, 735 . 737 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 738 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 739 May 2017, . 741 15.2. Informative References 743 [I-D.ietf-idr-te-pm-bgp] 744 Ginsberg, L., Previdi, S., Wu, Q., Tantsura, J., and C. 745 Filsfils, "BGP-LS Advertisement of IGP Traffic Engineering 746 Performance Metric Extensions", draft-ietf-idr-te-pm- 747 bgp-14 (work in progress), October 2018. 749 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 750 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 751 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 752 . 754 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in 755 Support of Generalized Multi-Protocol Label Switching 756 (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, 757 . 759 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 760 Measurement for MPLS Networks", RFC 6374, 761 DOI 10.17487/RFC6374, September 2011, 762 . 764 [RFC6375] Frost, D., Ed. and S. Bryant, Ed., "A Packet Loss and 765 Delay Measurement Profile for MPLS-Based Transport 766 Networks", RFC 6375, DOI 10.17487/RFC6375, September 2011, 767 . 769 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 770 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 771 "Application-Layer Traffic Optimization (ALTO) Protocol", 772 RFC 7285, DOI 10.17487/RFC7285, September 2014, 773 . 775 Appendix A. Changes from RFC 7810 777 Errata ID: 5293 (https://www.rfc-editor.org/ 778 errata_search.php?rfc=7810) correctly identified that in [RFC7810] 779 the length associated with the following sub-TLVs did not match the 780 figures associated with each: 782 37 Unidirectional Residual Bandwidth 784 38 Unidirectional Available Bandwidth 786 39 Unidirectional Utilized Bandwidth 788 The length specified was 4 which did not include the RESERVED field 789 shown in the figures. Subsequent investigation revealed that some 790 implementations had used the specified length (4) and omitted the 791 RESERVED field while other implementations included the specified 792 RESERVED field and used a length of 5. 794 Because these different implementation choices are not interoperable, 795 it was decided that a bis version should be generated which resolved 796 the ambiguity. 798 The choice made here is to omit the unused RESERVED field from these 799 sub-TLVs and use the length of 4. This matches the corresponding 800 advertisements specified in the equivalent OSPF specification 801 [RFC7471] and the corresponding BGP-LS specification 802 [I-D.ietf-idr-te-pm-bgp]. 804 Some minor editorial corrections have also been made. 806 As a means of interoperating with implementations which do not 807 conform to the corrections defined in this document, implementers may 808 wish to consider temporarily supporting sending and/or receiving the 809 form of the sub-TLVs using a length of 5 and including the RESERVED 810 field. However, the intent of this revision is to specify one and 811 only one normative behavior. Any existing implementations which 812 encode the sub-TLVs using a length of 5 are expected to be revised to 813 conform to the normative behavior specified in this document. 815 Errata ID: 5486 (https://www.rfc-editor.org/errata/eid5486) 816 identified that in [RFC7810] Section 4.6 the definition of available 817 bandwidth on bundled links used a circular definition i.e., it used 818 "sum of the component link available bandwidths" when it should have 819 used "sum of the component link residual bandwidths". This has been 820 corrected and clarified. 822 Authors' Addresses 824 Les Ginsberg (editor) 825 Cisco Systems, Inc. 827 Email: ginsberg@cisco.com 828 Stefano Previdi (editor) 829 Huawei 831 Email: stefano@previdi.net 833 Spencer Giacolone 834 Microsoft 836 Email: spencer.giacalone@gmail.com 838 Dave Ward 839 Cisco Systems, Inc. 841 Email: wardd@cisco.com 843 John Drake 844 Juniper Networks 845 1194 N. Matilda Ace. 846 Sunnyvale, C 94089 847 United States 849 Email: jdrake@juniper.net 851 Qin Wu 852 Huawei 853 101 Software Avenue, Yuhua District 854 Nanjing, Jiangsu 210012 855 China 857 Email: sunseawq@huawei.com