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
|
<pre>Internet Engineering Task Force (IETF) S. Esale
Request for Comments: 8223 R. Torvi
Updates: <a href="./rfc7473">7473</a> Juniper Networks
Category: Standards Track L. Jalil
ISSN: 2070-1721 Verizon
U. Chunduri
Huawei
K. Raza
Cisco Systems, Inc.
August 2017
<span class="h1">Application-Aware Targeted LDP</span>
Abstract
Recent Targeted Label Distribution Protocol (tLDP) applications, such
as remote Loop-Free Alternates (LFAs) and BGP auto-discovered
pseudowires, may automatically establish a tLDP session with any
Label Switching Router (LSR) in a network. The initiating LSR has
information about the targeted applications to administratively
control initiation of the session. However, the responding LSR has
no such information to control acceptance of this session. This
document defines a mechanism to advertise and negotiate the Targeted
Application Capability (TAC) during LDP session initialization. As
the responding LSR becomes aware of targeted applications, it may
establish a limited number of tLDP sessions for certain applications.
In addition, each targeted application is mapped to LDP Forwarding
Equivalence Class (FEC) elements to advertise only necessary LDP FEC
label bindings over the session. This document updates <a href="./rfc7473">RFC 7473</a> for
enabling advertisement of LDP FEC label bindings over the session.
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/rfc8223">https://www.rfc-editor.org/info/rfc8223</a>.
<span class="grey">Esale, 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="./rfc8223">RFC 8223</a> Application-Aware tLDP August 2017</span>
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
<a href="#section-1.1">1.1</a>. Conventions Used in This Document ..........................<a href="#page-4">4</a>
<a href="#section-1.2">1.2</a>. Terminology ................................................<a href="#page-4">4</a>
<a href="#section-2">2</a>. Targeted Application Capability .................................<a href="#page-5">5</a>
<a href="#section-2.1">2.1</a>. Encoding ...................................................<a href="#page-5">5</a>
<a href="#section-2.2">2.2</a>. Procedures .................................................<a href="#page-5">5</a>
<a href="#section-2.3">2.3</a>. LDP Message Procedures .....................................<a href="#page-8">8</a>
<a href="#section-2.3.1">2.3.1</a>. Initialization Message ..............................<a href="#page-8">8</a>
<a href="#section-2.3.2">2.3.2</a>. Capability Message ..................................<a href="#page-8">8</a>
<a href="#section-3">3</a>. Targeted Application FEC Advertisement Procedures ...............<a href="#page-9">9</a>
4. Interaction of Targeted Application Capabilities and State
Advertisement Control Capabilities .............................<a href="#page-10">10</a>
<a href="#section-5">5</a>. Use Cases ......................................................<a href="#page-12">12</a>
<a href="#section-5.1">5.1</a>. Remote LFA Automatic Targeted Session .....................<a href="#page-12">12</a>
<a href="#section-5.2">5.2</a>. FEC 129 Auto-discovery Targeted Session ...................<a href="#page-13">13</a>
<a href="#section-5.3">5.3</a>. LDP over RSVP and Remote LFA Targeted Session .............<a href="#page-13">13</a>
<a href="#section-5.4">5.4</a>. mLDP Node Protection Targeted Session .....................<a href="#page-13">13</a>
<a href="#section-6">6</a>. Security Considerations ........................................<a href="#page-14">14</a>
<a href="#section-7">7</a>. IANA Considerations ............................................<a href="#page-14">14</a>
<a href="#section-8">8</a>. References .....................................................<a href="#page-15">15</a>
<a href="#section-8.1">8.1</a>. Normative References ......................................<a href="#page-15">15</a>
<a href="#section-8.2">8.2</a>. Informative References ....................................<a href="#page-16">16</a>
Acknowledgments ...................................................<a href="#page-17">17</a>
Contributors ......................................................<a href="#page-17">17</a>
Authors' Addresses ................................................<a href="#page-18">18</a>
<span class="grey">Esale, 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="./rfc8223">RFC 8223</a> Application-Aware tLDP August 2017</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
LDP uses the Extended Discovery mechanism to establish the
Targeted LDP (tLDP) adjacency and subsequent session, as described in
[<a href="./rfc5036" title=""LDP Specification"">RFC5036</a>]. A Label Switching Router (LSR) initiates Extended
Discovery by sending a tLDP Hello to a specific address. The remote
LSR decides to either accept or ignore the tLDP Hello based on local
configuration only. A tLDP application is an application that uses a
tLDP session to exchange information such as FEC label bindings
("FEC" stands for "Forwarding Equivalence Class") with a peer LSR in
the network. For an application such as FEC 128 pseudowire, the
remote LSR is configured with the source LSR address so that it can
use that information to accept or ignore a given tLDP Hello.
However, applications such as remote Loop-Free Alternates (LFAs) and
BGP auto-discovered pseudowires automatically initiate asymmetric
Extended Discovery to any LSR in a network based on local state only.
With these applications, the remote LSR is not explicitly configured
with the source LSR address. So, the remote LSR either responds to
all tLDP Hellos or ignores them.
In addition, since the session is initiated and established after
adjacency formation, the responding LSR has no information on
targeted applications available from which it can choose a session
with a targeted application that it is configured to support. Also,
the initiating LSR may employ a limit per application on locally
initiated automatic tLDP sessions; however, the responding LSR has
no such information to employ a similar limit on the incoming tLDP
sessions. Further, the responding LSR does not know whether the
source LSR is establishing a tLDP session for configured
applications, automatic applications, or both.
This document proposes and describes a solution to advertise the
Targeted Application Capability (TAC), consisting of a list of
targeted applications, during initialization of a tLDP session. It
also defines a mechanism to enable a new application and disable an
old application after session establishment. This capability
advertisement provides the responding LSR with the necessary
information to control the acceptance of tLDP sessions
per application. For instance, an LSR may accept all BGP
auto-discovered tLDP sessions as described in [<a href="./rfc6074" title=""Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)"">RFC6074</a>] but may only
accept a limited number of remote LFA tLDP sessions as described
in [<a href="./rfc7490" title=""Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)"">RFC7490</a>].
Also, the tLDP application is mapped to LDP FEC element types to
advertise specific application FECs only, avoiding the advertisement
of other unnecessary FECs over a tLDP session.
<span class="grey">Esale, 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="./rfc8223">RFC 8223</a> Application-Aware tLDP August 2017</span>
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Conventions Used in This Document</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
<a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>] [<a href="./rfc8174" title=""Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"">RFC8174</a>] when, and only when, they appear in all
capitals, as shown here.
<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>. Terminology</span>
In addition to the terminology defined in [<a href="./rfc7473" title=""Controlling State Advertisements of Non-negotiated LDP Applications"">RFC7473</a>], this document
uses the following terms:
tLDP : Targeted LDP
TAC : Targeted Application Capability
TAE : Targeted Application Element
TA-Id : Targeted Application Identifier
SAC : State Advertisement Control
LSR : Label Switching Router
mLDP : Multipoint LDP
PQ node : Remote LFA next hops
RSVP-TE : RSVP Traffic Engineering
P2MP : Point-to-Multipoint
PW : Pseudowire
P2P-PW : Point-to-Point Pseudowire
MP2MP : Multipoint-to-Multipoint
HSMP LSP: Hub and Spoke Multipoint Label Switched Path
LSP : Label Switched Path
MP2P : Multipoint-to-Point
MPT : Merge Point
<span class="grey">Esale, 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="./rfc8223">RFC 8223</a> Application-Aware tLDP August 2017</span>
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Targeted Application Capability</span>
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Encoding</span>
An LSR MAY advertise that it is capable of negotiating a tLDP
application list over a tLDP session by using the capability
advertisement as defined in [<a href="./rfc5561" title=""LDP Capabilities"">RFC5561</a>] and encoded as follows:
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| TLV Code Point | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | |
+-+-+-+-+-+-+-+-+ Capability Data |
| +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flag "U" MUST be set to 1 to indicate that this capability must be
silently ignored if unknown. The TAC's Capability Data field
contains the Targeted Application Element (TAE) information, encoded
as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TA-Id |E| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TA-Id: A 16-bit Targeted Application Identifier value.
E: E-bit (Enable bit). Indicates whether the sender is
advertising or withdrawing the TAE. The E-bit value is used
as follows:
1 - The TAE is advertising the targeted application.
0 - The TAE is withdrawing the targeted application.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Procedures</span>
At tLDP session establishment time, an LSR MAY include a new
capability TLV, the TAC TLV, as an optional TLV in the LDP
Initialization message. The TAC TLV's Capability data MAY consist of
zero or more TAEs, each pertaining to a unique TA-Id that an LSR
supports over the session. If the receiver LSR receives the same
TA-Id in more than one TAE, it MUST process the first element and
<span class="grey">Esale, 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="./rfc8223">RFC 8223</a> Application-Aware tLDP August 2017</span>
ignore the duplicate elements. If the receiver LSR receives an
unknown TA-Id in the TAE, it MUST silently ignore such a TAE and
continue processing the rest of the TLV.
If the receiver LSR does not receive the TAC TLV in the
Initialization message or it does not understand the TAC TLV, the TAC
negotiation is considered unsuccessful and the session establishment
proceeds as per [<a href="./rfc5036" title=""LDP Specification"">RFC5036</a>]. On receipt of a valid TAC TLV, an LSR
MUST generate its own TAC TLV with TAEs consisting of unique TA-Ids
that it supports over the tLDP session. If there is at least one
common TAE between the TAC TLV it has received and its own, the
session MUST proceed to establishment as per [<a href="./rfc5036" title=""LDP Specification"">RFC5036</a>]. If not, an
LSR MUST send a 'Session Rejected/Targeted Application Capability
Mismatch' Notification message to the peer and close the session.
The initiating LSR SHOULD tear down the corresponding tLDP adjacency
after sending or receiving a 'Session Rejected/Targeted Application
Capability Mismatch' Notification message to or from the responding
LSR, respectively.
If both of the peers support the TAC TLV, an LSR decides to establish
or close a tLDP session based on the negotiated list of targeted
applications. For example, an initiating LSR advertises A, B, and C
as TA-Ids, and the responding LSR advertises C, D, and E as TA-Ids.
Then, the negotiated TA-Id as per both LSRs is C. In another
example, an initiating LSR advertises A, B, and C as TA-Ids, and the
responding LSR, which acts as a passive LSR, advertises all of the
applications -- A, B, C, D, and E -- as TA-Ids that it supports over
this session. The negotiated targeted applications as per both LSRs
are then A, B, and C. Finally, if the initiating LSR advertises A,
B, and C as TA-Ids and the responding LSR advertises D and E as
TA-Ids, then the negotiated targeted applications as per both LSRs
are "none". Therefore, if the intersection of the sets of received
and sent TA-Ids is null, then the LSR sends a 'Session
Rejected/Targeted Application Capability Mismatch' Notification
message to the peer LSR and closes the session.
When the responding LSR playing the active role [<a href="./rfc5036" title=""LDP Specification"">RFC5036</a>] in LDP
session establishment receives a 'Session Rejected/Targeted
Application Capability Mismatch' Notification message, it MUST set
its session setup retry interval to a maximum value -- that is,
0xFFFF. The session MAY stay in a non-existent state. When it
detects a change in the initiating LSR or local LSR configuration
pertaining to the TAC TLV, it MUST clear the session setup backoff
delay associated with the session to reattempt session establishment.
An LSR detects the configuration change on the other LSR upon receipt
of a tLDP Hello message that has a higher configuration sequence
number than the earlier tLDP Hello message.
<span class="grey">Esale, 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="./rfc8223">RFC 8223</a> Application-Aware tLDP August 2017</span>
When the initiating LSR playing the active role in LDP session
establishment receives a 'Session Rejected/Targeted Application
Capability Mismatch' Notification message, it MUST either (1) close
the session and tear down the corresponding tLDP adjacency or (2) set
its session setup retry interval to a maximum value -- that is,
0xFFFF.
If the initiating LSR decides to tear down the associated tLDP
adjacency, the session is closed on the initiating LSR as well as the
responding LSR. It MAY also take appropriate actions. For instance,
if an automatic session intended to support the remote LFA
application is rejected by the responding LSR, the initiating LSR may
inform the IGP to calculate another PQ node [<a href="./rfc7490" title=""Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)"">RFC7490</a>] for the route
or set of routes. More specific actions are a local matter and are
outside the scope of this document.
If the initiating LSR sets the session setup retry interval to
maximum, the session MAY stay in a non-existent state. When this LSR
detects a change in the responding LSR configuration or its own
configuration pertaining to the TAC TLV, it MUST clear the session
setup backoff delay associated with the session in order to reattempt
session establishment.
After a tLDP session using the TAC mechanism has been established,
the initiating and responding LSRs MUST distribute FEC label bindings
for the negotiated applications only. For instance, if the tLDP
session is established for a BGP auto-discovered pseudowire, only FEC
129 label bindings MUST be distributed over the session. Similarly,
an LSR operating in downstream on-demand mode MUST request FEC label
bindings for the negotiated applications only.
If the TAC and the Dynamic Capability [<a href="./rfc5561" title=""LDP Capabilities"">RFC5561</a>] are negotiated during
session initialization, the TAC MAY be renegotiated after session
establishment by sending an updated TAC TLV in the LDP Capability
message. The updated TAC TLV carries TA-Ids with an incremental
update only. The updated TLV MUST consist of one or more TAEs with
the E-bit set (1) or off (0), to advertise or withdraw the new
application and the old application, respectively. This may lead to
advertisements or withdrawals of certain types of FEC label bindings
over the session or to teardown of the tLDP adjacency and,
subsequently, the session.
The TAC is advertised on the tLDP session only. If the tLDP session
changes to a link session, an LSR SHOULD withdraw it with the S-bit
set to 0. Similarly, if the link session changes to tLDP, an LSR
SHOULD advertise it via the Capability message. If the capability
negotiation fails, this may lead to destruction of the tLDP session.
<span class="grey">Esale, 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="./rfc8223">RFC 8223</a> Application-Aware tLDP August 2017</span>
By default, an LSR SHOULD accept tLDP Hellos in order to then accept
or reject the tLDP session based on the application information.
In addition, an LSR SHOULD allow the configuration of any TA-Id in
order to facilitate the use of private TA-Ids by a network operator.
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. LDP Message Procedures</span>
<span class="h4"><a class="selflink" id="section-2.3.1" href="#section-2.3.1">2.3.1</a>. Initialization Message</span>
1. The S-bit of the TAC TLV MUST be set to 1 to advertise the TAC and
SHOULD be ignored on receipt, as described in [<a href="./rfc5561" title=""LDP Capabilities"">RFC5561</a>].
2. The E-bit of the TAE MUST be set to 1 to enable the targeted
application and SHOULD be ignored on receipt.
3. An LSR MAY add the State Advertisement Control Capability by
mapping the TAE to the State Advertisement Control (SAC) elements
as defined in <a href="#section-4">Section 4</a>.
<span class="h4"><a class="selflink" id="section-2.3.2" href="#section-2.3.2">2.3.2</a>. Capability Message</span>
After a change to local configuration, the initiating or responding
LSR may renegotiate the TAC via the Capability message.
1. The S-bit of the TAC is set to 1 or 0 to advertise or withdraw it.
2. After the configuration change, if there is no common TAE between
its new TAE list and the peer's TAE list, the LSR MUST send a
'Session Rejected/Targeted Application Capability Mismatch'
Notification message and close the session.
3. If there is a common TAE, an LSR MAY also update the SAC
Capability based on the updated TAC, as described in <a href="#section-4">Section 4</a>,
and send the updated TAC and SAC Capability in a Capability
message to the peer.
4. A receiving LSR processes the Capability message with the TAC TLV.
If the S-bit is set to 0, the TAC is disabled for the session.
5. If the S-bit is set to 1, the LSR processes a list of TAEs from
the TAC's data with the E-bit set to 1 or 0 to update the
peer's TAE.
<span class="grey">Esale, 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="./rfc8223">RFC 8223</a> Application-Aware tLDP August 2017</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Targeted Application FEC Advertisement Procedures</span>
The tLDP application MUST be mapped to LDP FEC element types as
follows to advertise only necessary LDP FEC label bindings over the
tLDP session.
Targeted Application Description FEC Mappings
+----------------------+------------------------+------------------+
|LDPv4 Tunneling | LDP IPv4 over RSVP-TE | IPv4 prefix |
| | or other MPLS tunnel | |
+----------------------+------------------------+------------------+
| | | |
|LDPv6 Tunneling | LDP IPv6 over RSVP-TE | IPv6 prefix |
| | or other MPLS tunnel | |
+----------------------+------------------------+------------------+
|mLDP Tunneling | mLDP over RSVP-TE or | P2MP |
| | other MPLS tunnel | MP2MP-up |
| | | MP2MP-down |
| | | HSMP-downstream |
| | | HSMP-upstream |
+----------------------+------------------------+------------------+
| | | |
|LDPv4 remote LFA | LDPv4 over LDPv4 or | IPv4 prefix |
| | other MPLS tunnel | |
+----------------------+------------------------+------------------+
|LDPv6 remote LFA | LDPv6 over LDPv6 or | IPv6 prefix |
| | other MPLS tunnel | |
+----------------------+------------------------+------------------+
| | | |
|LDP FEC 128 PW | LDP FEC 128 Pseudowire | PWid FEC element |
+----------------------+------------------------+------------------+
| | | |
|LDP FEC 129 PW | LDP FEC 129 Pseudowire | Generalized PWid |
| | | FEC element |
+----------------------+------------------------+------------------+
| | | FEC types as |
|LDP Session Protection| LDP session protection | per protected |
| | | session |
+----------------------+------------------------+------------------+
|LDP ICCP | LDP Inter-Chassis | |
| | Communication Protocol | None |
+----------------------+------------------------+------------------+
| | | |
|LDP P2MP PW | LDP P2MP Pseudowire | P2MP PW Upstream |
| | | FEC element |
<span class="grey">Esale, 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="./rfc8223">RFC 8223</a> Application-Aware tLDP August 2017</span>
+----------------------+------------------------+------------------+
| | | P2MP |
|mLDP Node Protection | mLDP node protection | MP2MP-up |
| | | MP2MP-down |
| | | HSMP-downstream |
| | | HSMP-upstream |
+----------------------+------------------------+------------------+
| | | |
|IPv4 intra-area FECs* | IPv4 intra-area FECs* | IPv4 prefix |
+----------------------+------------------------+------------------+
| | | |
|IPv6 intra-area FECs* | IPv6 intra-area FECs* | IPv6 prefix |
+----------------------+------------------------+------------------+
* Intra-area FECs: FECs that are on the shortest-path tree and
are not leafs of the shortest-path tree.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Interaction of Targeted Application Capabilities and State</span>
<span class="h2"> Advertisement Control Capabilities</span>
As described in this document, the set of TAEs negotiated between two
LDP peers advertising the TAC represents the willingness of both
peers to advertise state information for a set of applications. The
set of applications negotiated by the TAC mechanism is symmetric
between the two LDP peers. In the absence of further mechanisms, two
LDP peers will both advertise state information for the same set of
applications.
As described in [<a href="./rfc7473" title=""Controlling State Advertisements of Non-negotiated LDP Applications"">RFC7473</a>], the SAC TLV can be used by an LDP speaker
to communicate its interest or disinterest in receiving state
information from a given peer for a particular application. Two LDP
peers can use the SAC mechanism to create asymmetric advertisements
of state information between the two peers.
The TAC negotiation facilitates the awareness of targeted
applications to both of the peers. It enables them to advertise only
necessary LDP FEC label bindings corresponding to negotiated
applications. With the SAC, the responding LSR is not aware of
targeted applications. Thus, it may be unable to communicate its
interest or disinterest in receiving state information from the peer.
Therefore, when the responding LSR is not aware of targeted
applications such as remote LFAs and BGP auto-discovered pseudowires,
the TAC mechanism should be used, and when the responding LSR is
aware (with appropriate configuration) of targeted applications such
as FEC 128 pseudowire, the SAC mechanism should be used. Also, after
the TAC mechanism makes the responding LSR aware of targeted
applications, the SAC mechanism may be used to communicate its
<span class="grey">Esale, 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="./rfc8223">RFC 8223</a> Application-Aware tLDP August 2017</span>
disinterest in receiving state information from the peer for a
particular negotiated application, creating asymmetric
advertisements.
Thus, the TAC mechanism enables two LDP peers to symmetrically
advertise state information for negotiated targeted applications.
Further, the SAC mechanism enables both of them to asymmetrically
disable receipt of state information for some of the already-
negotiated targeted applications. Collectively, the TAC mechanism
and the SAC mechanism can both be used to control the FEC label
bindings that are advertised over the tLDP session. For instance,
suppose that the initiating LSR establishes a tLDP session, using the
TAC mechanism, with the responding LSR for remote LFA and FEC 129 PW
targeted applications. So, each LSR advertises the corresponding FEC
label bindings. Further, suppose that the initiating LSR is not the
PQ node for the responding LSR's remote LFA IGP calculations. In
such a case, the responding LSR may use the SAC mechanism to convey
its disinterest in receiving state information for remote LFA tLDP
applications.
For a given tLDP session, the TAC mechanism can be used without the
SAC mechanism, and the SAC mechanism can be used without the TAC
mechanism. It is useful to discuss the behavior that occurs when the
TAC and SAC mechanisms are used on the same tLDP session. The TAC
mechanism MUST take precedence over the SAC mechanism with respect to
enabling applications for which state information will be advertised.
For a tLDP session using the TAC mechanism, the LDP peers MUST NOT
advertise state information for an application that has not been
negotiated in the most recent TAE list (referred to as a
non-negotiated application). This is true even if one of the peers
announces its interest in receiving state information that
corresponds to the non-negotiated application by sending a SAC TLV.
In other words, when the TAC mechanism is being used, the SAC
mechanism cannot and should not enable state information
advertisements for applications that have not been enabled by the TAC
mechanism.
On the other hand, the SAC mechanism MUST take precedence over the
TAC mechanism with respect to disabling state information
advertisements. If an LDP speaker has announced its disinterest in
receiving state information for a given application to a given peer
using the SAC mechanism, its peer MUST NOT send state information for
that application, even if the two peers have negotiated the
corresponding application via the TAC mechanism.
<span class="grey">Esale, 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="./rfc8223">RFC 8223</a> Application-Aware tLDP August 2017</span>
For the purposes of determining the correspondence between targeted
applications defined in this document and application state as
defined in [<a href="./rfc7473" title=""Controlling State Advertisements of Non-negotiated LDP Applications"">RFC7473</a>], an LSR MUST use the following mappings:
LDPv4 Tunneling - IPv4 Prefix-LSPs
LDPv6 Tunneling - IPv6 Prefix-LSPs
LDPv4 Remote LFA - IPv4 Prefix-LSPs
LDPv6 Remote LFA - IPv6 Prefix-LSPs
LDP FEC 128 PW - FEC 128 P2P-PW
LDP FEC 129 PW - FEC 129 P2P-PW
An LSR MUST map the targeted application to the LDP capability
as follows:
mLDP Tunneling - P2MP Capability, MP2MP Capability, and HSMP LSP
Capability TLV
mLDP Node Protection - P2MP Capability, MP2MP Capability, and HSMP
LSP Capability TLV
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Use Cases</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Remote LFA Automatic Targeted Session</span>
The LSR determines that it needs to form an automatic tLDP session
with a remote LSR based on IGP calculation as described in [<a href="./rfc7490" title=""Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)"">RFC7490</a>]
or some other mechanism outside the scope of this document. The LSR
forms the tLDP adjacency and constructs an Initialization message
with the TAC TLV consisting of the TAE as the remote LFA during
session establishment. The receiver LSR processes the LDP
Initialization message and verifies whether it is configured to
accept a remote LFA tLDP session. If it is, it may further verify
that establishing such a session does not exceed the configured limit
for remote LFA sessions. If all of these conditions are met, the
receiver LSR may respond back with an Initialization message with the
TAC corresponding to the remote LFA, and subsequently the session
may be established.
After the session using the TAC mechanism has been established, the
sender and receiver LSRs distribute IPv4 or IPv6 FEC label bindings
over the session. Further, the receiver LSR may determine that it
does not need these FEC label bindings. So, it may disable the
receipt of these FEC label bindings by mapping the TAE to the State
Advertisement Control Capability as described in <a href="#section-4">Section 4</a>.
<span class="grey">Esale, 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="./rfc8223">RFC 8223</a> Application-Aware tLDP August 2017</span>
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. FEC 129 Auto-discovery Targeted Session</span>
BGP auto-discovery may determine whether the LSR needs to initiate an
auto-discovery tLDP session with a border LSR. Multiple LSRs may try
to form an auto-discovered tLDP session with a border LSR. So, a
service provider may want to limit the number of auto-discovered tLDP
sessions that a border LSR can accept. As described in <a href="#section-2">Section 2</a>,
LDP may convey targeted applications with the TAC TLV to a border
LSR. A border LSR may establish or reject the tLDP session based on
local administrative policy. Also, as the receiver LSR becomes aware
of targeted applications, it can also employ an administrative policy
for security. For instance, it can employ a policy to accept all
auto-discovered sessions from a source addresses list.
Moreover, the sender and receiver LSRs must exchange FEC 129 label
bindings only over the tLDP session.
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. LDP over RSVP and Remote LFA Targeted Session</span>
An LSR may want to establish a tLDP session with a remote LSR for
LDP-over-RSVP tunneling and remote LFA applications. The sender LSR
may add both of these applications as a unique TAE in the TAC data of
a TAC TLV. The receiver LSR may have reached a configured limit for
accepting remote LFA automatic tLDP sessions, but it may have been
configured to accept LDP-over-RSVP tunneling. In such a case, the
tLDP session is formed for both LDP-over-RSVP tunneling and remote
LFA applications, as both need the same FECs -- IPv4, IPv6, or both.
<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>. mLDP Node Protection Targeted Session</span>
A Merge Point (MPT) LSR may determine that it needs to form an
automatic tLDP session with the upstream point of local repair (PLR)
LSR for MP2P and MP2MP LSP [<a href="./rfc6388" title=""Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths"">RFC6388</a>] node protection as described in
[<a href="./rfc7715" title=""Multipoint LDP (mLDP) Node Protection"">RFC7715</a>]. The MPT LSR may add a new tLDP application -- mLDP
protection -- as a unique TAE in the TAC data of a TAC TLV and send
it in the Initialization message to the PLR. If the PLR is
configured for mLDP node protection and establishing this session
does not exceed the limit of either mLDP node protection sessions or
automatic tLDP sessions, the PLR may decide to accept this session.
Also, the PLR may respond back with the Initialization message with a
TAC TLV that has one of the TAEs as mLDP protection, and the session
proceeds to establishment as per [<a href="./rfc5036" title=""LDP Specification"">RFC5036</a>].
<span class="grey">Esale, 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="./rfc8223">RFC 8223</a> Application-Aware tLDP August 2017</span>
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
The procedures described in this document do not introduce any
changes to LDP security considerations as described in [<a href="./rfc5036" title=""LDP Specification"">RFC5036</a>].
As described in [<a href="./rfc5036" title=""LDP Specification"">RFC5036</a>], DoS attacks via Extended Hellos, which are
required to establish a tLDP session, can be addressed by filtering
Extended Hellos using access lists that define addresses with which
Extended Discovery is permitted. Further, as described in
<a href="#section-5.2">Section 5.2</a> of this document, an LSR can employ a policy to accept
all auto-discovered Extended Hellos from the configured source
addresses list.
Also, for the two LSRs supporting the TAC, the tLDP session is only
established after successful negotiation of the TAC. The initiating
and receiving LSRs MUST only advertise TA-Ids that they support --
in other words, what they are configured for over the tLDP session.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. IANA Considerations</span>
IANA has assigned the following code point for the new Capability
Parameter TLV defined in this document. The code point has been
assigned from the "TLV Type Name Space" sub-registry of the "Label
Distribution Protocol (LDP) Parameters" registry.
Value Description Reference
------ ------------------------------- ---------
0x050F Targeted Application Capability <a href="./rfc8223">RFC 8223</a>
IANA has assigned a new status code from the "Status Code Name Space"
sub-registry of the "Label Distribution Protocol (LDP) Parameters"
registry.
Value E Description Reference
---------- --- ----------------------------------- ---------
0x0000004C 1 Session Rejected/Targeted
Application Capability Mismatch <a href="./rfc8223">RFC 8223</a>
<span class="grey">Esale, 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="./rfc8223">RFC 8223</a> Application-Aware tLDP August 2017</span>
IANA has created a new registry called "LDP Targeted Application
Identifier" in the "Label Distribution Protocol (LDP) Parameters"
registry. The range is 0x0001-0xFFFE. Values in the range
0x0001-0x1FFF in this registry shall be allocated according to the
"IETF Review" procedure [<a href="./rfc8126" title="">RFC8126</a>]; values in the range 0x2000-0xF7FF
shall be allocated according to the "First Come First Served"
procedure [<a href="./rfc8126" title="">RFC8126</a>]. The initial values are as follows.
Value Description Reference
--------------- ------------------------------- ---------
0x0000 Reserved <a href="./rfc8223">RFC 8223</a>
0x0001 LDPv4 Tunneling <a href="./rfc8223">RFC 8223</a>
0x0002 LDPv6 Tunneling <a href="./rfc8223">RFC 8223</a>
0x0003 mLDP Tunneling <a href="./rfc8223">RFC 8223</a>
0x0004 LDPv4 Remote LFA <a href="./rfc8223">RFC 8223</a>
0x0005 LDPv6 Remote LFA <a href="./rfc8223">RFC 8223</a>
0x0006 LDP FEC 128 PW <a href="./rfc8223">RFC 8223</a>
0x0007 LDP FEC 129 PW <a href="./rfc8223">RFC 8223</a>
0x0008 LDP Session Protection <a href="./rfc8223">RFC 8223</a>
0x0009 LDP ICCP <a href="./rfc8223">RFC 8223</a>
0x000A LDP P2MP PW <a href="./rfc8223">RFC 8223</a>
0x000B mLDP Node Protection <a href="./rfc8223">RFC 8223</a>
0x000C LDPv4 Intra-area FECs <a href="./rfc8223">RFC 8223</a>
0x000D LDPv6 Intra-area FECs <a href="./rfc8223">RFC 8223</a>
0x000E-0xF7FF Unassigned
0xF800-0xFBFF Available for Private Use
0xFC00-0xFFFE Available for Experimental Use
0xFFFF Reserved <a href="./rfc8223">RFC 8223</a>
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. References</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.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>>.
<span class="grey">Esale, 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="./rfc8223">RFC 8223</a> Application-Aware tLDP August 2017</span>
[<a id="ref-RFC7473">RFC7473</a>] Raza, K. and S. Boutros, "Controlling State Advertisements
of Non-negotiated LDP Applications", <a href="./rfc7473">RFC 7473</a>,
DOI 10.17487/RFC7473, March 2015,
<<a href="https://www.rfc-editor.org/info/rfc7473">https://www.rfc-editor.org/info/rfc7473</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>>.
[<a id="ref-RFC8174">RFC8174</a>] Leiba, B., "Ambiguity of Uppercase vs Lowercase in
<a href="./rfc2119">RFC 2119</a> Key Words", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc8174">RFC 8174</a>,
DOI 10.17487/RFC8174, May 2017,
<<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>>.
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Informative References</span>
[<a id="ref-RFC6074">RFC6074</a>] Rosen, E., Davie, B., Radoaca, V., and W. Luo,
"Provisioning, Auto-Discovery, and Signaling in Layer 2
Virtual Private Networks (L2VPNs)", <a href="./rfc6074">RFC 6074</a>,
DOI 10.17487/RFC6074, January 2011,
<<a href="https://www.rfc-editor.org/info/rfc6074">https://www.rfc-editor.org/info/rfc6074</a>>.
[<a id="ref-RFC6388">RFC6388</a>] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.
Thomas, "Label Distribution Protocol Extensions for
Point-to-Multipoint and Multipoint-to-Multipoint Label
Switched Paths", <a href="./rfc6388">RFC 6388</a>, DOI 10.17487/RFC6388,
November 2011, <<a href="https://www.rfc-editor.org/info/rfc6388">https://www.rfc-editor.org/info/rfc6388</a>>.
[<a id="ref-RFC7490">RFC7490</a>] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N.
So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)",
<a href="./rfc7490">RFC 7490</a>, DOI 10.17487/RFC7490, April 2015,
<<a href="https://www.rfc-editor.org/info/rfc7490">https://www.rfc-editor.org/info/rfc7490</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>>.
<span class="grey">Esale, 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="./rfc8223">RFC 8223</a> Application-Aware tLDP August 2017</span>
Acknowledgments
The authors wish to thank Nischal Sheth, Hassan Hosseini, Kishore
Tiruveedhula, Loa Andersson, Eric Rosen, Yakov Rekhter, Thomas
Beckhaus, Tarek Saad, Lizhong Jin, and Bruno Decraene for their
detailed reviews. Thanks to Manish Gupta and Martin Ehlers for their
input to this work and many helpful suggestions.
Contributors
The following people contributed substantially to the content of this
document and should be considered co-authors:
Chris Bowers
Juniper Networks
1133 Innovation Way
Sunnyvale, CA 94089
United States of America
Email: cbowers@juniper.net
Zhenbin Li
Huawei
Bldg. No. 156 Beiqing Rd.
Beijing 100095
China
Email: lizhenbin@huawei.com
<span class="grey">Esale, 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="./rfc8223">RFC 8223</a> Application-Aware tLDP August 2017</span>
Authors' Addresses
Santosh Esale
Juniper Networks
1133 Innovation Way
Sunnyvale, CA 94089
United States of America
Email: sesale@juniper.net
Raveendra Torvi
Juniper Networks
10 Technology Park Drive
Westford, MA 01886
United States of America
Email: rtorvi@juniper.net
Luay Jalil
Verizon
1201 East Arapaho Road
Richardson, TX 75081
United States of America
Email: luay.jalil@verizon.com
Uma Chunduri
Huawei
2330 Central Expressway
Santa Clara, CA 95050
United States of America
Email: uma.chunduri@huawei.com
Kamran Raza
Cisco Systems, Inc.
2000 Innovation Drive
Ottawa, ON K2K-3E8
Canada
Email: skraza@cisco.com
Esale, et al. Standards Track [Page 18]
</pre>
|
