idnits 2.17.1 draft-decraene-lsr-isis-flooding-speed-05.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 (October 29, 2020) is 1269 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 (-18) exists of draft-ietf-lsr-dynamic-flooding-07 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 0 errors (**), 0 flaws (~~), 3 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: May 2, 2021 Jayesh. J 6 Juniper Networks, Inc. 7 T. Li 8 Arista Networks 9 G. Van de Velde 10 Nokia 11 October 29, 2020 13 IS-IS Flooding Parameters advertisement 14 draft-decraene-lsr-isis-flooding-speed-05 16 Abstract 18 This document proposes a mechanism to adjust IS-IS flooding speed 19 between two adjacent routers by adjusting the sender flooding speed 20 to the capability of the receiver. This helps improving the flooding 21 throughput, reducing LSPs losses and retransmissions due to receiver 22 overload, and avoiding manual tuning of flooding parameters by the 23 network operator. This document defines a new TLV for SNP and/or 24 Hello messages. This TLV may carry a set of parameters indicating 25 the performance capacity to receive LSPs. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on May 2, 2021. 44 Copyright Notice 46 Copyright (c) 2020 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 63 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Flooding Parameters TLV . . . . . . . . . . . . . . . . . . . 4 65 3.1. InterfaceLSPReceiveWindow sub-TLV . . . . . . . . . . . . 5 66 3.2. minimumInterfaceLSPTransmissionInterval sub-TLV . . . . . 5 67 3.3. minimumLSPTransmissionInterval sub-TLV . . . . . . . . . 5 68 4. Flow control . . . . . . . . . . . . . . . . . . . . . . . . 5 69 4.1. Operation on a point to point interface . . . . . . . . . 6 70 4.2. Faster acknowledgments of LSPs . . . . . . . . . . . . . 6 71 4.3. Operation on a LAN interface . . . . . . . . . . . . . . 7 72 5. Congestion control . . . . . . . . . . . . . . . . . . . . . 8 73 6. Faster loss detection and recovery . . . . . . . . . . . . . 9 74 7. Interaction with other LSP rate limiting mechanisms . . . . . 10 75 8. Determining values to be advertised in the Flooding 76 Parameters TLV . . . . . . . . . . . . . . . . . . . . . . . 10 77 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 78 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 79 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 80 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 12.1. Normative References . . . . . . . . . . . . . . . . . . 13 82 12.2. Informative References . . . . . . . . . . . . . . . . . 14 83 Appendix A. Changes / Author Notes . . . . . . . . . . . . . . . 14 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 86 1. Introduction 88 IGP flooding is paramount for Link State IGP as routing computations 89 assume that the Link State DataBases (LSDBs) are always in sync 90 across all nodes in the flooding domain. 92 Slow flooding directly translates to delayed network reaction to 93 failure and LSDB inconsistencies across nodes. The former increases 94 packet loss. The latter translates to routing inconsistencies and 95 possibly micro-loops leading to packet loss, link overload, and 96 jitter for all classes of service. Note that across the network, 97 multiple links may be affected by these forwarding issues, even in 98 the case of a single link failure. 100 In addition, one single event in the network can require the flooding 101 of multiple LSPs. The typical case is a node failure which requires 102 the flooding of at least one LSP per neighbor of the failed node. 103 Hence, if a node has N IGP neighbors, the failure of this node 104 requires the advertisement and flooding of at least N LSPs. The 105 network won't be able to converge to the new topology until all N 106 LSPs are received by all nodes. Hence there is a need to be able to 107 quickly exchange N LSPs. This document addresses this requirement by 108 allowing the fast flooding of a number of consecutive LSPs. 110 IGP flooding is hard. One would want fast flooding when the network 111 is stable and slow enough flooding to not overload the neighbor(s) 112 when the network is less stable. Since flooding is performed hop by 113 hop, not overloading the adjacent receiver is sufficient. 115 Improving the communication speed and efficiency between IS-IS 116 neighbors improves IS-IS scaling. These extensions do not compete 117 with proposed extensions to reduce LSP flooding traffic by reducing 118 the flooding topology such as [I-D.ietf-lsr-dynamic-flooding]. On 119 the contrary, this extension complements those proposals. Indeed 120 reducing the flooding topology does not reduce the size of the LSDB 121 or the total number of LSPs to exchange between two nodes. So 122 increasing the overall flooding speed can be beneficial for nodes 123 implementing dynamic flooding. The reverse is also true: as dynamic 124 flooding reduces the number of neighbors with flooding enabled, this 125 allows nodes implementing the flooding parameter extensions to focus 126 their flooding resources on those neighbors by sending better 127 parameters to the selected flooding nodes and worse parameters to 128 non-selected flooding nodes. 130 1.1. Requirements Language 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 134 "OPTIONAL" in this document are to be interpreted as described in BCP 135 14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they 136 appear in all capitals, as shown here. 138 2. Overview 140 Ensuring the goodput between two entities is a layer 4 responsibility 141 as per the OSI model and a typical example is the TCP protocol 142 defined in RFC 793 [RFC0793]. It typically relies on the following 143 sub-functions: flow control, congestion control and reliability. 145 Flow control is about creating a control loop between a single 146 transmitter and single receiver. TCP provides a mean for the 147 receiver to govern the amount of data sent by the sender. This is 148 achieved by advertising a "receive window", in units of octets, with 149 every ACK. This document proposes to use the same mechanism by 150 advertising a receive window, in units of LSP packets, in either IS- 151 IS xSNP (ack) or IS-IS Hello. The window indicates an allowed number 152 of LSPs that the sender may transmit before receiving acknowledgment 153 of those LSPs. There is an assumption that this is related to the 154 currently available data buffer space available for this adjacency. 155 Indicating a large window encourages transmissions. 157 Congestion control is about creating multiple interacting control 158 loops between multiple transmitters and multiple receivers. Whereas 159 flow control prevents the sender from overwhelming the receiver, 160 congestion control prevents senders from overwhelming the network. 161 For an IS-IS adjacency, the network between two IS-IS neighbors is 162 relatively limited in scope and consist in a link which is typically 163 over-sized compared to the capability of the IS-IS speakers, but also 164 includes components inside both routers such as a fabric switch, line 165 card CPU and forwarding plane buffers which may experience 166 congestion. For congestion avoidance in steady state TCP uses the 167 AIMD (Additive Increase Multiplicative Decrease) algorithm to react 168 to packet loss. This document proposes to use the same principle. 170 Reliability relies on loss detection and recovery. IS-IS already has 171 mechanisms to ensure the reliable transmission of LSPs. However the 172 reaction time is hard coded in the specification and may be too long 173 in some situation. This document proposes that the delay before 174 assuming a lost packet be advertised by the receiver. This permits a 175 faster receiver to allow for a faster loss detection on the sender 176 side. 178 3. Flooding Parameters TLV 180 This document defines a new TLV called "Flooding Parameters TLV" that 181 may be included in SNP and/or IIH PDUs. It allows the LSP receiver 182 to advertise receiver related parameters and capabilities which 183 allows the LSP 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 Three 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 3.2. minimumInterfaceLSPTransmissionInterval sub-TLV 207 The sub-TLV minimumInterfaceLSPTransmissionInterval advertises the 208 minimum interval, in micro-seconds, between LSPs arrivals which can 209 be processed/received on this interface, after the maximum number of 210 un-acknowledged LSPs has been sent. 212 Type: 2. 214 Length: 4 octets. 216 Value: minimum interval, in micro-seconds, between two consecutive 217 LSPs sent after the receive window has been used. 219 3.3. minimumLSPTransmissionInterval sub-TLV 221 The sub-TLV minimumLSPTransmissionInterval advertises the ISO 222 minimumLSPTransmissionInterval, in micro-seconds, that the LSP 223 transmitter may use. 225 Type: 3. 227 Length: 4 octets. 229 Value: minimum interval, in micro-seconds, before further propagating 230 another Link State PDU from the same source system. 232 4. Flow control 234 Flow control is about creating a control loop between a single 235 transmitter and single receiver. This document proposes to use a 236 mechanism similar to the TCP receive window to allow the receiver to 237 govern the amount of data sent by the sender. This receive window 238 indicates an allowed number of LSPs that the sender may transmit 239 before receiving acknowledgment of those LSPs. This receive window, 240 in units of LSPs, is advertised in the sub-TLV 241 InterfaceLSPReceiveWindow in either IS-IS SNP (ack) or IS-IS Hello. 243 4.1. Operation on a point to point interface 245 By sending the InterfaceLSPReceiveWindow sub-TLV with a value N1, the 246 node advertises to its IS-IS neighbor, its ability to receive, over 247 that interface, a maximum of N1 un-acknowledged LSPs with no 248 separation interval. This is akin to a reception window or sliding 249 window in flow control. 251 By sending the minimumInterfaceLSPTransmissionInterval sub-TLV with a 252 value N2, the node advertises to its IS-IS neighbor, its ability to 253 receive, over that interface, after the receive window is full, LSPs 254 separated by at least N2 micro-seconds. 256 The IS transmitter MUST NOT exceed these parameters. After having 257 send N1 un-acknowledged LSPs, it MUST send the following LSPs with an 258 interval of at least N2 micro-seconds between each LSP. 260 Note however that if either the LSP transmitter or receiver does not 261 adhere to these parameters, for example because of transient 262 conditions, this causes no fatal condition to the operation of IS-IS. 263 The worst case, the loss of LSP on the IS receiver, is already 264 accounted for in [ISO10589]. As per [ISO10589], after a few seconds, 265 respectively 2 and 10 by default in [ISO10589], neighbors will 266 exchange PSNP (for point to point interface) or CSNP (for broadcast 267 interface) and recover from the lost LSPs. This worst case, 268 overrunning the receiver, should however be avoided as those 269 additional seconds are impacting the network and the traffic as the 270 LSDB in not fully synchronized. Hence it is better to err on the 271 conservative side and to underun the receiver rather then overrun it. 273 For a given IS-IS adjacency, the Flooding Parameters TLV does not 274 need to be advertised in each SNP and IIS. The IS transmitter uses 275 the latest value received of each parameter (sub-TLV) until a new 276 value is advertised by the IS receiver. Note however that CSNP and 277 IIH are not reliability exchanged, hence some PDU may never be 278 received. For a parameter which has never been advertised, the IS 279 transmitter use its local default value. That value SHOULD be 280 configurable on a per node basis and MAY be configurable on a per 281 interface basis. 283 4.2. Faster acknowledgments of LSPs 285 As per [ISO10589], on point to point interfaces, the LSP receiver 286 dynamically acknowledges the received LSPs by sending PSNP messages. 288 By acknowledging the LSPs before the InterfaceLSPReceiveWindow is 289 exhausted, the receiver can achieve dynamic flow control and increase 290 the flooding throughput without risking to overload any IS-IS router. 291 If the InterfaceLSPReceiveWindow is large enough, the downstream 292 flooding node can acknowledge a set of multiple LSPs up to the 293 maximum size of a PSNP (90 LSPs) which allows dynamic flow control 294 with limited or even no increase in the number of sent PSNPs. 296 In order to avoid reducing the throughput, the receiver should avoid 297 letting the receive window exhaust. Therefore, the receiver SHOULD 298 acknowledge the LSP more quickly than the default specified in 299 [ISO10589]. This is beneficial both to the LSP sender which receives 300 faster feedback and to the LSP receiver which have more time to 301 acknowledge many LSPs before the sender times out and resend the LSP. 302 The way LSPs are acknowledged faster is a local decision on the 303 receiving IS. 305 Receiver MAY reduce partialSNPInterval. Possibly reduce it even 306 further when the IS-IS adjacency initially transitions to the UP 307 state, or when a large number of LSPs need to be received quickly, or 308 until the LSDB has been synchronized. The choice of this lower value 309 is a local choice. It may depends on the (available) processing 310 power of the node, the number of adjacencies been brought up at the 311 same time, the requirement to synchronize the LSDB more quickly. 313 In addition to the timer based partialSNPInterval, the receiver 314 SHOULD keep track of the number of unacknowledged LSPs per circuit 315 and level. When this number exceeds a preset threshold, the receiver 316 SHOULD immediately send a PSNP without waiting for the PSNP timer to 317 expire. In case of a burst of LSPs, this allows for more frequent 318 PSNPs, hence a faster feedback loop to the sender. While in the 319 absence of a burst of LSP, the usual time-based PSNP approach comes 320 into effect. By deploying both the time-based and the threshold- 321 based PSNP approaches, the receiver can be adaptive to both LSP 322 bursts and infrequent LSP updates. This number SHOULD be lower or 323 equal to 90 as this is the maximum number of LSPs that can be 324 acknowledged in a PSNP, hence waiting longer would not reduce the 325 number of PSNPs sent but would delay the acknoledgements. This 326 number SHOULD also be lower or equal to the advertised receive window 327 InterfaceLSPReceiveWindow, e.g., InterfaceLSPReceiveWindow/2. Based 328 on experimental evidence, 15 unacknowledged LSPs is a right value. 330 4.3. Operation on a LAN interface 332 On a LAN interface an IS receiver will generally receive LSPs from 333 many IS transmitters. And the LSPs sent by a given IS transmitter 334 will be received by all of the IS receivers on that LAN. In this 335 section, we clarify how the flooding parameters should be interpreted 336 in the context of a LAN. 338 An IS receiver on a LAN will communicate its desired flooding 339 parameters using a single Flooding Parameters TLV, copies of which 340 will be received by all N transmitters. The flooding parameters sent 341 by the IS receiver MUST be understood as instructions from the 342 receiver to each transmitter about the desired maximum transmit 343 characteristics of each transmitter. The receiver is aware that 344 there are N transmitters that can send LSPs to the receiver LAN 345 interface. The receiver might want to take that into account by 346 advertising a higher value of InterfaceLSPTransmissionInterval on 347 this LAN interface than what it would advertise on a point to point 348 interface. When the transmitters receive the 349 InterfaceLSPTransmissionInterval value advertised by the DIS 350 receiver, the transmitters should rate limit LSPs according to the 351 advertised flooding parameters. They should not apply any further 352 interpretation to the flooding parameters advertised by the receiver. 354 A given IS transmitter will receive flooding parameter advertisements 355 from N different Flooding Parameters TLVs, which may carry different 356 flooding parameter values. A given transmitter SHOULD adjust the 357 flooding behavior on this LAN interface such that none of the 358 receivers receives more un-acknowledged LSPs or LSPs at a higher rate 359 than indicated by their individual flooding parameter advertisements. 361 In order for the InterfaceLSPReceiveWindow to be a useful parameter, 362 an IS transmitter needs to be able to keep track of the number of un- 363 acknowledged LSPs it has sent to a given IS receiver. On a LAN there 364 is no explicit acknowledgment of the receipt of LSPs between a given 365 IS transmitter and a given IS receiver. However, an IS transmitter 366 on a LAN can infer whether or not any IS receivers on the LAN have 367 requested retransmission of LSPs from the DIS by monitoring PSNPs 368 generated on the LAN. If no PSNPs have been generated on the LAN for 369 a suitable period of time, then an IS transmitter can safely set the 370 number of un-acknowledged LSPs to zero. 372 5. Congestion control 374 Whereas flow control prevents the sender from overwhelming the 375 receiver, congestion control prevents senders from overwhelming the 376 network. For an IS-IS adjacency, the network between two IS-IS 377 neighbors is relatively limited in scope and include in a single link 378 which is typically over-sized compared to the capability of the IS-IS 379 speakers. But also includes components inside both routers such as a 380 fabric switch, line card CPU and forwarding plane buffers which may 381 experience congestion. For congestion avoidance in steady state, TCP 382 uses the AIMD (Additive Increase Multiplicative Decrease) algorithm 383 to react to packet loss. This document proposes to use the same 384 principle. This document proposes one congestion control algorithm 385 but implementations may choose a different one. 387 The congestion control algorithm uses 389 o a moderate starting rate based on the receive window advertised by 390 the receiver; 392 o an Additive Increase proportional to the number of LSPs correctly 393 received (acknowledged); 395 o an exponential reduction in case of LSP loss. 397 When a new set of LSPs need to be sent, the sender start with a 398 congestion window set to half of the receive window. 400 When the reception of N LSPs is acknowledged, the congestion window 401 is increased by N, without exceeding the received windows. 403 When the loss of LSP is detected, the congestion window is divided by 404 two. 406 Note that this congestion control algorithm benefits from the 407 extensions proposed in this document, namely the advertisement of a 408 receive window from the receiver (Section 4) which avoid the use of 409 an arbitrary value by the sender, the faster acknowledgment of LSP 410 (Section 4.2) which allows for a faster control loop and hence a 411 faster increase of the congestion window in the absence of 412 congestion, and the faster detection of lost LSP (Section 6) which 413 allows for a faster control loop and hence a decrease of the 414 congestion window in case of congestion. 416 6. Faster loss detection and recovery 418 As per [ISO10589], an LSP transmitter resends a un-acknowledged LSP 419 no sooner than minimumLSPTransmissionInterval, which is 5 seconds by 420 default. As the goal is to increase the speed of reliable 421 transmission of LSP, the transmitter should be able to retransmit 422 faster in case of LSP loss. The delay need to be compatible (higher) 423 than the partialSNPInterval or the delay needed by the IS receiver to 424 acknowledge the received LSPs. This document allows the receiver to 425 advertise to the sender a more realistic value for 426 minimumLSPTransmissionInterval, with a goal to advertise a smaller 427 value than the ISO default value and hence allow for a faster 428 recovery of lost LSPs. 430 The reception of the parameter minimumLSPTransmissionInterval means 431 that the IS transmitter MAY set its minimumLSPTransmissionInterval to 432 this value or higher. 434 The interval advertised in minimumLSPTransmissionInterval MUST be 435 higher than the effective partialSNPInterval of the receiver plus the 436 Round Trip Time (RTT) of the interface. The effective 437 partialSNPInterval of the receiver is the maximum amount of time that 438 the receiver is expected to take to acknowledge the LSP. This would 439 be the partialSNPInterval on a receiver following only [ISO10589], or 440 an effective value if the receiver has implemented a faster method to 441 acknowledge LSPs, as discussed in Section 4.2. The receiver should 442 not be telling the transmitter to resend un-acknowledged LSPs before 443 the receiver had time to acknowledge LSPs it has actually received. 445 An LSP receiver MAY update this value depending on certain 446 conditions. For example, it can advertise a higher 447 minimumLSPTransmissionInterval value when a large number of LSPs are 448 been received and hence it is experiencing high load. Or it can 449 advertise a lower value when an LSP storm has passed, especially if 450 there is reason to believe that some LSPs may have been lost. 452 7. Interaction with other LSP rate limiting mechanisms 454 [ISO10589] describes a mechanism that limits the rate at which LSPs 455 from the same source system are sent out on interfaces. (See the 456 description of the parameter 457 minimumBroadcastLSPTranLSPTransmissionInterval in section 7.3.15.6 of 458 [ISO10589] .) In practice, however, router vendors have implemented 459 mechanisms that limit the rate of LSPs sent on a given interface. 460 This is often configurable on a per-interface basis using 'lsp- 461 interval' or 'lsp-pacing-interval' CLI configuration.) The mechanism 462 described in the current document extends the practice of limiting 463 the rate of LSPs sent on a given interface, by using parameters 464 advertised by the LSP receiver. When the mechanism described in the 465 current document is used, the mechanism described in section 7.3.15.6 466 of [ISO10589] is not used. 468 8. Determining values to be advertised in the Flooding Parameters TLV 470 The values that a receiving IS advertises do not need to be close to 471 perfection. It is OK to be too low and hence not to use the full 472 bandwidth or CPU resources. It is OK to be too high during some 473 situation and hence have the receiver drop some LSPs as the IS-IS 474 protocol has mechanisms to recover. What is not OK is to flood 475 multiple order of magnitudes slower than both nodes can achieve, or 476 to consistently overload the receiver. 478 The values may not need to be dynamic as a form of dynamic is 479 provided by the dynamic acknowledgment of LSPs in SNP messages. 480 Acknowledgments provides a feedback loop on how fast/slower the LSPs 481 are processed by the receiver. They also signal that the LSPs have 482 been processed by the receiver hence removed from receive window, 483 explicitly signaling to the sender that more LSPs may be sent. By 484 advertising relatively static parameters, we expect to produce 485 overall flooding behavior similar to what might be achieved by 486 manually configuring per-interface LSP rate limiting on all 487 interfaces in the network. The advertised values may be based, for 488 example, on an off line tests of the overall LSP processing speed for 489 a particular set of hardware and the number of interfaces configured 490 for IS-IS. With such a formula, the values advertised in the 491 Flooding Parameters TLV would only change when additional IS-IS 492 interfaces are configured. 494 The values MAY be updated dynamically, to reflect the relative change 495 of load of the receiver, by improving the values when the receiver 496 load is getting lower and degrading the values when the receiver load 497 is getting higher. For example, if LSPs are regularly dropped, or 498 the queue regularly comes close to being filled, then values may be 499 too high. On the other hand, if the queue is barely used (by IS-IS), 500 then values may be too low. 502 The values MAY may also be absolute value reflecting relevant 503 (averaged) hardware resources that are been monitored, typically the 504 amount of buffer space used by incoming LSPs. In this case, care 505 must be taken when choosing the parameters influencing the values, in 506 order to avoid undesirable or instable feedback loops. It would be 507 undesirable to use a formula that depends, for example, on an active 508 measurement of the instantaneous CPU load to modify the values 509 advertised in the Flooding Parameters TLV. This could introduce 510 feedback into the IGP flooding process that could produce unexpected 511 behavior. 513 9. IANA Considerations 515 IANA is requested to allocate one TLV from the IS-IS TLV codepoint 516 registry. 518 Type Description IIH LSP SNP Purge 519 ---- --------------------------- --- --- --- --- 520 TBD1 Flooding Parameters TLV y n y n 522 Figure 1 524 This document creates the following sub-TLV Registry: 526 Name: Sub-TLVs for TLV TBD1 (Flooding Parameters TLV). 528 Registration Procedure: Expert Review [RFC8126]. 530 +-------+-----------------------------------------+ 531 | Type | Description | 532 +-------+-----------------------------------------+ 533 | 0 | Reserved | 534 | 1 | InterfaceLSPReceiveWindow | 535 | 2 | minimumInterfaceLSPTransmissionInterval | 536 | 3 | minimumLSPTransmissionInterval | 537 | 4-255 | Unassigned | 538 +-------+-----------------------------------------+ 540 Table 1: Initial allocations 542 10. Security Considerations 544 Any new security issues raised by the procedures in this document 545 depend upon the ability of an attacker to inject a false but 546 apparently valid SNP or IIH, the ease/difficulty of which has not 547 been altered. 549 As with others TLV advertisements, the use of a cryptographic 550 authentication as defined in [RFC5304] or [RFC5310] allows the 551 authentication of the peer and the integrity of the message. As this 552 document defines a TLV for SNP or IIH message, the relevant 553 cryptographic authentication is for SNP and IIH message. 555 In the absence of cryptographic authentication, as IS-IS does not run 556 over IP but directly over the link layer, it's considered difficult 557 to inject false SNP/IHH without having access to the link layer. 559 If a false SNP/IIH is sent with a Flooding Parameters TLV set to 560 conservative values, the attacker can reduce the flooding speed 561 between the two adjacent neighbors which can result in LSDB 562 inconsistencies and transient forwarding loops. However, it is not 563 significantly different than filtering or altering LSPDUs which would 564 also be possible with access to the link layer. In addition, if the 565 downstream flooding neighbor has multiple IGP neighbors, which is 566 typically the case for reliability or topological reasons, it would 567 receive LSPs at a regular speed from its other neighbors and hence 568 would maintain LSDB consistency. 570 If a false SNP/IIH is sent with a Flooding Parameters TLV set to 571 aggressive values, the attacker can increase the flooding speed which 572 can either overload a node or more likely generate loss of LSPs. 573 However, it is not significantly different than sending many LSPs 574 which would also be possible with access to the link layer, even with 575 cryptographic authentication enabled. In addition, IS-IS has 576 procedures to detect the loss of LSPs and recover. 578 This TLV advertisement is not flooded across the network but only 579 sent between adjacent IS-IS neighbors. This would limit the 580 consequences in case of forged messages, and also limits the 581 dissemination of such information. 583 11. Acknowledgments 585 The authors would like to thank Henk Smit, Sarah Chen, and Xuesong 586 Geng for their reviews, comments and suggestions. 588 The authors would like to thank David Jacquet, Sarah Chen, and 589 Qiangzhou Gao for the tests performed on commercial implementations 590 and their identification of some limiting factors. 592 12. References 594 12.1. Normative References 596 [ISO10589] 597 International Organization for Standardization, 598 "Intermediate system to Intermediate system intra-domain 599 routeing information exchange protocol for use in 600 conjunction with the protocol for providing the 601 connectionless-mode Network Service (ISO 8473)", ISO/ 602 IEC 10589:2002, Second Edition, Nov 2002. 604 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 605 Requirement Levels", BCP 14, RFC 2119, 606 DOI 10.17487/RFC2119, March 1997, 607 . 609 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 610 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 611 2008, . 613 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 614 and M. Fanto, "IS-IS Generic Cryptographic 615 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 616 2009, . 618 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 619 Writing an IANA Considerations Section in RFCs", BCP 26, 620 RFC 8126, DOI 10.17487/RFC8126, June 2017, 621 . 623 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 624 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 625 May 2017, . 627 12.2. Informative References 629 [I-D.ietf-lsr-dynamic-flooding] 630 Li, T., Psenak, P., Ginsberg, L., Chen, H., Przygienda, 631 T., Cooper, D., Jalil, L., Dontula, S., and G. Mishra, 632 "Dynamic Flooding on Dense Graphs", draft-ietf-lsr- 633 dynamic-flooding-07 (work in progress), June 2020. 635 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 636 RFC 793, DOI 10.17487/RFC0793, September 1981, 637 . 639 Appendix A. Changes / Author Notes 641 [RFC Editor: Please remove this section before publication] 643 00: Initial version. 645 01: Two notes added in section 3 "Operation". 647 02: Refresh, no technical change. 649 03: 651 o Flooding Parameters TLV: name changed, advertised in both Hello 652 and SNP rather than just Hello, contains sub-TLVs, parameters 653 encoded in 4 octets. 655 o Terminology: upstream/downstream terms removed, in favor of terms 656 from ISO specification (transmitter, receiver); burst-size rename 657 to receive-window. 659 o Significant editorials changes. 661 o New section on the faster acknowledgment of LSPs. 663 o New section on the faster retransmission of lost LSPs. 665 04: 667 o Adding general introduction on flow control, congestion control, 668 loss detection and recovery. 670 o Reorganizing sections as per the high level functions: flow 671 control, congestion control, loss detection and recovery. 673 o Adding a section on congestion control. 675 05: 677 o Some editorials changes. 679 o Updating section "Faster acknowledgements of LSPs" following the 680 IS-IS flooding performance tests presented during IETF 108. 682 o Updated IANA section (new registry). 684 Authors' Addresses 686 Bruno Decraene 687 Orange 689 Email: bruno.decraene@orange.com 691 Chris Bowers 692 Juniper Networks, Inc. 693 1194 N. Mathilda Avenue 694 Sunnyvale, CA 94089 695 USA 697 Email: cbowers@juniper.net 699 Jayesh J 700 Juniper Networks, Inc. 701 1194 N. Mathilda Avenue 702 Sunnyvale, CA 94089 703 USA 705 Email: jayeshj@juniper.net 707 Tony Li 708 Arista Networks 709 5453 Great America Parkway 710 Santa Clara, California 95054 711 USA 713 Email: tony.li@tony.li 714 Gunter Van de Velde 715 Nokia 716 Copernicuslaan 50 717 Antwerp 2018 718 Belgium 720 Email: gunter.van_de_velde@nokia.com