1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
|
<pre>Internet Engineering Task Force (IETF) M. Zhang
Request for Comments: 8249 X. Zhang
Updates: <a href="./rfc6325">6325</a>, <a href="./rfc7177">7177</a>, <a href="./rfc7780">7780</a> D. Eastlake 3rd
Category: Standards Track Huawei
ISSN: 2070-1721 R. Perlman
Dell EMC
S. Chatterjee
Cisco
September 2017
<span class="h1">Transparent Interconnection of Lots of Links (TRILL):</span>
<span class="h1">MTU Negotiation</span>
Abstract
The base IETF TRILL (Transparent Interconnection of Lots of Links)
protocol has a TRILL campus-wide MTU feature, specified in RFCs 6325
and 7177, that assures that link-state changes can be successfully
flooded throughout the campus while being able to take advantage of a
campus-wide capability to support jumbo packets. This document
specifies recommended updates to that MTU feature to take advantage,
for appropriate link-local packets, of link-local MTUs that exceed
the TRILL campus MTU. In addition, it specifies an efficient
algorithm for local MTU testing. This document updates RFCs 6325,
7177, and 7780.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc7841#section-2">Section 2 of RFC 7841</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="https://www.rfc-editor.org/info/rfc8249">https://www.rfc-editor.org/info/rfc8249</a>.
<span class="grey">Zhang, et al. Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc8249">RFC 8249</a> MTU Negotiation September 2017</span>
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
<a href="#section-1.1">1.1</a>. Conventions Used in This Document ..........................<a href="#page-3">3</a>
<a href="#section-2">2</a>. Link-Wide TRILL MTU Size ........................................<a href="#page-4">4</a>
<a href="#section-2.1">2.1</a>. Operations .................................................<a href="#page-5">5</a>
<a href="#section-3">3</a>. Testing Link MTU Size ...........................................<a href="#page-6">6</a>
<a href="#section-4">4</a>. Refreshing Sz ...................................................<a href="#page-8">8</a>
<a href="#section-5">5</a>. Relationship between Port MTU, Lz, and Sz .......................<a href="#page-9">9</a>
<a href="#section-6">6</a>. LSP Synchronization ............................................<a href="#page-10">10</a>
<a href="#section-7">7</a>. Recommendations for Traffic Link Testing of MTU Size ...........<a href="#page-10">10</a>
<a href="#section-8">8</a>. Backward Compatibility .........................................<a href="#page-11">11</a>
<a href="#section-9">9</a>. Security Considerations ........................................<a href="#page-11">11</a>
<a href="#section-10">10</a>. Additions to Configuration ....................................<a href="#page-12">12</a>
<a href="#section-10.1">10.1</a>. Per-RBridge Configuration ................................<a href="#page-12">12</a>
<a href="#section-10.2">10.2</a>. Per-RBridge Port Configuration ...........................<a href="#page-12">12</a>
<a href="#section-11">11</a>. IANA Considerations ...........................................<a href="#page-12">12</a>
<a href="#section-12">12</a>. References ....................................................<a href="#page-12">12</a>
<a href="#section-12.1">12.1</a>. Normative References .....................................<a href="#page-12">12</a>
<a href="#section-12.2">12.2</a>. Informative References ...................................<a href="#page-14">14</a>
Acknowledgements ..................................................<a href="#page-14">14</a>
Authors' Addresses ................................................<a href="#page-14">14</a>
<span class="grey">Zhang, et al. Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc8249">RFC 8249</a> MTU Negotiation September 2017</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
[<a id="ref-RFC6325">RFC6325</a>] describes the way RBridges agree on the campus-wide minimum
acceptable inter-RBridge MTU (Maximum Transmission Unit) size (called
"Sz") to ensure that link-state flooding operates properly and all
RBridges converge to the same link state. For the proper operation
of TRILL (Transparent Interconnection of Lots of Links) IS-IS, all
RBridges format their Link State Protocol Data Units (LSPs) to fit
in Sz.
[<a id="ref-RFC7177">RFC7177</a>] diagrams the state transitions of an adjacency. If MTU
testing is enabled, "Link MTU size is successfully tested" is part of
an event (event A6) causing the transition from the "2-Way" state
[<a href="./rfc7177" title=""Transparent Interconnection of Lots of Links (TRILL): Adjacency"">RFC7177</a>] to the "Report" state for an adjacency. This means that
the link MTU testing of size x succeeds, and x is greater than or
equal to Sz [<a href="./rfc6325" title=""Routing Bridges (RBridges): Base Protocol Specification"">RFC6325</a>]. If this link cannot support an MTU of Sz, it
will not be reported as part of the campus topology.
In this document, a new RECOMMENDED link-wide minimum inter-RBridge
MTU size, "Lz", is specified. As further discussed in <a href="#section-2">Section 2</a>, by
calculating and using Lz as specified herein, link-scoped Protocol
Data Units (PDUs) can be formatted greater than Sz, up to the
link-wide minimum acceptable inter-RBridge MTU size, potentially
improving the efficiency of link utilization and speeding link-state
convergence.
An optional TRILL MTU size-testing algorithm is specified in
<a href="#section-3">Section 3</a> as an efficient method to update the old MTU testing method
described in <a href="./rfc6325#section-4.3.2">Section 4.3.2 of [RFC6325]</a> and in [<a href="./rfc7177" title=""Transparent Interconnection of Lots of Links (TRILL): Adjacency"">RFC7177</a>]. The new
MTU size-testing method specified in this document is backward
compatible with the old one. Multicasting the MTU-probes is
recommended when there are multiple RBridges on a link responding to
the probing with an MTU-ack [<a href="./rfc7177" title=""Transparent Interconnection of Lots of Links (TRILL): Adjacency"">RFC7177</a>]. The testing method and rules
of this document are devised in a way that minimizes the number of
MTU-probes for testing, therefore reducing the number of multicast
packets for MTU testing.
This document updates RFCs 6325, 7177, and 7780. The update to
[<a href="./rfc6325" title=""Routing Bridges (RBridges): Base Protocol Specification"">RFC6325</a>] and [<a href="./rfc7177" title=""Transparent Interconnection of Lots of Links (TRILL): Adjacency"">RFC7177</a>] is specified in <a href="#section-3">Section 3</a>. The update to
[<a href="./rfc7780" title=""Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates"">RFC7780</a>] is specified in <a href="#section-4">Section 4</a>.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Conventions Used in This Document</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
<a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>] [<a href="./rfc8174" title=""Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"">RFC8174</a>] when, and only when, they appear in all
capitals, as shown here.
<span class="grey">Zhang, et al. Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc8249">RFC 8249</a> MTU Negotiation September 2017</span>
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Link-Wide TRILL MTU Size</span>
This document specifies a new value "Lz" for the minimum acceptable
inter-RBridge link MTU size on a local link. Link-wide Lz is the
minimum Lz supported and agreed upon amongst all RBridges on a
specific link. If the link is usable, Lz will be greater than or
equal to Sz.
Some TRILL IS-IS PDUs are exchanged only between neighbors instead of
throughout the whole campus. They are confined by the link-wide Lz
instead of Sz. Complete Sequence Number PDUs (CSNPs) and Partial
Sequence Number PDUs (PSNPs) are examples of such PDUs. These PDUs
are exchanged only on the local link. (While TRILL IS-IS Hellos are
also link local, they are always limited to 1470 bytes for
robustness.)
[<a id="ref-RFC7356">RFC7356</a>] defines the PDUs that support flooding scopes in addition
to area-wide scopes and domain-wide scopes. As specified in
[<a href="./rfc8139" title=""Transparent Interconnection of Lots of Links (TRILL): Appointed Forwarders"">RFC8139</a>], RBridges support the Extended L1 Circuit Scope (E-L1CS)
Flooding Scope LSP (FS-LSP) [<a href="./rfc7780" title=""Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates"">RFC7780</a>]. The originatingSNPBufferSize
for a port is the minimum of the following two quantities but
not less than 1470 bytes: (1) the MTU of the port and (2) the maximum
LSP size that the TRILL IS-IS implementation can handle. They use
that flooding to exchange their maximum supported value of "Lz". The
smallest value of the Lz advertised by the RBridges on a link, but
not less than Sz, is the link-wide Lz. An RBridge on a local link
will be able to tell which other RBridges on that link support E-L1CS
FS-LSPs because, as required by [<a href="./rfc7780" title=""Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates"">RFC7780</a>], all RBridges include the
Scope Flooding Support TLV [<a href="./rfc7356" title=""IS-IS Flooding Scope Link State PDUs (LSPs)"">RFC7356</a>] in their TRILL Hellos.
The maximum size for a level-1 link-local PDU (such as a PSNP or
CSNP) that may be generated by a system is controlled by the value of
the management parameter originatingL1SNPBufferSize. This value
determines Lz. The TRILL APPsub-TLV shown in Figure 1 SHOULD be
included in a TRILL GENINFO TLV [<a href="./rfc7357" title=""Transparent Interconnection of Lots of Links (TRILL): End Station Address Distribution Information (ESADI) Protocol"">RFC7357</a>] in an E-L1CS FS-LSP
fragment zero. If it is missing from an E-L1CS FS-LSP fragment zero
or there is no E-L1CS FS-LSP fragment zero, it is assumed that its
originating IS is implicitly advertising its originatingSNPBufferSize
value as Sz octets.
E-L1CS FS-LSPs are link local and can also be sent up to a size of Lz
but, for robustness, E-L1CS FS-LSP fragment zero MUST NOT exceed
1470 bytes.
<span class="grey">Zhang, et al. Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc8249">RFC 8249</a> MTU Negotiation September 2017</span>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 21 | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length = 2 | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| originatingSNPBufferSize | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: The originatingSNPBufferSize APPsub-TLV
Type: Set to the originatingSNPBufferSize APPsub-TLV (TRILL
APPsub-TLV type 21). Two bytes, because this APPsub-TLV appears
in an extended TLV [<a href="./rfc7356" title=""IS-IS Flooding Scope Link State PDUs (LSPs)"">RFC7356</a>].
Length: Set to 2.
originatingSNPBufferSize: The local value of
originatingL1SNPBufferSize as an unsigned integer, limited to the
range from 1470 to 65,535 bytes. (A value less than 1470 will be
ignored.)
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Operations</span>
Lz MAY be reported using an originatingSNPBufferSize APPsub-TLV that
occurs in fragment zero of the RBridge's E-L1CS FS-LSP. An
originatingSNPBufferSize APPsub-TLV occurring in any other fragment
is ignored. If more than one originatingSNPBufferSize APPsub-TLV
occurs in fragment zero, the one advertising the smallest value for
originatingSNPBufferSize, but not less than 1470 bytes, is used.
Even if all RBridges on a specific link have reached consensus on the
value of link-wide Lz based on advertised originatingSNPBufferSize,
it does not mean that these RBridges can safely exchange PDUs between
each other. Figure 2 shows such a corner case. RB1, RB2, and RB3
are three RBridges on the same link and their Lz is 1800, so the
link-wide Lz of this link is 1800. There is an intermediate bridge
(say B1) between RB2 and RB3 whose port MTU size is 1700. If RB2
sends PDUs formatted in chunks of size 1800, those PDUs will be
discarded by B1.
<span class="grey">Zhang, et al. Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc8249">RFC 8249</a> MTU Negotiation September 2017</span>
Lz:1800 Lz:1800
+---+ | +---+
|RB1|(2000)---|---(2000)|RB2|
+---+ | +---+
|
Lz:1800 |
+---+ +--+
|RB3|(2000)---(1700)|B1|
+---+ +--+
|
Figure 2: Link-Wide Lz = 1800 vs. Tested Link MTU Size = 1700
Therefore, the link MTU size SHOULD be tested. After the link MTU
size of an adjacency is successfully tested, those link-local PDUs,
such as CSNPs, PSNPs, and E-L1CS FS-LSPs, will be formatted
no greater than the tested link MTU size and will be safely
transmitted on this link.
As for Sz, RBridges continue to propagate their
originatingL1LSPBufferSize across the campus through the
advertisement of LSPs as defined in <a href="./rfc6325#section-4.3.2">Section 4.3.2 of [RFC6325]</a>. The
smallest value of Sz advertised by any RBridge, but not less than
1470, will be deemed as Sz. Each RBridge formats their "campus-wide"
PDUs -- for example, LSPs -- no greater than what they determine
as Sz.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Testing Link MTU Size</span>
[<a id="ref-RFC7177">RFC7177</a>] defines event A6 as indicating that the MTU test was
successful if MTU testing is enabled. As described in <a href="./rfc6325#section-4.3.2">Section 4.3.2
of [RFC6325]</a>, this is a combination of the following event and
condition:
o Event: The link MTU size has been tested.
o Condition: The link can support Sz.
This condition can be efficiently tested by the following "binary
search algorithm" and rules. This updates [<a href="./rfc6325" title=""Routing Bridges (RBridges): Base Protocol Specification"">RFC6325</a>] and [<a href="./rfc7177" title=""Transparent Interconnection of Lots of Links (TRILL): Adjacency"">RFC7177</a>].
x, lowerBound, and upperBound are local integer variables. The
MTU-probe and MTU-ack PDUs are specified in <a href="./rfc7176#section-3">Section 3 of [RFC7176]</a>.
It is RECOMMENDED that one Round-Trip Time (RTT) between the two
adjacent RBridges be used as the minimum interval between two
successive probes. Note that RTT estimation is out of scope for this
document. If operators cannot estimate the RTT, the default value of
5 milliseconds should be assumed.
<span class="grey">Zhang, et al. Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc8249">RFC 8249</a> MTU Negotiation September 2017</span>
Step 0: RB1 sends an MTU-probe padded to the size of link-wide Lz.
1) If RB1 successfully receives the MTU-ack from RB2 to the probe
of the value of link-wide Lz within k tries (where k is a
configurable parameter whose default is 3), the link MTU size
is set to the size of link-wide Lz. Stop.
2) RB1 tries to send an MTU-probe padded to 1470 bytes.
a) If RB1 fails to receive an MTU-ack from RB2 after k tries
(an MTU-ack should be considered to have failed two RTTs
after the probe is sent out), RB1 sets the "failed minimum
MTU test" flag for RB2 in RB1's Hello. Stop.
b) The link MTU size is set to 1470; lowerBound is set to 1470;
upperBound is set to the link-wide Lz; x is set to
[(lowerBound + upperBound) / 2], rounded down to the nearest
integer.
Step 1: RB1 tries to send an MTU-probe padded to the size x.
1) If RB1 fails to receive an MTU-ack from RB2 after k tries:
upperBound is set to x - 1; x is set to
[(lowerBound + upperBound) / 2], rounded down to the nearest
integer.
2) If RB1 receives an MTU-ack to a probe of size x from RB2:
The link MTU size is set to x; lowerBound is set to x; x is set
to [(lowerBound + upperBound) / 2], rounded down to the nearest
integer. If lowerBound equals upperBound - 1, then x is set to
upperBound.
3) If lowerBound >= upperBound or Step 1 has been repeated n times
(where n is a configurable parameter whose default value is 5),
stop.
4) Repeat Step 1.
After the testing, the two connected RBridges agree on the value of
the link MTU size. MTU testing is only done in the Designated VLAN
[<a href="./rfc7177" title=""Transparent Interconnection of Lots of Links (TRILL): Adjacency"">RFC7177</a>]. Since the execution of the above algorithm can be
resource consuming, it is RECOMMENDED that the Designated RBridge
(DRB) [<a href="./rfc7177" title=""Transparent Interconnection of Lots of Links (TRILL): Adjacency"">RFC7177</a>] take the responsibility to do the testing. Multicast
MTU-probes are used instead of unicast when multiple RBridges are
<span class="grey">Zhang, et al. Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc8249">RFC 8249</a> MTU Negotiation September 2017</span>
desired to respond with an MTU-ack on the link. The binary search
algorithm given here is a way to minimize the probing attempts; it
reduces the number of multicast packets for MTU-probing.
The following rules are designed to determine whether the
aforementioned "Condition" holds.
RBridges have figured out the upper bound and lower bound of the link
MTU size from the execution of the above algorithm. If Sz is smaller
than the lower bound or greater than the upper bound, RBridges can
directly judge whether the link supports Sz without MTU-probing.
(a) If lowerBound >= Sz, this link can support Sz.
(b) Else if upperBound <= Sz, this link cannot support Sz.
Otherwise, RBridges SHOULD test whether the link can support Sz as in
item (c) below. If they do not, the only safe assumption will be
that the link cannot support Sz. This assumption, without testing,
might rule out the use of a link that can, in fact, handle packets up
to Sz. In the worst case, this might result in unnecessary network
partition.
(c) lowerBound < Sz < upperBound. RBridges probe the link with
MTU-probe messages padded to Sz. If an MTU-ack is received
within k tries, this link can support Sz. Otherwise, this link
cannot support Sz. Through this test, the lower bound and upper
bound of the link MTU size can be updated accordingly.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Refreshing Sz</span>
RBridges may join or leave the campus; this may change Sz.
1) Joining
a) When a new RBridge joins the campus and its
originatingL1LSPBufferSize is smaller than the current Sz,
reporting its originatingL1LSPBufferSize in its LSPs will cause
other RBridges to decrease their Sz. Then, any LSP greater
than the reduced Sz MUST be split, and/or the LSP contents in
the campus MUST be otherwise redistributed so that no LSP is
greater than the new Sz.
b) If the joining RBridge's originatingL1LSPBufferSize is greater
than or equal to the current Sz, reporting its
originatingL1LSPBufferSize will not change Sz.
<span class="grey">Zhang, et al. Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc8249">RFC 8249</a> MTU Negotiation September 2017</span>
2) Leaving
a) From the specification of the Joining process, we know that if
an RBridge's originatingL1LSPBufferSize is smaller than Sz,
this RBridge will not join this campus.
b) When an RBridge leaves the campus and its
originatingL1LSPBufferSize equals Sz, its LSPs are purged from
the remainder of the campus after reaching MaxAge [<a href="#ref-IS-IS" title=""Information technology -- Telecommunications and information exchange between systems -- Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)"">IS-IS</a>]. Sz
MAY be recalculated and MAY increase. In other words, while in
most cases RB1 ignores link-state information for IS-IS
unreachable RBridge RB2 [<a href="./rfc7780" title=""Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates"">RFC7780</a>], originatingL1LSPBufferSize
is meaningful. Its value, even from IS-IS unreachable
RBridges, is used in determining Sz. This updates [<a href="./rfc7780" title=""Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates"">RFC7780</a>].
c) When an RBridge leaves the campus and its
originatingL1LSPBufferSize is greater than Sz, Sz will not be
updated, since Sz is determined by another RBridge with a
smaller originatingL1LSPBufferSize.
Frequent LSP "resizing" is harmful to the stability of the TRILL
campus, so, to avoid this, upward resizing SHOULD be dampened. When
an upward resizing event is noticed by an RBridge, it is RECOMMENDED
that a timer be set at that RBridge via a configurable parameter --
LSPresizeTime -- whose default value is 300 seconds. Before this
timer expires, all subsequent upward resizing will be dampened
(ignored). Of course, in a well-configured campus with all RBridges
configured to have the same originatingL1LSPBufferSize, no resizing
will be necessary. It does not matter if different RBridges have
different dampening timers or if some RBridges resize upward more
quickly than others.
If the refreshed Sz is smaller than the lower bound or greater than
the upper bound of the tested link MTU size, the issue of resource
consumption from testing the link MTU size can be avoided according
to rule (a) or (b) as specified in <a href="#section-3">Section 3</a>. Otherwise, RBridges
test the link MTU size according to rule (c).
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Relationship between Port MTU, Lz, and Sz</span>
When the port MTU of an RBridge is smaller than the local
originatingL1SNPBufferSize of an RBridge (an inconsistent
configuration), that port SHOULD be disabled, since, in any case, an
adjacency cannot be formed through such a port. On the other hand,
when an RBridge receives an LSP or E-L1CS FS-LSP with size greater
than the link-wide Lz or Sz but not greater than its port MTU size,
this LSP is processed normally. If the size of an LSP is greater
<span class="grey">Zhang, et al. Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc8249">RFC 8249</a> MTU Negotiation September 2017</span>
than the MTU size of a port over which it is to be propagated, this
LSP MUST NOT be sent over the port and an LSPTooLargeToPropagate
alarm shall be generated [<a href="#ref-IS-IS" title=""Information technology -- Telecommunications and information exchange between systems -- Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)"">IS-IS</a>].
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. LSP Synchronization</span>
An RBridge participates in LSP synchronization on a link as soon as
it has at least one adjacency on that link that has advanced to at
least the 2-Way state [<a href="./rfc7177" title=""Transparent Interconnection of Lots of Links (TRILL): Adjacency"">RFC7177</a>]. On a LAN link, CSNPs and PSNPs are
used for synchronization. On a point-to-point link, only PSNPs are
used.
The CSNPs and PSNPs can be formatted in chunks of size (at most)
link-wide Lz but are processed normally if received having a larger
size. Since the link MTU size may not have been tested in the 2-Way
state, link-wide Lz may be greater than the supported link MTU size.
In that case, a CSNP or PSNP may be discarded. After the link MTU
size is successfully tested, RBridges will begin to format these PDUs
with a size no greater than that MTU; therefore, these PDUs will
eventually get through.
Note that the link MTU size is frequently greater than Sz.
Link-local PDUs are limited in size by the link MTU size rather than
Sz, which, when Lz is greater than Sz, promises a reduction in the
number of PDUs and a faster LSP synchronization process.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Recommendations for Traffic Link Testing of MTU Size</span>
Sz and link-wide Lz are used to limit the size of most TRILL IS-IS
PDUs. They are different from the MTU size restricting the size of
TRILL Data packets. The size of a TRILL Data packet is restricted by
the physical MTU of the ports and links the packet traverses. It is
possible that a TRILL Data packet successfully gets through the
campus but its size is greater than Sz or link-wide Lz values.
The algorithm defined for testing the link MTU size can also be used
in TRILL traffic MTU size testing; in that case, the link-wide Lz
used in that algorithm is replaced by the port MTU of the RBridge
sending MTU-probes. The successfully tested size x MAY be advertised
as an attribute of this link, using the MTU sub-TLV defined in
[<a href="./rfc7176" title=""Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS"">RFC7176</a>].
Unlike RBridges, end stations do not participate in the exchange of
TRILL IS-IS PDUs; therefore, they cannot grasp the traffic link MTU
size from a TRILL campus automatically. An operator may collect
these values using network management tools such as TRILL ping or
TraceRoute. Then, the path MTU can be set as the smallest tested
<span class="grey">Zhang, et al. Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc8249">RFC 8249</a> MTU Negotiation September 2017</span>
link MTU on this path, and end stations should not generate frames
that -- when encapsulated as TRILL Data packets -- exceed this
path MTU.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Backward Compatibility</span>
There can be a mixture of Lz-ignorant and Lz-aware RBridges on a
link. This configuration will behave properly, although it may
not be as efficient as it would be if all RBridges on the link are
Lz aware.
For an Lz-ignorant RBridge, TRILL IS-IS PDUs are always formatted
no greater than Sz. Lz-aware RBridges as receivers can handle these
PDUs, since they cannot be greater than the link-wide Lz.
For an Lz-aware RBridge, in the case that link-wide Lz is greater
than Sz, larger link-local TRILL IS-IS PDUs can be sent out to
increase efficiency. Lz-ignorant RBridges as receivers will have
no problem handling them, since the originatingL1LSPBufferSize value
of these RBridges had been tested and the link-wide Lz is not greater
than that value.
An Lz-ignorant RBridge might not support the link MTU size-testing
algorithm defined in <a href="#section-3">Section 3</a> but could be using some algorithm just
to test for the Sz MTU on the link. In any case, if an RBridge per
[<a href="./rfc6325" title=""Routing Bridges (RBridges): Base Protocol Specification"">RFC6325</a>] receives an MTU-probe, it MUST respond with an MTU-ack
padded to the same size as the MTU-probe.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Security Considerations</span>
This document raises no significant new security issues for TRILL.
In TRILL, RBridges are generally considered to be trusted devices.
Protection against forged TRILL IS-IS PDUs, including forged Hellos
containing originatingSNPBufferSize APPsub-TLVs, can be obtained
through IS-IS PDU cryptographic authentication [<a href="./rfc5310" title=""IS-IS Generic Cryptographic Authentication"">RFC5310</a>]. The worst
that an RBridge can do by reporting an erroneous
originatingSNPBufferSize is reduce Lz to Sz and thus make unavailable
the optimization of being able to use link MTUs that exceed the
campus-wide MTU for link-local TRILL IS-IS PDUs.
For general and adjacency-related TRILL security considerations, see
[<a href="./rfc6325" title=""Routing Bridges (RBridges): Base Protocol Specification"">RFC6325</a>] and [<a href="./rfc7177" title=""Transparent Interconnection of Lots of Links (TRILL): Adjacency"">RFC7177</a>].
<span class="grey">Zhang, et al. Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc8249">RFC 8249</a> MTU Negotiation September 2017</span>
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Additions to Configuration</span>
Implementation of the features specified in this document adds two
RBridge configuration parameters, as follows:
<span class="h3"><a class="selflink" id="section-10.1" href="#section-10.1">10.1</a>. Per-RBridge Configuration</span>
Each RBridge implementing the RECOMMENDED LSP resizing damping
strategy specified in <a href="#section-4">Section 4</a> has an LSPresizeTime parameter that
is an integer in the range of 0-65,535 and that defaults to 300. It
is the number of seconds for which an RBridge determines that Sz has
increased before it will create any LSP or E-L1FS FS-LSP fragments.
<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>. Per-RBridge Port Configuration</span>
Each RBridge port on which the calculation and use of Lz are
implemented has an originatingL1SNPBufferSize parameter that is an
integer in the range of 1470-65,535. This parameter defaults to the
minimum of the size that the port can accommodate and the link-local
IS-IS PDU size that the TRILL implementation can accommodate.
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. IANA Considerations</span>
IANA has assigned a new APPsub-TLV type for the TRILL
originatingSNPBufferSize APPsub-TLV defined in <a href="#section-2">Section 2</a> of this
document. This new type has been assigned from the range less than
256 in the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application
Identifier 1" registry. The entry is as follows:
Type Name Reference
---- ------------------------ ---------
21 originatingSNPBufferSize <a href="./rfc8249">RFC 8249</a>
<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>. References</span>
<span class="h3"><a class="selflink" id="section-12.1" href="#section-12.1">12.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>,
DOI 10.17487/RFC2119, March 1997,
<<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>>.
[<a id="ref-RFC5310">RFC5310</a>] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
and M. Fanto, "IS-IS Generic Cryptographic
Authentication", <a href="./rfc5310">RFC 5310</a>, DOI 10.17487/RFC5310,
February 2009, <<a href="https://www.rfc-editor.org/info/rfc5310">https://www.rfc-editor.org/info/rfc5310</a>>.
<span class="grey">Zhang, et al. Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc8249">RFC 8249</a> MTU Negotiation September 2017</span>
[<a id="ref-RFC6325">RFC6325</a>] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
Ghanwani, "Routing Bridges (RBridges): Base Protocol
Specification", <a href="./rfc6325">RFC 6325</a>, DOI 10.17487/RFC6325, July 2011,
<<a href="https://www.rfc-editor.org/info/rfc6325">https://www.rfc-editor.org/info/rfc6325</a>>.
[<a id="ref-RFC7176">RFC7176</a>] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt,
D., and A. Banerjee, "Transparent Interconnection of Lots
of Links (TRILL) Use of IS-IS", <a href="./rfc7176">RFC 7176</a>,
DOI 10.17487/RFC7176, May 2014,
<<a href="https://www.rfc-editor.org/info/rfc7176">https://www.rfc-editor.org/info/rfc7176</a>>.
[<a id="ref-RFC7177">RFC7177</a>] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and
V. Manral, "Transparent Interconnection of Lots of Links
(TRILL): Adjacency", <a href="./rfc7177">RFC 7177</a>, DOI 10.17487/RFC7177,
May 2014, <<a href="https://www.rfc-editor.org/info/rfc7177">https://www.rfc-editor.org/info/rfc7177</a>>.
[<a id="ref-RFC7356">RFC7356</a>] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding
Scope Link State PDUs (LSPs)", <a href="./rfc7356">RFC 7356</a>,
DOI 10.17487/RFC7356, September 2014,
<<a href="https://www.rfc-editor.org/info/rfc7356">https://www.rfc-editor.org/info/rfc7356</a>>.
[<a id="ref-RFC7357">RFC7357</a>] Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O.
Stokes, "Transparent Interconnection of Lots of Links
(TRILL): End Station Address Distribution Information
(ESADI) Protocol", <a href="./rfc7357">RFC 7357</a>, DOI 10.17487/RFC7357,
September 2014, <<a href="https://www.rfc-editor.org/info/rfc7357">https://www.rfc-editor.org/info/rfc7357</a>>.
[<a id="ref-RFC7780">RFC7780</a>] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A.,
Ghanwani, A., and S. Gupta, "Transparent Interconnection
of Lots of Links (TRILL): Clarifications, Corrections, and
Updates", <a href="./rfc7780">RFC 7780</a>, DOI 10.17487/RFC7780, February 2016,
<<a href="https://www.rfc-editor.org/info/rfc7780">https://www.rfc-editor.org/info/rfc7780</a>>.
[<a id="ref-RFC8174">RFC8174</a>] Leiba, B., "Ambiguity of Uppercase vs Lowercase in
<a href="./rfc2119">RFC 2119</a> Key Words", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc8174">RFC 8174</a>,
DOI 10.17487/RFC8174, May 2017,
<<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>>.
<span class="grey">Zhang, et al. Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc8249">RFC 8249</a> MTU Negotiation September 2017</span>
<span class="h3"><a class="selflink" id="section-12.2" href="#section-12.2">12.2</a>. Informative References</span>
[<a id="ref-IS-IS">IS-IS</a>] International Organization for Standardization,
"Information technology -- Telecommunications and
information exchange between systems -- Intermediate
System to Intermediate System intra-domain routeing
information exchange protocol for use in conjunction with
the protocol for providing the connectionless-mode network
service (ISO 8473)", ISO/IEC 10589:2002, Second Edition,
November 2002.
[<a id="ref-RFC8139">RFC8139</a>] Eastlake 3rd, D., Li, Y., Umair, M., Banerjee, A., and F.
Hu, "Transparent Interconnection of Lots of Links (TRILL):
Appointed Forwarders", <a href="./rfc8139">RFC 8139</a>, DOI 10.17487/RFC8139,
June 2017, <<a href="https://www.rfc-editor.org/info/rfc8139">https://www.rfc-editor.org/info/rfc8139</a>>.
Acknowledgements
The authors would like to thank Vishwas Manral for his comments and
suggestions.
Authors' Addresses
Mingui Zhang
Huawei Technologies
No. 156 Beiqing Rd. Haidian District
Beijing 100095
China
Phone: +86-13810702575
Email: zhangmingui@huawei.com
Xudong Zhang
Huawei Technologies
No. 156 Beiqing Rd. Haidian District
Beijing 100095
China
Email: zhangxudong@huawei.com
<span class="grey">Zhang, et al. Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc8249">RFC 8249</a> MTU Negotiation September 2017</span>
Donald Eastlake 3rd
Huawei Technologies
155 Beaver Street
Milford, MA 01757
United States of America
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
Radia Perlman
Dell EMC
505 1st Ave South
Seattle, WA 98104
United States of America
Email: radia@alum.mit.edu
Somnath Chatterjee
Cisco Systems
SEZ Unit, Cessna Business Park
Outer Ring Road
Bangalore 560087
India
Email: somnath.chatterjee01@gmail.com
Zhang, et al. Standards Track [Page 15]
</pre>
|
