idnits 2.17.1 draft-decraene-lsr-isis-flooding-speed-07.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 12, 2021) is 1011 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589' == Outdated reference: A later version (-02) exists of draft-cardwell-iccrg-bbr-congestion-control-00 == Outdated reference: A later version (-18) exists of draft-ietf-lsr-dynamic-flooding-08 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Decraene 3 Internet-Draft Orange 4 Intended status: Standards Track C. Bowers 5 Expires: January 13, 2022 Jayesh. J 6 Juniper Networks, Inc. 7 T. Li 8 Arista Networks 9 G. Van de Velde 10 Nokia 11 G. Solignac 12 Orange 13 July 12, 2021 15 IS-IS Flooding Congestion Control 16 draft-decraene-lsr-isis-flooding-speed-07 18 Abstract 20 This document proposes a mechanism to adjust IS-IS flooding speed 21 between two adjacent routers by adjusting the sender flooding speed 22 to the capability of the receiver. This helps improving the flooding 23 throughput, reducing LSPs losses and retransmissions due to receiver 24 overload, and avoiding manual tuning of flooding parameters by the 25 network operator. This document defines a new TLV for Hello 26 messages. This TLV may carry a set of parameters indicating the 27 performance capacity to receive LSPs. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 13, 2022. 46 Copyright Notice 48 Copyright (c) 2021 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 65 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Flooding Parameters TLV . . . . . . . . . . . . . . . . . . . 5 67 3.1. InterfaceLSPReceiveWindow sub-TLV . . . . . . . . . . . . 5 68 3.2. minimumInterfaceLSPTransmissionInterval sub-TLV . . . . . 5 69 4. Flow control . . . . . . . . . . . . . . . . . . . . . . . . 6 70 4.1. Operation on a point to point interface . . . . . . . . . 6 71 4.2. Faster acknowledgments of LSPs . . . . . . . . . . . . . 7 72 4.3. Operation on a LAN interface . . . . . . . . . . . . . . 8 73 5. Congestion control . . . . . . . . . . . . . . . . . . . . . 9 74 5.1. Slow start . . . . . . . . . . . . . . . . . . . . . . . 9 75 5.2. Congestion avoidance . . . . . . . . . . . . . . . . . . 10 76 5.3. Remarks . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 6. Interaction with other LSP rate limiting mechanisms . . . . . 11 78 7. Determining values to be advertised in the Flooding 79 Parameters TLV . . . . . . . . . . . . . . . . . . . . . . . 12 80 8. Operation considerations . . . . . . . . . . . . . . . . . . 13 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 82 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 83 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 84 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 12.1. Normative References . . . . . . . . . . . . . . . . . . 15 86 12.2. Informative References . . . . . . . . . . . . . . . . . 15 87 Appendix A. Changes / Author Notes . . . . . . . . . . . . . . . 16 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 90 1. Introduction 92 IGP flooding is paramount for Link State IGP as routing computations 93 assume that the Link State DataBases (LSDBs) are always in sync 94 across all nodes in the flooding domain. 96 Slow flooding directly translates to delayed network reaction to 97 failure and LSDB inconsistencies across nodes. The former increases 98 packet loss. The latter translates to routing inconsistencies and 99 possibly micro-loops leading to packet loss, link overload, and 100 jitter for all classes of service. Note that across the network, 101 multiple links may be affected by these forwarding issues, even in 102 the case of a single link failure. 104 In addition, one single event in the network can require the flooding 105 of multiple LSPs. The typical case is a node failure which requires 106 the flooding of at least one LSP per neighbor of the failed node. 107 Hence, if a node has N IGP neighbors, the failure of this node 108 requires the advertisement and flooding of at least N LSPs. The 109 network won't be able to converge to the new topology until all N 110 LSPs are received by all nodes. Hence there is a need to be able to 111 quickly exchange N LSPs. This document addresses this requirement by 112 allowing the fast flooding of a number of consecutive LSPs. 114 IGP flooding is hard. One would want fast flooding when the network 115 is stable and slow enough flooding to not overload the neighbor(s) 116 when the network is less stable. Since flooding is performed hop by 117 hop, not overloading the adjacent receiver is sufficient. 119 Improving the communication speed and efficiency between IS-IS 120 neighbors improves IS-IS scaling. These extensions do not compete 121 with proposed extensions to reduce LSP flooding traffic by reducing 122 the flooding topology such as [I-D.ietf-lsr-dynamic-flooding] . On 123 the contrary, this extension complements those proposals. Indeed 124 reducing the flooding topology does not reduce the size of the LSDB 125 or the total number of LSPs to exchange between two nodes. So 126 increasing the overall flooding speed can be beneficial for nodes 127 implementing dynamic flooding. The reverse is also true: as dynamic 128 flooding reduces the number of neighbors with flooding enabled, this 129 allows nodes implementing the flooding parameter extensions to focus 130 their flooding resources on those neighbors by sending better 131 parameters to the selected flooding nodes and worse parameters to 132 non-selected flooding nodes. 134 1.1. Requirements Language 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 138 "OPTIONAL" in this document are to be interpreted as described in BCP 139 14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they 140 appear in all capitals, as shown here. 142 2. Overview 144 Ensuring the goodput between two entities is a layer 4 responsibility 145 as per the OSI model and a typical example is the TCP protocol 146 defined in RFC 793 [RFC0793] . It typically relies on the following 147 sub-functions: flow control, congestion control and reliability. 149 Flow control is about creating a control loop between a single 150 transmitter and single receiver. TCP provides a mean for the 151 receiver to govern the amount of data sent by the sender. This is 152 achieved by advertising a "receive window", in units of octets, with 153 every ACK. This document proposes to use the same mechanism by 154 advertising a receive window, in units of LSP packets, in IS-IS 155 Hello. The window indicates an allowed number of LSPs that the 156 sender may transmit before receiving acknowledgment of those LSPs. 157 There is an assumption that this is related to the currently 158 available data buffer space available for this adjacency. Indicating 159 a large window encourages transmissions. 161 Congestion control is about creating multiple interacting control 162 loops between multiple transmitters and multiple receivers. Whereas 163 flow control prevents the sender from overwhelming the receiver, 164 congestion control prevents senders from overwhelming the network. 165 For an IS-IS adjacency, the network between two IS-IS neighbors is 166 relatively limited in scope and consist in a link which is typically 167 over-sized compared to the capability of the IS-IS speakers, but also 168 includes components inside both routers such as a fabric switch, line 169 card CPU and forwarding plane buffers which may experience 170 congestion. This document proposes to use the AIMD (Additive 171 Increase Multiplicative Decrease) algorithm to react to packet loss. 172 Note that TCP Reno relies on the same algorithm. 174 Reliability relies on loss detection and recovery. IS-IS already has 175 mechanisms to ensure the reliable transmission of LSPs. This is not 176 changed by this document. 178 3. Flooding Parameters TLV 180 This document defines a new TLV called "Flooding Parameters TLV" that 181 may be included in IIH PDUs. It allows the LSP receiver to advertise 182 receiver related parameters and capabilities which allows the LSP 183 sender to better adapt to the receiver. 185 Type: TBD1. 187 Length: variable, the size in octet of the Value field. 189 Value: a list of sub-TLVs. 191 Two sub-TLVs are defined in this document. 193 3.1. InterfaceLSPReceiveWindow sub-TLV 195 The sub-TLV InterfaceLSPReceiveWindow advertises the maximum number 196 of un-acknowledged LSPs that the node can receive/process with no 197 separation interval between LSPs. 199 Type: 1. 201 Length: 4 octets. 203 Value: number of un-acknowledged LSPs which can be sent back to back. 205 Note that if an LSP has not been acknowledged and is sent again, it 206 does not count twice. The reason is that this LSP is assumed to be 207 lost and hence not in a buffer at the receiver. 209 3.2. minimumInterfaceLSPTransmissionInterval sub-TLV 211 The sub-TLV minimumInterfaceLSPTransmissionInterval advertises the 212 minimum interval, in micro-seconds, between LSPs arrivals which can 213 be processed/received on this interface, after the maximum number of 214 un-acknowledged LSPs has been sent. 216 Type: 2. 218 Length: 4 octets. 220 Value: minimum interval, in micro-seconds, between two consecutive 221 LSPs sent after the receive window has been used. 223 4. Flow control 225 Flow control is about creating a control loop between a single 226 transmitter and single receiver. This document proposes to use a 227 mechanism similar to the TCP receive window to allow the receiver to 228 govern the amount of data sent by the sender. This receive window 229 indicates an allowed number of LSPs that the sender may transmit 230 before receiving acknowledgment of those LSPs. This receive window, 231 in units of LSPs, is advertised in the sub-TLV 232 InterfaceLSPReceiveWindow. 234 4.1. Operation on a point to point interface 236 By sending the InterfaceLSPReceiveWindow sub-TLV with a value N, the 237 node advertises to its IS-IS neighbor, its ability to receive a 238 maximum of N un-acknowledged LSPs from this neighbor, with no 239 separation interval. This is akin to a reception window or sliding 240 window in flow control. This value typically reflects the socket 241 buffer size. Special care must be taken to let space for Hello and 242 SNP PDUs if they share the same socket. In this case, this document 243 suggests to advertise a Receive Window corresponding to half the size 244 of the socket buffer. 246 By sending the minimumInterfaceLSPTransmissionInterval sub-TLV with a 247 value T, the node advertises to its IS-IS neighbor, its ability to 248 receive, after the receive window is full, LSPs separated by at least 249 T micro-seconds from this neighbor. 251 The IS transmitter MUST NOT exceed these parameters. After having 252 sent N un-acknowledged LSPs, it MUST send the following LSPs with an 253 interval of at least T micro-seconds between each LSP. 255 Note however that if either the LSP transmitter or receiver does not 256 adhere to these parameters, for example because of transient 257 conditions, this causes no fatal condition to the operation of IS-IS. 258 The worst case, the loss of LSP on the IS receiver, is already 259 accounted for in [ISO10589] . As per [ISO10589] , after a few 260 seconds, respectively 2 and 10 by default in [ISO10589] , neighbors 261 will exchange PSNP (for point to point interface) or CSNP (for 262 broadcast interface) and recover from the lost LSPs. This worst case 263 (overrunning the receiver) should however be avoided as those 264 additional seconds are impacting the network and the traffic as the 265 LSDB is not fully synchronized. Hence it is better to err on the 266 conservative side and to under-run the receiver rather than over-run 267 it. 269 For a given IS-IS adjacency, the Flooding Parameters TLV does not 270 need to be advertised in each IIH. The IS transmitter uses the 271 latest received value for each parameter (sub-TLV) until a new value 272 is advertised by the IS receiver. Note however that IIH are not 273 reliably exchanged, hence may never be received. For a parameter 274 which has never been advertised, the IS transmitter use its local 275 default value. That value SHOULD be configurable on a per node basis 276 and MAY be configurable on a per interface basis. 278 4.2. Faster acknowledgments of LSPs 280 As per [ISO10589] , on point to point interfaces, the LSP receiver 281 dynamically acknowledges the received LSPs by sending PSNP messages. 283 By acknowledging the LSPs before the InterfaceLSPReceiveWindow is 284 exhausted, the receiver can achieve dynamic flow control and increase 285 the flooding throughput without risking overloading any IS-IS router. 286 If the InterfaceLSPReceiveWindow is large enough, the downstream 287 flooding node can acknowledge a set of multiple LSPs up to the 288 maximum size of a PSNP (90 LSPs) which allows dynamic flow control 289 with limited or even no increase in the number of sent PSNPs. 291 In order to avoid reducing the throughput, the receiver should avoid 292 letting the receive window exhaust. Therefore, the receiver SHOULD 293 acknowledge the LSP more quickly than the default specified in 294 [ISO10589] . This is beneficial both to the LSP sender which receives 295 faster feedback and to the LSP receiver which has more time to 296 acknowledge many LSPs before the sender times out and resend the LSP. 298 Receiver SHOULD reduce partialSNPInterval. The choice of this lower 299 value is a local choice. It may depend on the (available) processing 300 power of the node, the number of adjacencies, the requirement to 301 synchronize the LSDB more quickly. 200 ms seems a reasonable value. 303 In addition to the timer based partialSNPInterval, the receiver 304 SHOULD keep track of the number of unacknowledged LSPs per circuit 305 and level. When this number exceeds a preset threshold LSP per PSNP 306 (LPP), the receiver SHOULD immediately send a PSNP without waiting 307 for the PSNP timer to expire. In case of a burst of LSPs, this 308 allows for more frequent PSNPs, hence a faster feedback loop to the 309 sender. In the absence of burst, the usual time-based PSNP approach 310 comes into effect. This number SHOULD be lower than the advertised 311 receive window InterfaceLSPReceiveWindow, e.g., 312 InterfaceLSPReceiveWindow/2. This number SHOULD also be lower or 313 equal to 90 as this is the maximum number of LSPs that can be 314 acknowledged in a PSNP, hence waiting longer would not reduce the 315 number of PSNPs sent but would delay the acknowledgements. Best 316 performance is achieved when this number is an integer fraction of 317 InterfaceLSPReceiveWindow. Based on experimental evidence, 15 318 unacknowledged LSPs is a right value assuming that 319 InterfaceLSPReceiveWindow is at least twice bigger (>30). 321 By deploying both the time-based and the threshold-based PSNP 322 approaches, the receiver can be adaptive to both LSP bursts and 323 infrequent LSP updates. 325 4.3. Operation on a LAN interface 327 On a LAN interface, an IS receiver will generally receive LSPs from 328 multiple IS transmitters. Also the LSPs sent by a given IS 329 transmitter is received by all of the IS receivers on that LAN. In 330 this section, we clarify how the flooding parameters should be 331 interpreted in the context of a LAN. 333 An IS receiver on a LAN will communicate its desired flooding 334 parameters using a single Flooding Parameters TLV, copies of which 335 will be received by all N transmitters. The flooding parameters sent 336 by the IS receiver MUST be understood as instructions from the 337 receiver to each transmitter about the desired maximum transmit 338 characteristics of each transmitter. The receiver is aware that 339 there are N transmitters that can send LSPs to the receiver LAN 340 interface. The receiver might want to take that into account by 341 advertising a higher value of InterfaceLSPTransmissionInterval on 342 this LAN interface than what it would advertise on a point to point 343 interface. When the transmitters receive the 344 InterfaceLSPTransmissionInterval value advertised by the DIS 345 receiver, the transmitters should rate limit LSPs according to the 346 advertised flooding parameters. They should not apply any further 347 interpretation to the flooding parameters advertised by the receiver. 349 A given IS transmitter will receive flooding parameter advertisements 350 from N different Flooding Parameters TLVs, which may carry different 351 flooding parameter values. A given transmitter SHOULD use the most 352 convervative value on a per Flooding parameter basis. For example, 353 if the transmitter receivers InterfaceLSPReceiveWindow from N IS-Is 354 nodes on the LAN, it should use the smallest value. 356 In order for the InterfaceLSPReceiveWindow to be a useful parameter, 357 an IS transmitter needs to be able to keep track of the number of un- 358 acknowledged LSPs it has sent to a given IS receiver. On a LAN there 359 is no explicit acknowledgment of the receipt of LSPs between a given 360 IS transmitter and a given IS receiver. However, an IS transmitter 361 on a LAN can infer whether any IS receiver on the LAN has requested 362 retransmission of LSPs from the DIS, by monitoring PSNPs generated on 363 the LAN. If no PSNPs have been generated on the LAN for a suitable 364 period of time, then an IS transmitter can safely set the number of 365 un-acknowledged LSPs to zero. Since this suitable period of time is 366 much higher than the fast acknowledgment of LSP defined in 367 Section 4.2 , the substainable sending rate of LSP will be much 368 slower on a LAN interface compared to a point to point interface. 369 However, InterfaceLSPReceiveWindow is still very useful for the first 370 LSPs sent and hence usefull for the faster flooding in case of a 371 single node failure which requires to flood a relatively small number 372 of LSPs. 374 A compliant implementation may choose to not support this operation 375 on a LAN interface. 377 5. Congestion control 379 Whereas flow control prevents the sender from overwhelming the 380 receiver, congestion control prevents senders from overwhelming the 381 network. For an IS-IS adjacency, the network between two IS-IS 382 neighbors is relatively limited in scope and includes a single link 383 which is typically over-sized compared to the capability of the IS-IS 384 speakers. It also includes components inside both routers such as a 385 fabric switch, line cards CPU and forwarding plane buffers which may 386 experience congestion. This document proposes one optional 387 congestion control algorithm but implementations may choose a 388 different one or none. 390 The congestion control algorithm defined in this document is largely 391 inspired by the TCP congestion control algorithm RFC 5681 [RFC5681]. 392 A congestion control algorithm is comprised of three elements : a 393 slow start phase, a congestion avoidance phase, and a transition 394 between the two. 396 The proposed algorithm uses a variable Congestion window 'cwin'. It 397 plays the same role as Receive Window described before. The main 398 difference is that CWin is dynamically changed according to the 399 feedback obtained by the PSNPs. 401 5.1. Slow start 403 The goal of the slow start phase is to grow fast and try to estimate 404 the effective link capacity. 406 The algorithm is circuit scoped. At the beginning of the slow start, 407 the sender starts with: 409 o a congestion window (cwin) set to one. cwin := 1; 411 o a number of acked LSPs. acked_lsps := 0; 413 o a max seen bandwidth. max_bw := 0; 414 o a current rtt estimate. cur_rtt := NA; 416 Upon LSP sending, a sender records for said LSP the current time in 417 time_sent and acked_lsps in acked_lsps_sent. This data is tied to 418 each LSP. 420 Upon PSNP reception, a sender does the following: 422 cwin := min(cwin + nb_of_lsp_entries, rwin) 423 acked_lsps += nb_of_lsp_entries 424 max_diff := 0 425 max_bw := 0 426 for every LSP entry: 427 time_to_ack := time_now - time_sent 428 nb_acked := acked_lsps - acked_lsps_sent 429 bw_est := nb_acked/time_to_ack 430 max_bw := max(max_bw, bw_est) 431 max_diff := max(max_diff, time_to_ack) 433 if cur_rtt == NA then cur_rtt = max_diff 434 else cur_rtt := 7/8 * cur_rtt + 1/8 * max_diff 436 Figure 1 438 Starting with the first PSNP, max_bw is checked every cur_rtt. Once 439 it has stalled for 3 consecutive times, the congestion control 440 algorithm transitions from slow start to congestion avoidance. There 441 is bandwidth stalling when the bandwidth has not increased by at 442 least 25% compared the last RTT. Note that this is similar to 443 Google's BBR ([I-D.cardwell-iccrg-bbr-congestion-control] ) slow 444 start phase. 446 5.2. Congestion avoidance 448 The goal of the congestion avoidance phase is to try to stay close to 449 the effective capacity of the link. For this, the algorithm 450 estimates the maximum time taken by the receiver to acknowledge a 451 LSP. If an LSP arrives slower than this delay, congestion is 452 inferred and cwin is decreased. 454 Upon PSNP reception, a sender does the following: 456 cwin = min(cwin + N/congestion window, rwin) 457 rtt_est := 0 458 for every LSP entry: 459 time_to_ack = time_now - time_sent 460 rtt_est = max(rtt_est, time_to_ack) 462 if rtt_var == NA then rtt_var = rtt_est / 2 463 else rtt_var = 3/4 * rtt_var + 1/4 * abs(cur_rtt - rtt_est) 465 cur_rtt = 7/8 * cur_rtt + 1/8 * rtt_est 467 Figure 2 469 Every LSP is checked to be acked within cur_rtt + rtt_var. If an LSP 470 arrives late, cwin is divided by two. This behaviour is similar to 471 TCP retransmission timer defined in RFC 6298 [RFC6298] 473 Note: there is no need for a timer per LSP. A timer per RTT is 474 enough. During an RTT, sent LSPs are recorded in a list list_1. 475 Once the RTT is over, list_1 is kept and another list list_2 is used 476 to store the next LSPs. LSPs are removed from the lists when acked. 477 At the end of the second RTT, every LSP in list_1 should have been 478 acked, so list_1 is checked to be empty. List_1 can then be reused 479 for the next RTT. 481 If there is no transmitted LSP for a fixed period of time, e.g. 2 482 seconds, the sender switches back to the slow start phase. 484 5.3. Remarks 486 This algorithm's performance is dependent on the LPP value. Indeed, 487 the smaller LPP is, the more information is available for the 488 congestion control algorithm to perform well. However, it also 489 increases the resources spent on sending PSNPs, so a tradeoff must be 490 made. This document recommends to use an LPP of 15 or less. 492 Note that this congestion control algorithm benefits from the 493 extensions proposed in this document. The advertisement of a receive 494 window from the receiver ( Section 4 ) avoids the use of an arbitrary 495 maximum value by the sender. The faster acknowledgment of LSP ( 496 Section 4.2 ) allows for a faster control loop and hence a faster 497 increase of the congestion window in the absence of congestion. 499 6. Interaction with other LSP rate limiting mechanisms 501 [ISO10589] describes a mechanism that limits the rate at which LSPs 502 from the same source system are sent out on interfaces. (See the 503 description of the parameter 504 minimumBroadcastLSPTranLSPTransmissionInterval in section 7.3.15.6 of 505 [ISO10589] ). In practice, however, router vendors have implemented 506 mechanisms that limit the rate of LSPs sent on a given interface. 507 This is often configurable on a per-interface basis using 'lsp- 508 interval' or 'lsp-pacing-interval' CLI configuration). The mechanism 509 described in the current document extends the practice of limiting 510 the rate of LSPs sent on a given interface, by using parameters 511 advertised by the LSP receiver. When the mechanism described in the 512 current document is used, the mechanism described in section 7.3.15.6 513 of [ISO10589] is not used. 515 7. Determining values to be advertised in the Flooding Parameters TLV 517 The values that a receiving IS advertises do not need to be close to 518 perfection. It is OK to be too low and hence not to use the full 519 bandwidth or CPU resources. It is OK to be too high during some 520 situation and hence have the receiver drop some LSPs as the IS-IS 521 protocol has mechanisms to recover. What is not OK is to flood 522 multiple order of magnitudes slower than both nodes can achieve, or 523 to consistently overload the receiver. 525 The values may not need to be dynamic as a form of dynamic is 526 provided by the dynamic acknowledgment of LSPs in SNP messages. 527 Acknowledgments provides a feedback loop on how fast/slower the LSPs 528 are processed by the receiver. They also signal that the LSPs have 529 been processed by the receiver hence removed from receive window, 530 explicitly signaling to the sender that more LSPs may be sent. By 531 advertising relatively static parameters, we expect to produce 532 overall flooding behavior similar to what might be achieved by 533 manually configuring per-interface LSP rate limiting on all 534 interfaces in the network. The advertised values may be based, for 535 example, on an off line tests of the overall LSP processing speed for 536 a particular set of hardware and the number of interfaces configured 537 for IS-IS. With such a formula, the values advertised in the 538 Flooding Parameters TLV would only change when additional IS-IS 539 interfaces are configured. 541 The values may be updated dynamically, to reflect the relative change 542 of load of the receiver, by improving the values when the receiver 543 load is getting lower and degrading the values when the receiver load 544 is getting higher. For example, if LSPs are regularly dropped, or 545 the queue regularly comes close to being filled, then values may be 546 too high. On the other hand, if the queue is barely used (by IS-IS), 547 then values may be too low. 549 The values may also be absolute value reflecting relevant (averaged) 550 hardware resources that are been monitored, typically the amount of 551 buffer space used by incoming LSPs. In this case, care must be taken 552 when choosing the parameters influencing the values, in order to 553 avoid undesirable or instable feedback loops. It would be 554 undesirable to use a formula that depends, for example, on an active 555 measurement of the instantaneous CPU load to modify the values 556 advertised in the Flooding Parameters TLV. This could introduce 557 feedback into the IGP flooding process that could produce unexpected 558 behavior. 560 8. Operation considerations 562 As discussed in Section 4.3 , the solution is more effective on point 563 to point adjacencies. Hence a broadcast interface (e.g. Ethernet) 564 only shared by two IS-IS neighbhors should be configured as point to 565 point in order to have a more effective flooding. 567 9. IANA Considerations 569 IANA is requested to allocate one TLV from the IS-IS TLV codepoint 570 registry. 572 Type Description IIH LSP SNP Purge 573 ---- --------------------------- --- --- --- --- 574 TBD1 Flooding Parameters TLV y n n n 576 Figure 3 578 This document creates the following sub-TLV Registry: 580 Name: Sub-TLVs for TLV TBD1 (Flooding Parameters TLV). 582 Registration Procedure: Expert Review [RFC8126] . 584 +-------+-----------------------------------------+ 585 | Type | Description | 586 +-------+-----------------------------------------+ 587 | 0 | Reserved | 588 | 1 | InterfaceLSPReceiveWindow | 589 | 2 | minimumInterfaceLSPTransmissionInterval | 590 | 3-255 | Unassigned | 591 +-------+-----------------------------------------+ 593 Table 1: Initial allocations 595 10. Security Considerations 597 Any new security issues raised by the procedures in this document 598 depend upon the ability of an attacker to inject a false but 599 apparently valid SNP or IIH, the ease/difficulty of which has not 600 been altered. 602 As with others TLV advertisements, the use of a cryptographic 603 authentication as defined in [RFC5304] or [RFC5310] allows the 604 authentication of the peer and the integrity of the message. As this 605 document defines a TLV for SNP or IIH message, the relevant 606 cryptographic authentication is for SNP and IIH message. 608 In the absence of cryptographic authentication, as IS-IS does not run 609 over IP but directly over the link layer, it's considered difficult 610 to inject false SNP/IHH without having access to the link layer. 612 If a false SNP/IIH is sent with a Flooding Parameters TLV set to 613 conservative values, the attacker can reduce the flooding speed 614 between the two adjacent neighbors which can result in LSDB 615 inconsistencies and transient forwarding loops. However, it is not 616 significantly different than filtering or altering LSPDUs which would 617 also be possible with access to the link layer. In addition, if the 618 downstream flooding neighbor has multiple IGP neighbors, which is 619 typically the case for reliability or topological reasons, it would 620 receive LSPs at a regular speed from its other neighbors and hence 621 would maintain LSDB consistency. 623 If a false SNP/IIH is sent with a Flooding Parameters TLV set to 624 aggressive values, the attacker can increase the flooding speed which 625 can either overload a node or more likely generate loss of LSPs. 626 However, it is not significantly different than sending many LSPs 627 which would also be possible with access to the link layer, even with 628 cryptographic authentication enabled. In addition, IS-IS has 629 procedures to detect the loss of LSPs and recover. 631 This TLV advertisement is not flooded across the network but only 632 sent between adjacent IS-IS neighbors. This would limit the 633 consequences in case of forged messages, and also limits the 634 dissemination of such information. 636 11. Acknowledgments 638 The authors would like to thank Henk Smit, Sarah Chen, Xuesong Geng, 639 Pierre Francois and Hannes Gredler for their reviews, comments and 640 suggestions. 642 The authors would like to thank David Jacquet, Sarah Chen, and 643 Qiangzhou Gao for the tests performed on commercial implementations 644 and their identification of some limiting factors. 646 12. References 648 12.1. Normative References 650 [ISO10589] 651 International Organization for Standardization, 652 "Intermediate system to Intermediate system intra-domain 653 routeing information exchange protocol for use in 654 conjunction with the protocol for providing the 655 connectionless-mode Network Service (ISO 8473)", ISO/ 656 IEC 10589:2002, Second Edition, Nov 2002. 658 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 659 Requirement Levels", BCP 14, RFC 2119, 660 DOI 10.17487/RFC2119, March 1997, 661 . 663 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 664 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 665 2008, . 667 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 668 and M. Fanto, "IS-IS Generic Cryptographic 669 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 670 2009, . 672 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 673 "Computing TCP's Retransmission Timer", RFC 6298, 674 DOI 10.17487/RFC6298, June 2011, 675 . 677 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 678 Writing an IANA Considerations Section in RFCs", BCP 26, 679 RFC 8126, DOI 10.17487/RFC8126, June 2017, 680 . 682 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 683 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 684 May 2017, . 686 12.2. Informative References 688 [I-D.cardwell-iccrg-bbr-congestion-control] 689 Cardwell, N., Cheng, Y., Yeganeh, S. H., and V. Jacobson, 690 "BBR Congestion Control", draft-cardwell-iccrg-bbr- 691 congestion-control-00 (work in progress), July 2017. 693 [I-D.ietf-lsr-dynamic-flooding] 694 Li, T., Psenak, P., Ginsberg, L., Chen, H., Przygienda, 695 T., Cooper, D., Jalil, L., Dontula, S., and G. S. Mishra, 696 "Dynamic Flooding on Dense Graphs", draft-ietf-lsr- 697 dynamic-flooding-08 (work in progress), December 2020. 699 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 700 RFC 793, DOI 10.17487/RFC0793, September 1981, 701 . 703 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 704 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 705 . 707 Appendix A. Changes / Author Notes 709 [RFC Editor: Please remove this section before publication] 711 00: Initial version. 713 01: Two notes added in section 3 "Operation". 715 02: Refresh, no technical change. 717 03: 719 o Flooding Parameters TLV: name changed, advertised in both Hello 720 and SNP rather than just Hello, contains sub-TLVs, parameters 721 encoded in 4 octets. 723 o Terminology: upstream/downstream terms removed, in favor of terms 724 from ISO specification (transmitter, receiver); burst-size rename 725 to receive-window. 727 o Significant editorials changes. 729 o New section on the faster acknowledgment of LSPs. 731 o New section on the faster retransmission of lost LSPs. 733 04: 735 o Adding general introduction on flow control, congestion control, 736 loss detection and recovery. 738 o Reorganizing sections as per the high level functions: flow 739 control, congestion control, loss detection and recovery. 741 o Adding a section on congestion control. 743 05: 745 o Some editorials changes. 747 o Updating section "Faster acknowledgments of LSPs" following the 748 IS-IS flooding performance tests presented during IETF 108. 750 o Updated IANA section (new registry). 752 06: Refresh, no technical change. 754 07: 756 o Precision that if a LSP is lost and resent, it does not count 757 twice in the InterfaceLSPReceiveWindow. 759 o Title changed. 761 o Removed fast retransmissions of LSPs. 763 o Changed congestion control algorithm. 765 o Removed support of TLV in SNP. 767 Authors' Addresses 769 Bruno Decraene 770 Orange 772 Email: bruno.decraene@orange.com 774 Chris Bowers 775 Juniper Networks, Inc. 776 1194 N. Mathilda Avenue 777 Sunnyvale, CA 94089 778 USA 780 Email: cbowers@juniper.net 781 Jayesh J 782 Juniper Networks, Inc. 783 1194 N. Mathilda Avenue 784 Sunnyvale, CA 94089 785 USA 787 Email: jayeshj@juniper.net 789 Tony Li 790 Arista Networks 791 5453 Great America Parkway 792 Santa Clara, California 95054 793 USA 795 Email: tony.li@tony.li 797 Gunter Van de Velde 798 Nokia 799 Copernicuslaan 50 800 Antwerp 2018 801 Belgium 803 Email: gunter.van_de_velde@nokia.com 805 Guillaume Solignac 806 Orange 808 Email: guillaume.solignac@orange.com