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
|
<pre>Internet Engineering Task Force (IETF) A. Atlas
Request for Comments: 8320 K. Tiruveedhula
Category: Standards Track C. Bowers
ISSN: 2070-1721 Juniper Networks
J. Tantsura
Individual
IJ. Wijnands
Cisco Systems, Inc.
February 2018
<span class="h1">LDP Extensions to Support Maximally Redundant Trees</span>
Abstract
This document specifies extensions to the Label Distribution Protocol
(LDP) to support the creation of Label Switched Paths (LSPs) for
Maximally Redundant Trees (MRTs). A prime use of MRTs is for unicast
and multicast IP/LDP Fast Reroute, which we will refer to as
"MRT-FRR".
The sole protocol extension to LDP is simply the ability to advertise
an MRT Capability. This document describes that extension and the
associated behavior expected for Label Switching Routers (LSRs) and
Label Edge Routers (LERs) advertising the MRT Capability.
MRT-FRR uses LDP multi-topology extensions, so three multi-topology
IDs have been allocated from the MPLS MT-ID space.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc7841#section-2">Section 2 of RFC 7841</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="https://www.rfc-editor.org/info/rfc8320">https://www.rfc-editor.org/info/rfc8320</a>.
<span class="grey">Atlas, 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="./rfc8320">RFC 8320</a> LDP Extensions to Support MRTs February 2018</span>
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
<span class="grey">Atlas, 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="./rfc8320">RFC 8320</a> LDP Extensions to Support MRTs February 2018</span>
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2">2</a>. Requirements Language . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-3">3</a>. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-4">4</a>. Overview of LDP Signaling Extensions for MRT . . . . . . . . <a href="#page-6">6</a>
<a href="#section-4.1">4.1</a>. MRT Capability Advertisement . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-4.1.1">4.1.1</a>. Interaction of MRT Capability and MT Capability . . . <a href="#page-7">7</a>
4.1.2. Interaction of LDP MRT Capability with IPv4 and IPv6 8
<a href="#section-4.2">4.2</a>. Use of the Rainbow MRT MT-ID . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-4.3">4.3</a>. MRT-Blue and MRT-Red FECs . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
4.4. Interaction of MRT-Related LDP Advertisements with the
MRT Topology and Computations . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-5">5</a>. LDP MRT FEC Advertisements . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-5.1">5.1</a>. MRT-Specific Behavior . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-5.1.1">5.1.1</a>. ABR Behavior and Use of the Rainbow FEC . . . . . . . <a href="#page-10">10</a>
<a href="#section-5.1.2">5.1.2</a>. Proxy-Node Attachment Router Behavior . . . . . . . . <a href="#page-11">11</a>
5.2. LDP Protocol Procedures in the Context of MRT Label
Distribution . . . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-5.2.1">5.2.1</a>. LDP Peer in <a href="./rfc5036">RFC 5036</a> . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-5.2.2">5.2.2</a>. Next Hop in <a href="./rfc5036">RFC 5036</a> . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-5.2.3">5.2.3</a>. Egress LSR in <a href="./rfc5036">RFC 5036</a> . . . . . . . . . . . . . . . <a href="#page-13">13</a>
5.2.4. Use of Rainbow FEC to Satisfy Label Mapping Existence
Requirements in <a href="./rfc5036">RFC 5036</a> . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-5.2.5">5.2.5</a>. Validating FECs in the Routing Table . . . . . . . . <a href="#page-15">15</a>
<a href="#section-5.2.6">5.2.6</a>. Recognizing New FECs . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-5.2.7">5.2.7</a>. Not Propagating Rainbow FEC Label Mappings . . . . . <a href="#page-15">15</a>
<a href="#section-6">6</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
7. Potential Restrictions on MRT-Related MT-ID Values Imposed by
<a href="./rfc6420">RFC 6420</a> . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-8">8</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
<a href="#section-9">9</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
<a href="#section-9.1">9.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
<a href="#section-9.2">9.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-19">19</a>
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-21">21</a>
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-21">21</a>
<span class="grey">Atlas, 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="./rfc8320">RFC 8320</a> LDP Extensions to Support MRTs February 2018</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
This document describes the LDP signaling extensions and associated
behavior necessary to support the architecture that defines how IP/
LDP Fast Reroute can use MRTs [<a href="./rfc7812" title=""An Architecture for IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR)"">RFC7812</a>]. The current document
provides a brief description of the MRT-FRR architecture, focusing on
the aspects most directly related to LDP signaling. The complete
description and specification of the MRT-FRR architecture can be
found in [<a href="./rfc7812" title=""An Architecture for IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR)"">RFC7812</a>].
At least one common standardized algorithm (e.g., the MRT Lowpoint
algorithm explained and fully documented in [<a href="./rfc7811" title=""An Algorithm for Computing IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR)"">RFC7811</a>]) is required to
be deployed so that the routers supporting MRT computation
consistently compute the same MRTs. LDP depends on an IGP for
computation of MRTs and alternates. Extensions to OSPF are defined
in [<a href="#ref-OSPF-MRT" title=""OSPF Extensions to Support Maximally Redundant Trees"">OSPF-MRT</a>]. Extensions to IS-IS are defined in [<a href="#ref-IS-IS-MRT">IS-IS-MRT</a>].
MRT can also be used to protect multicast traffic (signaled via PIM
or Multipoint LDP (mLDP)) using either global protection or local
protection as described in [<a href="#ref-ARCH" title=""An Architecture for Multicast Protection Using Maximally Redundant Trees"">ARCH</a>]. An MRT path can be used to
provide node-protection for mLDP traffic via the mechanisms described
in [<a href="./rfc7715" title=""Multipoint LDP (mLDP) Node Protection"">RFC7715</a>]; an MRT path can also be used to provide link protection
for mLDP traffic.
For each destination, IP/LDP Fast Reroute with MRT (MRT-FRR) creates
two alternate destination-based trees separate from the shortest-path
forwarding used during stable operation. LDP uses the multi-topology
extensions [<a href="./rfc7307" title=""LDP Extensions for Multi-Topology"">RFC7307</a>] to signal Forwarding Equivalency Classes (FECs)
for these two sets of forwarding trees, MRT-Blue and MRT-Red.
In order to create MRT paths and support IP/LDP Fast Reroute, a new
capability extension is needed for LDP. An LDP implementation
supporting MRT MUST also follow the rules described here for
originating and managing FECs related to MRT, as indicated by their
multi-topology ID. Network reconvergence is described in [<a href="./rfc7812" title=""An Architecture for IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR)"">RFC7812</a>]
and the worst-case network convergence time can be flooded via the
extension in [<a href="#ref-PARAM-SYNC">PARAM-SYNC</a>].
IP/LDP Fast Reroute using MRTs can provide 100% coverage for link and
node failures in an arbitrary network topology where the failure
doesn't partition the network. It can also be deployed
incrementally; an MRT Island is formed of connected supporting
routers and the MRTs are computed inside that island.
<span class="grey">Atlas, 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="./rfc8320">RFC 8320</a> LDP Extensions to Support MRTs February 2018</span>
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Requirements Language</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
<a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>] [<a href="./rfc8174" title=""Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"">RFC8174</a>] when, and only when, they appear in all
capitals, as shown here.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Terminology</span>
For ease of reading, some of the terminology defined in [<a href="./rfc7812" title=""An Architecture for IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR)"">RFC7812</a>] is
repeated here. Please refer to <a href="./rfc7812#section-3">Section 3 of [RFC7812]</a> for a more
complete list.
Redundant Trees (RTs): A pair of trees where the path from any node
X to the root R along the first tree is node-disjoint with the
path from the same node X to the root along the second tree.
Redundant trees can always be computed in 2-connected graphs.
Maximally Redundant Trees (MRTs): A pair of trees where the path
from any node X to the root R along the first tree and the path
from the same node X to the root along the second tree share the
minimum number of nodes and the minimum number of links. Each
such shared node is a cut-vertex. Any shared links are cut-links.
In graphs that are not 2-connected, it is not possible to compute
RTs. However, it is possible to compute MRTs. MRTs are maximally
redundant in the sense that they are as redundant as possible
given the constraints of the network graph.
MRT-Red: MRT-Red is used to describe one of the two MRTs; it is used
to describe the associated forwarding topology and MPLS Multi-
Topology Identifier (MT-ID).
MRT-Blue: MRT-Blue is used to describe one of the two MRTs; it is
used to described the associated forwarding topology and MPLS
MT-ID.
Rainbow MRT: It is useful to have an MPLS MT-ID that refers to the
multiple MRT forwarding topologies and to the default forwarding
topology. This is referred to as the "Rainbow MRT MPLS MT-ID" and
is used by LDP to reduce signaling and permit the same label to
always be advertised to all peers for the same (MT-ID, Prefix).
MRT Island: The set of routers that support a particular MRT Profile
and the links connecting them that support MRT.
<span class="grey">Atlas, 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="./rfc8320">RFC 8320</a> LDP Extensions to Support MRTs February 2018</span>
Island Border Router (IBR): A router in the MRT Island that is
connected to a router not in the MRT Island, both of which are in
a common area or level.
Island Neighbor (IN): A router that is not in the MRT Island but is
adjacent to an IBR and in the same area/level as the IBR.
There are several places in this document where the construction
"red(blue) FEC" is used to cover the case of the red FEC and the case
of the blue FEC, independently. As an example, consider the sentence
"When the ABR requires best-area behavior for a red(blue) FEC, it
MUST withdraw any existing label mappings advertisements for the
corresponding Rainbow FEC and advertise label mappings for the
red(blue) FEC." This sentence should be read as applying to red
FECs. Then it should be read as applying to blue FECs.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Overview of LDP Signaling Extensions for MRT</span>
Routers need to know which of their LDP neighbors support MRT. This
is communicated using the MRT Capability Advertisement. Supporting
MRT indicates several different aspects of behavior, as listed below.
1. Sending and receiving multi-topology FEC elements, as defined in
[<a href="./rfc7307" title=""LDP Extensions for Multi-Topology"">RFC7307</a>].
2. Understanding the Rainbow MRT MT-ID and applying the associated
labels to all relevant MT-IDs.
3. Advertising the Rainbow MRT FEC to the appropriate neighbors for
the appropriate prefix.
4. If acting as LDP egress for a prefix in the default topology,
also acting as egress for the same prefix in MRT-Red and
MRT-Blue.
5. For a FEC learned from a neighbor that does not support MRT,
originating FECs for MRT-Red and MRT-Blue with the same prefix.
This MRT Island egress behavior is to support an MRT Island that
does not include all routers in the area/level.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. MRT Capability Advertisement</span>
A new MRT Capability Parameter TLV is defined in accordance with the
LDP Capability definition guidelines [<a href="./rfc5561" title=""LDP Capabilities"">RFC5561</a>].
The LDP MRT Capability can be advertised during LDP session
initialization or after the LDP session is established.
Advertisement of the MRT Capability indicates support of the
<span class="grey">Atlas, 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="./rfc8320">RFC 8320</a> LDP Extensions to Support MRTs February 2018</span>
procedures for establishing the MRT-Blue and MRT-Red Label Switched
Paths (LSPs) detailed in this document. If the peer has not
advertised the MRT Capability, then it indicates that LSR does not
support MRT procedures.
If a router advertises the LDP MRT Capability to its peer, but the
peer has not advertised the MRT Capability, then the router MUST NOT
advertise MRT-related FEC-label bindings to that peer.
The following is the format of the MRT Capability Parameter.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| MRT Capability (0x050E) | Length (= 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved |
+-+-+-+-+-+-+-+-+
MRT Capability TLV Format
Where:
U-bit: The unknown TLV bit MUST be 1. A router that does not
recognize the MRT Capability TLV will silently ignore the TLV and
process the rest of the message as if the unknown TLV did not
exist.
F-bit: The forward unknown TLV bit MUST be 0 as required by
<a href="./rfc5561#section-3">Section 3 of [RFC5561]</a>.
MRT Capability: 0x050E
Length: The length (in octets) of the TLV. Its value is 1.
S-bit: The State bit MUST be 1 if used in the LDP Initialization
message. MAY be set to 0 or 1 in the dynamic Capability message
to advertise or withdraw the capability, respectively, as
described in [<a href="./rfc5561" title=""LDP Capabilities"">RFC5561</a>].
<span class="h4"><a class="selflink" id="section-4.1.1" href="#section-4.1.1">4.1.1</a>. Interaction of MRT Capability and MT Capability</span>
An LSR advertising the LDP MRT Capability MUST also advertise the LDP
Multi-Topology (MT) Capability. If an LSR negotiates the LDP MRT
Capability with an LDP neighbor without also negotiating the LDP MT
Capability, the LSR MUST behave as if the LDP MRT Capability was not
negotiated and respond with the "MRT Capability negotiated without MT
Capability" status code in the LDP Notification message (defined in
<span class="grey">Atlas, 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="./rfc8320">RFC 8320</a> LDP Extensions to Support MRTs February 2018</span>
the document). The E-bit of this Notification should be set to 0 to
indicate that this is an Advisory Notification. The LDP session
SHOULD NOT be terminated.
<span class="h4"><a class="selflink" id="section-4.1.2" href="#section-4.1.2">4.1.2</a>. Interaction of LDP MRT Capability with IPv4 and IPv6</span>
The MRT LDP Capability Advertisement does not distinguish between
IPv4 and IPv6 address families. An LSR that advertises the MRT LDP
Capability is expected to advertise MRT-related FEC-label bindings
for the same address families for which it advertises shortest-path
FEC-label bindings. Therefore, an LSR advertising MRT LDP Capability
and shortest-path FEC-label bindings for IPv4 only (or IPv6 only)
would be expected to advertise MRT-related FEC-label binding for IPv4
only (or IPv6 only). An LSR advertising the MRT LDP Capability and
shortest-path FEC-label bindings for BOTH IPv4 and IPv6 is expected
to advertise MRT-related FEC-label bindings for BOTH IPv4 and IPv6.
In this scenario, advertising MRT-related FEC-label bindings only for
IPv4 only (or only for IPv6) is not supported.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Use of the Rainbow MRT MT-ID</span>
<a href="./rfc7812#section-10.1">Section 10.1 of [RFC7812]</a> describes the need for an Area Border
Router (ABR) to have different neighbors use different MPLS labels
when sending traffic to the ABR for the same FEC. More detailed
discussion of the Rainbow MRT MT-ID is provided in <a href="#section-5.1.1">Section 5.1.1</a>.
Another use for the Rainbow MRT MT-ID is for an LSR to send the
Rainbow MRT MT-ID with an IMPLICIT_NULL label to indicate
penultimate-hop-popping for all three types of FECs (shortest path,
red, and blue). The EXPLICIT_NULL label advertised using the Rainbow
MRT MT-ID similarly applies to all the types of FECs. Note that the
only scenario in which it is generally useful to advertise the
implicit or explicit null label for all three FEC types is when the
FEC refers to the LSR itself. See <a href="#section-5.2.3">Section 5.2.3</a> for more details.
The value of the Rainbow MRT MPLS MT-ID (3945) has been assigned by
IANA from the MPLS MT-ID space.
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. MRT-Blue and MRT-Red FECs</span>
To provide MRT support in LDP, the MT Prefix FEC is used. [<a href="./rfc7812" title=""An Architecture for IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR)"">RFC7812</a>]
defines the Default MRT Profile. <a href="#section-8">Section 8</a> specifies the values in
the "MPLS Multi-Topology Identifiers" registry for the MRT-Red and
MRT-Blue MPLS MT-IDs associated with the Default MRT Profile (3946
and 3947).
<span class="grey">Atlas, 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="./rfc8320">RFC 8320</a> LDP Extensions to Support MRTs February 2018</span>
As described in <a href="./rfc7812#section-8.1">Section 8.1 of [RFC7812]</a>, when a new MRT Profile is
defined, new and unique values should be allocated from the "MPLS
Multi-Topology Identifiers" registry, corresponding to the MRT-Red
and MRT-Blue MT-ID values for the new MRT Profile.
The MT Prefix FEC encoding is defined in [<a href="./rfc7307" title=""LDP Extensions for Multi-Topology"">RFC7307</a>] and is used
without alteration for advertising label mappings for MRT-Blue,
MRT-Red, and Rainbow MRT FECs.
<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>. Interaction of MRT-Related LDP Advertisements with the MRT</span>
<span class="h3"> Topology and Computations</span>
[<a id="ref-RFC7811">RFC7811</a>] and [<a href="./rfc7812" title=""An Architecture for IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR)"">RFC7812</a>] describe how the MRT topology is created
based on information in IGP advertisements. The MRT topology and
computations rely on IGP advertisements. The presence or absence of
MRT-related LDP advertisements does not affect the MRT topology or
the MRT-Red and MRT-Blue next hops computed for that topology.
As an example, consider a network where all nodes are running MRT IGP
extensions to determine the MRT topology, which is then used to
compute MRT-Red and MRT-Blue next hops. The network operator also
configures the nodes in this network to exchange MRT-related LDP
advertisements in order to distribute MPLS labels corresponding to
those MRT next hops. Suppose that, due to a misconfiguration on one
particular link, the MRT-related LDP advertisements are not being
properly exchanged for that link. Since the MRT-related IGP
advertisements for the link are still being distributed, the link is
still included in the MRT topology and computations. In this
scenario, there will be missing MPLS forwarding entries corresponding
to paths that use the misconfigured link.
Note that the situation is analogous to the interaction of normal LDP
advertisements and IGP advertisements for shortest-path forwarding.
Deactivating the distribution of labels for normal shortest-path FECs
on a link does not change the topology on which the Shortest Path
First (SPF) algorithm is run by the IGP.
"LDP IGP Synchronization" [<a href="./rfc5443" title=""LDP IGP Synchronization"">RFC5443</a>] addresses the issue of the LDP
topology not matching the IGP topology by advertising the maximum IGP
cost on links where LDP is not fully operational. This makes the IGP
topology match the LDP topology. As described in <a href="./rfc7812#section-7.3.1">Section 7.3.1 of
[RFC7812]</a>, MRT is designed to be compatible with the LDP IGP
synchronization mechanism. When the IGP advertises the maximum cost
on a link where LDP is not fully operational, the link is excluded
from MRT Island formation, which prevents the MRT algorithm from
creating any paths using that link.
<span class="grey">Atlas, 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="./rfc8320">RFC 8320</a> LDP Extensions to Support MRTs February 2018</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. LDP MRT FEC Advertisements</span>
This sections describes how and when labels for MRT-Red and MRT-Blue
FECs are advertised. In order to provide protection paths that are
immediately usable by the point of local repair in the event of a
failure, the associated LSPs need to be created before a failure
occurs.
In this section, we will use the term "shortest-path FEC" to refer to
the usual FEC associated with the shortest-path destination-based
forwarding tree for a given prefix as determined by the IGP. We will
use the terms "red FEC" and "blue FEC" to refer to FECs associated
with the MRT-Red and MRT-Blue destination-based forwarding trees for
a given prefix as determined by a particular MRT algorithm.
We first describe label distribution behavior specific to MRT. Then,
we provide the correct interpretation of several important concepts
in [<a href="./rfc5036" title=""LDP Specification"">RFC5036</a>] in the context of MRT FEC label distribution.
[<a id="ref-RFC5036">RFC5036</a>] specifies two different Label Distribution Control Modes
(Independent and Ordered), two different Label Retention Modes
(Conservative and Liberal), and two different Label Advertisement
Modes (Downstream Unsolicited and Downstream on Demand). The current
specification for LDP MRT requires that the same Label Distribution
Control, Label Retention, and Label Advertisement modes be used for
the shortest-path FECs and the MRT FECs.
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. MRT-Specific Behavior</span>
<span class="h4"><a class="selflink" id="section-5.1.1" href="#section-5.1.1">5.1.1</a>. ABR Behavior and Use of the Rainbow FEC</span>
<a href="./rfc7812#section-10.1">Section 10.1 of [RFC7812]</a> describes the need for an ABR to have
different neighbors use different MPLS labels when sending traffic to
the ABR for the same FEC. The method to accomplish this using the
Rainbow MRT MT-ID is described in detail in [<a href="./rfc7812" title=""An Architecture for IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR)"">RFC7812</a>]. Here we
provide a brief summary. To those LDP peers in the same area as the
best route to the destination, the ABR advertises two different
labels corresponding to the MRT-Red and MRT-Blue forwarding trees for
the destination. An LDP peer receiving these advertisements forwards
MRT traffic to the ABR using these two different labels, depending on
the FEC of the traffic. We refer to this as "best-area advertising
and forwarding behavior", which is identical to normal MRT behavior.
For all other LDP peers supporting MRT, the ABR advertises a FEC-
label binding for the FEC, which is in the Rainbow MRT MT-ID, with
the label that corresponds to that FEC in the default forwarding tree
for the destination. An LDP peer receiving this advertisement
forwards MRT traffic to the ABR using this label, for both MRT-Red
<span class="grey">Atlas, 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="./rfc8320">RFC 8320</a> LDP Extensions to Support MRTs February 2018</span>
and MRT-Blue traffic. We refer to this as "non-best-area advertising
and forwarding behavior".
The use of the Rainbow-FEC by the ABR for non-best-area
advertisements is RECOMMENDED. An ABR MAY advertise the label for
the default topology in separate MRT-Blue and MRT-Red advertisements.
An LSR advertising the MRT Capability MUST recognize the Rainbow MRT
MT-ID and associate the advertised label with the specific prefix
with the MRT-Red and MRT-Blue MT-IDs associated with all MRT Profiles
that advertise LDP as the forwarding mechanism.
Due to changes in topology or configuration, an ABR and a given LDP
peer may need to transition from best-area advertising and forwarding
behavior to non-best-area behavior for a given destination, and vice
versa. When the ABR requires best-area behavior for a red(blue) FEC,
it MUST withdraw any existing label mappings advertisements for the
corresponding Rainbow FEC and advertise label mappings for the
red(blue) FEC. When the ABR requires non-best-area behavior for a
red(blue) FEC, it MUST withdraw any existing label mappings for both
red and blue FECs and advertise label mappings for the corresponding
Rainbow FEC label-binding.
In this transition, an ABR should never advertise a red(blue) FEC
before withdrawing the corresponding Rainbow FEC (or vice versa).
However, should this situation occur, the expected behavior of an LSR
receiving these conflicting advertisements is defined as follows:
- If an LSR receives a label mapping advertisement for a Rainbow FEC
from an MRT LDP peer while it still retains a label mapping for
the corresponding red or blue FEC, the LSR MUST continue to use
the label mapping for the red or blue FEC, and it MUST send a
Label Release message corresponding to the Rainbow FEC label
advertisement.
- If an LSR receives a label mapping advertisement for a red or blue
FEC while it still retains a label mapping for the corresponding
Rainbow FEC, the LSR MUST continue to use the label mapping for
the Rainbow FEC, and it MUST send a Label Release message
corresponding to the red or blue FEC label advertisement.
<span class="h4"><a class="selflink" id="section-5.1.2" href="#section-5.1.2">5.1.2</a>. Proxy-Node Attachment Router Behavior</span>
<a href="./rfc7812#section-11.2">Section 11.2 of [RFC7812]</a> describes how MRT provides FRR protection
for multi-homed prefixes using calculations involving a named proxy-
node. This covers the scenario where a prefix is originated by a
router in the same area as the MRT Island, but outside of the MRT
Island. It also covers the scenario of a prefix being advertised by
multiple routers in the MRT Island.
<span class="grey">Atlas, 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="./rfc8320">RFC 8320</a> LDP Extensions to Support MRTs February 2018</span>
In the named proxy-node calculation, each multi-homed prefix is
represented by a conceptual proxy-node that is attached to two real
proxy-node attachment routers. (A single proxy-node attachment
router is allowed in the case of a prefix advertised by a same area
router outside of the MRT Island, which is singly connected to the
MRT Island.) All routers in the MRT Island perform the same
calculations to determine the same two proxy-node attachment routers
for each multi-homed prefix. <a href="./rfc7811#section-5.9">Section 5.9 of [RFC7811]</a> describes the
procedure for identifying one proxy-node attachment router as "red"
and one as "blue" with respect to the multi-homed prefix, and
computing the MRT red and blue next hops to reach those red and blue
proxy-node attachment routers.
In terms of LDP behavior, a red proxy-node attachment router for a
given prefix MUST originate a label mapping for the red FEC for that
prefix, while the blue proxy-node attachment router for a given
prefix MUST originate a label mapping for the blue FEC for that
prefix. If the red(blue) proxy-node attachment router is an Island
Border Router (IBR), then when it receives a packet with the label
corresponding to the red(blue) FEC for a prefix, it MUST forward the
packet to the Island Neighbor (IN) whose cost was used in the
selection of the IBR as a proxy-node attachment router. The IBR MUST
swap the incoming label for the outgoing label corresponding to the
shortest-path FEC for the prefix advertised by the IN. In the case
where the IN does not support LDP, the IBR MUST pop the incoming
label and forward the packet to the IN.
If the proxy-node attachment router is not an IBR, then the packet
MUST be removed from the MRT forwarding topology and sent along the
interface(s) that caused the router to advertise the prefix. This
interface might be out of the area/level/AS.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. LDP Protocol Procedures in the Context of MRT Label Distribution</span>
[<a id="ref-RFC5036">RFC5036</a>] specifies the LDP label distribution procedures for
shortest-path FECs. In general, the same procedures can be applied
to the distribution of label mappings for red and blue FECs, provided
that the procedures are interpreted in the context of MRT FEC label
distribution. The correct interpretation of several important
concepts in [<a href="./rfc5036" title=""LDP Specification"">RFC5036</a>] in the context of MRT FEC label distribution is
provided below.
<span class="h4"><a class="selflink" id="section-5.2.1" href="#section-5.2.1">5.2.1</a>. LDP Peer in <a href="./rfc5036">RFC 5036</a></span>
In the context of distributing label mappings for red and blue FECs,
we restrict the LDP peer in [<a href="./rfc5036" title=""LDP Specification"">RFC5036</a>] to mean LDP peers for which the
LDP MRT Capability has been negotiated. In order to make this
distinction clear, in this document we will use the term "MRT LDP
<span class="grey">Atlas, 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="./rfc8320">RFC 8320</a> LDP Extensions to Support MRTs February 2018</span>
peer" to refer to an LDP peer for which the LDP MRT Capability has
been negotiated.
<span class="h4"><a class="selflink" id="section-5.2.2" href="#section-5.2.2">5.2.2</a>. Next Hop in <a href="./rfc5036">RFC 5036</a></span>
Several procedures in [<a href="./rfc5036" title=""LDP Specification"">RFC5036</a>] use the next hop of a (shortest-path)
FEC to determine behavior. The next hop of the shortest-path FEC is
based on the shortest-path forwarding tree to the prefix associated
with the FEC. When the procedures of [<a href="./rfc5036" title=""LDP Specification"">RFC5036</a>] are used to
distribute label mapping for red and blue FECs, the next hop for the
red(blue) FEC is based on the MRT-Red(Blue) forwarding tree to the
prefix associated with the FEC.
For example, <a href="./rfc5036#appendix-A.1.7">Appendix A.1.7 of [RFC5036]</a> specifies the response by an
LSR to a change in the next hop for a FEC. For a shortest-path FEC,
the next hop may change as the result of the LSR running a shortest-
path computation on a modified IGP topology database. For the red
and blue FECs, the red and blue next hops may change as the result of
the LSR running a particular MRT algorithm on a modified IGP topology
database.
As another example, <a href="./rfc5036#section-2.6.1.2">Section 2.6.1.2 of [RFC5036]</a> specifies that when
an LSR is using LSP Ordered Control, it may initiate the transmission
of a label mapping only for a (shortest-path) FEC for which it has a
label mapping for the FEC next hop, or for which the LSR is the
egress. The FEC next hop for a shortest-path FEC is based on the
shortest-path forwarding tree to the prefix associated with the FEC.
In the context of distributing MRT LDP labels, this procedure is
understood to mean the following. When an LSR is using LSP Ordered
Control, it may initiate the transmission of a label mapping only for
a red(blue) FEC for which it has a label mapping for the red(blue)
FEC next hop, or for which the LSR is the egress. The red or blue
FEC next hop is based on the MRT-Red or Blue forwarding tree to the
prefix associated with the FEC.
<span class="h4"><a class="selflink" id="section-5.2.3" href="#section-5.2.3">5.2.3</a>. Egress LSR in <a href="./rfc5036">RFC 5036</a></span>
Procedures in [<a href="./rfc5036" title=""LDP Specification"">RFC5036</a>] related to Ordered Control label distribution
mode rely on whether or not an LSR may act as an egress LSR for a
particular FEC in order to determine whether or not the LSR may
originate a label mapping for that FEC. The status of being an
egress LSR for a particular FEC is also used in the loop detection
procedures described in [<a href="./rfc5036" title=""LDP Specification"">RFC5036</a>]. <a href="./rfc5036#section-2.6.1.2">Section 2.6.1.2 of [RFC5036]</a>
specifies the conditions under which an LSR may act as an egress LSR
with respect to a particular (shortest-path) FEC:
1. The (shortest-path) FEC refers to the LSR itself (including one
of its directly attached interfaces).
<span class="grey">Atlas, 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="./rfc8320">RFC 8320</a> LDP Extensions to Support MRTs February 2018</span>
2. The next hop router for the (shortest-path) FEC is outside of the
Label Switching Network.
3. (Shortest-path) FEC elements are reachable by crossing a routing
domain boundary.
The conditions for determining an egress LSR with respect to a red or
blue FEC need to be modified. An LSR may act as an egress LSR with
respect to a particular red(blue) FEC under any of the following
conditions:
1. The prefix associated with the red(blue) FEC refers to the LSR
itself (including one of its directly attached interfaces).
2. The LSR is the red(blue) proxy-node attachment router with
respect to the multi-homed prefix associated with the red(blue)
FEC. This includes the degenerate case of a single red and blue
proxy-node attachment router for a single-homed prefix.
3. The LSR is an ABR AND the MRT LDP peer requires non-best-area
advertising and forwarding behavior for the prefix associated
with the FEC.
Note that condition 3 scopes an LSR's status as an egress LSR with
respect to a particular FEC to a particular MRT LDP peer. Therefore,
the condition "Is LSR egress for FEC?" that occurs in several
procedures in [<a href="./rfc5036" title=""LDP Specification"">RFC5036</a>] needs to be interpreted as "Is LSR egress for
FEC with respect to Peer?"
Also note that there is no explicit condition that allows an LSR to
be classified as an egress LSR with respect to a red or blue FEC
based only on the primary next hop for the shortest-path FEC not
supporting LDP or not supporting LDP MRT Capability. These
situations are covered by the proxy-node attachment router and ABR
conditions (conditions 2 and 3). In particular, an Island Border
Router is not the egress LSR for a red(blue) FEC unless it is also
the red(blue) proxy-node attachment router for that FEC.
Also note that, in general, a proxy-node attachment router for a
given prefix should not advertise an implicit or explicit null label
for the corresponding red or blue FEC, even though it may be an
egress LSR for the shortest-path FEC. In general, the proxy-node
attachment router needs to forward red or blue traffic for that
prefix to a particular loop-free island neighbor, which may be
different from the shortest-path next hop. The proxy-node attachment
router needs to receive the red or blue traffic with a non-null label
to correctly forward it.
<span class="grey">Atlas, 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="./rfc8320">RFC 8320</a> LDP Extensions to Support MRTs February 2018</span>
<span class="h4"><a class="selflink" id="section-5.2.4" href="#section-5.2.4">5.2.4</a>. Use of Rainbow FEC to Satisfy Label Mapping Existence</span>
<span class="h4"> Requirements in <a href="./rfc5036">RFC 5036</a></span>
Several procedures in [<a href="./rfc5036" title=""LDP Specification"">RFC5036</a>] require the LSR to determine if it
has previously received and retained a label mapping for a FEC from
the next hop. In the case of an LSR that has received and retained a
label mapping for a Rainbow FEC from an ABR, the label mapping for
the Rainbow FEC satisfies the label mapping existence requirement for
the corresponding red and blue FECs. Label mapping existence
requirements in the context of MRT LDP label distribution are
modified as: "Has LSR previously received and retained a label
mapping for the red(blue) FEC (or the corresponding Rainbow FEC) from
the red(blue) next hop?"
As an example, this behavior allows an LSR that has received and
retained a label mapping for the Rainbow FEC to advertise label
mappings for the corresponding red and blue FECs when operating in
Ordered Control label distribution mode.
<span class="h4"><a class="selflink" id="section-5.2.5" href="#section-5.2.5">5.2.5</a>. Validating FECs in the Routing Table</span>
In [<a href="./rfc5036" title=""LDP Specification"">RFC5036</a>], an LSR uses its routing table to validate prefixes
associated with shortest-path FECs. For example, <a href="./rfc5036#section-3.5.7.1">Section 3.5.7.1 of
[RFC5036]</a> specifies that "an LSR receiving a Label Mapping message
from a downstream LSR for a Prefix SHOULD NOT use the label for
forwarding unless its routing table contains an entry that exactly
matches the FEC Element." In the context of MRT FECs, a red or blue
FEC element matches a routing table entry if the corresponding
shortest-path FEC element matches a routing table entry.
<span class="h4"><a class="selflink" id="section-5.2.6" href="#section-5.2.6">5.2.6</a>. Recognizing New FECs</span>
<a href="./rfc5036#appendix-A.1.6">Appendix A.1.6 of [RFC5036]</a> describes the response of an LSR to the
"Recognize New FEC" event, which occurs when an LSR learns a new
(shortest-path) FEC via the routing table. In the context of MRT
FECs, if the MRT LDP Capability has been enabled, then when an LSR
learns a new shortest-path FEC, the LSR should generate "Recognize
New FEC" events for the corresponding Red and Blue FECS in addition
to the normally generated "Recognize New FEC" event for the shortest-
path FEC
<span class="h4"><a class="selflink" id="section-5.2.7" href="#section-5.2.7">5.2.7</a>. Not Propagating Rainbow FEC Label Mappings</span>
A label mapping for the Rainbow FEC should only be originated by an
ABR under the conditions described in <a href="#section-5.1.1">Section 5.1.1</a>. A neighbor of
the ABR that receives a label mapping for the Rainbow FEC MUST NOT
propagate a label mapping for that Rainbow FEC.
<span class="grey">Atlas, 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="./rfc8320">RFC 8320</a> LDP Extensions to Support MRTs February 2018</span>
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
The labels distributed by the extensions in this document create
additional forwarding paths that do not follow shortest-path routes.
The transit label swapping operations defining these alternative
forwarding paths are created during normal operations (before a
failure occurs). Therefore, a malicious packet with an appropriate
label injected into the network from a compromised location would be
forwarded to a destination along a non-shortest path. When this
technology is deployed, a network security design should not rely on
assumptions about potentially malicious traffic only following
shortest paths.
It should be noted that the creation of non-shortest forwarding paths
is not unique to MRT. For example, RSVP-TE [<a href="./rfc3209" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RFC3209</a>] can be used to
construct forwarding paths that do not follow the shortest path.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Potential Restrictions on MRT-Related MT-ID Values Imposed by</span>
<a href="./rfc6420">RFC 6420</a>
As discussed in the introduction, in addition to unicast-forwarding
applications, MRT can be used to provide disjoint trees for multicast
traffic distribution. In the case of PIM, this is accomplished by
using the MRT red and blue next hops as the PIM Reverse Path
Forwarding (RPF) topology, the collection of routes used by PIM to
perform the RPF operation when building source trees. The PIM Multi-
Topology ID (MT-ID) Join Attribute defined in <a href="./rfc6420#section-5.2">Section 5.2 of
[RFC6420]</a> can be used to establish MRT-based multicast distribution
trees. [<a href="./rfc6420" title=""PIM Multi-Topology ID (MT-ID) Join Attribute"">RFC6420</a>] limits the values of the PIM MT-ID from 1 through
4095.
For the purpose of reducing management overhead and simplifying
troubleshooting, it is desirable to be able to use the same numerical
value for the PIM MT-ID as for the MPLS MT-ID for multicast and
unicast applications using MRT routes constructed using the same MRT
Profile. In order to enable this simplification, the MPLS MT-ID
values assigned in this document fall in the range 1 through 4095.
The "MPLS Multi-Topology Identifiers" registry reflects this by
listing the values from 3948 through 3995 as for MRT-related MPLS
MT-ID values. This allows for 51 MRT-related MPLS MT-ID values that
can be directly mapped to PIM MT-ID values, which accommodates 25 MRT
Profiles with red and blue MT-ID pairs, with one extra for the
Rainbow MPLS MT-ID value. [<a href="./rfc7307" title=""LDP Extensions for Multi-Topology"">RFC7307</a>] designates the MT-ID range
6-3995 as "Unassigned for future IGP topologies". As shown in the
IANA Considerations, the guidance for the range 3948-3995 has been
changed to "Unassigned (for future MRT-related values)".
<span class="grey">Atlas, 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="./rfc8320">RFC 8320</a> LDP Extensions to Support MRTs February 2018</span>
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. IANA Considerations</span>
IANA has allocated a value for the new LDP Capability TLV from the
"Label Distribution Protocol (LDP) Parameters" registry under "TLV
Type Name Space": MRT Capability TLV (0x050E).
Value Description Reference Notes / Reg. Date
------------- ------------------ ------------ -----------------
0x050E MRT Capability TLV <a href="./rfc8320">RFC 8320</a>
IANA has allocated a value for the new LDP Status Code from the
"Label Distribution Protocol (LDP) Parameters" registry under "Status
Code Name Space": MRT Capability negotiated without MT Capability
(0x00000034). The Status Code E-bit is set to 0.
Value E Description Reference Notes / Reg. Date
------------- - ------------------ ------------ -----------------
0x00000034 0 MRT Capability <a href="./rfc8320">RFC 8320</a>
negotiated without
MT Capability
IANA has allocated three values from the "MPLS Multi-Topology
Identifiers" registry [<a href="./rfc7307" title=""LDP Extensions for Multi-Topology"">RFC7307</a>]:
3945 Rainbow MRT MPLS MT-ID
3946 Default Profile MRT-Red MPLS MT-ID
3947 Default Profile MRT-Blue MPLS MT-ID
<span class="grey">Atlas, 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="./rfc8320">RFC 8320</a> LDP Extensions to Support MRTs February 2018</span>
Also, IANA has changed the Purpose field of the "MPLS Multi-Topology
Identifiers" registry for MT-ID range 3948-3995 to "Unassigned (for
future MRT-related values)". The registration procedure for the
entire registry remains Standards Action [<a href="./rfc8126" title="">RFC8126</a>]. The current
registry is shown below:
Value Purpose Reference
------------ ---------------------- ------------
0 Default/standard topology [<a href="./rfc7307" title=""LDP Extensions for Multi-Topology"">RFC7307</a>]
1 IPv4 in-band management [<a href="./rfc7307" title=""LDP Extensions for Multi-Topology"">RFC7307</a>]
2 IPv6 routing topology [<a href="./rfc7307" title=""LDP Extensions for Multi-Topology"">RFC7307</a>]
3 IPv4 multicast topology [<a href="./rfc7307" title=""LDP Extensions for Multi-Topology"">RFC7307</a>]
4 IPv6 multicast topology [<a href="./rfc7307" title=""LDP Extensions for Multi-Topology"">RFC7307</a>]
5 IPv6 in-band management [<a href="./rfc7307" title=""LDP Extensions for Multi-Topology"">RFC7307</a>]
6-3944 Unassigned (for future IGP topologies)
3945 Rainbow MRT MPLS MT-ID <a href="./rfc8320">RFC 8320</a>
3946 Default Profile MRT-Red MPLS MT-ID <a href="./rfc8320">RFC 8320</a>
3947 Default Profile MRT-Blue MPLS MT-ID <a href="./rfc8320">RFC 8320</a>
3948-3995 Unassigned (for future MRT-related values) <a href="./rfc8320">RFC 8320</a>
3996-4095 Reserved for Experimental Use [<a href="./rfc7307" title=""LDP Extensions for Multi-Topology"">RFC7307</a>]
4096-65534 Unassigned (for MPLS topologies)
65535 Wildcard Topology [<a href="./rfc7307" title=""LDP Extensions for Multi-Topology"">RFC7307</a>]
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. References</span>
<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>,
DOI 10.17487/RFC2119, March 1997,
<<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>>.
[<a id="ref-RFC5036">RFC5036</a>] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
"LDP Specification", <a href="./rfc5036">RFC 5036</a>, DOI 10.17487/RFC5036,
October 2007, <<a href="https://www.rfc-editor.org/info/rfc5036">https://www.rfc-editor.org/info/rfc5036</a>>.
[<a id="ref-RFC5561">RFC5561</a>] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and
JL. Le Roux, "LDP Capabilities", <a href="./rfc5561">RFC 5561</a>,
DOI 10.17487/RFC5561, July 2009,
<<a href="https://www.rfc-editor.org/info/rfc5561">https://www.rfc-editor.org/info/rfc5561</a>>.
[<a id="ref-RFC6420">RFC6420</a>] Cai, Y. and H. Ou, "PIM Multi-Topology ID (MT-ID) Join
Attribute", <a href="./rfc6420">RFC 6420</a>, DOI 10.17487/RFC6420, November 2011,
<<a href="https://www.rfc-editor.org/info/rfc6420">https://www.rfc-editor.org/info/rfc6420</a>>.
<span class="grey">Atlas, 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="./rfc8320">RFC 8320</a> LDP Extensions to Support MRTs February 2018</span>
[<a id="ref-RFC7307">RFC7307</a>] Zhao, Q., Raza, K., Zhou, C., Fang, L., Li, L., and
D. King, "LDP Extensions for Multi-Topology", <a href="./rfc7307">RFC 7307</a>,
DOI 10.17487/RFC7307, July 2014,
<<a href="https://www.rfc-editor.org/info/rfc7307">https://www.rfc-editor.org/info/rfc7307</a>>.
[<a id="ref-RFC7811">RFC7811</a>] Enyedi, G., Csaszar, A., Atlas, A., Bowers, C., and
A. Gopalan, "An Algorithm for Computing IP/LDP Fast
Reroute Using Maximally Redundant Trees (MRT-FRR)",
<a href="./rfc7811">RFC 7811</a>, DOI 10.17487/RFC7811, June 2016,
<<a href="https://www.rfc-editor.org/info/rfc7811">https://www.rfc-editor.org/info/rfc7811</a>>.
[<a id="ref-RFC7812">RFC7812</a>] Atlas, A., Bowers, C., and G. Enyedi, "An Architecture for
IP/LDP Fast Reroute Using Maximally Redundant Trees
(MRT-FRR)", <a href="./rfc7812">RFC 7812</a>, DOI 10.17487/RFC7812, June 2016,
<<a href="https://www.rfc-editor.org/info/rfc7812">https://www.rfc-editor.org/info/rfc7812</a>>.
[<a id="ref-RFC8126">RFC8126</a>] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", <a href="https://www.rfc-editor.org/bcp/bcp26">BCP 26</a>,
<a href="./rfc8126">RFC 8126</a>, DOI 10.17487/RFC8126, June 2017,
<<a href="https://www.rfc-editor.org/info/rfc8126">https://www.rfc-editor.org/info/rfc8126</a>>.
[<a id="ref-RFC8174">RFC8174</a>] Leiba, B., "Ambiguity of Uppercase vs Lowercase in <a href="./rfc2119">RFC</a>
<a href="./rfc2119">2119</a> Key Words", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc8174">RFC 8174</a>, DOI 10.17487/RFC8174,
May 2017, <<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>>.
<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>. Informative References</span>
[<a id="ref-ARCH">ARCH</a>] Atlas, A., Kebler, R., Wijnands, IJ., Csaszar, A., and G.
Envedi, "An Architecture for Multicast Protection Using
Maximally Redundant Trees", Work in Progress,
<a href="./draft-atlas-rtgwg-mrt-mc-arch-02">draft-atlas-rtgwg-mrt-mc-arch-02</a>, July 2013.
[<a id="ref-IS-IS-MRT">IS-IS-MRT</a>]
Li, Z., Wu, N., Zhao, Q., Atlas, A., Bowers, C., and
J. Tantsura, "Intermediate System to Intermediate System
(IS-IS) Extensions for Maximally Redundant Trees (MRTs)",
Work in Progress, <a href="./draft-ietf-isis-mrt-03">draft-ietf-isis-mrt-03</a>, June 2017.
[<a id="ref-OSPF-MRT">OSPF-MRT</a>] Atlas, A., Hegde, S., Bowers, C., Tantsura, J., and Z. Li,
"OSPF Extensions to Support Maximally Redundant Trees",
Work in Progress, <a href="./draft-ietf-ospf-mrt-03">draft-ietf-ospf-mrt-03</a>, June 2017.
[<a id="ref-PARAM-SYNC">PARAM-SYNC</a>]
Bryant, S., Atlas, A., and C. Bowers, "Routing Timer
Parameter Synchronization", Work in Progress,
<a href="./draft-ietf-rtgwg-routing-timer-param-sync-00">draft-ietf-rtgwg-routing-timer-param-sync-00</a>, October
2017.
<span class="grey">Atlas, 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="./rfc8320">RFC 8320</a> LDP Extensions to Support MRTs February 2018</span>
[<a id="ref-RFC3209">RFC3209</a>] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", <a href="./rfc3209">RFC 3209</a>, DOI 10.17487/RFC3209, December 2001,
<<a href="https://www.rfc-editor.org/info/rfc3209">https://www.rfc-editor.org/info/rfc3209</a>>.
[<a id="ref-RFC5443">RFC5443</a>] Jork, M., Atlas, A., and L. Fang, "LDP IGP
Synchronization", <a href="./rfc5443">RFC 5443</a>, DOI 10.17487/RFC5443, March
2009, <<a href="https://www.rfc-editor.org/info/rfc5443">https://www.rfc-editor.org/info/rfc5443</a>>.
[<a id="ref-RFC7715">RFC7715</a>] Wijnands, IJ., Ed., Raza, K., Atlas, A., Tantsura, J., and
Q. Zhao, "Multipoint LDP (mLDP) Node Protection",
<a href="./rfc7715">RFC 7715</a>, DOI 10.17487/RFC7715, January 2016,
<<a href="https://www.rfc-editor.org/info/rfc7715">https://www.rfc-editor.org/info/rfc7715</a>>.
<span class="grey">Atlas, 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="./rfc8320">RFC 8320</a> LDP Extensions to Support MRTs February 2018</span>
Acknowledgements
The authors would like to thank Ross Callon, Loa Andersson, Stewart
Bryant, Mach Chen, Greg Mirsky, Uma Chunduri, and Tony Przygienda for
their comments and suggestions.
Authors' Addresses
Alia Atlas
Juniper Networks
10 Technology Park Drive
Westford, MA 01886
United States of America
Email: akatlas@juniper.net
Kishore Tiruveedhula
Juniper Networks
10 Technology Park Drive
Westford, MA 01886
United States of America
Email: kishoret@juniper.net
Chris Bowers
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
United States of America
Email: cbowers@juniper.net
Jeff Tantsura
Individual
United States of America
Email: jefftant.ietf@gmail.com
IJsbrand Wijnands
Cisco Systems, Inc.
Email: ice@cisco.com
Atlas, et al. Standards Track [Page 21]
</pre>
|
