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
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
|
<pre>Internet Engineering Task Force (IETF) W. Hao
Request for Comments: 7956 Y. Li
Category: Standards Track Huawei
ISSN: 2070-1721 A. Qu
MediaTec
M. Durrani
Equinix Inc.
P. Sivamurugan
IP Infusion
September 2016
<span class="h1">Transparent Interconnection of Lots of Links (TRILL)</span>
<span class="h1">Distributed Layer 3 Gateway</span>
Abstract
The base TRILL (Transparent Interconnection of Lots of Links)
protocol provides optimal pair-wise data frame forwarding for Layer 2
intra-subnet traffic but not for Layer 3 inter-subnet traffic. A
centralized gateway solution is typically used for Layer 3 inter-
subnet traffic forwarding but has the following issues:
1. Sub-optimum forwarding paths for inter-subnet traffic.
2. A centralized gateway that may need to support a very large number
of gateway interfaces in a Data Center, one per tenant per Data
Label used by that tenant, to provide interconnect functionality
for all the Layer 2 Virtual Networks in a TRILL campus.
3. A traffic bottleneck at the gateway.
This document specifies an optional TRILL distributed gateway
solution that resolves these centralized gateway issues.
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="http://www.rfc-editor.org/info/rfc7956">http://www.rfc-editor.org/info/rfc7956</a>.
<span class="grey">Hao, 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="./rfc7956">RFC 7956</a> TRILL Distributed Layer 3 Gateway September 2016</span>
Copyright Notice
Copyright (c) 2016 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.
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
<a href="#section-1.1">1.1</a>. Document Organization ......................................<a href="#page-3">3</a>
<a href="#section-2">2</a>. Conventions Used in This Document ...............................<a href="#page-4">4</a>
<a href="#section-3">3</a>. Simplified Example and Problem Statement ........................<a href="#page-5">5</a>
<a href="#section-3.1">3.1</a>. Simplified Example .........................................<a href="#page-6">6</a>
<a href="#section-3.2">3.2</a>. Problem Statement Summary ..................................<a href="#page-8">8</a>
<a href="#section-4">4</a>. Layer 3 Traffic Forwarding Model ................................<a href="#page-9">9</a>
<a href="#section-5">5</a>. Distributed Gateway Solution Details ...........................<a href="#page-10">10</a>
<a href="#section-5.1">5.1</a>. Local Routing Information .................................<a href="#page-11">11</a>
<a href="#section-5.2">5.2</a>. Local Routing Information Synchronization .................<a href="#page-12">12</a>
<a href="#section-5.3">5.3</a>. Active-Active Access ......................................<a href="#page-14">14</a>
<a href="#section-5.4">5.4</a>. Data Traffic Forwarding Process ...........................<a href="#page-15">15</a>
<a href="#section-6">6</a>. Distributed Layer 3 Gateway Process Example ....................<a href="#page-16">16</a>
<a href="#section-6.1">6.1</a>. Control-Plane Process .....................................<a href="#page-17">17</a>
<a href="#section-6.2">6.2</a>. Data-Plane Process ........................................<a href="#page-19">19</a>
<a href="#section-7">7</a>. TRILL Protocol Extensions ......................................<a href="#page-20">20</a>
<a href="#section-7.1">7.1</a>. The Tenant Label and Gateway MAC APPsub-TLV ...............<a href="#page-20">20</a>
<a href="#section-7.2">7.2</a>. The SE Flag in the NickFlags APPsub-TLV ...................<a href="#page-21">21</a>
<a href="#section-7.3">7.3</a>. The IPv4 Prefix APPsub-TLV ................................<a href="#page-22">22</a>
<a href="#section-7.4">7.4</a>. The IPv6 Prefix APPsub-TLV ................................<a href="#page-23">23</a>
<a href="#section-8">8</a>. Security Considerations ........................................<a href="#page-24">24</a>
<a href="#section-9">9</a>. Management Considerations ......................................<a href="#page-24">24</a>
<a href="#section-10">10</a>. IANA Considerations ...........................................<a href="#page-24">24</a>
<a href="#section-11">11</a>. References ....................................................<a href="#page-25">25</a>
<a href="#section-11.1">11.1</a>. Normative References .....................................<a href="#page-25">25</a>
<a href="#section-11.2">11.2</a>. Informative References ...................................<a href="#page-26">26</a>
Acknowledgments ...................................................<a href="#page-27">27</a>
Authors' Addresses ................................................<a href="#page-28">28</a>
<span class="grey">Hao, 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="./rfc7956">RFC 7956</a> TRILL Distributed Layer 3 Gateway September 2016</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The TRILL (Transparent Interconnection of Lots of Links) protocol
[<a href="./rfc6325" title=""Routing Bridges (RBridges): Base Protocol Specification"">RFC6325</a>] [<a href="./rfc7780" title=""Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates"">RFC7780</a>] provides a solution for least-cost transparent
routing in multi-hop networks with arbitrary topologies and link
technologies, using IS-IS [<a href="#ref-IS-IS" title=""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>] [<a href="./rfc7176" title=""Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS"">RFC7176</a>] link-state routing and a
hop count. TRILL switches are sometimes called RBridges (Routing
Bridges).
The base TRILL protocol provides optimal unicast forwarding for
Layer 2 intra-subnet traffic but not for Layer 3 inter-subnet
traffic, where "subnet" means a different IP address prefix and,
typically, a different Data Label (VLAN or FGL (Fine-Grained Label)).
This document specifies a TRILL-based distributed Layer 3 gateway
solution that provides optimal unicast forwarding for Layer 3
inter-subnet traffic. With distributed gateway support, an edge
RBridge provides routing based on the Layer 2 identity (address and
Virtual Network (VN, i.e., Data Label)) among End Stations (ESs) that
belong to the same subnet and also provides routing based on the
Layer 3 identity among ESs that belong to different subnets of the
same routing domain. An edge RBridge supporting this feature needs
to provide routing instances and Layer 3 gateway interfaces for
locally connected ESs. Such routing instances provide IP address
isolation between tenants. In the TRILL distributed Layer 3 gateway
solution, inter-subnet traffic can be fully spread over edge
RBridges, so there is no single bottleneck.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Document Organization</span>
This document is organized as follows: <a href="#section-3">Section 3</a> gives a simplified
example and also a more detailed problem statement. <a href="#section-4">Section 4</a> gives
the Layer 3 traffic forwarding model. <a href="#section-5">Section 5</a> provides a
distributed gateway solution overview. <a href="#section-6">Section 6</a> gives a detailed
distributed gateway solution example. <a href="#section-7">Section 7</a> describes the TRILL
protocol extensions needed to support this distributed gateway
solution.
<span class="grey">Hao, 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="./rfc7956">RFC 7956</a> TRILL Distributed Layer 3 Gateway September 2016</span>
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Conventions Used in This Document</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">RFC 2119</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
The terms and acronyms in [<a href="./rfc6325" title=""Routing Bridges (RBridges): Base Protocol Specification"">RFC6325</a>] are used, with the following
additions:
AGG: Aggregation switch.
ARP: Address Resolution Protocol [<a href="./rfc826" title=""Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware"">RFC826</a>].
Campus: The name for a network using the TRILL protocol in the same
sense that a "bridged LAN" is the name for a network using
bridging. In TRILL, the word "campus" has no academic
implication.
COR: Core switch.
Data Label: VLAN or FGL [<a href="./rfc7172" title=""Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling"">RFC7172</a>].
DC: Data Center.
Edge RBridge: An RBridge that connects to one or more ESs without any
intervening RBridges.
ES: End Station. A Virtual Machine or physical server, whose address
is either the destination or source of a data frame.
FGL: Fine-Grained Label [<a href="./rfc7172" title=""Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling"">RFC7172</a>].
Gateway interface: A Layer 3 virtual interface that terminates
Layer 2 forwarding and forwards IP traffic to the destination
using IP forwarding rules. Incoming traffic from a physical port
on a gateway will be distributed to its virtual gateway interface
based on the Data Label (VLAN or FGL).
Inner.MacDA: The inner MAC destination address in a TRILL Data packet
[<a href="./rfc6325" title=""Routing Bridges (RBridges): Base Protocol Specification"">RFC6325</a>].
Inner.MacSA: The inner MAC source address in a TRILL Data packet
[<a href="./rfc6325" title=""Routing Bridges (RBridges): Base Protocol Specification"">RFC6325</a>].
Inner.VLAN: The inner VLAN tag in a TRILL Data packet payload
[<a href="./rfc6325" title=""Routing Bridges (RBridges): Base Protocol Specification"">RFC6325</a>].
<span class="grey">Hao, 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="./rfc7956">RFC 7956</a> TRILL Distributed Layer 3 Gateway September 2016</span>
L2: Layer 2.
L3: IP Layer 3.
LSP: Link State PDU
ND: IPv6's Neighbor Discovery [<a href="./rfc4861" title=""Neighbor Discovery for IP version 6 (IPv6)"">RFC4861</a>].
ToR: Top of Rack.
VN: Virtual Network. In a TRILL campus, a unique 12-bit VLAN ID or a
24-bit FGL [<a href="./rfc7172" title=""Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling"">RFC7172</a>] identifies each VN.
VRF: Virtual Routing and Forwarding. In IP-based computer networks,
VRF technology supports multiple instances of routing tables
existing within the same router at the same time.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Simplified Example and Problem Statement</span>
There is normally a Data Label (VLAN or FGL) associated with each IP
subnet. For traffic within a subnet -- that is, IP traffic to
another ES in the same Data Label attached to the TRILL campus -- the
ES just ARPs for the MAC address of the destination ES's IP. It then
uses this MAC address for traffic to that destination. TRILL routes
the ingressed TRILL Data packets to the destination's edge RBridge
based on the egress nickname for that destination MAC address and
Data Label. This is the regular TRILL base protocol [<a href="./rfc6325" title=""Routing Bridges (RBridges): Base Protocol Specification"">RFC6325</a>]
process.
If two ESs of the same tenant are on different subnets and need to
communicate with each other, their packets are typically forwarded to
an IP L3 gateway that performs L3 routing and, if necessary, changes
the Data Label. Either a centralized L3 gateway solution or the
distributed L3 gateway solution specified in this document can be
used for inter-subnet traffic forwarding.
<a href="#section-3.1">Section 3.1</a> gives a simplified example in a TRILL campus with and
without a distributed L3 gateway using VLAN Data Labels. <a href="#section-3.2">Section 3.2</a>
gives a detailed description of the issues related to using a
centralized gateway (i.e., without a distributed L3 gateway). The
remainder of this document, particularly <a href="#section-5">Section 5</a>, describes the
distributed gateway solution in detail.
<span class="grey">Hao, 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="./rfc7956">RFC 7956</a> TRILL Distributed Layer 3 Gateway September 2016</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Simplified Example</span>
Figure 1 depicts a TRILL DC network, where ToR switches are edge
RBridges and the AGGs and CORs are non-edge RBridges.
------- --------
| COR1| | COR2 |
------- --------
| |
------- -------
|AGG1 | |AGG2 |
------- -------
| |
-----------------------------------------------------
| -------------|------------------|----------------|
| | | | | | | |
------- ------- ------- -------
| RB1 | | RB2 | | RB3 | | RB4 |
|ToR1 | |ToR2 | |ToR3 | |ToR4 |
------- ------- ------- -------
| | | | | | | |
----- ----- ----- ----- ----- ----- ----- -----
|ES1| |ES2| |ES3| |ES4| |ES5| |ES6| |ES7| |ES8|
----- ----- ----- ----- ----- ----- ----- -----
Figure 1: A Typical TRILL DC Network
<span class="grey">Hao, 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="./rfc7956">RFC 7956</a> TRILL Distributed Layer 3 Gateway September 2016</span>
ES1 through ES8 belong to one tenant network, and the tenant has
four subnets with each subnet corresponding to one VLAN (which
indicates one individual L2 VN). Each ES's IP address, VLAN, and
subnet are listed below:
+----+----------------+-----------------+----------+
| ES | IP Address | Subnet | VLAN |
+----+----------------+-----------------+----------+
| ES1| 192.0.2.2 | 192.0.2.0/24 | 10 |
+----+----------------+-----------------+----------+
| ES2| 198.51.100.2 | 198.51.100.0/24 | 11 |
+----+----------------+-----------------+----------+
| ES3| 192.0.2.3 | 192.0.2.0/24 | 10 |
+----+----------------+-----------------+----------+
| ES4| 198.51.100.3 | 198.51.100.0/24 | 11 |
+----+----------------+-----------------+----------+
| ES5| 203.0.113.2 | 203.0.113.0/25 | 12 |
+----+----------------+-----------------+----------+
| ES6| 203.0.113.130 | 203.0.113.128/25| 13 |
+----+----------------+-----------------+----------+
| ES7| 203.0.113.3 | 203.0.113.0/25 | 12 |
+----+----------------+-----------------+----------+
| ES8| 203.0.113.131 | 203.0.113.128/25| 13 |
+----+----------------+-----------------+----------+
Assume that a centralized gateway solution is used with both COR1 and
COR2 acting as centralized gateways for redundancy in Figure 1. COR1
and COR2 each have four gateway interfaces for the four subnets in
the tenant. In the centralized L3 gateway solution, all traffic
within the tenant between different VLANs must go through the
centralized L3 gateway device of COR1 or COR2, even if the traffic is
between two ESs connected to the same edge RBridge, because only the
L3 gateway can change the VLAN labeling of the traffic.
This is generally sub-optimal because the two ESs may be connected to
the same ToR where L3 switching could have been performed locally.
For example, in Figure 1 above, the unicast IP traffic between ES1
and ES2 has to go through a centralized gateway of COR1 or COR2. It
can't be locally routed between them on ToR1. However, if an edge
RBridge has the distributed gateway capabilities specified in this
document, then it can still perform optimum L2 forwarding for
intra-subnet traffic and, in addition, optimum L3 forwarding for
inter-subnet traffic, thus delivering optimum forwarding for unicast
packets in all important cases.
With a distributed L3 gateway, each edge RBridge acts as a default L3
gateway for local connecting ESs and has IP router capabilities to
direct IP communications to other edge RBridges. Each edge RBridge
<span class="grey">Hao, 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="./rfc7956">RFC 7956</a> TRILL Distributed Layer 3 Gateway September 2016</span>
only needs gateway interfaces for local connecting ESs, i.e., RB1 and
RB2 need gateway interfaces only for VLAN 10 and VLAN 11 while RB3
and RB4 need gateway interfaces only for VLAN 12 and VLAN 13. No
device needs to maintain gateway interfaces for all VLANs in the
entire network. This will enhance scalability in terms of the number
of tenants and subnets per tenant.
When each ES ARPs for its L3 gateway, that is, its IP router, the
edge RBridge to which it is connected will respond with that
RBridge's "gateway MAC". When the ES later sends IP traffic to the
L3 gateway, which it does if the destination IP is outside of its
subnet, the edge RBridge intercepts the IP packet because the
destination MAC is its gateway MAC. That RBridge routes the IP
packet using the routing instance associated with that tenant,
handling it in one of three ways:
(1) ES1 communicates with ES2. The destination IP is connected to
the same edge RBridge; the RBridge of ToR1 can simply transmit
the IP packet out the right edge port in the destination VLAN.
(2) If the destination IP is located in an outside network, the edge
RBridge encapsulates it as a TRILL Data packet and sends it to
the actual TRILL campus edge RBridge connecting to an external IP
router.
(3) ES1 communicates with ES4. The destination ES is connected to a
different edge RBridge; the ingress RBridge ToR1 uses TRILL
encapsulation to route the IP packet to the correct egress
RBridge ToR2, using the egress RBridge's gateway MAC and an
Inner.VLAN identifying the tenant. Finally, the egress RBridge
terminates the TRILL encapsulation and routes the IP packet to
the destination ES based on the routing instance for that tenant.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Problem Statement Summary</span>
With FGL [<a href="./rfc7172" title=""Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling"">RFC7172</a>], in theory, up to 16 million L2 VNs can be
supported in a TRILL campus. To support inter-subnet traffic, a very
large number of L3 gateway interfaces could be needed on a
centralized gateway, if each VN corresponds to a subnet and there are
many tenants with many subnets per tenant. It is a big burden for
the centralized gateway to support so many interfaces. In addition,
all inter-subnet traffic will go through a centralized gateway that
may become a traffic bottleneck.
<span class="grey">Hao, 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="./rfc7956">RFC 7956</a> TRILL Distributed Layer 3 Gateway September 2016</span>
The centralized gateway has the following issues:
1. Sub-optimum forwarding paths for inter-subnet traffic can occur
due to the requirements to perform IP routing and possibly change
Data Labels at a centralized gateway.
2. The centralized gateway may need to support a very large number of
gateway interfaces -- in a DC, one per tenant per Data Label used
by that tenant -- to provide interconnect functionality for all
the L2 VNs in the TRILL campus.
3. There may be a traffic bottleneck at the centralized gateway.
A distributed gateway on edge RBridges addresses these issues.
Through the distributed L3 gateway solution, the inter-subnet traffic
is fully dispersed and is transmitted along optimal pair-wise
forwarding paths, improving network efficiency.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Layer 3 Traffic Forwarding Model</span>
In a DC network, each tenant has one or more L2 VNs, and, in normal
cases, each tenant corresponds to one routing domain. Normally, each
L2 VN uses a different Data Label and corresponds to one or more IP
subnets.
Each L2 VN in a TRILL campus is identified by a unique 12-bit VLAN ID
or 24-bit FGL [<a href="./rfc7172" title=""Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling"">RFC7172</a>]. Different routing domains may have
overlapping address space but need distinct and separate routes. The
ESs that belong to the same subnet communicate through L2 forwarding;
ESs of the same tenant that belong to different subnets communicate
through L3 routing.
<span class="grey">Hao, 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="./rfc7956">RFC 7956</a> TRILL Distributed Layer 3 Gateway September 2016</span>
Figure 2 depicts the model where there are n VRFs corresponding to
n tenants, with each tenant having up to m segments/subnets (VNs).
+---------------------------------------------+
| |
| +-----------+ +-----------+ |
| | Tenant n |---------| VRF n | |
| +------------+ | +------------+ | |
| | +-----+ | | | | | |
| | | VN1 | | | | | | |
| | +-----+ | | | VRF 1 | | |
| | .. +-------+ | | |
| | +-----+ | | | | | |
| | | VNm | | | | | | |
| | +-----+ | | | | | |
| | Tenant1 |-+ | | | |
| +------------+ | | | |
| +------------+ +------------+ |
| |
| Edge RBridge |
+---------------------------------------------+
Figure 2: Edge RBridge Model as Distributed Gateway
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Distributed Gateway Solution Details</span>
With the TRILL distributed gateway solution, an edge RBridge
continues to perform routing based on the L2 MAC address for the ESs
that are on the same subnet but performs IP routing for the ESs that
are on the different subnets of the same tenant.
As the IP address space in different routing domains can overlap, VRF
instances need to be created on each edge RBridge to isolate the IP
forwarding process for different routing domains present on the edge
RBridge. A Tenant ID unique across the TRILL campus identifies each
routing domain. The network operator MUST configure the Tenant IDs
on each edge RBridge for each routing domain consistently so that the
same ID always refers to the same tenant. Otherwise, data might be
delivered to the wrong tenant. If a routing domain spreads over
multiple edge RBridges, routing information for the routing domain is
synchronized among these edge RBridges through the link-state
database to ensure reachability to all ESs in that routing domain.
The routing information is, in effect, labeled with the Tenant ID to
differentiate the routing domains.
From the data-plane perspective, all edge RBridges are connected to
each other via one or more TRILL hops; however, they are always just
a single IP hop away. When an ingress RBridge receives inter-subnet
<span class="grey">Hao, 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="./rfc7956">RFC 7956</a> TRILL Distributed Layer 3 Gateway September 2016</span>
IP traffic from a local ES whose destination MAC is the edge
RBridge's gateway MAC, that RBridge will perform Ethernet header
termination. The tenant involved is determined by the VLAN of the
traffic and the port on which it arrives. The edge RBridge looks up
in its IP routing table for that tenant how to route the traffic to
the IP next hop. If the destination ES is connected to a remote edge
RBridge, the remote RBridge will be the IP next hop for traffic
forwarding. For such inter-subnet traffic, the ingress RBridge will
rewrite the original Ethernet header with the ingress RBridge's
gateway MAC address as the Inner.MacSA and the egress RBridge's
gateway MAC address as the Inner.MacDA and then perform TRILL
encapsulation to the remote RBridge's nickname, setting the inner
Data Label to indicate the tenant involved. TRILL then routes it to
the remote edge RBridge through the TRILL campus.
When that remote edge RBridge receives the traffic, it will
decapsulate the TRILL Data packet and see that the inner destination
MAC is its gateway MAC. It then terminates the inner Ethernet
encapsulation and looks up the destination IP in the RBridge's IP
forwarding table for the tenant indicated by the inner Data Label, to
route it to the destination ES.
Through this method, TRILL with distributed gateways provides optimum
pair-wise data routing for inter-subnet traffic.
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Local Routing Information</span>
An ES can be locally connected to an edge RBridge through an L2
network (such as a point-to-point Ethernet link or a bridged LAN) or
externally connected through an L3 IP network.
If the ES is connected to an edge RBridge through an L2 network, then
the edge RBridge acts as an L3 gateway for the ES. A gateway
interface is established on the edge RBridge for the connecting ES.
Because the ESs in a subnet may be spread over multiple edge
RBridges, each such edge RBridge that establishes its gateway
interface for the subnet SHOULD share the same gateway MAC and
gateway IP address configuration. Sharing the configuration and
insuring configuration consistency can be done by local configuration
and Network Configuration Protocol (NETCONF) / YANG models.
With a distributed gateway, the edge RBridge to which an ES is
connected appears to be the local IP router on its link. As in any
IP network, before the ES starts to send inter-subnet traffic, it
acquires its gateway's MAC through the ARP/ND process. Local
connecting edge RBridges that support this distributed gateway
feature always respond with the gateway MAC address when receiving
ARP/ND requests for the gateway IP. Through the ARP/ND process, the
<span class="grey">Hao, 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="./rfc7956">RFC 7956</a> TRILL Distributed Layer 3 Gateway September 2016</span>
edge RBridge can learn the IP and MAC correspondence of a local ES
connected to the edge RBridge by L2 and then generate local IP
routing entries for that ES in the corresponding routing domain.
To TRILL, an IP router connected to an edge RBridge looks like an ES.
If a router/ES is located in an external IP network, it normally
provides access to one or more IP prefixes. The router/ES SHOULD run
an IP routing protocol with the connecting TRILL edge RBridge. The
edge RBridge will learn the IP prefixes behind the router/ES through
that IP routing protocol, and the RBridge will then generate local IP
routing entries in the corresponding routing domain. If such a
routing protocol is not run with the edge RBridge, then only the IP
prefixes behind the router/ES that are explicitly configured on the
edge RBridge will be accessible.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Local Routing Information Synchronization</span>
When a routing instance is created on an edge RBridge, the Tenant ID,
tenant Data Label (VLAN or FGL), and tenant gateway MAC that
correspond to that instance are configured and MUST be globally
advertised (see <a href="#section-7.1">Section 7.1</a>). The Tenant ID uniquely identifies that
tenant throughout the campus. The tenant Data Label identifies that
tenant at the edge RBridge. The tenant gateway MAC MAY identify that
tenant, all tenants, or some subset of tenants at the edge RBridge.
When an ingress RBridge performs inter-subnet traffic TRILL
encapsulation, the ingress RBridge uses the Data Label advertised by
the egress RBridge as the inner VLAN or FGL and uses the tenant
gateway MAC advertised by the egress RBridge as the Inner.MacDA. The
egress RBridge relies on this tenant Data Label to find the local VRF
instance for the IP forwarding process when receiving inter-subnet
traffic from the TRILL campus. (The role of the tenant Data Label is
akin to an MPLS VPN Label in an MPLS IP / MPLS VPN network.) Tenant
Data Labels are independently allocated on each edge RBridge for each
routing domain. An edge RBridge can use an access Data Label from a
routing domain to act as the inter-subnet Data Label, or the edge
RBridge can use a Data Label different from any access Data Labels to
be a tenant Data Label. It is implementation dependent, and there is
no restriction on this assignment of Data Labels.
The tenant gateway MAC differentiates inter-subnet L3 traffic from
intra-subnet L2 traffic on the egress RBridge. Each tenant on an
RBridge can use a different gateway MAC or the same tenant gateway
MAC for inter-subnet traffic purposes. This is also implementation
dependent, and there is no restriction on it.
<span class="grey">Hao, 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="./rfc7956">RFC 7956</a> TRILL Distributed Layer 3 Gateway September 2016</span>
When a local IP prefix is learned in a routing instance on an edge
RBridge, the edge RBridge should advertise the IP prefix information
for the routing instance so that other edge RBridges will generate IP
routing entries. If the ESs in a VN are spread over multiple
RBridges, these RBridges MUST advertise each local connecting ES's IP
address in the VN to other RBridges. If the ESs in a VN are only
connected to one edge RBridge, that RBridge only needs to advertise
the subnet corresponding to the VN to other RBridges using host
routes. A Tenant ID unique across the TRILL campus is also carried
in the advertisement to differentiate IP prefixes between different
tenants, because the IP address space of different tenants can
overlap (see Sections <a href="#section-7.3">7.3</a> and <a href="#section-7.4">7.4</a>).
If a tenant is deleted on an edge RBridge RB1, RB1 updates the local
tenant Data Label, tenant gateway MAC, and related IP prefix
information it is advertising to include only the rest of the
tenants. It may take some time for these updates to reach all other
RBridges, so during this period of time there may be transient route
inconsistency among the edge RBridges. If there is traffic in flight
during this time, it will be dropped at the egress RBridge due to
local tenant deletion. When a stable state is reached, the traffic
to the deleted tenant will be dropped by the ingress RBridge.
Therefore, the transient route inconsistency won't cause issues other
than wasting some network bandwidth.
If a new tenant is created and a previously used tenant Data Label is
assigned to the new tenant immediately, this may cause a security
policy violation for the traffic in flight, because when the egress
RBridge receives traffic from the old tenant, it will forward it in
the new tenant's routing instance and deliver it to the wrong
destination. So, a tenant Data Label MUST NOT be reallocated until a
reasonable amount of time -- for example, twice the IS-IS
Holding Time generally in use in the TRILL campus -- has passed to
allow any traffic in flight to be discarded.
When the ARP entry in an edge RBridge for an ES times out, it will
trigger an edge RBridge LSP advertisement to other edge RBridges with
the corresponding IP routing entry deleted. If the ES is an IP
router, the edge RBridge also notifies other edge RBridges that they
must delete the routing entries corresponding to the IP prefixes
accessible through that IP router. During the IP prefix deleting
process, if there is traffic in flight, the traffic will be discarded
at the egress RBridge because there is no local IP routing entry to
the destination.
<span class="grey">Hao, 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="./rfc7956">RFC 7956</a> TRILL Distributed Layer 3 Gateway September 2016</span>
If an edge RBridge changes its tenant gateway MAC, it will trigger an
edge RBridge LSP advertisement to other edge RBridges, giving the new
gateway MAC to be used as the Inner.MacDA for future traffic destined
to the edge RBridge. During the gateway MAC changing process, if
there is traffic in flight using the old gateway MAC as the
Inner.MacDA, the traffic will be discarded or will be forwarded as L2
intra-subnet traffic on the edge RBridge. If the inter-subnet tenant
Data Label is a unique Data Label that is different from any access
Data Labels, when the edge RBridge receives the traffic whose
Inner.MacDA is different from the local tenant gateway MAC, the
traffic will be discarded. If the edge RBridge uses one of the
access Data Labels as an inter-subnet tenant Data Label, the traffic
will be forwarded as L2 intra-subnet traffic unless a special
traffic-filtering policy is enforced on the edge RBridge.
If there are multiple nicknames owned by an edge RBridge, the edge
RBridge can also specify one nickname as the egress nickname for
inter-subnet traffic forwarding. A NickFlags APPsub-TLV with the
SE flag set can be used for this purpose. If the edge RBridge
doesn't specify a nickname for this purpose, the ingress RBridge can
use any one of the nicknames owned by the egress as the egress
nickname for inter-subnet traffic forwarding.
TRILL Extended Level 1 Flooding Scope (E-L1FS) FS-LSP [<a href="./rfc7780" title=""Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates"">RFC7780</a>]
APPsub-TLVs are used for IP routing information synchronization in
each routing domain among edge RBridges. Based on the synchronized
information from other edge RBridges, each edge RBridge generates
routing entries in each routing domain for remote IP addresses and
subnets.
Through this solution, the intra-subnet forwarding and inter-subnet
IP routing functions are integrated, and network management and
deployment are simplified.
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. Active-Active Access</span>
TRILL active-active service provides ESs with flow-level load balance
and resilience against link failures at the edge of TRILL campuses,
as described in [<a href="./rfc7379" title=""Problem Statement and Goals for Active-Active Connection at the Transparent Interconnection of Lots of Links (TRILL) Edge"">RFC7379</a>].
If an ES is connected to two TRILL RBridges, say RB1 and RB2, in
active-active mode, RB1 and RB2 MUST both be configured to act as a
distributed L3 gateway for the ES in order to use a distributed
gateway. RB1 and RB2 each learn the ES's IP address through the
ARP/ND process, and then they announce the IP address to the TRILL
campus independently. The remote ingress RBridge will generate an IP
routing entry corresponding to the IP address with two IP next hops
of RB1 and RB2. When the ingress RBridge receives inter-subnet
<span class="grey">Hao, 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="./rfc7956">RFC 7956</a> TRILL Distributed Layer 3 Gateway September 2016</span>
traffic from a local access network, the ingress RBridge selects RB1
or RB2 as the IP next hop based on least cost or, if costs are equal,
the local load-balancing algorithm. The traffic will then be
transmitted to the selected next-hop destination RB1 or RB2 through
the TRILL campus.
<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>. Data Traffic Forwarding Process</span>
After ES1, connected by L2 in VLAN-x, acquires its gateway's MAC, it
can start inter-subnet data traffic transmission to ES2 in VLAN-y.
When the edge RBridge attached to ES1 receives inter-subnet traffic
from ES1, that RBridge performs L2 header termination; then, using
the local VRF corresponding to VLAN-x, it performs the IP routing
process in that VRF.
If destination ES2 is attached to the same edge RBridge, the traffic
will be locally forwarded to ES2 by that RBridge. Compared to the
centralized gateway solution, the forwarding path is optimal, and a
traffic detour through the centralized gateway is avoided.
If ES2 is attached to a remote edge RBridge, the remote edge RBridge
is the IP next hop, and the inter-subnet traffic is forwarded to the
IP next hop through TRILL encapsulation. If there are multiple
equal-cost shortest paths between the ingress RBridge and the egress
RBridge, all these paths can be used for inter-subnet traffic
forwarding, so load-spreading can be achieved for inter-subnet
traffic.
When the remote RBridge receives the inter-subnet TRILL-encapsulated
traffic, the RBridge decapsulates these TRILL packets and checks the
Inner.MacDA. If that MAC address is the local gateway MAC
corresponding to the inner label (VLAN or FGL), the inner label will
be used to find the corresponding local VRF; the IP routing process
in that VRF will then be performed, and the traffic will be locally
forwarded to destination ES2.
In summary, this solution avoids traffic detours through a central
gateway. Both inter-subnet and intra-subnet traffic can be forwarded
along pair-wise shortest paths, and network bandwidth is conserved.
<span class="grey">Hao, 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="./rfc7956">RFC 7956</a> TRILL Distributed Layer 3 Gateway September 2016</span>
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Distributed Layer 3 Gateway Process Example</span>
This section gives a detailed description of a distributed L3 gateway
solution example for IPv4 and IPv6.
In Figure 3, RB1 and RB2 support the distribution gateway function,
ES1 connects to RB1, and ES2 connects to RB2. ES1 and ES2 belong to
Tenant1 but are in different subnets.
--------- ---------
| RB3 | | RB4 |
--------- ---------
# * # *
# **************************
########################### *
# *
# *
# *
--------- ---------
| RB1 | | RB2 |
--------- ---------
| |
----- -----
|ES1| |ES2|
----- -----
Figure 3: Distributed Gateway Scenario
For IPv4, the IP address, VLAN, and subnet information of ES1 and ES2
are as follows:
+----+----------+------------------+------------------+----------+
| ES | Tenant | IP Address | Subnet | VLAN |
+----+----------+------------------+------------------+----------+
| ES1| Tenant1 | 192.0.2.2 | 192.0.2.0/24 | 10 |
+----+----------+------------------+------------------+----------+
| ES2| Tenant1 | 198.51.100.2 | 198.51.100.0/24 | 20 |
+----+----------+------------------+------------------+----------+
Figure 4: IPv4 ES Information
<span class="grey">Hao, 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="./rfc7956">RFC 7956</a> TRILL Distributed Layer 3 Gateway September 2016</span>
For IPv6, the IP address, VLAN, and subnet information of ES1 and ES2
are as follows:
+----+----------+------------------+------------------+----------+
| ES | Tenant | IP Address | Subnet | VLAN |
+----+----------+------------------+------------------+----------+
| ES1| Tenant1 | 2001:db8:0:1::2 |2001:db8:0:1::0/64| 10 |
+----+----------+------------------+------------------+----------+
| ES2| Tenant1 | 2001:db8:0:2::2 |2001:db8:0:2::0/64| 20 |
+----+----------+------------------+------------------+----------+
Figure 5: IPv6 ES Information
The nickname, VRF, tenant Label, and tenant gateway MAC for Tenant1
on RB1 and RB2 are as follows:
+----+---------+-----------+-------+--------------+--------------+
| RB | Nickname| Tenant | VRF | Tenant Label | Gateway MAC |
+----+---------+-----------+-------+--------------+--------------+
| RB1| nick1 | Tenant1 | VRF1 | 100 | MAC1 |
+----+---------+-----------+-------+--------------+--------------+
| RB2| nick2 | Tenant1 | VRF2 | 100 | MAC2 |
+----+---------+-----------+-------+--------------+--------------+
Figure 6: RBridge Information
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Control-Plane Process</span>
RB1 advertises the following local routing information to the TRILL
campus:
Tenant ID: 1
Tenant gateway MAC: MAC1
Tenant Label for Tenant1: VLAN 100
IPv4 prefix for Tenant1: 192.0.2.0/24
IPv6 prefix for Tenant1: 2001:db8:0:1::0/64
<span class="grey">Hao, 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="./rfc7956">RFC 7956</a> TRILL Distributed Layer 3 Gateway September 2016</span>
RB2 announces the following local routing information to the TRILL
campus:
Tenant ID: 1
Tenant gateway MAC: MAC2
Tenant Label for Tenant1: VLAN 100
IPv4 prefix for Tenant1: 198.51.100.0/24
IPv6 prefix for Tenant1: 2001:db8:0:2::0/64
Relying on the routing information from RB2, remote routing entries
on RB1 are generated as follows:
+------------------+-------------+--------------+----------------+
| Prefix/Mask | Inner.MacDA | Inner VLAN | Egress Nickname|
+------------------+-------------+--------------+----------------+
|198.51.100.0/24 | MAC2 | 100 | nick2 |
+------------------+-------------+--------------+----------------+
|2001:db8:0:2::0/64| MAC2 | 100 | nick2 |
+------------------+-------------+--------------+----------------+
Figure 7: Tenant1 Remote Routing Table on RB1
Similarly, relying on the routing information from RB1, remote
routing entries on RB2 are generated as follows:
+------------------+-------------+--------------+----------------+
| Prefix/Mask | Inner.MacDA | Inner VLAN | Egress Nickname|
+------------------+-------------+--------------+----------------+
| 192.0.2.0/24 | MAC1 | 100 | nick1 |
+------------------+-------------+--------------+----------------+
|2001:db8:0:1::0/64| MAC1 | 100 | nick1 |
+------------------+-------------+--------------+----------------+
Figure 8: Tenant1 Remote Routing Table on RB2
<span class="grey">Hao, 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="./rfc7956">RFC 7956</a> TRILL Distributed Layer 3 Gateway September 2016</span>
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Data-Plane Process</span>
Assuming that ES1 sends unicast inter-subnet traffic to ES2, the
traffic forwarding process is as follows:
1. ES1 sends unicast inter-subnet traffic to RB1 with RB1's gateway's
MAC as the destination MAC and the VLAN as VLAN 10.
2. Ingress RBridge (RB1) forwarding process:
RB1 checks the destination MAC. If the destination MAC equals the
local gateway MAC, the gateway function will terminate the L2
header and perform L3 routing.
RB1 looks up IP routing table information by destination IP and
Tenant ID to get IP next-hop information, which includes the
egress RBridge's gateway MAC (MAC2), tenant Label (VLAN 100), and
egress nickname (nick2). Using this information, RB1 will perform
inner Ethernet header encapsulation and TRILL encapsulation. RB1
will use MAC2 as the Inner.MacDA, MAC1 (RB1's own gateway MAC) as
the Inner.MacSA, VLAN 100 as the Inner.VLAN, nick2 as the egress
nickname, and nick1 as the ingress nickname.
RB1 looks up TRILL forwarding information by egress nickname and
sends the traffic to the TRILL next hop as per [<a href="./rfc6325" title=""Routing Bridges (RBridges): Base Protocol Specification"">RFC6325</a>]. The
traffic will be sent to RB3 or RB4 as a result of load-balancing.
Assuming that the traffic is forwarded to RB3, the following occurs:
3. Transit RBridge (RB3) forwarding process:
RB3 looks up TRILL forwarding information by egress nickname and
forwards the traffic to RB2 as per [<a href="./rfc6325" title=""Routing Bridges (RBridges): Base Protocol Specification"">RFC6325</a>].
4. Egress RBridge forwarding process:
As the egress nickname is RB2's own nickname, RB2 performs TRILL
decapsulation. It then checks the Inner.MacDA and, because that
MAC is equal to the local gateway MAC, performs inner Ethernet
header termination. Using the inner VLAN, RB2 finds the local
corresponding VRF and looks up the packet's destination IP address
in the VRF's IP routing table. The traffic is then locally
forwarded to ES2 with VLAN 20.
<span class="grey">Hao, 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="./rfc7956">RFC 7956</a> TRILL Distributed Layer 3 Gateway September 2016</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. TRILL Protocol Extensions</span>
If an edge RBridge RB1 participates in the distributed gateway
function, it announces its tenant gateway MAC and tenant Data Label
to the TRILL campus through the tenant Label and gateway MAC
APPsub-TLV. It should announce its local IPv4 and IPv6 prefixes
through the IPv4 Prefix APPsub-TLV and the IPv6 Prefix APPsub-TLV,
respectively. If RB1 has multiple nicknames, it can announce
one nickname for use by the distributed gateway, by using the
NickFlags APPsub-TLV with the SE flag set to 1.
The remote ingress RBridges belonging to the same routing domain use
this information to generate IP routing entries in that routing
domain. These RBridges use the nickname, tenant gateway MAC, and
tenant Label of RB1 to perform inter-subnet TRILL encapsulation when
they receive inter-subnet traffic from a local ES. The nickname is
used as the egress nickname, the tenant gateway MAC is used as the
Inner.MacDA, and the tenant Data Label is used as the Inner.Label.
The following APPsub-TLVs MUST be included in a TRILL GENINFO TLV in
E-L1FS FS-LSPs [<a href="./rfc7780" title=""Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates"">RFC7780</a>].
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. The Tenant Label and Gateway MAC APPsub-TLV</span>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tenant ID (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Resv1 | Label1 | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Resv2 | Label2 | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+....-+-+-+-+-+-+-+-+-+
| Tenant Gateway MAC (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+....-+-+-+-+-+-+-+-+-+
o Type: Set to the TENANT-GWMAC-LABEL sub-TLV type (7). 2 bytes,
because this APPsub-TLV appears in an extended TLV [<a href="./rfc7356" title=""IS-IS Flooding Scope Link State PDUs (LSPs)"">RFC7356</a>].
o Length: If the Label1 field is used to represent a VLAN, the
value of the Length field is 12. If the Label1 and Label2
fields are used to represent an FGL, the value of the
Length field is 14.
o Tenant ID: This identifies a Tenant ID unique across the TRILL
campus.
<span class="grey">Hao, 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="./rfc7956">RFC 7956</a> TRILL Distributed Layer 3 Gateway September 2016</span>
o Resv1: 4 bits that MUST be sent as zero and ignored on receipt.
o Label1: If the value of the Length field is 12, it identifies a
tenant Label corresponding to a VLAN ID. If the value of the
Length field is 14, it identifies the higher 12 bits of a tenant
Label corresponding to an FGL.
o Resv2: 4 bits that MUST be sent as zero and ignored on receipt.
Only present if the Length field is 14.
o Label2: This field has the lower 12 bits of the tenant Label
corresponding to an FGL. Only present if the Length field
is 14.
o Tenant Gateway MAC: This identifies the local gateway MAC
corresponding to the Tenant ID. The remote ingress RBridges use
the gateway MAC as the Inner.MacDA. The advertising TRILL
RBridge uses the gateway MAC to differentiate L2 intra-subnet
traffic and L3 inter-subnet traffic in the egress direction.
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. The SE Flag in the NickFlags APPsub-TLV</span>
The NickFlags APPsub-TLV is specified in [<a href="./rfc7780" title=""Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates"">RFC7780</a>], where the IN flag
is described. The SE Flag is assigned as follows:
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Nickname |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|IN|SE| RESV |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
NICKFLAG RECORD
o SE: If the SE flag is set to 1, it indicates that the advertising
RBridge suggests that the Nickname SHOULD be used as the
Inter-Subnet Egress nickname for inter-subnet traffic forwarding.
If the SE flag is set to 0, that Nickname SHOULD NOT be used for
that purpose. The SE flag is ignored if the NickFlags APPsub-TLV
is advertised by an RBridge that does not own the Nickname.
<span class="grey">Hao, 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="./rfc7956">RFC 7956</a> TRILL Distributed Layer 3 Gateway September 2016</span>
<span class="h3"><a class="selflink" id="section-7.3" href="#section-7.3">7.3</a>. The IPv4 Prefix APPsub-TLV</span>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+
| Tenant ID | (4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+
|PrefixLength(1)| (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+
| Prefix (1) | (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+
| ..... | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+
| ..... | (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+
|PrefixLength(N)| (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+
| Prefix (N) | (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+
o Type: Set to the IPV4-PREFIX sub-TLV type (8). 2 bytes, because
this APPsub-TLV appears in an extended TLV [<a href="./rfc7356" title=""IS-IS Flooding Scope Link State PDUs (LSPs)"">RFC7356</a>].
o Total Length: This 2-byte unsigned integer indicates the total
length of the Tenant ID, Prefix Length, and Prefix fields,
in octets. A value of 0 indicates that no IPv4 prefix is being
advertised.
o Tenant ID: This identifies a Tenant ID unique across the TRILL
campus.
o Prefix Length: The Prefix Length field indicates the length,
in bits, of the IPv4 address prefix. A length of 0 (i.e., the
prefix itself is 0 octets) indicates a prefix that matches all
IPv4 addresses.
o Prefix: The Prefix field contains an IPv4 address prefix,
followed by enough trailing bits to make the end of the field
fall on an octet boundary. Note that the value of the trailing
bits is irrelevant. For example, if the Prefix Length is 12,
indicating 12 bits, then the Prefix is 2 octets and the
low-order 4 bits of the Prefix are irrelevant.
<span class="grey">Hao, 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="./rfc7956">RFC 7956</a> TRILL Distributed Layer 3 Gateway September 2016</span>
<span class="h3"><a class="selflink" id="section-7.4" href="#section-7.4">7.4</a>. The IPv6 Prefix APPsub-TLV</span>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+
| Tenant ID | (4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+
|PrefixLength(1)| (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+
| Prefix (1) | (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+
| ..... | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+
| ..... | (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+
|PrefixLength(N)| (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+
| Prefix (N) | (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+
o Type: Set to the IPV6-PREFIX sub-TLV type (9). 2 bytes, because
this APPsub-TLV appears in an extended TLV [<a href="./rfc7356" title=""IS-IS Flooding Scope Link State PDUs (LSPs)"">RFC7356</a>].
o Total Length: This 2-byte unsigned integer indicates the total
length of the Tenant ID, Prefix Length, and Prefix fields,
in octets. A value of 0 indicates that no IPv6 prefix is being
advertised.
o Tenant ID: This identifies a Tenant ID unique across the TRILL
campus.
o Prefix Length: The Prefix Length field indicates the length,
in bits, of the IPv6 address prefix. A length of 0 (i.e., the
prefix itself is 0 octets) indicates a prefix that matches all
IPv6 addresses.
o Prefix: The Prefix field contains an IPv6 address prefix,
followed by enough trailing bits to make the end of the field
fall on an octet boundary. Note that the value of the trailing
bits is irrelevant. For example, if the Prefix Length is 100,
indicating 100 bits, then the Prefix is 13 octets and the
low-order 4 bits of the Prefix are irrelevant.
<span class="grey">Hao, et al. Standards Track [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc7956">RFC 7956</a> TRILL Distributed Layer 3 Gateway September 2016</span>
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Security Considerations</span>
Correct configuration of the participating edge RBridges is important
to assure that data is not delivered to the wrong tenant, as such
incorrect delivery would violate security constraints. IS-IS
security [<a href="./rfc5310" title=""IS-IS Generic Cryptographic Authentication"">RFC5310</a>] can be used to secure the information advertised
by the edge RBridges in LSPs and FS-LSPs.
To avoid the mishandling of data in flight, see <a href="#section-5.2">Section 5.2</a> for
constraints on the reuse of a tenant Label and on tenant gateway MAC
changes. Selecting tenant Labels and IDs in a pseudorandom fashion
[<a href="./rfc4086" title=""Randomness Requirements for Security"">RFC4086</a>] can make it more difficult for an adversary to guess a
tenant Label or ID that is in use.
Particularly sensitive data should be encrypted end-to-end --
that is, from the source ES to the destination ES. Since the TRILL
campus is, for the most part, transparent to ES traffic, such ESs are
free to use whatever end-to-end security protocol they would like.
For general TRILL security considerations, see [<a href="./rfc6325" title=""Routing Bridges (RBridges): Base Protocol Specification"">RFC6325</a>].
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Management Considerations</span>
The configuration at each RBridge to support the distributed L3
gateway feature is visible, via the link-state database, to all other
RBridges in the campus. Operations, Administration, and Maintenance
(OAM) facilities for TRILL are primarily specified in [<a href="./rfc7455" title=""Transparent Interconnection of Lots of Links (TRILL): Fault Management"">RFC7455</a>]
and [<a href="./rfc7456" title=""Loss and Delay Measurement in Transparent Interconnection of Lots of Links (TRILL)"">RFC7456</a>].
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. IANA Considerations</span>
IANA has assigned three APPsub-TLV type numbers that are lower than
255 in the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application
Identifier 1" registry. The registry has been updated as follows:
Type Name Reference
---- ------------------ -------------
7 TENANT-GWMAC-LABEL this document
8 IPV4-PREFIX this document
9 IPV6-PREFIX this document
<span class="grey">Hao, et al. Standards Track [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc7956">RFC 7956</a> TRILL Distributed Layer 3 Gateway September 2016</span>
IANA has assigned a flag bit in the NickFlags APPsub-TLV as described
in <a href="#section-7.2">Section 7.2</a> and updated the "NickFlags Bits" registry, created by
[<a href="./rfc7780" title=""Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates"">RFC7780</a>], as follows:
Bit Mnemonic Description Reference
----- -------- ------------------- -------------
1 SE Inter-Subnet Egress this document
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. References</span>
<span class="h3"><a class="selflink" id="section-11.1" href="#section-11.1">11.1</a>. Normative References</span>
[<a id="ref-IS-IS">IS-IS</a>] International Organization for Standardization,
"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 Standard 10589, 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>,
DOI 10.17487/RFC2119, March 1997,
<<a href="http://www.rfc-editor.org/info/rfc2119">http://www.rfc-editor.org/info/rfc2119</a>>.
[<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="http://www.rfc-editor.org/info/rfc6325">http://www.rfc-editor.org/info/rfc6325</a>>.
[<a id="ref-RFC7172">RFC7172</a>] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and
D. Dutt, "Transparent Interconnection of Lots of Links
(TRILL): Fine-Grained Labeling", <a href="./rfc7172">RFC 7172</a>,
DOI 10.17487/RFC7172, May 2014,
<<a href="http://www.rfc-editor.org/info/rfc7172">http://www.rfc-editor.org/info/rfc7172</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="http://www.rfc-editor.org/info/rfc7176">http://www.rfc-editor.org/info/rfc7176</a>>.
<span class="grey">Hao, et al. Standards Track [Page 25]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-26" ></span>
<span class="grey"><a href="./rfc7956">RFC 7956</a> TRILL Distributed Layer 3 Gateway September 2016</span>
[<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="http://www.rfc-editor.org/info/rfc7356">http://www.rfc-editor.org/info/rfc7356</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="http://www.rfc-editor.org/info/rfc7780">http://www.rfc-editor.org/info/rfc7780</a>>.
<span class="h3"><a class="selflink" id="section-11.2" href="#section-11.2">11.2</a>. Informative References</span>
[<a id="ref-RFC826">RFC826</a>] Plummer, D., "Ethernet Address Resolution Protocol: Or
Converting Network Protocol Addresses to 48.bit Ethernet
Address for Transmission on Ethernet Hardware", STD 37,
<a href="./rfc826">RFC 826</a>, DOI 10.17487/RFC0826, November 1982,
<<a href="http://www.rfc-editor.org/info/rfc826">http://www.rfc-editor.org/info/rfc826</a>>.
[<a id="ref-RFC4086">RFC4086</a>] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", <a href="https://www.rfc-editor.org/bcp/bcp106">BCP 106</a>, <a href="./rfc4086">RFC 4086</a>,
DOI 10.17487/RFC4086, June 2005,
<<a href="http://www.rfc-editor.org/info/rfc4086">http://www.rfc-editor.org/info/rfc4086</a>>.
[<a id="ref-RFC4861">RFC4861</a>] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", <a href="./rfc4861">RFC 4861</a>,
DOI 10.17487/RFC4861, September 2007,
<<a href="http://www.rfc-editor.org/info/rfc4861">http://www.rfc-editor.org/info/rfc4861</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="http://www.rfc-editor.org/info/rfc5310">http://www.rfc-editor.org/info/rfc5310</a>>.
[<a id="ref-RFC7379">RFC7379</a>] Li, Y., Hao, W., Perlman, R., Hudson, J., and H. Zhai,
"Problem Statement and Goals for Active-Active Connection
at the Transparent Interconnection of Lots of Links
(TRILL) Edge", <a href="./rfc7379">RFC 7379</a>, DOI 10.17487/RFC7379,
October 2014, <<a href="http://www.rfc-editor.org/info/rfc7379">http://www.rfc-editor.org/info/rfc7379</a>>.
<span class="grey">Hao, et al. Standards Track [Page 26]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-27" ></span>
<span class="grey"><a href="./rfc7956">RFC 7956</a> TRILL Distributed Layer 3 Gateway September 2016</span>
[<a id="ref-RFC7455">RFC7455</a>] Senevirathne, T., Finn, N., Salam, S., Kumar, D., Eastlake
3rd, D., Aldrin, S., and Y. Li, "Transparent
Interconnection of Lots of Links (TRILL): Fault
Management", <a href="./rfc7455">RFC 7455</a>, DOI 10.17487/RFC7455, March 2015,
<<a href="http://www.rfc-editor.org/info/rfc7455">http://www.rfc-editor.org/info/rfc7455</a>>.
[<a id="ref-RFC7456">RFC7456</a>] Mizrahi, T., Senevirathne, T., Salam, S., Kumar, D., and
D. Eastlake 3rd, "Loss and Delay Measurement in
Transparent Interconnection of Lots of Links (TRILL)",
<a href="./rfc7456">RFC 7456</a>, DOI 10.17487/RFC7456, March 2015,
<<a href="http://www.rfc-editor.org/info/rfc7456">http://www.rfc-editor.org/info/rfc7456</a>>.
Acknowledgments
The authors wish to acknowledge the important contributions of Donald
Eastlake, Gayle Noble, Mohammed Umair, Susan Hares, Guangrui Wu,
Zhenbin Li, Zhibo Hu, Liang Xia, Scott Bradner, Stephen Farrell,
Shawn Emery, Ben Campbell, Russ White, Kathleen Moriarty, Suresh
Krishnan, Mirja Kuehlewind, and Francis Dupont.
<span class="grey">Hao, et al. Standards Track [Page 27]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-28" ></span>
<span class="grey"><a href="./rfc7956">RFC 7956</a> TRILL Distributed Layer 3 Gateway September 2016</span>
Authors' Addresses
Weiguo Hao
Huawei Technologies
101 Software Avenue
Nanjing 210012
China
Phone: +86-25-56623144
Email: haoweiguo@huawei.com
Yizhou Li
Huawei Technologies
101 Software Avenue
Nanjing 210012
China
Phone: +86-25-56625375
Email: liyizhou@huawei.com
Andrew Qu
MediaTec
Email: laodulaodu@gmail.com
Muhammad Durrani
Equinix Inc.
Email: mdurrani@equinix.com
Ponkarthick Sivamurugan
IP Infusion
RMZ Centennial
Mahadevapura Post
Bangalore 560048
Email: Ponkarthick.sivamurugan@ipinfusion.com
Hao, et al. Standards Track [Page 28]
</pre>
|
