idnits 2.17.1 draft-decraene-lsr-isis-flooding-speed-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 (January 6, 2020) is 1569 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' Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 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: July 9, 2020 Jayesh. J 6 Juniper Networks, Inc. 7 T. Li 8 Arista Networks 9 G. Van de Velde 10 Nokia 11 January 6, 2020 13 IS-IS Flooding Speed advertisement 14 draft-decraene-lsr-isis-flooding-speed-02 16 Abstract 18 This document proposes a mechanism that can be used to increase the 19 speed at which link state information is flooded across a network 20 when multiple LSPDUs need to be flooded, such as in case of a node 21 failure. It also reduces the likelihood of overloading the 22 downstream flooding neighbors. This document defines a new TLV to be 23 advertised in IS-IS Hello messages. This TLV carries two parameters 24 indicating the performance capacity to receive LSPDUs: the minimum 25 delay between two consecutive LSPDUs and the number of LSPDUs which 26 can the received back to back. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on July 9, 2020. 45 Copyright Notice 47 Copyright (c) 2020 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 64 2. Flooding Speed TLV . . . . . . . . . . . . . . . . . . . . . 4 65 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 4. Interaction with other LSPDU rate limiting mechanisms . . . . 6 67 5. Determining values to be advertised in the Flooding Speed TLV 6 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 70 8. Normative References . . . . . . . . . . . . . . . . . . . . 8 71 Appendix A. Changes / Author Notes . . . . . . . . . . . . . . . 8 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 74 1. Introduction 76 IGP flooding is paramount for Link State IGP as routing computations 77 assume that the Link State DataBases (LSDBs) are always in sync 78 across all nodes in the flooding domain. 80 Slow flooding directly translates to delayed network reaction to 81 failure and LSDB inconsistencies across nodes. The former increases 82 packets losses. The latter translates to routing inconsistencies and 83 micro-loops leading to packets losses, link(s) overload, and jitter 84 for all classes of services. Note that the link(s) affected by those 85 forwarding issues may be any link in the network and not necessarily 86 the links whose IGP status has changed. 88 IGP flooding is hard. One would want fast flooding when the network 89 is stable and slow enough flooding to not overload the neighbor(s) 90 when the network is less stable. Since flooding is performed hop by 91 hop, not overloading the adjacent neighbors is sufficient. This 92 document addresses these requirements by shaping LSPDUs with a 93 minimal delay between two consecutive LSPDUs. This flooding behavior 94 is already largely implemented by most implementations and hence 95 doesn't require changes in the basic flooding behavior. However 96 existing implementations rely on a shaping delay configured on the 97 node sending the LSPDUs. But since the need is to not overload the 98 downstream flooding node, the need is for the upstream flooding node 99 to know the receiving speed of its downstream flooding neighbors. 100 Although in theory this parameter could be configured on each 101 upstream flooding node, given the knowledge of each of its neighbor 102 in the topology and the receiving speed of those neighbors, in 103 practice this configuration is difficult to maintain over time as the 104 network topology change. In addition, as things currently stand, 105 each network operator needs to evaluate the receiving capacity of 106 each type of platform, depending on its hardware, software version 107 and number of IS-IS adjacencies. Such platform performance is better 108 known by its designer (the vendor) and even if validation tests are 109 required, one single validation test by the vendor is more effective 110 than N validations from N network providers. Finally, the reasoning 111 behind the original choices of default value is not clear. Default 112 values have largely remained unchanged over many years, despite very 113 large increases in interface speeds and processing speed. This has 114 resulted in default values that are likely to be very sub-optimal. 115 For example, typical default values are one LSPDU per 33ms or 100ms, 116 resulting in the ability to only send 30 or 10 LSPDUs per second. 117 However, the same vendors recommend setting a BGP DDoS policer to 118 10,000 packets per second or more on the same control plane hardware, 119 indicating that the control plane is capable of processing BGP 120 packets at a rate of 10,000 packets per second. 122 This document proposes that the downstream flooding node advertises 123 its LSPDU receiving speed for a single interface to the upstream 124 flooding node in IS-IS hellos. This allows the sender to take into 125 account the actual speed of the receiver. It also creates an 126 incentive for vendors to improve this speed over time and to innovate 127 to advertise a value reflecting the speed in the deployed environment 128 (for example, by taking into account the number of IS-IS neighbors, 129 which may send LSPDUs at the same time). 131 In addition, one single event in the network can require the flooding 132 of multiple LSPDUs. The typical case is a node failure which 133 requires the flooding of at least one LSPDU per neighbor of the 134 failed node. Hence, if a node has N IGP neighbors, the failure of 135 this node requires the advertisement and flooding of at least N 136 LSPDUs. The network won't be able to converge to the new topology 137 until all N LSPDUs are received by all nodes. Hence there is a need 138 to be able to quickly flood N LSPDUs. This document addresses this 139 requirement by allowing the fast flooding of some number of 140 consecutive LSPDUs. 142 This document defines a new TLV for IS-IS hello that allows a given 143 node to be able to advertise the rate at which the node can be 144 expected to safely receive and process IS-IS LSPDUs from a given 145 upstream flooding neighbor on a given interface. Each upstream 146 flooding neighbor listens to the value advertised by the downstream 147 flooding neighbor. This allows the fast flooding of LSPDUs while at 148 the same time protecting the downstream flooding neighbor from 149 receiving more LSPDUs than it can safely process in the event of 150 network instability. 152 1.1. Requirements Language 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 156 "OPTIONAL" in this document are to be interpreted as described in BCP 157 14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they 158 appear in all capitals, as shown here. 160 2. Flooding Speed TLV 162 This document defines a new TLV called "Flooding Speed TLV" to be 163 included in IIH PDUs. All IIHs transmitted by a router that support 164 this capability MUST include this TLV. 166 Type is TBD1. 168 Length is 4 octets. 170 Value field has two two-octets fields: 172 o minimumInterfaceLSPTransmissionInterval: the minimum interval, in 173 milliseconds, between two LSPDUs consecutively sent by the 174 upstream flooding node on a single interface; 176 o maximumInterfaceLSPTransmissionBurst: the maximum number of un- 177 acknowledged LSPDUs that can be transmitted by the upstream 178 flooding node on a single interface with a separation interval 179 shorter than minimumInterfaceLSPTransmissionInterval (or even 180 'back to back'). 182 +-----------------------------------------------------+ 183 | minimumInterfaceLSPTransmissionInterval (2 octets) | 184 +-----------------------------------------------------+ 185 | maximumInterfaceLSPTransmissionBurst (2 octets) | 186 +-----------------------------------------------------+ 188 Figure 1: Flooding Speed TLV 190 3. Operation 192 By sending the Flooding Speed TLV the node advertises to its IS-IS 193 neighbor(s) its ability to receive, from the upstream flooding 194 neighbor receiving this Flooding Speed TLV: 196 o minimumInterfaceLSPTransmissionInterval: the minimum interval, in 197 milliseconds, between two LSPDUs consecutively sent by the 198 upstream flooding node on a single interface; 200 o maximumInterfaceLSPTransmissionBurst: the maximum number of un- 201 acknowledged LSPDUs that can be transmitted by the upstream 202 flooding node on a single interface with a separation interval 203 shorter than minimumInterfaceLSPTransmissionInterval (or even 204 'back to back'). 206 The node sending the Flooding Speed TLV is the downstream flooding 207 neighbor. It MUST be prepared to sustain, for a long duration, the 208 reception of one LSPDU every minimumInterfaceLSPTransmissionInterval 209 milliseconds. In addition, it MUST be capable of receiving 210 maximumInterfaceLSPTransmissionBurst un-acknowledged LSPDUs with a 211 shorter separation interval, provided than no more than 1000/ 212 minimumInterfaceLSPTransmissionInterval un-acknowledged LSPDUs are 213 transmitted in any one second period. 215 Note that if the above two "MUST" cannot be fulfilled because of 216 transient conditions, this cause no severe harm to the operation of 217 IS-IS as this condition is already accounted for in [ISO10589]. As 218 per [ISO10589], after a few seconds, respectively 2 and 10 by default 219 in [ISO10589], neighbors will exchange PSNP (for point to point 220 interface) or CSNP (for broadcast interface) and recover from the 221 lost LSPDUs. 223 Note that, as per [ISO10589], the downstream flooding node 224 dynamically acknowledges the received LSPDUs by sending CSNP or PSNP 225 . By acknowledging the LSPDUs before the 226 maximumInterfaceLSPTransmissionBurst is exhausted, the downstream 227 flooding neighbor can achieve dynamic flow control and increase the 228 flooding speed with its upstream flooding node without risking to 229 overload any IS-IS router. If the 230 maximumInterfaceLSPTransmissionBurst is large enough, on a point to 231 point interface the downstream flooding node can acknowledge a set of 232 multiple LSPDUs up to the maximum size of a PSNP (up to 90 LPDUs) 233 which allows dynamic flow control without even increasing the number 234 of PSNPs. 236 The node receiving the Flooding Speed TLV is the upstream flooding 237 neighbor. The upstream flooding neighbor MUST NOT transmit LSPDUs at 238 a sustained rate greater than one LSPDU every 239 minimumInterfaceLSPTransmissionInterval milliseconds. The upstream 240 flooding neighbor MAY transmit maximumInterfaceLSPTransmissionBurst 241 un-acknowledged LSPDUs with a shorter separation interval, provided 242 than no more than 1000/minimumInterfaceLSPTransmissionInterval LSPDUs 243 are transmitted in any one second period. 245 4. Interaction with other LSPDU rate limiting mechanisms 247 [ISO10589] describes a mechanism that limits the rate at which LSPDUs 248 from the same source system are sent out all interfaces. (See the 249 description of the parameter minimumLSPTransmissionInterval in 250 sections 7.3.21 and 7.3.15.5 of [ISO10589] .) In practice, however, 251 router vendors have implemented mechanisms that limit the rate of 252 LSPDUs sent on a given interface. This is often configurable on a 253 per-interface basis using 'lsp-interval' or 'lsp-pacing-interval' CLI 254 configuration.) The mechanism described in the current document 255 extends the practice of limiting the rate of LSPDUs sent on a given 256 interface, by using parameters advertised by the downstream flooding 257 neighbor. When the mechanism described in the current document is 258 used, the mechanism described in section 7.3.15.5 of [ISO10589] is 259 not used. 261 5. Determining values to be advertised in the Flooding Speed TLV 263 The values that a downstream flooding neighbor advertises in the 264 Flooding Speed TLV should not change often. For example, in order to 265 compute the values in the Flooding Speed TLV, a reasonable choice 266 might be for a node to use a formula based on an off line tests of 267 the overall LSPDU processing speed for a particular set of hardware 268 and the number of interfaces configured for IS-IS. With such a 269 formula, the values advertised in the Flooding Speed TLV would only 270 change when additional IS-IS interfaces are configured. On the other 271 hand, it would be undesirable to use a formula that depends, for 272 example, on an active measurement of the CPU load to modify the 273 values advertised in the Flooding Speed TLV. This could introduce 274 feedback into the IGP flooding process that could produce unexpected 275 behavior. Since correct IGP flooding is so fundamental to network 276 operation, we do not want to introduce new dynamic behavior to it. 277 By requiring that the values advertised in the Flooding Speed TLV not 278 change very often, we expect to produce overall flooding behavior 279 similar to what might be achieved by manually configuring per- 280 interface LSPDU rate limiting on all interfaces in the network. 282 6. IANA Considerations 284 IANA is requested to allocate one TLV from the IS-IS TLV codepoint 285 registry. 287 Type Description IIH LSP SNP Purge 288 ---- --------------------------- --- --- --- --- 289 TBD Flooding Speed TLV y n n n 291 Figure 2 293 7. Security Considerations 295 Any new security issues raised by the procedures in this document 296 depend upon the ability of an attacker to inject a false but 297 apparently valid IIH, the ease/difficulty of which has not been 298 altered. 300 As with others TLV advertisements, the use of a cryptographic 301 authentication as defined in [RFC5304] or [RFC5310] allows the 302 authentication of the peer and the integrity of the message. As this 303 document defines a TLV for IS-IS Hello message (IIH), the relevant 304 cryptographic authentication is for IS-IS Hello message (IIH). 306 In the absence of cryptographic authentication, as IS-IS does not run 307 over IP but directly over the link layer, it's considered difficult 308 to inject false IIH without having access to the link layer. 310 If a false IIH is sent with a Flooding Speed TLV set to low values, 311 the attacker can reduce the flooding speed between the two adjacent 312 neighbors which can result in LSDB inconsistencies and transient 313 forwarding loops. However, is not significantly different than 314 filtering or altering LSPDUs which would also be possible with access 315 to the link layer. In addition, if the downstream flooding neighbor 316 has multiple IGP neighbors, which is typically the case for 317 reliability or topological reasons, it would receive LSPDUs at a 318 regular speed from its other neighbors and hence would maintain LSDB 319 consistency. 321 If a false IIH is sent with a Flooding Speed TLV set to high values, 322 the attacker can increase the flooding speed which can either 323 overload a node or more likely generate loss of LSPDUs. However, is 324 not significantly different than sending many LSPDUs which would also 325 be possible with access to the link layer, even with cryptographic 326 authentication enabled. In addition, IS-IS has procedures to detect 327 the loss of LSPDUs and recover. 329 This TLV advertisement is not flooded across the network but only 330 sent between two adjacent IS-IS neighbors. This would limit the 331 consequences in case of forged messages, and also limits the 332 dissemination of such information. 334 8. Normative References 336 [ISO10589] 337 International Organization for Standardization, 338 "Intermediate system to Intermediate system intra-domain 339 routeing information exchange protocol for use in 340 conjunction with the protocol for providing the 341 connectionless-mode Network Service (ISO 8473)", ISO/ 342 IEC 10589:2002, Second Edition, Nov 2002. 344 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 345 Requirement Levels", BCP 14, RFC 2119, 346 DOI 10.17487/RFC2119, March 1997, 347 . 349 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 350 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 351 2008, . 353 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 354 and M. Fanto, "IS-IS Generic Cryptographic 355 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 356 2009, . 358 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 359 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 360 May 2017, . 362 Appendix A. Changes / Author Notes 364 [RFC Editor: Please remove this section before publication] 366 00: Initial version. 368 01: Two notes added in section 3 "Operation". 370 02: Refresh, no technical change. 372 Authors' Addresses 373 Bruno Decraene 374 Orange 376 Email: bruno.decraene@orange.com 378 Chris Bowers 379 Juniper Networks, Inc. 380 1194 N. Mathilda Avenue 381 Sunnyvale, CA 94089 382 USA 384 Email: cbowers@juniper.net 386 Jayesh J 387 Juniper Networks, Inc. 388 1194 N. Mathilda Avenue 389 Sunnyvale, CA 94089 390 USA 392 Email: jayeshj@juniper.net 394 Tony Li 395 Arista Networks 396 5453 Great America Parkway 397 Santa Clara, California 95054 398 USA 400 Email: tony.li@tony.li 402 Gunter Van de Velde 403 Nokia 404 Copernicuslaan 50 405 Antwerp 2018 406 Belgium 408 Email: gunter.van_de_velde@nokia.com