idnits 2.17.1 draft-decraene-lsr-isis-flooding-speed-04.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 (June 10, 2020) is 1415 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-06 -- 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: December 12, 2020 Jayesh. J 6 Juniper Networks, Inc. 7 T. Li 8 Arista Networks 9 G. Van de Velde 10 Nokia 11 June 10, 2020 13 IS-IS Flooding Parameters advertisement 14 draft-decraene-lsr-isis-flooding-speed-04 16 Abstract 18 This document proposes a mechanism that can be used to increase the 19 speed at which link state information is exchanged between two 20 routers when multiple LSPs need to be flooded, such as in case of a 21 node failure. It also reduces the likelihood of overloading the 22 router receiving the LSPs, causing LSPs losses and delayed 23 retransmission. This document defines a new TLV to be advertised in 24 SNP and/or Hello messages. This TLV may carry a set of parameters 25 indicating the performance capacity to receive LSPs: the number of 26 LSPs which can the received back to back, the minimum delay between 27 further two consecutive LSPs and the minimum delay before 28 retransmission of an LSP. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on December 12, 2020. 47 Copyright Notice 49 Copyright (c) 2020 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 66 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. Flooding Parameters TLV . . . . . . . . . . . . . . . . . . . 4 68 3.1. InterfaceLSPReceiveWindow sub-TLV . . . . . . . . . . . . 5 69 3.2. minimumInterfaceLSPTransmissionInterval sub-TLV . . . . . 5 70 3.3. minimumLSPTransmissionInterval sub-TLV . . . . . . . . . 5 71 4. Flow control . . . . . . . . . . . . . . . . . . . . . . . . 6 72 4.1. Operation on a point to point interface . . . . . . . . . 6 73 4.2. Faster acknowledgments of LSPs . . . . . . . . . . . . . 7 74 4.3. Operation on a LAN interface . . . . . . . . . . . . . . 7 75 5. Congestion control . . . . . . . . . . . . . . . . . . . . . 8 76 6. Faster loss detection and recovery . . . . . . . . . . . . . 9 77 7. Interaction with other LSP rate limiting mechanisms . . . . . 10 78 8. Determining values to be advertised in the Flooding 79 Parameters TLV . . . . . . . . . . . . . . . . . . . . . . . 10 80 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 81 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 82 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 83 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 12.1. Normative References . . . . . . . . . . . . . . . . . . 12 85 12.2. Informative References . . . . . . . . . . . . . . . . . 13 86 Appendix A. Changes / Author Notes . . . . . . . . . . . . . . . 13 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 89 1. Introduction 91 IGP flooding is paramount for Link State IGP as routing computations 92 assume that the Link State DataBases (LSDBs) are always in sync 93 across all nodes in the flooding domain. 95 Slow flooding directly translates to delayed network reaction to 96 failure and LSDB inconsistencies across nodes. The former increases 97 packet loss. The latter translates to routing inconsistencies and 98 possibly micro-loops leading to packet loss, link overload, and 99 jitter for all classes of service. Note that across the network, 100 multiple links may be affected by these forwarding issues, even in 101 the case of a single link failure. 103 In addition, one single event in the network can require the flooding 104 of multiple LSPs. The typical case is a node failure which requires 105 the flooding of at least one LSP per neighbor of the failed node. 106 Hence, if a node has N IGP neighbors, the failure of this node 107 requires the advertisement and flooding of at least N LSPs. The 108 network won't be able to converge to the new topology until all N 109 LSPs are received by all nodes. Hence there is a need to be able to 110 quickly exchange N LSPs. This document addresses this requirement by 111 allowing the fast flooding of some number of consecutive LSPs. 113 IGP flooding is hard. One would want fast flooding when the network 114 is stable and slow enough flooding to not overload the neighbor(s) 115 when the network is less stable. Since flooding is performed hop by 116 hop, not overloading the adjacent receiver is sufficient. 118 Improving the communication speed and efficiency between IS-IS 119 neighbors improves IS-IS scaling. These extensions do not compete 120 with proposed extensions to reduce LSP flooding traffic by reducing 121 the flooding topology such as [I-D.ietf-lsr-dynamic-flooding]. 122 Instead, the extensions complement those proposals. Indeed reducing 123 the flooding topology does not reduce the size of the LSDB or the 124 total number of LSPs to exchange between two nodes. So increasing 125 the overall flooding speed can be beneficial for nodes implementing 126 dynamic flooding. The reverse is also true: as dynamic flooding 127 reduces the number of neighbors with flooding enabled, this allows 128 nodes implementing the flooding parameter extensions to focus their 129 flooding resources on those neighbors by sending better parameters to 130 the selected flooding nodes and worse parameters to non-selected 131 flooding nodes. 133 1.1. Requirements Language 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 137 "OPTIONAL" in this document are to be interpreted as described in BCP 138 14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they 139 appear in all capitals, as shown here. 141 2. Overview 143 Ensuring the goodput between two entities is a layer 4 responsibility 144 as per the OSI model and a typical example is the TCP protocol 145 defined in RFC 793 [RFC0793]. It typically relies on the following 146 sub-functions: flow control, congestion control and reliability. 148 Flow control is about creating a control loop between a single 149 transmitter and single receiver. TCP provides a mean for the 150 receiver to govern the amount of data sent by the sender. This is 151 achieved by advertising a "receive window", in units of octets, with 152 every ACK. This document proposes to use the same mechanism by 153 advertising a receive window, in units of LSP packets, in either IS- 154 IS xSNP (ack) or IS-IS Hello. The window indicates an allowed number 155 of LSPs that the sender may transmit before receiving acknowledgment 156 of those LSPs. There is an assumption that this is related to the 157 currently available data buffer space available for this adjacency. 158 Indicating a large window encourages transmissions. 160 Congestion control is about creating multiple interacting control 161 loops between multiple transmitters and multiple receivers. Whereas 162 flow control prevents the sender from overwhelming the receiver, 163 congestion control prevents senders from overwhelming the network. 164 For an IS-IS adjacency, the network between two IS-IS neighbors is 165 relatively limited in scope and consist in a link which is typically 166 over-sized compared to the capability of the IS-IS speakers, but also 167 includes components inside both routers such as a fabric switch, line 168 card CPU and forwarding plane buffers which may experience 169 congestion. For congestion avoidance in steady state TCP uses the 170 AIMD (Additive Increase Multiplicative Decrease) algorithm to react 171 to packet loss. This document proposes to use the same principle. 173 Reliability relies on loss detection and recovery. IS-IS already has 174 mechanisms to ensure the reliable transmission of LSPs. However the 175 reaction time is hard coded in the specification and may be too long 176 in some situation. This document proposes that the delay before 177 assuming a lost packet be advertised by the receiver. This permits a 178 faster receiver to allow for a faster loss detection on the sender 179 side. 181 3. Flooding Parameters TLV 183 This document defines a new TLV called "Flooding Parameters TLV" that 184 may be included in SNP and/or IIH PDUs. It allows the LSP receiver 185 to advertise receiver related parameters and allows to LSP sender to 186 better adapt to the receivers. 188 Type: TBD1. 190 Length: variable, the size in octet of the Value field. 192 Value: a list of sub-TLVs. 194 Three sub-TLVs are defined in this document. 196 3.1. InterfaceLSPReceiveWindow sub-TLV 198 The sub-TLV InterfaceLSPReceiveWindow advertises the maximum number 199 of un-acknowledged LSPs that the node can receive/process with no 200 separation interval between LSPs. 202 Type: 1. 204 Length: 4 octets. 206 Value: number of un-acknowledged LSPs which can be sent back to back. 208 3.2. minimumInterfaceLSPTransmissionInterval sub-TLV 210 The sub-TLV minimumInterfaceLSPTransmissionInterval advertises the 211 minimum interval, in micro-seconds, between LSPs arrivals which can 212 be processed/received on this interface, once the maximum number of 213 un-acknowledged LSPs has been sent. 215 Type: 2. 217 Length: 4 octets. 219 Value: minimum interval, in micro-seconds, between two consecutive 220 LSPs sent after the receive window has been used. 222 3.3. minimumLSPTransmissionInterval sub-TLV 224 The sub-TLV minimumLSPTransmissionInterval advertises the ISO 225 minimumLSPTransmissionInterval, in micro-seconds, that the LSP 226 transmitter may use. 228 Type: 3. 230 Length: 4 octets. 232 Value: minimum interval, in micro-seconds, before further propagating 233 another Link State PDU from the same source system. 235 4. Flow control 237 Flow control is about creating a control loop between a single 238 transmitter and single receiver. This document proposes to use a 239 mechanism similar to the TCP receive window to allow the receiver to 240 govern the amount of data sent by the sender. This receive window 241 indicates an allowed number of LSPs that the sender may transmit 242 before receiving acknowledgment of those LSPs. This receive window, 243 in units of LSPs, is advertised in the sub-TLV 244 InterfaceLSPReceiveWindow in either IS-IS SNP (ack) or IS-IS Hello. 246 4.1. Operation on a point to point interface 248 By sending the InterfaceLSPReceiveWindow sub-TLV with a value N1, the 249 node advertises to its IS-IS neighbor, its ability to receive, over 250 that interface, a maximum of N1 un-acknowledged LSPs with no 251 separation interval. This is akin to a reception window or sliding 252 window in flow control. 254 By sending the minimumInterfaceLSPTransmissionInterval sub-TLV with a 255 value N2, the node advertises to its IS-IS neighbor, its ability to 256 receive, over that interface, after the receive window is full, LSPs 257 separated by at least N2 micro-seconds. 259 The IS transmitter MUST NOT exceed these parameters. After having 260 send N1 un-acknowledged LSPs, it MUST send the following LSPs with an 261 interval of at least N2 micro-seconds between each LSP. 263 Note however that if either the LSP transmitter or receiver does not 264 adhere to these parameters, for example because of transient 265 conditions, this causes no fatal condition to the operation of IS-IS. 266 The worst case, the loss of LSP on the IS receiver, is already 267 accounted for in [ISO10589]. As per [ISO10589], after a few seconds, 268 respectively 2 and 10 by default in [ISO10589], neighbors will 269 exchange PSNP (for point to point interface) or CSNP (for broadcast 270 interface) and recover from the lost LSPs. This worst case, 271 overrunning the receiver, should however be avoided as those 272 additional seconds are impacting the network and the traffic as the 273 LSDB in not fully synchronized. Hence it is better to err on the 274 conservative side and to underun the receiver rather then overrun it. 276 For a given IS-IS adjacency, the Flooding Parameters TLV does not 277 need to be advertised in each SNP and IIS. The IS transmitter uses 278 the latest value received of each parameter (sub-TLV) until a new 279 value is advertised by the IS receiver. Note however that CSNP and 280 IIH are not reliability exchanged, hence some PDU may never be 281 received. For a parameter which has never been advertised, the IS 282 transmitter use its local default value. That value SHOULD be 283 configurable on a per node basis and MAY be configurable on a per 284 interface basis. 286 4.2. Faster acknowledgments of LSPs 288 As per [ISO10589], on point to point interfaces, the LSP receiver 289 dynamically acknowledges the received LSPs by sending PSNP messages. 290 By acknowledging the LSPs before the InterfaceLSPReceiveWindow is 291 exhausted, the receiver can achieve dynamic flow control and increase 292 the flooding throughput without risking to overload any IS-IS router. 293 If the InterfaceLSPReceiveWindow is large enough, the downstream 294 flooding node can acknowledge a set of multiple LSPs up to the 295 maximum size of a PSNP (90 LSPs) which allows dynamic flow control 296 with limited or even no increase in the number of sent PSNPs. 298 The way LSPs are acknowledged faster is a local decision on the 299 receiving IS. Without limiting the possibilities, there are at least 300 two options: 302 o Reduce partialSNPInterval. Possibly reduce it even further when 303 the IS-IS adjacency initially transitions to the UP state, when a 304 large number of LSPs need to be received quickly, until the LSDB 305 has been synchronized. The choice of this lower value is a local 306 choice. It may depends on the (available) processing power of the 307 node, the number of adjacencies been brought up at the same time, 308 the requirement to synchronize the LSDB more quickly. 310 o Track the number of received and un-acknowledged LSP per interface 311 and level, and send a PSNP when the number reaches 90 (max per 312 PSNP) or is significant enough e.g., 10 or 313 InterfaceLSPReceiveWindow/2. 315 4.3. Operation on a LAN interface 317 On a LAN interface an IS receiver will generally receive LSPs from 318 many IS transmitters. And the LSPs sent by a given IS transmitter 319 will be received by all of the IS receivers. In this section, we 320 clarify how the flooding parameters should be interpreted in the 321 context of a LAN. 323 An IS receiver on a LAN will communicate its desired flooding 324 parameters using a single Flooding Parameters TLV, copies of which 325 will be received by all N transmitters. The flooding parameters sent 326 by the IS receiver MUST be understood as instructions from the 327 receiver to each transmitter about the desired maximum transmit 328 characteristics of each transmitter. The receiver is aware that 329 there are N transmitters that can send LSPs to the receiver LAN 330 interface. The receiver might want to take that into account by 331 advertising a higher value of InterfaceLSPTransmissionInterval on 332 this LAN interface than what it would advertise on a point to point 333 interface. When the transmitters receive the 334 InterfaceLSPTransmissionInterval value advertised by the DIS 335 receiver, the transmitters should rate limit LSPs according to the 336 advertised flooding parameters. They should not apply any further 337 interpretation to the flooding parameters advertised by the receiver. 339 On the other hand, a given IS transmitter will receive flooding 340 parameter advertisements using N different Flooding Parameters TLVs, 341 which could carry different flooding parameter values. A given 342 transmitter SHOULD adjust the flooding behavior on this LAN interface 343 such that none of the receivers receives more un-acknowledged LSPs or 344 LSPs at a higher rate than indicated by their individual flooding 345 parameter advertisements. 347 In order for the InterfaceLSPReceiveWindow to be a useful parameter, 348 an IS transmitter needs to be able to keep track of the number of un- 349 acknowledged LSPs it has sent to a given IS receiver. On a LAN there 350 is no explicit acknowledgment of the receipt of LSPs between a given 351 IS transmitter and a given IS receiver. However, an IS transmitter 352 on a LAN can infer whether or not any IS receivers on the LAN have 353 requested retransmission of LSPs from the DIS by monitoring PSNPs 354 generated on the LAN. If no PSNPs have been generated on the LAN for 355 a suitable period of time, then an IS transmitter can safely set the 356 number of un-acknowledged LSPs to zero. 358 5. Congestion control 360 Whereas flow control prevents the sender from overwhelming the 361 receiver, congestion control prevents senders from overwhelming the 362 network. For an IS-IS adjacency, the network between two IS-IS 363 neighbors is relatively limited in scope and include in a single link 364 which is typically over-sized compared to the capability of the IS-IS 365 speakers. But also includes components inside both routers such as a 366 fabric switch, line card CPU and forwarding plane buffers which may 367 experience congestion. For congestion avoidance in steady state TCP 368 uses the AIMD (Additive Increase Multiplicative Decrease) algorithm 369 to react to packet loss. This document proposes an to use the same 370 principle. This document proposes one congestion control algorithm 371 but implementations may choose a different one. 373 The congestion control algorithm uses 375 o a moderate starting rate based on the receive window advertised by 376 the receiver; 378 o an Additive Increase proportional to the number of LSPs correctly 379 received (acknowledged); 381 o an exponential reduction in case of LSP loss. 383 When a new set of LSPs need to be sent, the sender start with a 384 congestion window set to half of the receive window. 386 When the reception of N LSPs is acknowledged, the congestion window 387 is increased by N, without exceeding the received windows. 389 When the loss of LSP is detected, the congestion window is divided by 390 two. 392 Note that this congestion control algorithm benefits from the 393 extensions proposed in this document, namely the advertisement of a 394 receive window from the receiver (Section 4) which avoid the use of 395 an arbitrary value chose by the sender, the faster acknowledgment of 396 LSP (Section 4.2) which allows for a faster control loop and hence a 397 faster increase of the congestion window in the absence of 398 congestion, and the faster detection of lost LSP (Section 6) which 399 allows for a faster control loop and hence a decrease of the 400 congestion window in case of congestion. 402 6. Faster loss detection and recovery 404 As per [ISO10589], an LSP transmitter resends a un-acknowledged LSP 405 no sooner than minimumLSPTransmissionInterval, which is 5 seconds by 406 default. As the goal is to increase the speed of reliable 407 transmission of LSP, the transmitter should be able to retransmit 408 faster in case of LSP loss. The delay need to be compatible (higher) 409 than the partialSNPInterval or the delay needed by the IS receiver to 410 acknowledge the received LSPs. This document allows the receiver to 411 advertise to the sender a more realistic value for 412 minimumLSPTransmissionInterval, with a goal to advertise a smaller 413 value than the ISO default value and hence allow for a faster 414 recovery of lost LSPs. 416 The reception of the parameter minimumLSPTransmissionInterval means 417 that the IS transmitter MAY set its minimumLSPTransmissionInterval to 418 this value or higher. 420 The interval advertised in minimumLSPTransmissionInterval MUST be 421 higher than the effective partialSNPInterval of the receiver plus the 422 Round Trip Time (RTT) of the interface. The effective 423 partialSNPInterval of the receiver is the maximum amount of time that 424 the receiver is expected to take to acknowledge the LSP. This would 425 be the partialSNPInterval on a receiver following only [ISO10589], or 426 an effective value if the receiver has implemented a faster method to 427 acknowledge LSPs, as discussed in Section 4.2. The receiver should 428 not be telling the transmitter to resend un-acknowledged LSPs before 429 the receiver had time to acknowledge LSPs it has actually received. 431 An LSP receiver MAY update this value depending on certain 432 conditions. For example, it can advertise a higher 433 minimumLSPTransmissionInterval value when a large number of LSPs are 434 been received and hence it is experiencing high load. Or it can 435 advertise a lower value when an LSP storm has passed, especially if 436 there is reason to believe that some LSPs may have been lost. 438 7. Interaction with other LSP rate limiting mechanisms 440 [ISO10589] describes a mechanism that limits the rate at which LSPs 441 from the same source system are sent out on interfaces. (See the 442 description of the parameter 443 minimumBroadcastLSPTranLSPTransmissionInterval in section 7.3.15.6 of 444 [ISO10589] .) In practice, however, router vendors have implemented 445 mechanisms that limit the rate of LSPs sent on a given interface. 446 This is often configurable on a per-interface basis using 'lsp- 447 interval' or 'lsp-pacing-interval' CLI configuration.) The mechanism 448 described in the current document extends the practice of limiting 449 the rate of LSPs sent on a given interface, by using parameters 450 advertised by the LSP receiver. When the mechanism described in the 451 current document is used, the mechanism described in section 7.3.15.6 452 of [ISO10589] is not used. 454 8. Determining values to be advertised in the Flooding Parameters TLV 456 The values that a receiving IS advertises do not need to be close to 457 perfection. It is OK to be too low and hence not to use the full 458 bandwidth or CPU resources. It is OK to be too high during some 459 situation and hence have the receiver drop some LSPs as the IS-IS 460 protocol has mechanisms to recover. What is not OK is to flood 461 multiple order of magnitudes slower than both nodes can achieve, or 462 to consistently overload the receiver. 464 The values may not need to be dynamic as a form of dynamic is 465 provided by the dynamic acknowledgment of LSPs in SNP messages. 466 Acknowledgments provides a feedback loop on how fast/slower the LSPs 467 are processed by the receiver. They also signal that the LSPs have 468 been processed by the receiver hence removed from receive window, 469 explicitly signaling to the sender that more LSPs may be sent. By 470 advertising relatively static parameters, we expect to produce 471 overall flooding behavior similar to what might be achieved by 472 manually configuring per-interface LSP rate limiting on all 473 interfaces in the network. The advertised values may be based, for 474 example, on an off line tests of the overall LSP processing speed for 475 a particular set of hardware and the number of interfaces configured 476 for IS-IS. With such a formula, the values advertised in the 477 Flooding Parameters TLV would only change when additional IS-IS 478 interfaces are configured. 480 The values MAY be updated dynamically, to reflect the relative change 481 of load of the receiver, by improving the values when the receiver 482 load is getting lower and degrading the values when the receiver load 483 is getting higher. For example, if LSPs are regularly dropped, or 484 the queue regularly comes close to being filled, then values may be 485 too high. On the other hand, if the queue is barely used (by IS-IS), 486 then values may be too low. 488 The values MAY may also be absolute value reflecting relevant 489 (averaged) hardware resources that are been monitored, typically the 490 amount of buffer space used by incoming LSPs. In this case, care 491 must be taken when choosing the parameters influencing the values, in 492 order to avoid undesirable or instable feedback loops. It would be 493 undesirable to use a formula that depends, for example, on an active 494 measurement of the instantaneous CPU load to modify the values 495 advertised in the Flooding Parameters TLV. This could introduce 496 feedback into the IGP flooding process that could produce unexpected 497 behavior. 499 9. IANA Considerations 501 IANA is requested to allocate one TLV from the IS-IS TLV codepoint 502 registry. 504 Type Description IIH LSP SNP Purge 505 ---- --------------------------- --- --- --- --- 506 TBD Flooding Parameters TLV y n y n 508 Figure 1 510 TBD: registry for sub-TLVs of the Flooding Parameters TLV. 512 10. Security Considerations 514 Any new security issues raised by the procedures in this document 515 depend upon the ability of an attacker to inject a false but 516 apparently valid SNP, the ease/difficulty of which has not been 517 altered. 519 As with others TLV advertisements, the use of a cryptographic 520 authentication as defined in [RFC5304] or [RFC5310] allows the 521 authentication of the peer and the integrity of the message. As this 522 document defines a TLV for SNP message, the relevant cryptographic 523 authentication is for SNP message. 525 In the absence of cryptographic authentication, as IS-IS does not run 526 over IP but directly over the link layer, it's considered difficult 527 to inject false SNP without having access to the link layer. 529 If a false SNP is sent with a Flooding Parameters TLV set to low 530 values, the attacker can reduce the flooding speed between the two 531 adjacent neighbors which can result in LSDB inconsistencies and 532 transient forwarding loops. However, is not significantly different 533 than filtering or altering LSPDUs which would also be possible with 534 access to the link layer. In addition, if the downstream flooding 535 neighbor has multiple IGP neighbors, which is typically the case for 536 reliability or topological reasons, it would receive LSPs at a 537 regular speed from its other neighbors and hence would maintain LSDB 538 consistency. 540 If a false SNP is sent with a Flooding Parameters TLV set to high 541 values, the attacker can increase the flooding speed which can either 542 overload a node or more likely generate loss of LSPs. However, it is 543 not significantly different than sending many LSPs which would also 544 be possible with access to the link layer, even with cryptographic 545 authentication enabled. In addition, IS-IS has procedures to detect 546 the loss of LSPs and recover. 548 This TLV advertisement is not flooded across the network but only 549 sent between adjacent IS-IS neighbors. This would limit the 550 consequences in case of forged messages, and also limits the 551 dissemination of such information. 553 11. Acknowledgments 555 The authors would like to thank Henk Smit for his review and 556 comments. 558 12. References 560 12.1. Normative References 562 [ISO10589] 563 International Organization for Standardization, 564 "Intermediate system to Intermediate system intra-domain 565 routeing information exchange protocol for use in 566 conjunction with the protocol for providing the 567 connectionless-mode Network Service (ISO 8473)", ISO/ 568 IEC 10589:2002, Second Edition, Nov 2002. 570 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 571 Requirement Levels", BCP 14, RFC 2119, 572 DOI 10.17487/RFC2119, March 1997, 573 . 575 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 576 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 577 2008, . 579 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 580 and M. Fanto, "IS-IS Generic Cryptographic 581 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 582 2009, . 584 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 585 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 586 May 2017, . 588 12.2. Informative References 590 [I-D.ietf-lsr-dynamic-flooding] 591 Li, T., Psenak, P., Ginsberg, L., Chen, H., Przygienda, 592 T., Cooper, D., Jalil, L., and S. Dontula, "Dynamic 593 Flooding on Dense Graphs", draft-ietf-lsr-dynamic- 594 flooding-06 (work in progress), May 2020. 596 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 597 RFC 793, DOI 10.17487/RFC0793, September 1981, 598 . 600 Appendix A. Changes / Author Notes 602 [RFC Editor: Please remove this section before publication] 604 00: Initial version. 606 01: Two notes added in section 3 "Operation". 608 02: Refresh, no technical change. 610 03: 612 o Flooding Parameters TLV: name changed, advertised in both Hello 613 and SNP rather than just Hello, contains sub-TLVs, parameters 614 encoded in 4 octets. 616 o Terminology: upstream/downstream terms removed, in favor of terms 617 from ISO specification (transmitter, receiver); burst-size rename 618 to receive-window. 620 o Significant editorials changes. 622 o New section on the faster acknowledgment of LSPs. 624 o New section on the faster retransmission of lost LSPs. 626 04: 628 o Adding general introduction on flow control, congestion control, 629 loss detection and recovery. 631 o Reorganizing sections as per the high level functions: flow 632 control, congestion control, loss detection and recovery. 634 o Adding a section on congestion control. 636 Authors' Addresses 638 Bruno Decraene 639 Orange 641 Email: bruno.decraene@orange.com 643 Chris Bowers 644 Juniper Networks, Inc. 645 1194 N. Mathilda Avenue 646 Sunnyvale, CA 94089 647 USA 649 Email: cbowers@juniper.net 651 Jayesh J 652 Juniper Networks, Inc. 653 1194 N. Mathilda Avenue 654 Sunnyvale, CA 94089 655 USA 657 Email: jayeshj@juniper.net 658 Tony Li 659 Arista Networks 660 5453 Great America Parkway 661 Santa Clara, California 95054 662 USA 664 Email: tony.li@tony.li 666 Gunter Van de Velde 667 Nokia 668 Copernicuslaan 50 669 Antwerp 2018 670 Belgium 672 Email: gunter.van_de_velde@nokia.com