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