idnits 2.17.1 draft-ietf-trill-mtu-negotiation-08.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 == Line 513 has weird spacing: '... tbd origi...' (Using the creation date from RFC6325, updated by this document, for RFC5378 checks: 2006-05-11) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 2, 2017) is 2452 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT M. Zhang 3 Intended Status: Standards Track X. Zhang 4 Updates: 6325, 7177, 7780 D. Eastlake 5 Huawei 6 R. Perlman 7 EMC 8 S. Chatterjee 9 Cisco 10 Expires: February 3, 2018 August 2, 2017 12 Transparent Interconnection of Lots of Links (TRILL): 13 MTU Negotiation 14 draft-ietf-trill-mtu-negotiation-08.txt 16 Abstract 18 The base IETF TRILL protocol has a TRILL campus-wide MTU feature, 19 specified in RFC 6325 and RFC 7177, that assures that link state 20 changes can be successfully flooded throughout the campus while being 21 able to take advantage of a campus-wide capability to support jumbo 22 packets. This document specifies recommended updates to that MTU 23 feature to take advantage, for appropriate link-local packets, of 24 link-local MTUs that exceed the TRILL campus MTU. In addition, it 25 specifies an efficient algorithm for local MTU testing. This document 26 updates RFC 6325, updates RFC 7177, and updates RFC 7780. 28 Status of this Memo 30 This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that 35 other groups may also distribute working documents as 36 Internet-Drafts. 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 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/1id-abstracts.html 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html 49 Copyright and License Notice 51 Copyright (c) 2017 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Conventions used in this document . . . . . . . . . . . . . 3 68 2. Link-Wide TRILL MTU Size . . . . . . . . . . . . . . . . . . . 3 69 2.1. Operations . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3. Link MTU Size Testing . . . . . . . . . . . . . . . . . . . . . 6 71 4. Refreshing Sz . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 5. Relationship between Port MTU, Lz and Sz . . . . . . . . . . . 9 73 6. LSP Synchronization . . . . . . . . . . . . . . . . . . . . . . 9 74 7. Recommendations for Traffic Link MTU Size Testing . . . . . . . 9 75 8. Backwards Compatibility . . . . . . . . . . . . . . . . . . . . 10 76 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 10 77 10. Additions to Configuration . . . . . . . . . . . . . . . . . . 11 78 10.1. Per RBridge Configuration . . . . . . . . . . . . . . . . 11 79 10.2. Per RBridge Port Configuration . . . . . . . . . . . . . . 11 80 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 81 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 82 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 13.1. Normative References . . . . . . . . . . . . . . . . . . . 12 84 13.2. Informative References . . . . . . . . . . . . . . . . . . 12 85 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 87 1. Introduction 89 [RFC6325] describes the way RBridges agree on the campus-wide minimum 90 acceptable inter-RBridge MTU (Maximum Transmission Unit) size (called 91 "Sz") to ensure that link state flooding operates properly and all 92 RBridges converge to the same link state. For the proper operation of 93 TRILL IS-IS, all RBridges format their LSPs to fit in Sz. 95 [RFC7177] diagrams the state transitions of an adjacency. If MTU 96 testing is enabled, "Link MTU size is successfully tested" is part of 97 an event (event A6) causing the transition from "2-way" state to 98 "Report" state for an adjacency. This means the link MTU testing of 99 size X succeeds, and X is greater than or equal to Sz [RFC6325]. If 100 this link cannot support an MTU of Sz, it will not be reported as 101 part of the campus topology. 103 In this document, a new RECOMMENDED link-wide minimum inter-RBridge 104 MTU size, Lz, is specified. As further discussed in Section 2, by 105 calculating and using Lz as specified herein, link-scoped PDUs can be 106 formatted greater than Sz, up to the link-wide minimum acceptable 107 inter-RBridge MTU size potentially improving the efficiency of link 108 utilization and speeding link state convergence. 110 An optional TRILL MTU size-testing algorithm is specified in Section 111 3 as an efficient method to update the old MTU testing method 112 described in Section 4.3.2 of [RFC6325] and in [RFC7177]. The new MTU 113 size testing method specified in this document is backward compatible 114 with the old one. Multicasting the MTU-probes is recommended when 115 there are multiple RBridges on a link responding to the probing with 116 MTU-ack [RFC7177]. The testing method and rules of this document are 117 devised in a way to minimize the number of MTU probes for testing, 118 which therefore reduces the number of multicast packets for MTU 119 testing. 121 This document updates [RFC7780] as specified in Section 4. 123 1.1. Conventions used in this document 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC 2119 [RFC2119]. 129 2. Link-Wide TRILL MTU Size 131 This document specifies a new value "Lz" for the minimum acceptable 132 inter-RBridge link MTU size on a local link. Link-wide Lz is the 133 minimum Lz supported and agreed amongst all RBridges on a specific 134 link. If the link is usable, Lz will be greater than or equal to Sz. 136 Some TRILL IS-IS PDUs are exchanged only between neighbors instead of 137 the whole campus. They are confined by the link-wide Lz instead of 138 Sz. CSNPs and PSNPs are examples of such PDUs. These PDUs are 139 exchanged only on the local link. (While TRILL IS-IS Hellos are also 140 link local, they are always limited to 1470 bytes for robustness.) 142 [RFC7356] defines the PDUs which support flooding scopes in addition 143 to area-wide scope and domain-wide scope. As specified in [RFC8139], 144 RBridges support the Extended L1 Circuit Scoped (E-L1CS) flooding 145 scope LSP (FS-LSP) [RFC7780]. The originatingSNPBufferSize for a port 146 is the minimum of the following two quantities, but not less than 147 1470 bytes: (1) the maximum MTU of the port and (2) the maximum LSP 148 size that the TRILL IS-IS implementation can handle. They use that 149 flooding to exchange their maximum supported value of "Lz". The 150 smallest value of the Lz advertised by the RBridges on a link, but 151 not less than Sz, is the link-wide Lz. An RBridge on a local link 152 will be able to tell which other RBridges on that link support E-L1CS 153 FS-LSPs because, as required by [RFC7780], all RBridges include the 154 Scoped Flooding Support TLV [RFC7356] in their TRILL Hellos. 156 The maximum sized level 1 link-local PDU, such as PSNP or CSNP, which 157 may be generated by a system is controlled by the value of the 158 management parameter originatingL1SNPBufferSize. This value 159 determines Lz. The TRILL APPsub-TLV shown in Figure 2.1 SHOULD be 160 included in a TRILL GENINFO TLV [RFC7357] in an E-L1CS FS-LSP 161 fragment zero. If it is missing from a fragment zero E-L1CS FS-LSP or 162 there is no fragment zero E-L1CS FS-LSP, it is assumed that its 163 originating IS is implicitly advertising its originatingSNPBufferSize 164 value as Sz octets. 166 E-L1CS FS-LSPs are link-local and can also be sent up to Lz in size 167 but, for robustness, E-L1CS FS-LSP fragment zero MUST NOT exceed 1470 168 bytes. 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Type = tbd | (2 byte) 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Length = 2 | (2 byte) 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | originatingSNPBufferSize | (2 byte) 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 Figure 2.1: The originatingSNPBufferSize TLV. 180 Type: set to originatingSNPBufferSize APPsubTLV (TRILL APPsub-TLV 181 type tbd). Two bytes because this APPsub-TLV appears in an Extended 182 TLV [RFC7356]. 184 Length: set to 2. 186 originatingSNPBufferSize: the local value of 187 originatingL1SNPBufferSize as an unsigned integer, limited in the 188 range from 1470 to 65,535 bytes. (A value less than 1470 will be 189 ignored.) 191 2.1. Operations 193 Lz MAY be reported using an originatingSNPBufferSize TLV that occurs 194 in fragment zero of the RBridge's E-L1CS FS-LSP. An 195 originatingSNPBufferSize APPsub-TLV occurring in any other fragment 196 is ignored. If more than one originatingSNPBufferSize APPsub-TLV 197 occurs in fragment zero, the one advertising the smallest value for 198 originatingSNPBufferSize, but not less than 1470 bytes, is used. 200 Lz:1800 Lz:1800 201 +---+ | +---+ 202 |RB1|(2000)---|---(2000)|RB2| 203 +---+ | +---+ 204 | 205 Lz:1800 | 206 +---+ +--+ 207 |RB3|(2000)---(1700)|B1| 208 +---+ +--+ 209 | 211 Figure 2.2: Link-wide Lz = 1800 v.s. tested link MTU size = 1700 213 Even if all RBridges on a specific link have reached consensus on the 214 value of link-wide Lz based on advertised originatingSNPBufferSize, 215 it does not mean that these RBridges can safely exchange PDUs between 216 each other. Figure 2.2 shows such a corner case. RB1, RB2 and RB3 are 217 three RBridges on the same link and their Lz is 1800, so the link- 218 wide Lz of this link is 1800. There is an intermediate bridge (say 219 B1) between RB2 and RB3 whose port MTU size is 1700. If RB2 sends 220 PDUs formatted in chunks of size 1800, it will be discarded by B1. 222 Therefore the link MTU size SHOULD be tested. After the link MTU size 223 of an adjacency is successfully tested, those link-local PDUs such as 224 CSNPs, PSNPs and E-L1CS FS-LSPs will be formatted no greater than the 225 tested link MTU size and will be safely transmitted on this link. 227 As for Sz, RBridges continue to propagate their 228 originatingL1LSPBufferSize across the campus through the 229 advertisement of LSPs as defined in Section 4.3.2 of [RFC6325]. The 230 smallest value of Sz advertised by any RBridge, but not less than 231 1470, will be deemed as Sz. Each RBridge formats their "campus-wide" 232 PDUs, for example LSPs, not greater than what they determine as Sz. 234 3. Link MTU Size Testing 236 [RFC7177] defines the event A6 as including "MTU test is successful" 237 if the MTU testing is enabled. As described in Section 4.3.2 of 238 [RFC6325], this is a combination of the following event and 239 condition. 241 Event: The link MTU size has been tested. 243 Condition: The link can support Sz. 245 This condition can be efficiently tested by the following "Binary 246 Search Algorithm" and rules. This updates [RFC7177] and [RFC6325]. 248 x, lowerBound, and upperBound are local integer variables. The MTU- 249 probe and MTU-ack PDUs are specified in Section 3 of [RFC7176]. 251 Step 0: RB1 sends an MTU-probe padded to the size of link-wide Lz. 253 1) If RB1 successfully receives the MTU-ack from RB2 to the probe of 254 the value of link-wide Lz within k tries (where k is a 255 configurable parameter whose default is 3. One Round Trip Time 256 (RTT) between the two adjacent RBridges is RECOMMENDED to be used 257 as the minimum interval between two successive probes. Note that 258 RTT estimation is out of the scope for this document. If operators 259 cannot not estimate the RTT, the default value 5-millisecond 260 should be assumed.), link MTU size is set to the size of link-wide 261 Lz and stop. 263 2) RB1 tries to send an MTU-probe padded to the size 1470. 265 a) If RB1 fails to receive an MTU-ack from RB2 after k tries (An 266 MTU-ack should be considered to have failed two RTT after the 267 probe is sent out.), RB1 sets the "failed minimum MTU test" 268 flag for RB2 in RB1's Hello and stop. 270 b) Link MTU size is set to 1470, lowerBound is set to 1470, 271 upperBound is set to the link-wide Lz, x is set to [(lowerBound 272 + upperBound)/2], rounded down to the nearest integer. 274 Step 1: RB1 tries to send an MTU-probe padded to the size x. 276 1) If RB1 fails to receive an MTU-ack from RB2 after k tries: 278 upperBound is set to x-1 and x is set to [(lowerBound + 279 upperBound)/2], rounded down to the nearest integer. 281 2) If RB1 receives an MTU-ack to a probe of size x from RB2: 283 link MTU size is set to x, lowerBound is set to x and x is set 284 to [(lowerBound + upperBound)/2], rounded down to the nearest 285 integer. If lowerBound equals upperBound-1 then x is set to 286 upperBound. 288 3) If lowerBound >= upperBound or Step 1 has been repeated n times 289 (where n is a configurable parameter whose default value is 5), 290 stop. 292 4) Repeat Step 1. 294 After the testing, the two connected RBridges agree on the value of 295 the link MTU size. MTU testing is only done in the Designated VLAN 296 [RFC7177]. Since the execution of the above algorithm can be resource 297 consuming, it is RECOMMENDED that the Designated RBRidge (DRB 298 [RFC7177]) take the responsibility to do the testing. Multicast MTU- 299 probes are used instead of unicast when multiple RBridges are desired 300 to respond with an MTU-ack on the link. The Binary Search Algorithm 301 given here is a way to minimize the probing attempts; it reduces the 302 number of multicast packets for MTU-probing. 304 The following rules are designed to determine whether the 305 aforementioned "Condition" holds. 307 RBridges have figured out the upper bound and lower bound for the 308 link MTU size from the execution of the above algorithm. If Sz is 309 smaller than the lower bound or greater than the upper bound, 310 RBridges can directly judge whether the link supports Sz without MTU- 311 probing. 313 (a) If "lowerBound" >= Sz. This link can support Sz. 315 (b) Else if "upperBound" <= Sz. This link cannot support Sz. 317 Otherwise, RBridges SHOULD test whether the link can support Sz as in 318 item (c) below. If they do not, the only safe assumption will be that 319 the link cannot support Sz. This assumption, without testing, might 320 rule out the use of a link that can, in fact, handle packets up to 321 Sz. In the worst case, this might result in unnecessary network 322 partition. 324 (c) "lowerBound" < Sz < "upperBound". RBridges probe the link with 325 MTU-probe messages padded to Sz. If an MTU-ack is received within 326 k tries, this link can support Sz. Otherwise, this link cannot 327 support Sz. Through this test, the lower bound and upper bound of 328 link MTU size can be updated accordingly. 330 4. Refreshing Sz 332 RBridges may join or leave the campus, which may change Sz. 334 1) Joining 336 a) When a new RBridge joins the campus and its 337 originatingL1LSPBufferSize is smaller than current Sz, 338 reporting its originatingL1LSPBufferSize in its LSPs will cause 339 other RBridges decrease their Sz. Then any LSP greater than the 340 reduced Sz MUST be split and/or the LSP contents in the campus 341 MUST be otherwise redistributed so that no LSP is greater than 342 the new Sz. 344 b) If the joining RBridge's originatingL1LSPBufferSize is equal to 345 or bigger than current Sz, reporting its 346 originatingL1LSPBufferSize will not change Sz. 348 2) Leaving 350 a) From the specification of the Joining process, we know it's 351 non-applicable that an RBridge leaves the campus while its 352 originatingL1LSPBufferSize is smaller than Sz. 354 b) When an RBridge leaves the campus and its 355 originatingL1LSPBufferSize equals to Sz, its LSPs are purged 356 from the remaining campus after reaching MaxAge [IS-IS]. Sz MAY 357 be recalculated and MAY increase. In other words, while in most 358 cases RB1 ignores link state information for IS-IS unreachable 359 RBridge RB2 [RFC7780], originatingL1LSPBufferSize is 360 meaningful. Its value, even from IS-IS unreachable RBridges, is 361 used in determining Sz. This updates [RFC7780]. 363 c) When an RBrige leaves the campus and its 364 originatingL1LSPBufferSize is greater than Sz, this will not 365 update Sz since Sz is determined by another RBridge with 366 smaller originatingL1LSPBufferSize. 368 Frequent LSP "re-sizing" is harmful to the stability of the TRILL 369 campus, so, to avoid this, upward resizing SHOULD be dampened. When 370 an upward resizing event is noticed by an RBridge, it is RECOMMENDED 371 that a timer be set at that RBridge. This is a configurable 372 parameter, LSPresizeTime, whose default value is 300 seconds. Before 373 this timer expires, all subsequent upward resizing will be dampened 374 (ignored). Of course, in a well-configured campus with all RBridges 375 configured to have the same originatingL1LSPBufferSize, no resizing 376 will be necessary. It does not matter if different RBridges have 377 different dampening timers or some RBridges re-size upward more 378 quickly than others. 380 If the refreshed Sz is smaller than the lower bound or greater than 381 the upper bound of the tested link MTU size, the resource consuming 382 link MTU size testing can be avoided according to rule (a) or (b) 383 specified in Section 3. Otherwise, RBridges test the link MTU size 384 according to rule (c). 386 5. Relationship between Port MTU, Lz and Sz 388 When the port MTU of an RBridge is smaller than the local 389 originatingL1SNPBufferSize of an RBridge (an inconsistent 390 configuration), that port SHOULD be disabled since, in any case, an 391 adjacency cannot be formed through such a port. On the other hand, 392 when an RBridge receives an LSP or E-L1CS FS-LSP with size greater 393 than the link-wide Lz or Sz but not greater than its port MTU size, 394 this LSP is processed normally. If the size of an LSP is greater than 395 the MTU size of a port over which it is to be propagated, this LSP 396 MUST NOT be sent over the port and an LSPTooLargeToPropagate alarm 397 shall be generated [IS-IS]. 399 6. LSP Synchronization 401 An RBridge participates in LSP synchronization on a link as soon as 402 it has at least one adjacency on that link that has advanced to at 403 least the 2-Way state [RFC7177]. On a LAN link, CSNP and PSNP PDUs 404 are used for synchronization. On a point-to-point link, only PSNP are 405 used. 407 The CSNPs and PSNPs can be formatted in chunks of size at most the 408 link-wide Lz but are processed normally if received larger than that 409 size. Since the link MTU size may not have been tested in the 2-Way 410 state, link-wide Lz may be greater than the supported link MTU size. 411 In that case, a CSNP or PSNP may be discarded. After the link MTU 412 size is successfully tested, RBridges will begin to format these PDUs 413 in the size no greater than that MTU, therefore these PDUs will 414 eventually get through. 416 Note that the link MTU size is frequently greater than Sz. Link-local 417 PDUs are limited in the size by the link MTU size rather than Sz, 418 which, when Lz is greater than Sz, promises a reduction in the number 419 of PDUs and a faster LSP synchronization process. 421 7. Recommendations for Traffic Link MTU Size Testing 423 Sz and link-wide Lz are used to limit the size of most TRILL IS-IS 424 PDUs. They are different from the MTU size restricting the size of 425 TRILL Data packets. The size of a TRILL Data packet is restricted by 426 the physical MTU of the ports and links the packet traverses. It is 427 possible that a TRILL Data packet successfully gets through the 428 campus but its size is greater than Sz or link-wide Lz values. 430 The algorithm defined for link MTU size testing can also be used in 431 TRILL traffic MTU size testing; in that case the link-wide Lz used in 432 that algorithm is replaced by the port MTU of the RBridge sending MTU 433 probes. The successfully tested size X MAY be advertised as an 434 attribute of this link using MTU sub-TLV defined in [RFC7176]. 436 Unlike RBridges, end stations do not participate in the exchange of 437 TRILL IS-IS PDUs; therefore, they cannot grasp the traffic link MTU 438 size from a TRILL campus automatically. An operator may collect these 439 values using network management tools such as TRILL ping or 440 TraceRoute. Then, the path MTU can be set as the smallest tested link 441 MTU on this path; and end stations should not generate frames that, 442 when encapsulated as TRILL Data packets, exceed this path MTU. 444 8. Backwards Compatibility 446 There can be a mixture of Lz-ignorant and Lz-aware RBridges on a 447 link. This will act properly although, it may not be as efficient as 448 it would be if all RBridges on the link are Lz-aware. 450 For an Lz-ignorant RBridge, TRILL IS-IS PDUs are always formatted not 451 greater than Sz. Lz-aware RBridges as receivers can handle these PDUs 452 since they cannot be greater than the link-wide Lz. 454 For an Lz-aware RBridge, in the case that link-wide Lz is greater 455 than Sz, larger link-local TRILL IS-IS PDUs can be sent out to gain 456 efficiencies. Lz-ignorant RBridges as receivers will have no problem 457 handling them since the originatingL1LSPBufferSize value of these 458 RBridges had been tested and the link-wide Lz is not greater than 459 that value. 461 An Lz-ignorant RBridge might not support the link MTU testing 462 algorithm defined in Section 3 but could be using some algorithm just 463 to test for Sz MTU on the link. In any case, if an RBridge per 464 [RFC6325] receives an MTU-probe, it MUST respond with an MTU-ack 465 padded to the same size as the MTU-probe. 467 9. Security Considerations 469 This document raises no significant new security issues for TRILL. In 470 TRILL, RBridges are generally considered to be trusted devices. 471 Protection against forged TRILL IS-IS PDUs, including forged Hellos 472 containing originatingSNPBufferSize APP-subTLVs, can be obtained 473 through IS-IS PDU cryptographic authentication [RFC5310]. The worst 474 that an RBridge can do by reporting an erroneous 475 originatingSNPBufferSize is reduce Lz to Sz and thus make unavailable 476 the optimization of being able to use link MTUs that exceed the 477 campus wide MTU for link local TRILL IS-IS PDUs. 479 For general and adjacency related TRILL security considerations, see 480 [RFC6325] and [RFC7177]. 482 10. Additions to Configuration 484 Implementation of the features specified in this document adds two 485 RBridge configuration parameters as follows: 487 10.1. Per RBridge Configuration 489 Each RBridge implementing the RECOMMENDED LSP re-sizing damping 490 strategy specified in Section 4 has an LSPresizeTime parameter that 491 is an integer in the range of 0-65,535 which defaults to 300. It is 492 the number of seconds for which an RBridge determines that Sz has 493 increased before it will create any LSP or E-L1FS FS-LSP fragments. 495 10.2. Per RBridge Port Configuration 497 Each RBridge port on which the calculation and use of Lz is 498 implemented has an originatingL1SNPBufferSize parameter that is an 499 integer in the range of 1,470-65,535. This parameter defaults to the 500 minimum of the size that the port can accommodate and the size link- 501 local IS-IS PDU that the TRILL implementation can accommodate. 503 11. IANA Considerations 505 IANA is requested to assign a new APPsub-TLV number from the range 506 less than 256 in the "TRILL APPsub-TLV Types under IS-IS TLV 251 507 Application Identifier 1" registry for the TRILL 508 originatingSNPBufferSize sub-TLV defined in Section 2 of this 509 document. The entry is as follows: 511 Type Name Reference 512 ---- ------------------------ --------------- 513 tbd originatingSNPBufferSize [this document] 515 12. Acknowledgements 517 Authors would like to thank the comments and suggestions from Vishwas 518 Manral. 520 13. References 521 13.1. Normative References 523 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 524 Requirement Levels", BCP 14, RFC 2119, DOI 525 10.17487/RFC2119, March 1997, . 528 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 529 and M. Fanto, "IS-IS Generic Cryptographic Authentication", 530 RFC 5310, DOI 10.17487/RFC5310, February 2009, 531 . 533 [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 534 Ghanwani, "Routing Bridges (RBridges): Base Protocol 535 Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, 536 . 538 [RFC7177] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and 539 V. Manral, "Transparent Interconnection of Lots of Links 540 (TRILL): Adjacency", RFC 7177, DOI 10.17487/RFC7177, May 541 2014, . 543 [RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, D., 544 and A. Banerjee, "Transparent Interconnection of Lots of 545 Links (TRILL) Use of IS-IS", RFC 7176, DOI 546 10.17487/RFC7176, May 2014, . 549 [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 550 Scope Link State PDUs (LSPs)", RFC 7356, DOI 551 10.17487/RFC7356, September 2014, . 554 [RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., 555 Ghanwani, A., and S. Gupta, "Transparent Interconnection of 556 Lots of Links (TRILL): Clarifications, Corrections, and 557 Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, 558 . 560 [RFC7357] Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. 561 Stokes, "Transparent Interconnection of Lots of Links 562 (TRILL): End Station Address Distribution Information 563 (ESADI) Protocol", RFC 7357, DOI 10.17487/RFC7357, 564 September 2014, . 566 13.2. Informative References 568 [IS-IS] International Organization for Standardization, 569 "Information technology -- Telecommunications and 570 information exchange between systems -- Intermediate System 571 to Intermediate System intra-domain routeing information 572 exchange protocol for use in conjunction with the protocol 573 for providing the connectionless-mode network service (ISO 574 8473)", ISO/IEC 10589:2002, Second Edition, November 2002. 576 [RFC8139] Eastlake 3rd, D., Li, Y., Umair, M., Banerjee, A., and F. 577 Hu, "Transparent Interconnection of Lots of Links (TRILL): 578 Appointed Forwarders", RFC 8139, DOI 10.17487/RFC8139, June 579 2017, . 581 Author's Addresses 583 Mingui Zhang 584 Huawei Technologies 585 No. 156 Beiqing Rd. Haidian District 586 Beijing 100095 587 China 589 Phone: +86-13810702575 590 Email: zhangmingui@huawei.com 592 Xudong Zhang 593 Huawei Technologies 594 No. 156 Beiqing Rd. Haidian District 595 Beijing 100095 596 China 598 Email: zhangxudong@huawei.com 600 Donald E. Eastlake, 3rd 601 Huawei Technologies 602 155 Beaver Street 603 Milford, MA 01757 604 United States 606 Phone: +1-508-333-2270 607 EMail: d3e3e3@gmail.com 609 Radia Perlman 610 EMC 611 2010 256th Avenue NE, #200 612 Bellevue, WA 98007 613 United States 615 Email: radia@alum.mit.edu 617 Somnath Chatterjee 618 Cisco Systems 619 SEZ Unit, Cessna Business Park 620 Outer Ring Road 621 Bangalore - 560087 622 India 624 Email: somnath.chatterjee01@gmail.com