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
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
|
<pre>Internet Engineering Task Force (IETF) L. Ginsberg
Request for Comments: 7356 S. Previdi
Category: Standards Track Y. Yang
ISSN: 2070-1721 Cisco Systems
September 2014
<span class="h1">IS-IS Flooding Scope Link State PDUs (LSPs)</span>
Abstract
Intermediate System to Intermediate System (IS-IS) provides efficient
and reliable flooding of information to its peers; however, the
current flooding scopes are limited to either area scope or domain
scope. There are existing use cases where support of other flooding
scopes is desirable. This document defines new Protocol Data Units
(PDUs) that provide support for new flooding scopes as well as
additional space for advertising information targeted for the
currently supported flooding scopes. This document also defines
extended Type-Length-Values (TLVs) and sub-TLVs that are encoded
using 16-bit fields for Type and Length.
The protocol extensions defined in this document are not backwards
compatible with existing implementations and so must be deployed with
care.
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="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc7356">http://www.rfc-editor.org/info/rfc7356</a>.
<span class="grey">Ginsberg, 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="./rfc7356">RFC 7356</a> IS-IS Flooding Scope LSPs September 2014</span>
Copyright Notice
Copyright (c) 2014 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="http://trustee.ietf.org/license-info">http://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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
<span class="grey">Ginsberg, 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="./rfc7356">RFC 7356</a> IS-IS Flooding Scope LSPs September 2014</span>
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-1.1">1.1</a>. Requirements Language . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-2">2</a>. Extended TLVs . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-2.1">2.1</a>. Use of Extended TLVs and Extended Sub-TLVs . . . . . . . <a href="#page-5">5</a>
2.2. Use of Standard Code Points in Extended TLVs and Extended
Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-3">3</a>. Definition of New PDUs . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-3.1">3.1</a>. Flooding Scoped LSP Format . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-3.2">3.2</a>. Flooding Scoped CSNP Format . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-3.3">3.3</a>. Flooding Scope PSNP Format . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-4">4</a>. Flooding Scope Update Process Operation . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-4.1">4.1</a>. Scope Types . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-4.2">4.2</a>. Operation on Point-to-Point Circuits . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-4.3">4.3</a>. Operation on Broadcast Circuits . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-4.4">4.4</a>. Use of Authentication . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-4.5">4.5</a>. Priority Flooding . . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-5">5</a>. Deployment Considerations . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-6">6</a>. Graceful Restart Interactions . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-7">7</a>. Multi-instance Interactions . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-8">8</a>. Circuit Scope Flooding . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-9">9</a>. Extending LSP Set Capacity . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
<a href="#section-10">10</a>. Domain Scope Flooding . . . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
<a href="#section-11">11</a>. Announcing Support for Flooding Scopes . . . . . . . . . . . <a href="#page-19">19</a>
<a href="#section-12">12</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-20">20</a>
<a href="#section-13">13</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-21">21</a>
<a href="#section-14">14</a>. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . <a href="#page-21">21</a>
<a href="#section-15">15</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-21">21</a>
<a href="#section-15.1">15.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-21">21</a>
<a href="#section-15.2">15.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-22">22</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The Update Process, as defined by [<a href="#ref-IS-IS" title=""Information technology -- Telecommunications and information exchange between systems -- Intermediate System to Intermediate System intradomain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)"">IS-IS</a>], provides reliable and
efficient flooding of information to all routers in a given flooding
scope. Currently, the protocol supports two flooding scopes and
associated PDUs. Level 1 (L1) Link State PDUs (LSPs) are flooded to
all routers in an area. Level 2 (L2) LSPs are flooded to all routers
in the Level 2 subdomain. The basic operation of the Update Process
can be applied to any subset of the routers in a given topology so
long as that topology is not partitioned. It is, therefore, possible
to introduce new PDUs in support of other flooding scopes and utilize
the same Update Process machinery to provide the same reliability and
efficiency that the Update Process currently provides for L1 and L2
scopes. This document defines these new PDUs and the modified Update
Process rules that are to be used in supporting new flooding scopes.
<span class="grey">Ginsberg, 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="./rfc7356">RFC 7356</a> IS-IS Flooding Scope LSPs September 2014</span>
New deployment cases have introduced the need for reliable and
efficient circuit scope flooding. For example, Appointed Forwarder
information, as defined in [<a href="./rfc7176" title=""Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS"">RFC7176</a>], needs to be flooded reliably
and efficiently to all Routing Bridges (RBridges) on a broadcast
circuit. Currently, only IS-IS Hellos (IIHs) have the matching scope
-- but IIHs are unreliable, i.e., individual IIHs may be lost without
affecting correct operation of the protocol. To provide reliability
in cases where the set of information to be flooded exceeds the
carrying capacity of a single PDU requires sending the information
periodically even when no changes in the content have occurred. When
the information content is large, this is inefficient and still does
not provide a guarantee of reliability. This document defines
circuit scope flooding in order to provide a solution for such cases.
Another existing limitation of [<a href="#ref-IS-IS" title=""Information technology -- Telecommunications and information exchange between systems -- Intermediate System to Intermediate System intradomain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)"">IS-IS</a>] is the carrying capacity of an
LSP set. It has been noted in [<a href="./rfc5311" title=""Simplified Extension of Link State PDU (LSP) Space for IS-IS"">RFC5311</a>] that the set of LSPs that
may be originated by a system at each level is limited to 256 LSPs,
and the maximum size of each LSP is limited by the minimum Maximum
Transmission Unit (MTU) of any link used to flood LSPs. [<a href="./rfc5311" title=""Simplified Extension of Link State PDU (LSP) Space for IS-IS"">RFC5311</a>]
has defined a backwards-compatible protocol extension that can be
used to overcome this limitation if needed. While the [<a href="./rfc5311" title=""Simplified Extension of Link State PDU (LSP) Space for IS-IS"">RFC5311</a>]
solution is viable, in order to be interoperable with routers that do
not support the extension, it imposes some restrictions on what can/
cannot be advertised in the Extended LSPs and requires allocation of
multiple unique system IDs to a given router. A more flexible and
less constraining solution is possible if interoperability with
legacy routers is not a requirement. By definition, the introduction
of new PDUs required to support new flooding scopes is not
interoperable with legacy routers. It is, therefore, possible to
simultaneously introduce an alternative solution to the limited LSP
set carrying capacity of Level 1 and Level 2 LSPs as part of the
extensions defined in this document. This capability is also defined
in this document.
Standard IS-IS TLVs are encoded using an 8-bit type and an 8-bit
length. In cases where the set of information about a single object
exceeds 255 octets, multiple TLVs are required to encode all of the
relevant information. This document introduces extended TLVs and
extended sub-TLVs that use a 16-bit Type field and a 16-bit Length
field.
The PDU Type field in the common header for all IS-IS PDUs is a 5-bit
field. Therefore, possible PDU types supported by the protocol are
limited to a maximum of 32. In order to minimize the need to
introduce additional PDU types in the future, the new PDUs introduced
in this document are defined so as to allow multiple flooding scopes
to be associated with the same PDU type. This means if new flooding
scopes are required in the future, the same PDU type can be used.
<span class="grey">Ginsberg, 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="./rfc7356">RFC 7356</a> IS-IS Flooding Scope LSPs September 2014</span>
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Requirements Language</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Extended TLVs</span>
Standard TLVs as defined in [<a href="#ref-IS-IS" title=""Information technology -- Telecommunications and information exchange between systems -- Intermediate System to Intermediate System intradomain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)"">IS-IS</a>] as well as standard sub-TLVs
(first introduced in [<a href="./rfc5305" title=""IS-IS Extensions for Traffic Engineering"">RFC5305</a>]) have an 8-bit Type field and an
eight-bit Length field. This constrains the information included in
a single TLV or sub-TLV to 255 octets. With the increasing use of
sub-TLVs, it becomes more likely that the amount of information about
a single object that needs to be advertised may exceed 255 octets.
In such cases, the information is encoded in multiple TLVs. This
leads to less efficient encoding since the information that uniquely
identifies the object must be repeated in each TLV and requires
additional implementation complexity when receiving the information
to ensure that all information about the object is correctly
collected from the multiple TLVs.
This document introduces extended TLVs and extended sub-TLVs. These
are encoded using a 16-bit Type field and a 16-bit Length field.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Use of Extended TLVs and Extended Sub-TLVs</span>
The following restrictions apply to the use of extended TLVs and
extended sub-TLVs:
o Extended TLVs and extended sub-TLVs are permitted only in Flooding
Scope PDUs that have a flooding scope designated for their use
(defined later in this document)
o A given flooding scope supports either the use of standard TLVs
and standard sub-TLVs or the use of extended TLVs and extended
sub-TLVs, but not both
o Extended TLVs and extended sub-TLVs MUST be used together, i.e.,
using Standard sub-TLVs within an Extended TLV or using Extended
sub-TLVs within a Standard TLV is invalid
o If additional levels of TLVs (e.g., sub-sub-TLVs) are introduced
in the future, then the size of the Type and Length fields in
these new sub-types MUST match the size used in the parent
o The 16-bit Type and Length fields are encoded in network byte
order
<span class="grey">Ginsberg, 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="./rfc7356">RFC 7356</a> IS-IS Flooding Scope LSPs September 2014</span>
o Use of extended TLVs and extended sub-TLVs does not alter in any
way the maximum size of PDUs that may sent or received
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Use of Standard Code Points in Extended TLVs and Extended Sub-TLVs</span>
Standard TLV and standard sub-TLV code points as defined in the IANA
"IS-IS TLV Codepoints" registry MAY be used in extended TLVs and
extended sub-TLVs. Encoding is as specified for each of the standard
TLVs and standard sub-TLVs with the following differences:
o The 8-bit Type field is encoded as an unsigned 16-bit integer
where the 8 most significant bits (MSBs) are all 0
o The 8-bit Length field is replaced by the 16-bit Length field
o The length MAY take on values greater than 255
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Definition of New PDUs</span>
In support of new flooding scopes, the following new PDUs are
required:
o Flooding Scope LSPs (FS-LSPs)
o Flooding Scope Complete Sequence Number PDUs (FS-CSNPs)
o Flooding Scope Partial Sequence Number PDUs (FS-PSNPs)
Each of these PDUs is intentionally defined with a header as similar
in format as possible to the corresponding PDU types currently
defined in [<a href="#ref-IS-IS" title=""Information technology -- Telecommunications and information exchange between systems -- Intermediate System to Intermediate System intradomain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)"">IS-IS</a>]. Although it might have been possible to
eliminate or redefine PDU header fields in a new way, the existing
formats are retained in order to allow maximum reuse of existing PDU
processing logic in an implementation.
Note that in the case of all FS PDUs, the Maximum Area Addresses
field in the header of the corresponding standard PDU has been
replaced with a Scope field. Therefore, maximum area addresses
checks specified in [<a href="#ref-IS-IS" title=""Information technology -- Telecommunications and information exchange between systems -- Intermediate System to Intermediate System intradomain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)"">IS-IS</a>] are not performed on FS PDUs.
<span class="grey">Ginsberg, 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="./rfc7356">RFC 7356</a> IS-IS Flooding Scope LSPs September 2014</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Flooding Scoped LSP Format</span>
An FS-LSP has the following format:
No. of octets
+-------------------------+
| Intradomain Routeing | 1
| Protocol Discriminator |
+-------------------------+
| Length Indicator | 1
+-------------------------+
| Version/Protocol ID | 1
| Extension |
+-------------------------+
| ID Length | 1
+-------------------------+
|R|R|R| PDU Type | 1
+-------------------------+
| Version | 1
+-------------------------+
| Reserved | 1
+-------------------------+
|P| Scope | 1
+-------------------------+
| PDU Length | 2
+-------------------------+
| Remaining Lifetime | 2
+-------------------------+
| FS LSP ID | ID Length + 2
+-------------------------+
| Sequence Number | 4
+-------------------------+
| Checksum | 2
+-------------------------+
|Reserved|LSPDBOL|IS Type | 1
+-------------------------+
: Variable-Length Fields : Variable
+-------------------------+
Intradomain Routeing Protocol Discriminator: 0x83 (as defined in
[<a href="#ref-IS-IS" title=""Information technology -- Telecommunications and information exchange between systems -- Intermediate System to Intermediate System intradomain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)"">IS-IS</a>]).
Length Indicator: Length of the fixed header in octets.
Version/Protocol ID Extension: 1
ID Length: As defined in [<a href="#ref-IS-IS" title=""Information technology -- Telecommunications and information exchange between systems -- Intermediate System to Intermediate System intradomain 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="grey">Ginsberg, 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="./rfc7356">RFC 7356</a> IS-IS Flooding Scope LSPs September 2014</span>
PDU Type: 10 - Format as defined in [<a href="#ref-IS-IS" title=""Information technology -- Telecommunications and information exchange between systems -- Intermediate System to Intermediate System intradomain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)"">IS-IS</a>].
Version: 1
Reserved: Transmitted as zero, ignored on receipt.
Scope: Bits 1-7 define the flooding scope.
The value 0 is reserved and MUST NOT be used. Received FS-LSPs
with a scope of 0 MUST be ignored and MUST NOT be flooded.
P: Bit 8 - Priority Bit. If set to 1, this LSP SHOULD be
flooded at high priority.
Scopes (1 - 63) are reserved for use with standard TLVs and
standard sub-TLVs.
Scopes (64 - 127) are reserved for use with extended TLVs and
extended sub-TLVs.
PDU Length: Entire length of this PDU, in octets, including the
header.
Remaining Lifetime: Number of seconds before this FS-LSP is
considered expired.
FS LSP ID: The system ID of the source of the FS-LSP. One of the
following two formats is used:
FS LSP ID Standard Format
+-------------------------+
| Source ID | ID Length
+-------------------------+
| Pseudonode ID | 1
+-------------------------+
| FS LSP Number | 1
+-------------------------+
FS LSP ID Extended Format
+-------------------------+
| Source ID | ID Length
+-------------------------+
| Extended FS LSP Number | 2
+-------------------------+
<span class="grey">Ginsberg, 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="./rfc7356">RFC 7356</a> IS-IS Flooding Scope LSPs September 2014</span>
Which format is used is specific to the scope and MUST be defined
when the specific flooding scope is defined.
Sequence Number: Sequence number of this FS-LSP.
Checksum: Checksum of contents of FS-LSP from the Source ID to the
end. Checksum is computed as defined in [<a href="#ref-IS-IS" title=""Information technology -- Telecommunications and information exchange between systems -- Intermediate System to Intermediate System intradomain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)"">IS-IS</a>].
Reserved/LSPDBOL/IS Type
Bits 4-8 are reserved, which means they are transmitted as 0
and ignored on receipt.
LSPDBOL: Bit 3 - A value of 0 indicates no FS-LSP Database
Overload and a value of 1 indicates that the FS-LSP Database is
overloaded. The overload condition is specific to FS-LSPs with
the scope specified in the Scope field.
IS Type: Bits 1 and 2. The type of Intermediate System as
defined in [<a href="#ref-IS-IS" title=""Information technology -- Telecommunications and information exchange between systems -- Intermediate System to Intermediate System intradomain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)"">IS-IS</a>].
Variable-length fields that are allowed in an FS-LSP are specific
to the defined scope.
<span class="grey">Ginsberg, 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="./rfc7356">RFC 7356</a> IS-IS Flooding Scope LSPs September 2014</span>
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Flooding Scoped CSNP Format</span>
An FS-CSNP has the following format:
No. of octets
+-------------------------+
| Intradomain Routeing | 1
| Protocol Discriminator |
+-------------------------+
| Length Indicator | 1
+-------------------------+
| Version/Protocol ID | 1
| Extension |
+-------------------------+
| ID Length | 1
+-------------------------+
|R|R|R| PDU Type | 1
+-------------------------+
| Version | 1
+-------------------------+
| Reserved | 1
+-------------------------+
|R| Scope | 1
+-------------------------+
| PDU Length | 2
+-------------------------+
| Source ID | ID Length + 1
+-------------------------+
| Start FS-LSP ID | ID Length + 2
+-------------------------+
| End FS-LSP ID | ID Length + 2
+-------------------------+
: Variable-Length Fields : Variable
+-------------------------+
Intradomain Routeing Protocol Discriminator: 0x83 (as defined in
[<a href="#ref-IS-IS" title=""Information technology -- Telecommunications and information exchange between systems -- Intermediate System to Intermediate System intradomain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)"">IS-IS</a>]).
Length Indicator: Length of the fixed header in octets.
Version/Protocol ID Extension: 1
ID Length: As defined in [<a href="#ref-IS-IS" title=""Information technology -- Telecommunications and information exchange between systems -- Intermediate System to Intermediate System intradomain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)"">IS-IS</a>].
PDU Type: 11 - Format as defined in [<a href="#ref-IS-IS" title=""Information technology -- Telecommunications and information exchange between systems -- Intermediate System to Intermediate System intradomain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)"">IS-IS</a>].
Version: 1
<span class="grey">Ginsberg, 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="./rfc7356">RFC 7356</a> IS-IS Flooding Scope LSPs September 2014</span>
Reserved: Transmitted as zero, ignored on receipt.
Scope: Bits 1-7 define the flooding scope.
The value 0 is reserved and MUST NOT be used. Received FS-
CSNPs with a scope of 0 MUST be ignored.
Bit 8 is Reserved, which means it is transmitted as 0 and
ignored on receipt.
Scopes (1 - 63) are reserved for use with standard TLVs and
standard sub-TLVs.
Scopes (64 - 127) are reserved for use with extended TLV and
extended sub-TLVs.
PDU Length: Entire length of this PDU, in octets, including the
header.
Source ID: The system ID of the Intermediate System (with zero
Circuit ID) generating this Sequence Number's PDU.
Start FS-LSP ID: The FS-LSP ID of the first FS-LSP with the
specified scope in the range covered by this FS-CSNP.
End FS-LSP ID: The FS-LSP ID of the last FS-LSP with the specified
scope in the range covered by this FS-CSNP.
Variable-length fields that are allowed in an FS-CSNP are limited
to those TLVs that are supported by standard CSNP.
<span class="grey">Ginsberg, 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="./rfc7356">RFC 7356</a> IS-IS Flooding Scope LSPs September 2014</span>
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Flooding Scope PSNP Format</span>
An FS-PSNP has the following format:
No. of octets
+-------------------------+
| Intradomain Routeing | 1
| Protocol Discriminator |
+-------------------------+
| Length Indicator | 1
+-------------------------+
| Version/Protocol ID | 1
| Extension |
+-------------------------+
| ID Length | 1
+-------------------------+
|R|R|R| PDU Type | 1
+-------------------------+
| Version | 1
+-------------------------+
| Reserved | 1
+-------------------------+
|U| Scope | 1
+-------------------------+
| PDU Length | 2
+-------------------------+
| Source ID | ID Length + 1
+-------------------------+
: Variable-Length Fields : Variable
+-------------------------+
Intradomain Routeing Protocol Discriminator: 0x83 (as defined in
[<a href="#ref-IS-IS" title=""Information technology -- Telecommunications and information exchange between systems -- Intermediate System to Intermediate System intradomain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)"">IS-IS</a>]).
Length Indicator: Length of the fixed header in octets.
Version/Protocol ID Extension: 1
ID Length: As defined in [<a href="#ref-IS-IS" title=""Information technology -- Telecommunications and information exchange between systems -- Intermediate System to Intermediate System intradomain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)"">IS-IS</a>].
PDU Type: 12 - Format as defined in [<a href="#ref-IS-IS" title=""Information technology -- Telecommunications and information exchange between systems -- Intermediate System to Intermediate System intradomain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)"">IS-IS</a>].
Version: 1
Reserved: Transmitted as zero, ignored on receipt.
<span class="grey">Ginsberg, 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="./rfc7356">RFC 7356</a> IS-IS Flooding Scope LSPs September 2014</span>
Scope: Bits 1-7 define the flooding scope.
The value 0 is reserved and MUST NOT be used. Received FS-
PSNPs with a scope of 0 MUST be ignored.
U: Bit 8 - A value of 0 indicates that the specified flooding
scope is supported. A value of 1 indicates that the specified
flooding scope is unsupported. When U = 1, variable-length
fields other than authentication MUST NOT be included in the
PDU.
Scopes (1 - 63) are reserved for use with standard TLVs and
standard sub-TLVs.
Scopes (64 - 127) are reserved for use with extended TLVs and
extended sub-TLVs.
PDU Length: Entire length of this PDU, in octets, including the
header.
Source ID: The system ID of the Intermediate System (with zero
Circuit ID) generating this Sequence Number's PDU.
Variable-length fields that are allowed in an FS-PSNP are limited
to those TLVs that are supported by standard PSNPs.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Flooding Scope Update Process Operation</span>
The Update Process, as defined in [<a href="#ref-IS-IS" title=""Information technology -- Telecommunications and information exchange between systems -- Intermediate System to Intermediate System intradomain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)"">IS-IS</a>], maintains a Link State
Database (LSDB) for each level supported. Each level-specific LSDB
contains the full set of LSPs generated by all routers operating in
that level-specific scope. The introduction of FS-LSPs creates
additional LSDBs (FS-LSDBs) for each additional scope supported. The
set of FS-LSPs in each FS-LSDB consists of all FS-LSPs generated by
all routers operating in that scope. Therefore, there is an
additional instance of the Update Process for each supported flooding
scope.
Operation of the scope-specific Update Process follows the Update
Process specification in [<a href="#ref-IS-IS" title=""Information technology -- Telecommunications and information exchange between systems -- Intermediate System to Intermediate System intradomain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)"">IS-IS</a>]. The circuit(s) on which FS-LSPs
are flooded is limited to those circuits that are participating in
the given scope. Similarly, the sending/receiving of FS-CSNPs and
FS-PSNPs is limited to the circuits participating in the given scope.
Consistent support of a given flooding scope on a circuit by all
routers operating on that circuit is required.
<span class="grey">Ginsberg, 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="./rfc7356">RFC 7356</a> IS-IS Flooding Scope LSPs September 2014</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Scope Types</span>
A flooding scope may be limited to a single circuit (circuit scope).
Circuit scopes may be further limited by level (L1 Circuit Scope / L2
Circuit Scope).
A flooding scope may be limited to all circuits enabled for L1
routing (area scope).
A flooding scope may be limited to all circuits enabled for L2
routing (L2 subdomain scope).
Additional scopes may be defined that include all circuits enabled
for either L1 or L2 routing (domain scope).
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Operation on Point-to-Point Circuits</span>
When a new adjacency is formed, synchronization of all FS-LSDBs
supported on that circuit is required; therefore, FS-CSNPs for all
supported scopes MUST be sent when a new adjacency reaches the UP
state. The Send Receive Message (SRM) bit MUST be set for all
FS-LSPs associated with the scopes supported on that circuit.
Receipt of an FS-PSNP with the U bit equal to 1 indicates that the
neighbor does not support that scope (although it does support FS
PDUs). This MUST cause the SRM bit to be cleared for all FS-LSPs
with the matching scope, which are currently marked for flooding on
that circuit.
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. Operation on Broadcast Circuits</span>
FS PDUs are sent to the same destination address(es) as standard PDUs
for the given protocol instance. For specification of the defined
destination addresses, consult [<a href="#ref-IS-IS" title=""Information technology -- Telecommunications and information exchange between systems -- Intermediate System to Intermediate System intradomain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)"">IS-IS</a>], [<a href="#ref-IEEEaq" title=""Standard for Local and metropolitan area networks -- Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks -- Amendment 20: Shortest Path Bridging"">IEEEaq</a>], [<a href="./rfc6822" title=""IS-IS Multi-Instance"">RFC6822</a>], and
[<a href="./rfc6325" title=""Routing Bridges (RBridges): Base Protocol Specification"">RFC6325</a>].
The Designated Intermediate System (DIS) for a broadcast circuit has
the responsibility to generate periodic scope-specific FS-CSNPs for
all supported scopes. A scope-specific DIS is NOT elected as all
routers on a circuit MUST support a consistent set of flooding
scopes.
It is possible that a scope may be defined that is not level
specific. In such a case, the DIS for each level enabled on a
broadcast circuit MUST independently send FS PDUs for that scope to
the appropriate level-specific destination address. This may result
in redundant flooding of FS-LSPs for that scope.
<span class="grey">Ginsberg, 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="./rfc7356">RFC 7356</a> IS-IS Flooding Scope LSPs September 2014</span>
<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>. Use of Authentication</span>
Authentication TLVs MAY be included in FS PDUs. When authentication
is in use, the scope is first used to select the authentication
configuration that is applicable. The authentication check is then
performed as normal. Although scope-specific authentication MAY be
used, sharing of authentication among multiple scopes and/or with the
standard LSPs/CSNPs/PSNPs is considered sufficient.
<span class="h3"><a class="selflink" id="section-4.5" href="#section-4.5">4.5</a>. Priority Flooding</span>
When the FS LSP ID Extended format is used, the set of LSPs generated
by an IS may be quite large. It may be useful to identify those LSPs
in the set that contain information of higher priority. Such LSPs
will have the P bit set to 1 in the Scope field in the LSP header.
Such LSPs SHOULD be flooded at a higher priority than LSPs with the P
bit set to 0. This is a suggested behavior on the part of the
originator of the LSP. When an LSP is purged, the original state of
the P bit MUST be preserved.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Deployment Considerations</span>
Introduction of new PDU types is incompatible with legacy
implementations. Legacy implementations do not support the
FS-specific Update process(es) and, therefore, flooding of the
FS-LSPs throughout the defined scope is unreliable when not all
routers in the defined scope support FS PDUs. Further, legacy
implementations will likely treat the reception of an FS PDU as an
error. Even when all routers in a given scope support FS PDUs, if
not all routers in the flooding domain for a given scope support that
scope, then flooding of the FS-LSPs may be compromised. When
deploying a new flooding scope, correct operation therefore requires
that both FS PDUs and the new scope be supported by all routers in
the flooding domain of the new scope.
The U bit in FS-PSNPs provides a means to suppress retransmissions of
unsupported scopes. Routers that support FS PDUs SHOULD support the
sending of PSNPs with the U bit equal to 1 when an FS-LSP is received
with a scope that is unsupported. Routers that support FS PDUs
SHOULD trigger management notifications when FS PDUs are received for
unsupported scopes and when PSNPs with the U bit equal to 1 are
received.
<span class="grey">Ginsberg, et al. Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc7356">RFC 7356</a> IS-IS Flooding Scope LSPs September 2014</span>
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Graceful Restart Interactions</span>
[<a id="ref-RFC5306">RFC5306</a>] defines protocol extensions in support of graceful restart
of a routing instance. Synchronization of all supported FS-LSDBs is
required in order for database synchronization to be complete. This
involves the use of additional T2 timers. Receipt of a PSNP with the
U bit equal to 1 will cause FS-LSDB synchronization with that
neighbor to be considered complete for that scope. See [<a href="./rfc5306" title=""Restart Signaling for IS-IS"">RFC5306</a>] for
further details.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Multi-instance Interactions</span>
In cases where FS-PDUs are associated with a non-zero instance, the
use of Instance Identifier TLVs (IID-TLVs) in FS-PDUs follows the
rules for use in LSPs, CSNPs, and PSNPs as defined in [<a href="./rfc6822" title=""IS-IS Multi-Instance"">RFC6822</a>].
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Circuit Scope Flooding</span>
This document defines four circuit scope flooding identifiers:
o Level 1 Circuit Scope (L1CS) -- this uses standard TLVs and
standard sub-TLVs
o Level 2 Circuit Scope (L2CS) -- this uses standard TLVs and
standard sub-TLVs
o Extended Level 1 Circuit Scope (E-L1CS) -- this uses extended TLVs
and extended sub-TLVs
o Extended Level 2 Circuit Scope (E-L2CS) -- this uses extended TLVs
and extended sub-TLVs
FS-LSPs with the Scope field set to one of these values contain
information specific to the circuit on which they are flooded. When
received, such FS-LSPs MUST NOT be flooded on any other circuit. The
FS LSP ID Extended format is used in these PDUs. The FS-LSDB
associated with circuit scope FS-LSPs consists of the set of FS-LSPs
that both have matching circuit scopes and are transmitted (locally
generated) or received on a specific circuit.
The set of TLVs that may be included in such FS-LSPs is specific to
the given use case and is outside the scope of this document.
<span class="grey">Ginsberg, et al. Standards Track [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc7356">RFC 7356</a> IS-IS Flooding Scope LSPs September 2014</span>
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Extending LSP Set Capacity</span>
The need for additional space in the set of LSPs generated by a
single IS has been articulated in [<a href="./rfc5311" title=""Simplified Extension of Link State PDU (LSP) Space for IS-IS"">RFC5311</a>]. When legacy
interoperability is not a requirement, the use of FS-LSPs meets that
need without requiring the assignment of alias system-ids to a single
IS. Four flooding scopes are defined for this purpose:
o Level 1 Flooding Scope (L1FS) -- this uses standard TLVs and
standard sub-TLVs
o Level 2 Flooding Scope (L2FS) -- this uses standard TLVs and
standard sub-TLVs
o Extended Level 1 Flooding Scope (E-L1FS) -- this uses extended
TLVs and extended sub-TLVs
o Extended Level 2 Flooding Scope (E-L2FS) -- this uses extended
TLVs and extended sub-TLVs
L1FS and E-L1FS LSPs are flooded on all L1 circuits. L2FS and E-L2FS
LSPs are flooded on all L2 circuits.
The FS LSP ID Extended format is used in these PDUs. This provides
64 K of additional LSPs that may be generated by a single system at
each level.
LxFS and E-LxFS LSPs are used by the level-specific Decision Process
(defined in [<a href="#ref-IS-IS" title=""Information technology -- Telecommunications and information exchange between systems -- Intermediate System to Intermediate System intradomain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)"">IS-IS</a>]) in the same manner as standard LSPs (i.e., as
additional information sourced by the same IS) subject to the
following restrictions:
o A valid version of standard LSP #0 from the same IS at the
corresponding level MUST be present in the LSDB in order for the
LxFS/E-LxFS set to be usable.
o Information in an LxFS of E-LxFS LSP (e.g., IS-Neighbor
information) that supports using the originating IS as a transit
node MUST NOT be used when the Overload bit is set in the
corresponding standard LSP #0.
o TLVs that are restricted to standard LSP #0 MUST NOT appear in
LxFS LSPs.
There are no further restrictions as to what TLVs may be advertised
in FS-LSPs.
<span class="grey">Ginsberg, et al. Standards Track [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc7356">RFC 7356</a> IS-IS Flooding Scope LSPs September 2014</span>
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Domain Scope Flooding</span>
Existing support for flooding information throughout a domain (i.e.,
to L1 routers in all areas as well as to routers in the Level 2
subdomain) requires the use of leaking procedures between levels.
For further details, see [<a href="./rfc4971" title=""Intermediate System to Intermediate System (IS-IS) Extensions for Advertising Router Information"">RFC4971</a>]. This is sufficient when the data
being flooded throughout the domain consists of individual TLVs. If
it is desired to retain the identity of the originating IS for the
complete contents of a PDU, then support for flooding the unchanged
PDU is desirable. This document, therefore, defines two flooding
scopes in support of domain flooding. FS-LSPs with this scope MUST
be flooded on all circuits regardless of what level(s) is supported
on that circuit.
o Domain Flooding Scope (DFS) -- this uses standard TLVs and
standard sub-TLVs
o Extended Domain Flooding Scope (E-DFS) -- this uses extended TLVs
and extended sub-TLVs
The FS LSP ID Extended format is used in these PDUs.
Use of information in FS-LSPs for a given scope depends on
determining the reachability to the IS originating the FS-LSP. This
presents challenges for FS-LSPs with domain scopes because no single
IS has the full view of the topology across all areas. It is,
therefore, necessary for the originator of domain scope DSFS and
E-DSFS LSPs to advertise an identifier that will allow an IS who
receives such an FS-LSP to determine whether the source of the FS-LSP
is currently reachable. The identifier required depends on what
"address-families" are being advertised.
When IS-IS is deployed in support of Layer 3 routing for IPv4 and/or
IPv6, then FS-LSP #0 with domain scope MUST include at least one of
the following TLVs:
o IPv4 Traffic Engineering Router ID (TLV 134)
o IPv6 Traffic Engineering Router ID (TLV 140)
When IS-IS is deployed in support of Layer 2 routing, current
standards (e.g., [<a href="./rfc6325" title=""Routing Bridges (RBridges): Base Protocol Specification"">RFC6325</a>]) only support a single area. Therefore,
domain scope is not yet applicable. When the Layer 2 standards are
updated to include multi-area support, the identifiers that can be
used to support inter-area reachability will be defined -- at which
point the use of domain scope for Layer 2 can be fully defined.
<span class="grey">Ginsberg, et al. Standards Track [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc7356">RFC 7356</a> IS-IS Flooding Scope LSPs September 2014</span>
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. Announcing Support for Flooding Scopes</span>
Announcements of support for flooding scope may be useful in
validating that full support has been deployed and/or in isolating
the reasons for incomplete flooding of FS-LSPs for a given scope.
ISs supporting FS-PDUs MAY announce supported scopes in IIH PDUs. To
do so, a new TLV is defined.
Scope Flooding Support
Type: 243
Length: 1 - 127
Value
No. of octets
+----------------------+
|R| Supported Scope | 1
+----------------------+
: :
+----------------------+
|R| Supported Scope | 1
+----------------------+
A list of the circuit scopes supported on this circuit and other
non-circuit-flooding scopes supported.
R bit MUST be 0 and is ignored on receipt.
In a Point-to-Point IIH, L1, L2, domain, and all circuit scopes
MAY be advertised.
In Level 1 LAN IIHs, L1, domain, and L1 Circuit Scopes MAY be
advertised. L2 Scopes and L2 Circuit Scopes MUST NOT be
advertised.
In Level 2 LAN IIHs, L2, domain, and L2 Circuit Scopes MAY be
advertised. L1 Scopes and L1 Circuit Scopes MUST NOT be
advertised.
Information in this TLV MUST NOT be considered in adjacency
formation.
Whether information in this TLV is used to determine when FS-LSPs
associated with a locally supported scope are flooded is an
implementation choice.
<span class="grey">Ginsberg, et al. Standards Track [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc7356">RFC 7356</a> IS-IS Flooding Scope LSPs September 2014</span>
<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>. IANA Considerations</span>
This document includes the definition of three new PDU types that are
reflected in the "IS-IS PDU Registry".
Value Description
---- ---------------------
10 FS-LSP
11 FS-CSNP
12 FS-PSNP
A new IANA registry has been created to control the assignment of
scope identifiers in FS-PDUs. The registration procedure is "Expert
Review" as defined in [<a href="./rfc5226" title="">RFC5226</a>]. The registry name is "LSP Flooding
Scope Identifier Registry". A scope identifier is a number from
1-127, inclusive. Values 1 - 63 are reserved for PDUs that use
standard TLVs and standard sub-TLVs. Values 64 - 127 are reserved
for PDUs that use extended TLVs and extended sub-TLVs. The list of
Hello PDUs in which support for a given scope MAY be announced (using
Scope Flooding Support TLV) is specified for each defined scope.
The following scope identifiers are defined by this document.
FS LSP ID Format/ IIH Announce
Value Description TLV Format P2P L1LAN L2LAN
----- ------------------------------ ----------------- ---------------
1 Level 1 Circuit Flooding Scope Extended/Standard Y Y N
2 Level 2 Circuit Flooding Scope Extended/Standard Y N Y
3 Level 1 Flooding Scope Extended/Standard Y Y N
4 Level 2 Flooding Scope Extended/Standard Y N Y
5 Domain Flooding Scope Extended/Standard Y Y Y
(6-63)Unassigned
64 Level 1 Circuit Flooding Scope Extended/Extended Y Y N
65 Level 2 Circuit Flooding Scope Extended/Extended Y N Y
66 Level 1 Flooding Scope Extended/Extended Y Y N
67 Level 2 Flooding Scope Extended/Extended Y N Y
68 Domain Flooding Scope Extended/Extended Y Y Y
(69-127) Unassigned
The definition of a new IS-IS TLV is reflected in the "IS-IS TLV
Codepoints" registry:
Value Name IIH LSP SNP Purge
---- ------------ --- --- --- -----
243 Scope Flooding Support Y N N N
<span class="grey">Ginsberg, et al. Standards Track [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc7356">RFC 7356</a> IS-IS Flooding Scope LSPs September 2014</span>
The IANA "IS-IS TLV Codepoints" registry has been extended to allow
definition of codepoints less than or equal to 65535. Codepoints
greater than 255 can only be used in PDUs designated to support
extended TLVs. This registry has also been updated to point to this
document as a reference (in addition to [<a href="./rfc3563" title=""Cooperative Agreement Between the ISOC/IETF and ISO/IEC Joint Technical Committee 1/Sub Committee 6 (JTC1/SC6) on IS-IS Routing Protocol Development"">RFC3563</a>] and [<a href="./rfc6233" title=""IS-IS Registry Extension for Purges"">RFC6233</a>]).
<span class="h2"><a class="selflink" id="section-13" href="#section-13">13</a>. Security Considerations</span>
Security concerns for IS-IS are addressed in [<a href="#ref-IS-IS" title=""Information technology -- Telecommunications and information exchange between systems -- Intermediate System to Intermediate System intradomain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)"">IS-IS</a>], [<a href="./rfc5304" title=""IS-IS Cryptographic Authentication"">RFC5304</a>], and
[<a href="./rfc5310" title=""IS-IS Generic Cryptographic Authentication"">RFC5310</a>].
The new PDUs introduced are subject to the same security issues
associated with their standard LSP/CSNP/PSNP counterparts. To the
extent that additional PDUs represent additional load for routers in
the network, this increases the opportunity for denial-of-service
attacks.
<span class="h2"><a class="selflink" id="section-14" href="#section-14">14</a>. Acknowledgements</span>
The authors wish to thank Ayan Banerjee, Donald Eastlake, Hannes
Gredler, and Mike Shand for their comments.
<span class="h2"><a class="selflink" id="section-15" href="#section-15">15</a>. References</span>
<span class="h3"><a class="selflink" id="section-15.1" href="#section-15.1">15.1</a>. Normative References</span>
[<a id="ref-IEEEaq">IEEEaq</a>] IEEE, "Standard for Local and metropolitan area networks
-- Media Access Control (MAC) Bridges and Virtual Bridged
Local Area Networks -- Amendment 20: Shortest Path
Bridging", IEEE Std 802.1aq-2012, June 2012.
[<a id="ref-IS-IS">IS-IS</a>] ISO/IEC 10589:2002, Second Edition, "Information
technology -- Telecommunications and information exchange
between systems -- Intermediate System to Intermediate
System intradomain routeing information exchange protocol
for use in conjunction with the protocol for providing the
connectionless-mode network service (ISO 8473)", 2002.
[<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>, March 1997.
[<a id="ref-RFC4971">RFC4971</a>] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate
System to Intermediate System (IS-IS) Extensions for
Advertising Router Information", <a href="./rfc4971">RFC 4971</a>, July 2007.
[<a id="ref-RFC5226">RFC5226</a>] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", <a href="https://www.rfc-editor.org/bcp/bcp26">BCP 26</a>, <a href="./rfc5226">RFC 5226</a>,
May 2008.
<span class="grey">Ginsberg, et al. Standards Track [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc7356">RFC 7356</a> IS-IS Flooding Scope LSPs September 2014</span>
[<a id="ref-RFC5304">RFC5304</a>] Li, T. and R. Atkinson, "IS-IS Cryptographic
Authentication", <a href="./rfc5304">RFC 5304</a>, October 2008.
[<a id="ref-RFC5305">RFC5305</a>] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", <a href="./rfc5305">RFC 5305</a>, October 2008.
[<a id="ref-RFC5306">RFC5306</a>] Shand, M. and L. Ginsberg, "Restart Signaling for IS-IS",
<a href="./rfc5306">RFC 5306</a>, October 2008.
[<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>, February 2009.
[<a id="ref-RFC6822">RFC6822</a>] Previdi, S., Ginsberg, L., Shand, M., Roy, A., and D.
Ward, "IS-IS Multi-Instance", <a href="./rfc6822">RFC 6822</a>, December 2012.
<span class="h3"><a class="selflink" id="section-15.2" href="#section-15.2">15.2</a>. Informative References</span>
[<a id="ref-RFC3563">RFC3563</a>] Zinin, A., "Cooperative Agreement Between the ISOC/IETF
and ISO/IEC Joint Technical Committee 1/Sub Committee 6
(JTC1/SC6) on IS-IS Routing Protocol Development", <a href="./rfc3563">RFC</a>
<a href="./rfc3563">3563</a>, July 2003.
[<a id="ref-RFC5311">RFC5311</a>] McPherson, D., Ginsberg, L., Previdi, S., and M. Shand,
"Simplified Extension of Link State PDU (LSP) Space for
IS-IS", <a href="./rfc5311">RFC 5311</a>, February 2009.
[<a id="ref-RFC6233">RFC6233</a>] Li, T. and L. Ginsberg, "IS-IS Registry Extension for
Purges", <a href="./rfc6233">RFC 6233</a>, May 2011.
[<a id="ref-RFC6325">RFC6325</a>] Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A.
Ghanwani, "Routing Bridges (RBridges): Base Protocol
Specification", <a href="./rfc6325">RFC 6325</a>, July 2011.
[<a id="ref-RFC7176">RFC7176</a>] Eastlake, 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>, May 2014.
<span class="grey">Ginsberg, et al. Standards Track [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc7356">RFC 7356</a> IS-IS Flooding Scope LSPs September 2014</span>
Authors' Addresses
Les Ginsberg
Cisco Systems
510 McCarthy Blvd.
Milpitas, CA 95035
USA
EMail: ginsberg@cisco.com
Stefano Previdi
Cisco Systems
Via Del Serafico 200
Rome 0144
Italy
EMail: sprevidi@cisco.com
Yi Yang
Cisco Systems
7100-9 Kit Creek Road
Research Triangle Park, NC 27709-4987
USA
EMail: yiya@cisco.com
Ginsberg, et al. Standards Track [Page 23]
</pre>
|
