idnits 2.17.1 draft-ietf-trill-mtu-negotiation-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 501 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 15, 2016) is 2801 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 16, 2017 August 15, 2016 12 Transparent Interconnection of Lots of Links (TRILL): 13 MTU Negotiation 14 draft-ietf-trill-mtu-negotiation-05.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) 2016 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 . . . . . . . . . . . . . . . . . . . . . 5 71 4. Refreshing Campus-Wide Sz . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . 11 84 13.2. Informative References . . . . . . . . . . . . . . . . . . 12 85 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 87 1. Introduction 89 [RFC6325] describes the way RBridges agree on the campus-wide minimum 90 acceptable inter-RBridge MTU (Maximum Transmission Unit) size - the 91 campus-wide "Sz" to ensure that link state flooding operates properly 92 and all RBridges converge to the same link state. For the proper 93 operation of TRILL IS-IS, all RBridges MUST format their LSPs to fit 94 in the campus-wide Sz. 96 [RFC7177] diagrams the state transitions of an adjacency. If MTU 97 testing is enabled, "Link MTU size is successfully tested" is part of 98 an event (event A6) causing the transition from "2-way" state to 99 "Report" state for an adjacency. This means the link MTU testing of 100 size X succeeds, and X is greater than or equal to the campus-wide Sz 101 [RFC6325]. In other words, if this link cannot support an MTU of the 102 campus-wide Sz, it will not be reported as part of the campus 103 topology. While in this document, a new RECOMMENDED link-wide minimum 104 inter-RBridge MTU size, Lz, is specified. By calculating a using Lz 105 as specified herein, link-scoped PDUs can be formatted greater than 106 the campus-wide Sz up to the link-wide minimum acceptable inter- 107 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 to the old one. Multicasting the MTU-probes is recommended when there 115 are multiple RBridges on a link responding to the probing with MTU- 116 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 1.1. Conventions used in this document 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in RFC 2119 [RFC2119]. 127 2. Link-Wide TRILL MTU Size 129 This document specifies a new value "Lz" for the acceptable inter- 130 RBridge link MTU size on a local link. Link-wide Lz is the minimum Lz 131 supported between all RBridges on a specific link. If the link is 132 usable, Lz will be greater than or equal to the campus-wide Sz MTU. 133 Some TRILL IS-IS PDUs are exchanged only between neighbors instead of 134 the whole campus. They are confined by the link-wide Lz instead of 135 the campus-wide Sz. CSNPs and PSNPs are examples of such PDUs. These 136 PDUs are exchanged just on the local link. (While TRILL IS-IS Hellos 137 are also link local, they are always limited to 1470 bytes for 138 robustness.) 140 [RFC7356] defines the PDUs which support flooding scopes in addition 141 to area-wide scope and domain-wide scope. As specified in 142 [RFC6439bis], RBridges MUST support the Extended L1 Circuit-Scoped 143 (E-L1CS) flooding scope LSP (FS-LSP). They use that flooding to 144 exchange their maximally supportable value of "Lz". The smallest 145 value of the Lz advertised by the RBridges on a link, but not less 146 than Sz, is the link-wide Lz. An RBridge on a local link will be able 147 to tell which other RBridges on that link support E-L1CS FS-LSPs 148 because, as required by [RFC7780], all RBridges MUST include the 149 Scoped Flooding Support TLV [RFC7356] in their TRILL Hellos. 151 The maximum sized level 1 link-local PDU, such as PSNP or CSNP, which 152 may be generated by a system is controlled by the value of the 153 management parameter originatingL1SNPBufferSize. This value 154 determines Lz. The TRILL APPsub-TLV shown in Figure 2.1 SHOULD be 155 included in a TRILL GENINFO TLV [RFC7357] in an E-L1CS FS-LSP 156 fragment zero. If it is missing from a fragment zero E-L1CS FS-LSP or 157 there is no fragment zero E-L1CS FS-LSP, it is assumed that its 158 originating IS is implicitly advertising its originatingSNPBufferSize 159 value as Sz octets. 161 E-L1CS FS-LSPs are link-local and can also be sent up to Lz in size 162 but, for robustness, E-L1CS FS-LSP fragment zero MUST NOT exceed 1470 163 bytes. 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Type = tbd | (2 byte) 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Length = 2 | (2 byte) 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | originatingSNPBufferSize | (2 byte) 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 Figure 2.1: The originatingSNPBufferSize TLV. 175 Type: set to originatingSNPBufferSize APPsubTLV (TRILL APPsub-TLV 176 type tbd). Two bytes because this APPsub-TLV appears in an Extended 177 TLV [RFC7356]. 179 Length: set to 2. 181 originatingSNPBufferSize: the local value of 182 originatingL1SNPBufferSize as an unsigned integer, limited in the 183 range from 1470 to 65,535 bytes. (A value less than 1470 will be 184 ignored.) 186 2.1. Operations 188 Lz is reported using a originatingSNPBufferSize TLV that MUST occur 189 in fragment zero of the RBridge's E-L1CS FS-LSP. An 190 originatingSNPBufferSize APPsub-TLV occurring in any other fragment 191 is ignored. If more than one originatingSNPBufferSize APPsub-TLV 192 occurs in fragment zero, the one advertising the smallest value for 193 originatingSNPBufferSize, but not less than 1470 bytes, is used. 195 Lz:1800 Lz:1800 196 +---+ | +---+ 197 |RB1|(2000)---|---(2000)|RB2| 198 +---+ | +---+ 199 | 200 Lz:1800 | 201 +---+ +--+ 202 |RB3|(2000)---(1700)|B1| 203 +---+ +--+ 204 | 206 Figure 2.2: Link-wide Lz = 1800 v.s. tested link MTU size = 1700 208 Even if all RBridges on a specific link have reached consensus on the 209 value of link-wide Lz based on advertised originatingSNPBufferSize, 210 it does not mean that these RBridges can safely exchange PDUs between 211 each other. Figure 2.2 shows such a corner case. RB1, RB2 and RB3 are 212 three RBridges on the same link and their Lz is 1800, so the link- 213 wide Lz of this link is 1800. There is an intermediate bridge (say 214 B1) between RB2 and RB3 whose port MTU size is 1700. If RB2 sends 215 PDUs formatted in chunk of size 1800, it will be discarded by B1. 217 Therefore the link MTU size SHOULD be tested. After the link MTU size 218 of an adjacency is successfully tested, those link-local PDUs such as 219 CSNPs, PSNPs and E-L1CS FS-LSPs will be formatted no greater than the 220 tested link MTU size and will be safely transmitted on this link. 222 As for campus-wide Sz, RBridges continue to propagate their 223 originatingL1LSPBufferSize across the campus through the 224 advertisement of LSPs as defined in Section 4.3.2 of [RFC6325]. The 225 smallest value of Sz advertised by any RBridge, but not less than 226 1470, will be deemed as the campus-wide Sz. Each RBridge formats 227 their "campus-wide" PDUs, for example LSPs, not greater than what 228 they determine as the campus-wide Sz. 230 3. Link MTU Size Testing 232 [RFC7177] defines the event A6 as including "MTU test is successful" 233 if the MTU testing is enabled. As described in Section 4.3.2 of 234 [RFC6325], this is a combination of the following event and 235 condition. 237 Event: The link MTU size has been tested. 239 Condition: The link can support the campus-wide Sz. 241 This condition can be efficiently tested by the following "Binary 242 Search Algorithm" and rules. The MTU-probe and MTU-ack PDUs are 243 specified in Section 3 of [RFC7176]. 245 linkMtuSize, lowerBound, and upperBound are local integer variables. 247 Step 0: RB1 sends an MTU-probe padded to the size of link-wide Lz. 249 1) If RB1 successfully receives the MTU-ack from RB2 to the probe of 250 the value of link-wide Lz within k tries (where k is a 251 configurable parameter whose default is 3), link MTU size is set 252 to the size of link-wide Lz and stop. 254 2) RB1 tries to send an MTU-probe padded to the size 1470. 256 a) If RB1 fails to receive an MTU-ack from RB2 after k tries, RB1 257 sets the "failed minimum MTU test" flag for RB2 in RB1's Hello 258 and stop. 260 b) Link MTU size is set to 1470, lowerBound is set to 1470, 261 upperBound is set to the link-wide Lz, linkMtuSize is set to 262 [(lowerBound + upperBound)/2] (Operation "[...]" returns the 263 fraction-rounded-up integer.). 265 Step 1: RB1 tries to send an MTU-probe padded to the size 266 linkMtuSize. 268 1) If RB1 fails to receive an MTU-ack from RB2 after k tries: 270 upperBound is set to linkMtuSize and linkMtuSize is set to 271 [(lowerBound + upperBound)/2] 273 2) If RB1 receives an MTU-ack to a probe of size linkMtuSize from 274 RB2: 276 link MTU size is set to linkMtuSize, lowerBound is set to 277 linkMtuSize and linkMtuSize is set to [(lowerBound + 278 upperBound)/2] 280 3) If lowerBound >= upperBound or Step 1 has been repeated n times 281 (where n is a configurable parameter whose default value is 5), 282 stop. 284 4) Repeat Step 1. 286 MTU testing is only done in the Designated VLAN [RFC7177]. Since the 287 execution of the above algorithm can be resource consuming, it is 288 RECOMMENDED that the Designated RBRidge (DRB [RFC7177]) take the 289 responsibility to do the testing. Multicast MTU-probes are used 290 instead of unicast when multiple RBridges are desired to respond with 291 an MTU-ack on the link. The Binary Search Algorithm given here is a 292 way to minimize the probing attempts; it reduces the number of 293 multicast packets for MTU-probing. 295 The following rules are designed to determine whether the 296 aforementioned "Condition" holds. 298 RBridges have figured out the upper bound and lower bound for the 299 link MTU size from the execution of the above algorithm. If the 300 campus-wide Sz is smaller than the lower bound or greater than the 301 upper bound, RBridges can directly judge whether the link supports 302 the campus-wide Sz without MTU-probing. 304 (a) If "lowerBound" >= campus-wide Sz. This link can support campus- 305 wide Sz. 307 (b) Else if "upperBound" <= campus-wide Sz. This link cannot support 308 campus-wide Sz. 310 Otherwise, RBridges SHOULD test whether the link can support campus- 311 wide Sz as in item (c) below. If they do not, the only safe 312 assumption will be that the link cannot support Sz. This assumption, 313 without testing, might rule out the use of a link that can, in fact, 314 handle packets up to Sz. In the worst case, this might result in 315 unnecessary network partition. 317 (c) "lowerBound" < campus-wide Sz < "upperBound". RBridges probe the 318 link with MTU-probe messages padded to campus-wide Sz. If an MTU- 319 ack is received within k tries, this link can support campus-wide 320 Sz. Otherwise, this link cannot support campus-wide Sz. Through 321 this test, the lower bound and upper bound of link MTU size can 322 be updated accordingly. 324 4. Refreshing Campus-Wide Sz 326 RBridges may join or leave the campus, which may change the campus- 327 wide Sz. 329 1) Joining 331 a) When a new RBridge joins the campus and its 332 originatingL1LSPBufferSize is smaller than current campus-wide 333 Sz, reporting its originatingL1LSPBufferSize in its LSPs will 334 cause other RBridges decrease their campus-wide Sz. Then any 335 LSP greater than the reduced Sz MUST be split and/or the LSP 336 contents in the campus MUST be otherwise redistributed so that 337 no LSP is greater than the new campus-wide Sz. 339 b) If the joining RBridge's originatingL1LSPBufferSize is equal to 340 or bigger than current campus-wide Sz, reporting its 341 originatingL1LSPBufferSize will not change the campus-wide Sz. 343 2) Leaving 345 a) From the specification of the Joining process, we know it's 346 non-applicable that an RBridge leaves the campus while its 347 origiatingL1LSPBufferSize is smaller than the campus-wide Sz. 349 b) When an RBridge leaves the campus and its 350 origiatingL1LSPBufferSize equals to the campus-wide Sz, its 351 LSPs are purged from the remaining campus after reaching MaxAge 352 [IS-IS]. The campus-wide Sz MAY be recalculated and MAY 353 increase. In other words, while in most cases RB1 ignores link 354 state information for IS-IS unreachable RBridge RB2 [RFC7780], 355 originatingL1LSPBufferSize is meaningful. Its value, even from 356 IS-IS unreachable RBridges, is used in determining Sz. This 357 updates [RFC7780]. 359 c) When an RBrige leaves the campus and its 360 originatingL1LSPBufferSize is greater than the campus-wide Sz, 361 this will not update Sz since Sz is determined by another 362 RBridge with smaller originatingL1LSPBufferSize. 364 Frequent LSP "re-sizing" is harmful to the stability of the TRILL 365 campus, so, to avoid this, upward resizing SHOULD be dampened. When 366 an upward resizing event is noticed by an RBridge, it is RECOMMENDED 367 that a timer be set at that RBridge. This is a configurable 368 parameter, LSPresizeTime, whose default value is 300 seconds. Before 369 this timer expires, all subsequent upward resizing will be dampened 370 (ignored). Of course, in a well-configured campus with all RBridges 371 configured to have the same originatingL1LSPBufferSize, no resizing 372 will be necessary. It does not matter if different RBridges have 373 different dampening timers or some RBridges re-size upward more 374 quickly than others. 376 If the refreshed campus-wide Sz is smaller than the lower bound or 377 greater than the upper bound of the tested link MTU size, the 378 resource consuming link MTU size testing can be avoided according to 379 rule (a) or (b) specified in Section 3. Otherwise, RBridges test the 380 link MTU size according to rule (c). 382 5. Relationship between Port MTU, Lz and Sz 384 When the port MTU of an RBridge is smaller than the local 385 originatingL1SNPBufferSize of an RBridge (an inconsistent 386 configuration), that port SHOULD be disabled and, in any case, an 387 adjacency cannot be formed through such a port. On the other hand, 388 when an RBridge receives an LSP or E-L1CS FS-LSP with size greater 389 than the link-wide Lz or the campus-wide Sz but not greater than its 390 port MTU size, this LSP is processed normally. If the size of an LSP 391 is greater than the MTU size of a port over which it is to be 392 propagated, this LSP MUST NOT be sent over the port and an 393 LSPTooLargeToPropagate alarm shall be generated [IS-IS]. 395 6. LSP Synchronization 397 An RBridge participates in LSP synchronization on a link as soon as 398 it has at least one adjacency on that link that has advanced to at 399 least the 2-Way state [RFC7177]. On a LAN link, CSNP and PSNP PDUs 400 are used for synchronization. On a point-to-point link, only PSNP are 401 used. 403 The CSNPs and PSNPs MUST be formatted in chunks of size at most the 404 link-wide Lz but are processed normally if received larger than that. 405 Since the link MTU size may not have been tested in the 2-Way state, 406 link-wide Lz may be greater than the supported link MTU size. In that 407 case, a CSNP or PSNP may be discarded. After the link MTU size is 408 successfully tested, RBridges will begin to format these PDUs in the 409 size no greater than that MTU, therefore these PDUs will eventually 410 get through. 412 Note that the link MTU size is frequently greater than the campus- 413 wide Sz. Link-local PDUs are limited in the size by the link MTU size 414 rather than the campus-wide Sz, which, when Lz is greater than Sz, 415 promises a reduction in the number of PDUs and a faster LSP 416 synchronization process. 418 7. Recommendations for Traffic Link MTU Size Testing 420 Campus-wide Sz and link-wide Lz are used to limit the size of most 421 TRILL IS-IS PDUs. They are different from the MTU size restricting 422 the size of TRILL Data packets. The size of a TRILL Data packet is 423 restricted by the physical MTU of the ports and links the packet 424 traverses. It is possible that a TRILL Data packet successfully gets 425 through the campus but its size is greater than the campus-wide Sz or 426 link-wide Lz values. 428 The algorithm defined for link MTU size testing can also be used in 429 TRILL traffic MTU size testing; in that case the link-wide Lz used in 430 that algorithm is replaced by the port MTU of the RBridge sending MTU 431 probes. The successfully tested size X MAY be advertised as an 432 attribute of this link using MTU sub-TLV defined in [RFC7176]. 434 Unlike RBridges, end stations do not participate in the exchange of 435 TRILL IS-IS PDUs, therefore they cannot grasp the traffic link MTU 436 size from a TRILL campus automatically. An operator may collect these 437 values using network management tools such as TRILL ping or 438 TraceRoute. Then the path MTU can be set as the smallest tested link 439 MTU on this path and end stations should not generate frames that, 440 when encapsulated as TRILL Data packets, exceed this path MTU. 442 8. Backwards Compatibility 444 There can be a mixture of Lz-ignorant and Lz-aware RBridges on a 445 link. This will act properly although it may not be as efficient as 446 it would be if all RBridges on the link are Lz-aware. 448 For an Lz-ignorant RBridge, TRILL IS-IS PDUs are always formatted not 449 greater than the campus-wide Sz. Lz-aware RBridges as receivers can 450 handle these PDUs since they cannot be greater than the link-wide Lz. 452 For an Lz-aware RBridge, in the case that link-wide Lz is greater 453 than campus-wide Sz, larger link-local TRILL IS-IS PDUs can be sent 454 out to gain efficiencies. Lz-ignorant RBridges as receivers will have 455 no problem handling them since the originatingL1LSPBufferSize value 456 of these RBridges had been tested and the link-wide Lz is not greater 457 than that value. 459 An Lz-ignorant RBridge might not support the link MTU testing 460 algorithm defined in Section 3 but could be using some algorithm just 461 to test for Sz MTU on the link. In any case, if an RBridge per 462 [RFC6325] receives an MTU-probe, it MUST respond with an MTU-ack 463 padded to the same size as the MTU-probe. 465 9. Security Considerations 467 This document raises no new security issues for TRILL. For general 468 and adjacency related TRILL security considerations, see [RFC6325] 469 and [RFC7177]. 471 10. Additions to Configuration 472 Implementation of the features specified in this document adds two 473 RBridge configuration parameters as follows: 475 10.1. Per RBridge Configuration 477 Each RBridge implementing the RECOMMENDED LSP re-sizing damping 478 strategy specified in Section 4 has an LSPresizeTime parameter that 479 is an integer in the range of 0-65,535 which defaults to 300. It is 480 the number of seconds for which an RBridge determines that Sz has 481 increased before it will create any LSP or E-L1FS FS-LSP fragments. 483 10.2. Per RBridge Port Configuration 485 Each RBridge port on which the calculation and use of Lz is 486 implemented has an originatingL1SNPBufferSize parameter that is an 487 integer in the range of 1,470-65,535. This parameter defaults to the 488 minimum of the size that the port can accommodate and the size link- 489 local IS-IS PDU that the TRILL implementation can accommodate. 491 11. IANA Considerations 493 IANA is requested to assign a new APPsub-TLV number from the range 494 less than 256 in the "TRILL APPsub-TLV Types under IS-IS TLV 251 495 Application Identifier 1" registry for the TRILL 496 originatingSNPBufferSize sub-TLV defined in Section 2 of this 497 document. The entry is as follows: 499 Type Name Reference 500 ---- ------------------------ --------------- 501 tbd originatingSNPBufferSize [this document] 503 12. Acknowledgements 505 Authors would like to thank the comments and suggestions from Vishwas 506 Manral. 508 13. References 510 13.1. Normative References 512 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 513 Requirement Levels", BCP 14, RFC 2119, DOI 514 10.17487/RFC2119, March 1997, . 517 [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 518 Ghanwani, "Routing Bridges (RBridges): Base Protocol 519 Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, 520 . 522 [RFC7177] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and 523 V. Manral, "Transparent Interconnection of Lots of Links 524 (TRILL): Adjacency", RFC 7177, DOI 10.17487/RFC7177, May 525 2014, . 527 [RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, D., 528 and A. Banerjee, "Transparent Interconnection of Lots of 529 Links (TRILL) Use of IS-IS", RFC 7176, DOI 530 10.17487/RFC7176, May 2014, . 533 [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 534 Scope Link State PDUs (LSPs)", RFC 7356, DOI 535 10.17487/RFC7356, September 2014, . 538 [RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., 539 Ghanwani, A., and S. Gupta, "Transparent Interconnection of 540 Lots of Links (TRILL): Clarifications, Corrections, and 541 Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, 542 . 544 [RFC7357] Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. 545 Stokes, "Transparent Interconnection of Lots of Links 546 (TRILL): End Station Address Distribution Information 547 (ESADI) Protocol", RFC 7357, DOI 10.17487/RFC7357, 548 September 2014, . 550 13.2. Informative References 552 [IS-IS] International Organization for Standardization, 553 "Information technology -- Telecommunications and 554 information exchange between systems -- Intermediate System 555 to Intermediate System intra-domain routeing information 556 exchange protocol for use in conjunction with the protocol 557 for providing the connectionless-mode network service (ISO 558 8473)", ISO/IEC 10589:2002, Second Edition, November 2002. 560 [RFC6439bis] Eastlake 3rd, D., Yizhou, L., et al, "TRILL: Appointed 561 Forwarders", draft-ietf-trill-rfc6439bis, Work in progress. 563 Author's Addresses 565 Mingui Zhang 566 Huawei Technologies 567 No. 156 Beiqing Rd. Haidian District 568 Beijing 100095 569 China 571 Phone: +86-13810702575 572 Email: zhangmingui@huawei.com 574 Xudong Zhang 575 Huawei Technologies 576 No. 156 Beiqing Rd. Haidian District 577 Beijing 100095 578 China 580 Email: zhangxudong@huawei.com 582 Donald E. Eastlake, 3rd 583 Huawei Technologies 584 155 Beaver Street 585 Milford, MA 01757 586 United States 588 Phone: +1-508-333-2270 589 EMail: d3e3e3@gmail.com 591 Radia Perlman 592 EMC 593 2010 256th Avenue NE, #200 594 Bellevue, WA 98007 595 United States 597 Email: radia@alum.mit.edu 599 Somnath Chatterjee 600 Cisco Systems 601 SEZ Unit, Cessna Business Park 602 Outer Ring Road 603 Bangalore - 560087 604 India 606 Email: somnath.chatterjee01@gmail.com