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) T. Morin, Ed.
Request for Comments: 7899 S. Litkowski
Updates: <a href="./rfc6514">6514</a> Orange
Category: Standards Track K. Patel
ISSN: 2070-1721 Cisco Systems
Z. Zhang
R. Kebler
J. Haas
Juniper Networks
June 2016
<span class="h1">Multicast VPN State Damping</span>
Abstract
This document describes procedures to damp Multicast VPN (MVPN)
routing state changes and control the effect of the churn due to the
multicast dynamicity in customer sites. The procedures described in
this document are applicable to BGP-based multicast VPN and help
avoid uncontrolled control-plane load increase in the core routing
infrastructure. The new procedures proposed were inspired by BGP
unicast route damping principles that have been adapted to multicast.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc7841#section-2">Section 2 of RFC 7841</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc7899">http://www.rfc-editor.org/info/rfc7899</a>.
<span class="grey">Morin, 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="./rfc7899">RFC 7899</a> MVPN Damping June 2016</span>
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3">3</a>. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-4">4</a>. Existing Mechanisms . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-4.1">4.1</a>. Rate-Limiting Multicast Control Traffic . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-4.2">4.2</a>. Existing PIM, IGMP, and MLD Timers . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-4.3">4.3</a>. BGP Route Damping . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-5">5</a>. Procedures for Multicast State Damping . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-5.1">5.1</a>. PIM Procedures . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-5.2">5.2</a>. Procedures for Multicast VPN State Damping . . . . . . . <a href="#page-10">10</a>
<a href="#section-6">6</a>. Procedures for P-Tunnel State Damping . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-6.1">6.1</a>. Damping MVPN P-Tunnel Change Events . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-6.2">6.2</a>. Procedures for Ethernet VPNs . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-7">7</a>. Operational Considerations . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-7.1">7.1</a>. Enabling Multicast Damping . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-7.2">7.2</a>. Troubleshooting and Monitoring . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-7.3">7.3</a>. Default and Maximum Values . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-8">8</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-9">9</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-9.1">9.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-9.2">9.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
<span class="grey">Morin, 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="./rfc7899">RFC 7899</a> MVPN Damping June 2016</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
In a multicast VPN [<a href="./rfc6513" title=""Multicast in MPLS/ BGP IP VPNs"">RFC6513</a>] deployed with BGP-based procedures
[<a href="./rfc6514" title=""BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs"">RFC6514</a>], when receivers in VPN sites join and leave a given
multicast group or channel through multicast membership control
protocols (Internet Group Management Protocol (IGMP) [<a href="./rfc3376" title=""Internet Group Management Protocol, Version 3"">RFC3376</a>] and
Multicast Listener Discovery (MLD) [<a href="./rfc3810" title=""Multicast Listener Discovery Version 2 (MLDv2) for IPv6"">RFC3810</a>]), multicast routing
protocols accordingly adjust multicast routing states and P-multicast
tree states to forward or prune multicast traffic to these receivers.
Similar challenges arise in the context of the multicast
specification for Virtual Private LAN Service (VPLS) [<a href="./rfc7117" title=""Multicast in Virtual Private LAN Service (VPLS)"">RFC7117</a>].
In VPN contexts, providing isolation between customers of a shared
infrastructure is a core requirement resulting in stringent
expectations with regard to risks of denial-of-service attacks.
By nature, multicast memberships change based on the behavior of
multicast applications running on end hosts. Hence, the frequency of
membership changes can legitimately be much higher than the typical
churn of unicast routing states.
Therefore, mechanisms need to be put in place to ensure that the load
put on the BGP control plane, and on the P-tunnel setup control
plane, remains under control regardless of the frequency at which
multicast membership changes are made by end hosts.
This document describes procedures inspired by existing BGP route
damping [<a href="./rfc2439" title=""BGP Route Flap Damping"">RFC2439</a>] that are aimed at offering means to set an upper
bound to the amount of processing for the MVPN control-plane
protocols: more precisely, the BGP control plane in [<a href="./rfc6514" title=""BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs"">RFC6514</a>], the
P-tunnel control-plane protocol in the contexts of [<a href="./rfc6514" title=""BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs"">RFC6514</a>], and the
multicast specification for VPLS [<a href="./rfc7117" title=""Multicast in Virtual Private LAN Service (VPLS)"">RFC7117</a>]. The goal of setting this
upper bound is pursued simultaneous with the goal of preserving the
service provided (delivering the multicast stream as requested by
Customer Edge devices), although at the expense of a minimal increase
of average bandwidth use in the provider network). The upper bound
to the control-plane load due to the processing of a given multicast
state is controlled indirectly via configurable parameters.
<a href="./rfc6514#section-16">Section 16 of [RFC6514]</a> specifically spells out the need for damping
the activity of C-multicast and Leaf Auto-discovery routes and
outlines how to do it by "delaying the advertisement of withdrawals
of C-multicast routes". This specification provides appropriate
detail on how to implement this approach and how to provide control
to the operator; for this reason, it is an update to [<a href="./rfc6514" title=""BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs"">RFC6514</a>].
<span class="grey">Morin, 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="./rfc7899">RFC 7899</a> MVPN Damping June 2016</span>
The base principle of this specification is described in <a href="#section-3">Section 3</a>.
Existing mechanisms that could be relied upon are discussed in
<a href="#section-4">Section 4</a>. <a href="#section-5">Section 5</a> details the procedures introduced by this
specification.
<a href="#section-6">Section 6</a> provides specific details related to the damping of
multicast VPNs P-tunnel state.
Finally, <a href="#section-7">Section 7</a> discusses operational considerations related to
the proposed mechanism.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <a href="./rfc2119">RFC 2119</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
This document reuses terminology from [<a href="./rfc7761" title=""Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)"">RFC7761</a>] and [<a href="./rfc6514" title=""BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs"">RFC6514</a>].
In this specification, damping of a multicast state will be said to
be "active" or "inactive". Note that in [<a href="./rfc2439" title=""BGP Route Flap Damping"">RFC2439</a>], the term used for
a unicast route that is dampened is "suppressed", but we will avoid
this term in this specification given that the proposed solution
consists in holding active a damped multicast state.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Overview</span>
The procedures described in this document allow the network operator
to configure multicast VPN PEs (Provider Edge routers) so that they
can delay the propagation of multicast state prune messages between
PEs when faced with a rate of multicast state dynamicity exceeding a
certain configurable threshold. Assuming that the number of
multicast states that can be created by a receiver is bounded,
delaying the propagation of multicast state pruning results in
setting up an upper bound to the average frequency at which the
router will send state updates to an upstream router.
From the point of view of a downstream router, such as a CE (Customer
Edge router), this approach has no impact: the multicast routing
state changes that it solicits to its PE will be honored without any
additional delay. Indeed, the propagation of Joins is not impacted
by the procedures specified here, and having the upstream router
delay state prune propagation to its own upstream router does not
affect what traffic is sent to the downstream router. In particular,
the amount of bandwidth used on the PE-CE link downstream to a PE
applying this damping technique is not increased.
<span class="grey">Morin, 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="./rfc7899">RFC 7899</a> MVPN Damping June 2016</span>
This approach increases the average bandwidth utilization on a link
upstream to a PE applying this technique, such as a PE-PE link:
indeed, a given multicast flow will be forwarded for a longer time
than if no damping was applied. That said, it is expected that this
technique will meet the goals of protecting the multicast routing
infrastructure control plane without a significant average increase
of bandwidth; for instance, damping events happening at a frequency
higher than one event per X seconds can be done without increasing by
more than X seconds the time during which a multicast flow is present
on a link.
That said, simulation of the exponential decay algorithm shows that
the multicast state churn can be drastically reduced without
significantly increasing the duration for which multicast traffic is
forwarded. Hence, using this technique will efficiently protect the
multicast routing infrastructure control plane against the issues
described here without a significant average increase of bandwidth.
The exception will be a scenario with strict constraints on multicast
bandwidth, where extending the time a multicast flow is forwarded
would result in congestion.
To be practical, such a mechanism requires configurability. In
particular, means are required to control when damping is triggered
and to allow delaying the pruning of a multicast state for a time
increasing with the churn of this multicast state. This will let the
operator control the trade-off made between minimizing the dynamicity
and reducing bandwidth consumption.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Existing Mechanisms</span>
This section describes mechanisms that could be considered to address
the issue but that end up appearing as not suitable or not efficient
enough.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Rate-Limiting Multicast Control Traffic</span>
The Protocol Independent Multicast - Sparse Mode (PIM-SM)
specification [<a href="./rfc7761" title=""Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)"">RFC7761</a>] examines multicast security threats and,
among other things, the risk of denial-of-service attacks described
in <a href="#section-1">Section 1</a>. A mechanism relying on rate-limiting PIM messages is
proposed in <a href="./rfc4609#section-5.3.3">Section 5.3.3 of [RFC4609]</a> but has the identified
drawbacks of impacting the service delivered and having side-effects
on legitimate users.
<span class="grey">Morin, 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="./rfc7899">RFC 7899</a> MVPN Damping June 2016</span>
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Existing PIM, IGMP, and MLD Timers</span>
In the context of PIM multicast routing protocols [<a href="./rfc7761" title=""Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)"">RFC7761</a>], a
mechanism exists that may offer a form of de facto damping of
multicast states, under some conditions. Indeed, when active, the
prune override mechanism consists in having a PIM upstream router
introduce a delay ("prune override interval") before taking into
account a PIM Prune message sent by a downstream neighbor.
This mechanism has not been designed specifically for the purpose of
damping multicast state, but as a means to allow PIM to operate on
multi-access networks. See <a href="./rfc7761#section-4.3.3">Section 4.3.3 of [RFC7761]</a>. However,
when active, this mechanism will prevent a downstream router from
producing multicast routing protocol messages that would cause, for a
given multicast state, the upstream router to send to its own
upstream router multicast routing protocol messages at a rate higher
than 1/[JP_Override_Interval]. This provides a form of de facto
damping.
Similarly, the IGMP and MLD multicast membership control protocols
can provide a similar behavior under the right conditions.
These mechanisms are not considered suitable to meet the goals
spelled out in <a href="#section-1">Section 1</a>, the main reasons being that:
o when enabled, these mechanisms require additional bandwidth on the
local link on which the effect of a prune is delayed (in our case,
the PE-CE link);
o when enabled, these mechanisms require disabling explicit tracking
(see <a href="./rfc7761#section-4.3.3">Section 4.3.3 of [RFC7761]</a>), even though enabling this
feature may otherwise be desired;
o on certain implementations, these mechanisms are incompatible with
behaviors that cannot be turned off (e.g., implementation applying
a fast-leave behavior on interfaces with only two neighbors);
o they do not provide a suitable level of configurability; and
o they do not provide a way to discriminate between multicast flows
based on estimation of their dynamicity.
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. BGP Route Damping</span>
The procedures defined in [<a href="./rfc2439" title=""BGP Route Flap Damping"">RFC2439</a>] and [<a href="./rfc7196" title=""Making Route Flap Damping Usable"">RFC7196</a>] for BGP route flap
damping are useful for operators who want to control the impact of
unicast route churn on the routing infrastructure and offer a
standardized set of parameters to control damping.
<span class="grey">Morin, 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="./rfc7899">RFC 7899</a> MVPN Damping June 2016</span>
These procedures are not directly relevant in a multicast context for
the following reasons:
o they are not specified for multicast routing protocol in general,
and
o even in contexts where BGP routes are used to carry multicast
routing states (e.g., [<a href="./rfc6514" title=""BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs"">RFC6514</a>]), these procedures do not allow
the implementation of the principle described in this document;
the main reason being that a damped route becomes suppressed while
the target behavior would be to keep advertising when damping is
triggered on a multicast route.
However, the set of parameters standardized to control the thresholds
of the exponential decay mechanism can be relevantly reused. This is
the approach proposed for the procedures described in this document
(<a href="#section-5">Section 5</a>). Motivations for doing so are to help the network
operator deploy this feature based on consistent configuration
parameters and to obtain predictable results without the drawbacks of
relying on rate-limiting multicast control protocol exchanges (as is
exposed in <a href="#section-4.1">Section 4.1</a>) or on the use of existing PIM/IGMP timers (as
is exposed in <a href="#section-4.2">Section 4.2</a>).
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Procedures for Multicast State Damping</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. PIM Procedures</span>
This section describes procedures for multicast state damping
satisfying the goals spelled out in <a href="#section-1">Section 1</a>. This section
describes procedures for (S,G) states in the PIM-SM protocol
[<a href="./rfc7761" title=""Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)"">RFC7761</a>]; they apply unchanged for such states created based on
multicast group management protocols (IGMP [<a href="./rfc3376" title=""Internet Group Management Protocol, Version 3"">RFC3376</a>], MLD [<a href="./rfc3810" title=""Multicast Listener Discovery Version 2 (MLDv2) for IPv6"">RFC3810</a>])
on downstream interfaces. The same procedures are applied to (*,G)
states in the context of PIM-SM Any-Source Multicast (ASM) groups
(damping is not applied to (S,G,Rpt) Prune state).
The following notions of [<a href="./rfc2439" title=""BGP Route Flap Damping"">RFC2439</a>] are reused in these procedures:
figure-of-merit: A number reflecting the current estimation of
recent past activity of an (S,G) multicast routing state, which
increases based on routing events related to this state and
decreases between these events following an exponential decay
function (see below); the activation or inactivation of damping on
the state is based on this number. This number is associated with
the upstream state machine for (S,G) and is initialized to a value
of zero on state creation.
<span class="grey">Morin, 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="./rfc7899">RFC 7899</a> MVPN Damping June 2016</span>
exponential decay function: A mathematical function as defined in
<a href="./rfc2439#section-2.3">Section 2.3 of [RFC2439]</a> (ignoring the first paragraph of the
section, as it does not apply here).
decay-half-life: The duration used to control how fast the
exponential decay of the *figure-of-merit* is; this parameter of
the exponential decay function is the time duration during which
the *figure-of-merit* will be reduced by half when in the absence
of a routing event (configurable parameter).
cutoff-threshold: The value of the *figure-of-merit* over which
damping is applied (configurable parameter).
reuse-threshold: The value of the *figure-of-merit* under which
damping stops being applied (configurable parameter).
In addition to these values, a configurable *increment-factor*
parameter is introduced that controls by how much the *figure-of-
merit* is incremented on multicast state update events.
<a href="#section-7.3">Section 7.3</a> proposes default and maximum values for the configurable
parameters.
On reception of updated multicast membership or routing information
on a downstream interface I for a given (S,G) state, which results in
a change of the state of the PIM downstream state machine (see
<a href="./rfc7761#section-4.5.3">Section 4.5.3 of [RFC7761]</a>), a router implementing these procedures
MUST:
o apply procedures of [<a href="./rfc7761" title=""Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)"">RFC7761</a>] unchanged, for everything relating
to what multicast traffic ends up being sent on downstream
interfaces, including interface I
o update the *figure-of-merit* following the exponential decay
algorithm
o increase the *figure-of-merit* for the (S,G) by the *increment-
factor*
o update the damping state for the (S,G) state: damping becomes
active on the state if the recomputed *figure-of-merit* is
strictly above the configured *cutoff-threshold*:
* if damping remains inactive on (S,G) state, update the upstream
state machine as usual (as per <a href="./rfc7761#section-4.5.7">Section 4.5.7 of [RFC7761]</a>).
<span class="grey">Morin, 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="./rfc7899">RFC 7899</a> MVPN Damping June 2016</span>
* if damping becomes active for the (S,G) state:
+ if the received message has caused the upstream state
machine to transition to Joined state, update the upstream
state machine for (S,G) applying usual PIM procedures in
<a href="./rfc7761#section-4.5.7">Section 4.5.7 of [RFC7761]</a> and including sending a PIM Join
to the upstream neighbor
+ if the received message has caused the upstream state
machine to transition to NotJoined state, do not update the
upstream state machine for (S,G)
+ hold the upstream state machine in Joined state until the
reuse threshold is reached: for the purpose of updating this
state machine, events that may result in updating the state
based on [<a href="./rfc7761" title=""Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)"">RFC7761</a>] SHOULD be ignored until the *reuse-
threshold* is reached. The effect is that in the meantime,
while PIM Join messages may be sent as refreshes to the
upstream neighbor, no PIM Prune message will be sent.
* if damping was already active, do not update the upstream state
machine for (S,G); the upstream state machine was frozen after
processing the previous message.
Once the *figure-of-merit* for (S,G) damping state decays to a value
strictly below the configured *reuse-threshold*, the upstream state
machine for (S,G) is recomputed based on states of downstream state
machines, eventually leading to a PIM Join or Prune message to be
sent to the upstream neighbor.
Given the specificity of multicast applications, it is REQUIRED for
the implementation to let the operator configure the *decay-half-
life* in seconds, rather than in minutes.
This specification does not impose the use of a particular technique
to update the *figure-of-merit* following the exponential decay
controlled by the configured *decay-half-life*. For instance, the
same techniques as the ones described in [<a href="./rfc2439" title=""BGP Route Flap Damping"">RFC2439</a>] can be applied.
The only requirement is that the *figure-of-merit* has to be updated
prior to increasing it and that its decay below the *reuse-threshold*
has to be reacted upon in a timely manner: in particular, if the
recomputation is done with a fixed time granularity, this granularity
should be low enough to not significantly delay the inactivation of
damping on a multicast state beyond what the operator wanted to
configure (e.g., for a *decay-half-life* of 10s, recomputing the
*figure-of-merit* each minute would result in a multicast state
remaining damped for a much longer time than specified).
<span class="grey">Morin, 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="./rfc7899">RFC 7899</a> MVPN Damping June 2016</span>
PIM implementations typically follow the suggestion from <a href="./rfc7761#section-4.1">Section 4.1
of [RFC7761]</a> that:
implementations will only maintain state when it is relevant to
forwarding operations - for example, the 'NoInfo' state might be
assumed from the lack of other state information, rather than
being held explicitly.
To properly implement damping procedures, an implementation MUST keep
an explicit (S,G) state as long as damping is active on an (S,G).
Once an (S,G) state expires, and damping becomes inactive on this
state, its associated *figure-of-merit* and damping state are removed
as well.
Note that these procedures:
o do not impact PIM procedures related to refreshes or expiration of
multicast routing states: PIM Prune messages triggered by the
expiration of the (S,G) keep-alive timer are not suppressed or
delayed, and the reception of Join messages not causing transition
of state on the downstream interface does not lead to incrementing
the *figure-of-merit*;
o do not impact the PIM Assert mechanism: in particular, PIM Prune
messages triggered by a change of the PIM Assert winner on the
upstream interface are not suppressed or delayed;
o do not impact PIM Prune messages that are sent when the RPF
neighbor is updated for a given multicast flow; and
o do not impact PIM Prune messages that are sent in the context of
switching between a Rendezvous Point Tree and a Shortest Path
Tree.
Note also that no action is triggered based on the reception of PIM
Prune messages (or corresponding IGMP/MLD messages) that relate to
non-existing (S,G) state: in particular, no *figure-of-merit* or
damping state is created in this case.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Procedures for Multicast VPN State Damping</span>
The procedures described in <a href="#section-5.1">Section 5.1</a> can be applied in the Virtual
Routing and Forwarding (VRF) PIM-SM implementation (in the "C-PIM
instance"), with the corresponding action to suppressing the emission
of a Prune(S,G) message being to not withdraw the C-multicast Source
Tree Join (C-S,C-G) BGP route. An implementation of [<a href="./rfc6513" title=""Multicast in MPLS/ BGP IP VPNs"">RFC6513</a>]
relying on the use of PIM to carry C-multicast routing information
MUST support this technique to be compliant with this specification.
<span class="grey">Morin, 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="./rfc7899">RFC 7899</a> MVPN Damping June 2016</span>
In the context of [<a href="./rfc6514" title=""BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs"">RFC6514</a>], where BGP is used to distribute
C-multicast routing information, the following procedure is proposed
as an alternative to the procedures in <a href="#section-5.1">Section 5.1</a> and consists in
applying damping in the BGP implementation based on existing BGP
damping mechanisms applied to C-multicast Source Tree Join routes and
Shared Tree Join routes (and as well to Leaf A-D routes - see
<a href="#section-6">Section 6</a>) and modified to implement the behavior described in
<a href="#section-3">Section 3</a> along the following guidelines:
o not withdrawing (instead of not advertising) damped routes;
o providing means to configure the *decay-half-life* in seconds if
that option is not already available; and
o using parameters for the exponential decay that are specific to
multicast based on default values and multicast-specific
configuration.
While these procedures would typically be implemented on PE routers,
in a context where BGP Route Reflectors (RRs) [<a href="./rfc4456" title=""BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)"">RFC4456</a>] are used it
can be considered useful to also be able to apply damping on RRs as
well to provide additional protection against activity created behind
multiple PEs. Additionally, for MVPN Inter-AS deployments, it can be
needed to protect one Autonomous System (AS) from the dynamicity of
multicast VPN routing events from other ASes.
The choice to implement damping based on BGP routes or the procedures
described in <a href="#section-5.1">Section 5.1</a> is up to the implementor, but at least one
of the two MUST be implemented. In the perspective of allowing
damping to be done on RRs and Autonomous System Border Routers
(ASBRs), implementing the BGP approach is recommended.
When not all routers in a deployment have the capability to drop
traffic coming from the wrong PE (as spelled out in <a href="./rfc6513#section-9.1.1">Section 9.1.1 of
[RFC6513]</a>), then the withdrawal of a C-multicast route resulting from
a change in the Upstream Multicast Hop or Upstream Multicast PE
SHOULD NOT be damped. An implementation of this specification MUST
do at least one of the two following things:
o not damp these withdrawals by default, and/or
o provide a tuning knob to disable the damping of these withdrawals.
Additionally, in such a deployment context, it is RECOMMENDED not to
enable any multicast VPN route damping on RRs and ASBRs since these
types of equipment cannot distinguish the event having caused a
C-multicast to be withdrawn.
<span class="grey">Morin, 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="./rfc7899">RFC 7899</a> MVPN Damping June 2016</span>
Note well that it is out of scope of this section to consider the
application of these damping techniques on MVPN BGP routes other than
C-multicast routes.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Procedures for P-Tunnel State Damping</span>
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Damping MVPN P-Tunnel Change Events</span>
When selective P-tunnels are used (see <a href="./rfc6513#section-7">Section 7 of [RFC6513]</a>), the
effect of updating the upstream state machine for a given (C-S,C-G)
state on a PE connected to multicast receivers is not only to
generate activity to propagate C-multicast routing information to the
source connected PE, but also to possibly trigger changes related to
the P-tunnels carrying (C-S,C-G) traffic. Protecting the provider
network from an excessive amount of change in the state of P-tunnels
is required, and this section details how this can be done.
A PE implementing these procedures for MVPN MUST damp Leaf A-D routes
in the same manner as it would for C-multicast routes (see
<a href="#section-5.2">Section 5.2</a>).
A PE implementing these procedures for MVPN MUST damp the activity
related to removing itself from a P-tunnel. Possible ways to do so
depend on the type of P-tunnel, and local implementation details are
left up to the implementor.
The following is proposed as an example of how the above can be
achieved:
o For P-tunnels implemented with the PIM protocol, this consists in
applying multicast state damping techniques described in
<a href="#section-5.1">Section 5.1</a> to the P-PIM instance, at least for (S,G) states
corresponding to P-tunnels.
o For P-tunnels implemented with multipoint LDP (mLDP), this
consists in applying damping techniques completely similar to the
one described in <a href="#section-5">Section 5</a> but generalized to apply to mLDP
states.
o For root-initiated P-tunnels (P-tunnels implemented with the
Point-to-Multipoint (P2MP) RSVP-TE, or relying on ingress
replication), no particular action needs to be implemented to damp
P-tunnels membership, if the activity of Leaf A-D route themselves
is damped.
<span class="grey">Morin, 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="./rfc7899">RFC 7899</a> MVPN Damping June 2016</span>
o Another possibility is to base the decision to join or not join
the P-tunnel to which a given (C-S,C-G) is bound and to advertise
or not advertise a Leaf A-D route related to (C-S,C-G) based on
whether or not a C-multicast Source Tree Join route is being
advertised for (C-S,C-G) rather than by relying on the state of
the C-PIM Upstream state machine for (C-S,C-G).
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Procedures for Ethernet VPNs</span>
Specifications exist to support or optimize multicast and broadcast
in the context of Ethernet VPNs [<a href="./rfc7117" title=""Multicast in Virtual Private LAN Service (VPLS)"">RFC7117</a>] relying on the use of
Selective P-Multicast Service Interface (S-PMSI) and P-tunnels. For
the same reasons as for IP multicast VPNs, an implementation of
[<a href="./rfc7117" title=""Multicast in Virtual Private LAN Service (VPLS)"">RFC7117</a>] MUST follow the procedures described in <a href="#section-6.1">Section 6.1</a> to be
compliant with this specification.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Operational Considerations</span>
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Enabling Multicast Damping</span>
In the context of multicast VPNs, these procedures would be enabled
on PE routers. Additionally, in the case of C-multicast routing
based on BGP extensions ([<a href="./rfc6514" title=""BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs"">RFC6514</a>]), these procedures can be enabled
on ASBRs and RRs.
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Troubleshooting and Monitoring</span>
Implementing the damping mechanisms described in this document should
be complemented by appropriate tools to observe and troubleshoot
damping activity.
Complementing the existing interface providing information on
multicast states with information on eventual damping of
corresponding states (e.g., Multicast Routing Information Base (MRIB)
states) is RECOMMENDED for C-multicast routing states and P-tunnel
states.
<span class="h3"><a class="selflink" id="section-7.3" href="#section-7.3">7.3</a>. Default and Maximum Values</span>
Considering that, by design, multicast streams will be delivered
unchanged to the end user independent of the value chosen for the
configurable parameters, and that the only trade-off being made is an
increase of bandwidth use, the default and maximum values do not have
to be perfectly tuned.
This section proposes default and maximum values that are
conservative, so as to not significantly impact network dimensioning
but still prevent multicast state churn going beyond what can be
<span class="grey">Morin, 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="./rfc7899">RFC 7899</a> MVPN Damping June 2016</span>
considered a reasonably low churn for a multicast state (see below
for illustrations in order of magnitude of the effect of these
values).
The following values are RECOMMENDED to be adopted as default values:
o *increment-factor*: 1000
o *cutoff-threshold*: 3000
o *decay-half-life*: 10s
o *reuse-threshold*: 1500
For unicast damping, it is common to set an upper bound to the time
during which a route is suppressed. In the case of multicast state
damping, which relies on not withdrawing a damped route, it may be
desirable to avoid a situation where a multicast flow would keep
flowing in a portion of the network for a very long time in the
absence of receivers.
The proposed default maximum value for the *figure-of-merit* is
20x*increment-factor*, i.e., 20000 with the proposed default
*increment-factor* of 1000.
As illustrations, with these values:
o a multicast state updated less frequently than once every 6 s will
not be damped at all;
o a multicast state changing once per second for 3 s, and then not
changing, will not be damped;
o a multicast state changing once per second for 4 s, and then not
changing, will be damped after the fourth change for approximately
13 s;
o a multicast state changing twice per second for 15 s, and then not
changing, will be damped after the fourth change for approximately
50 s; and
o a multicast state changing at a fast pace for a long time will
reach the maximum of *figure-of-merit*; once the activity on this
state stops, corresponding traffic may still flow in the network
for approximately 37 s before dampening stops being active.
<span class="grey">Morin, 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="./rfc7899">RFC 7899</a> MVPN Damping June 2016</span>
The following values are proposed as maximums:
o *decay-half-life*: 60 s
o *cutoff-threshold*: 50000
More aggressive protection against the risk of denial of service can
be achieved by increasing the *increment-factor* or the
*decay-half-life*, or by reducing the *cutoff-threshold* and/or
*reuse-threshold*.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Security Considerations</span>
The procedures defined in this document do not introduce additional
security issues not already present in the contexts addressed and
actually aim at addressing some of the identified risks without
introducing as much denial-of-service risk as some of the mechanisms
already defined.
The protection provided relates to the control plane of the multicast
routing protocols, including the components implementing the routing
protocols and the components responsible for updating the multicast
forwarding plane.
The procedures described are meant to provide some level of
protection for the router on which they are enabled by reducing the
amount of routing state updates that it needs to send to its upstream
neighbor or peers but do not provide any reduction of the control-
plane load related to processing routing information from downstream
neighbors. Protecting routers from an increase in control-plane load
due to activity on downstream interfaces toward core routers (or in
the context of BGP-based MVPN C-multicast routing, BGP peers) relies
on the activation of damping on corresponding downstream neighbors
(or BGP peers) and/or at the edge of the network. Protecting routers
from an increase in control-plane load due to activity on customer-
facing downstream interfaces or downstream interfaces to routers in
another administrative domain is out of the scope of this document
and should use already defined mechanisms (see [<a href="./rfc4609" title=""Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements"">RFC4609</a>]).
To be effective, the procedures described here must be complemented
by configuration limiting the number of multicast states that can be
created on a multicast router through protocol interactions with
multicast receivers, neighbor routers in adjacent ASes, or in
multicast VPN contexts with multicast CEs. Note well that the two
mechanisms may interact: the state for which Prune has been requested
may still remain taken into account for some time if damping has been
triggered and hence result in an otherwise acceptable new state from
being successfully created.
<span class="grey">Morin, 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="./rfc7899">RFC 7899</a> MVPN Damping June 2016</span>
Additionally, it is worth noting that these procedures are not meant
to protect against peaks of control-plane load but only address
averaged load. For instance, assuming a set of multicast states are
submitted to the same Join/Prune events, damping can prevent more
than a certain number of Join/Prune messages to be sent upstream in
the period of time that elapses between the reception of Join/Prune
messages triggering the activation of damping on these states and
when damping becomes inactive after decay.
<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="http://www.rfc-editor.org/info/rfc2119">http://www.rfc-editor.org/info/rfc2119</a>>.
[<a id="ref-RFC2439">RFC2439</a>] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route
Flap Damping", <a href="./rfc2439">RFC 2439</a>, DOI 10.17487/RFC2439, November
1998, <<a href="http://www.rfc-editor.org/info/rfc2439">http://www.rfc-editor.org/info/rfc2439</a>>.
[<a id="ref-RFC3376">RFC3376</a>] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", <a href="./rfc3376">RFC 3376</a>, DOI 10.17487/RFC3376, October 2002,
<<a href="http://www.rfc-editor.org/info/rfc3376">http://www.rfc-editor.org/info/rfc3376</a>>.
[<a id="ref-RFC3810">RFC3810</a>] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
Discovery Version 2 (MLDv2) for IPv6", <a href="./rfc3810">RFC 3810</a>,
DOI 10.17487/RFC3810, June 2004,
<<a href="http://www.rfc-editor.org/info/rfc3810">http://www.rfc-editor.org/info/rfc3810</a>>.
[<a id="ref-RFC6513">RFC6513</a>] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
BGP IP VPNs", <a href="./rfc6513">RFC 6513</a>, DOI 10.17487/RFC6513, February
2012, <<a href="http://www.rfc-editor.org/info/rfc6513">http://www.rfc-editor.org/info/rfc6513</a>>.
[<a id="ref-RFC6514">RFC6514</a>] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", <a href="./rfc6514">RFC 6514</a>, DOI 10.17487/RFC6514, February 2012,
<<a href="http://www.rfc-editor.org/info/rfc6514">http://www.rfc-editor.org/info/rfc6514</a>>.
[<a id="ref-RFC7117">RFC7117</a>] Aggarwal, R., Ed., Kamite, Y., Fang, L., Rekhter, Y., and
C. Kodeboniya, "Multicast in Virtual Private LAN Service
(VPLS)", <a href="./rfc7117">RFC 7117</a>, DOI 10.17487/RFC7117, February 2014,
<<a href="http://www.rfc-editor.org/info/rfc7117">http://www.rfc-editor.org/info/rfc7117</a>>.
<span class="grey">Morin, 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="./rfc7899">RFC 7899</a> MVPN Damping June 2016</span>
[<a id="ref-RFC7196">RFC7196</a>] Pelsser, C., Bush, R., Patel, K., Mohapatra, P., and O.
Maennel, "Making Route Flap Damping Usable", <a href="./rfc7196">RFC 7196</a>,
DOI 10.17487/RFC7196, May 2014,
<<a href="http://www.rfc-editor.org/info/rfc7196">http://www.rfc-editor.org/info/rfc7196</a>>.
[<a id="ref-RFC7761">RFC7761</a>] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
Multicast - Sparse Mode (PIM-SM): Protocol Specification
(Revised)", STD 83, <a href="./rfc7761">RFC 7761</a>, DOI 10.17487/RFC7761, March
2016, <<a href="http://www.rfc-editor.org/info/rfc7761">http://www.rfc-editor.org/info/rfc7761</a>>.
<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>. Informative References</span>
[<a id="ref-RFC4456">RFC4456</a>] Bates, T., Chen, E., and R. Chandra, "BGP Route
Reflection: An Alternative to Full Mesh Internal BGP
(IBGP)", <a href="./rfc4456">RFC 4456</a>, DOI 10.17487/RFC4456, April 2006,
<<a href="http://www.rfc-editor.org/info/rfc4456">http://www.rfc-editor.org/info/rfc4456</a>>.
[<a id="ref-RFC4609">RFC4609</a>] Savola, P., Lehtonen, R., and D. Meyer, "Protocol
Independent Multicast - Sparse Mode (PIM-SM) Multicast
Routing Security Issues and Enhancements", <a href="./rfc4609">RFC 4609</a>,
DOI 10.17487/RFC4609, October 2006,
<<a href="http://www.rfc-editor.org/info/rfc4609">http://www.rfc-editor.org/info/rfc4609</a>>.
Acknowledgements
We would like to thank Bruno Decraene and Lenny Giuliano for
discussions that helped shape this proposal. We would also like to
thank Yakov Rekhter and Eric Rosen for their reviews and helpful
comments. Thanks to Wim Henderickx for his comments and support of
this proposal. Additionally, Martin Vigoureux, Gunter Van De Velde,
and Alvaro Retana provided useful comments to finalize the document.
Authors' Addresses
Thomas Morin (editor)
Orange
2, avenue Pierre Marzin
Lannion 22307
France
Email: thomas.morin@orange.com
<span class="grey">Morin, 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="./rfc7899">RFC 7899</a> MVPN Damping June 2016</span>
Stephane Litkowski
Orange
France
Email: stephane.litkowski@orange.com
Keyur Patel
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
United States of America
Email: keyupate@cisco.com
Zhaohui Zhang
Juniper Networks Inc.
10 Technology Park Drive
Westford, MA 01886
United States of America
Email: zzhang@juniper.net
Robert Kebler
Juniper Networks Inc.
10 Technology Park Drive
Westford, MA 01886
United States of America
Email: rkebler@juniper.net
Jeffrey Haas
Juniper Networks
Email: jhaas@juniper.net
Morin, et al. Standards Track [Page 18]
</pre>
|
