idnits 2.17.1 draft-morin-bess-multicast-damping-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 23, 2014) is 3445 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Morin, Ed. 3 Internet-Draft S. Litkowski 4 Intended status: Standards Track Orange 5 Expires: April 26, 2015 K. Patel 6 Cisco Systems 7 J. Zhang 8 R. Kebler 9 J. Haas 10 Juniper Networks 11 October 23, 2014 13 Multicast VPN state damping 14 draft-morin-bess-multicast-damping-01 16 Abstract 18 This document describes procedures to damp multicast VPN routing 19 state changes and control the effect of the churn due to the 20 multicast dynamicity in customer site. The procedures described in 21 this document are applicable to BGP-based multicast VPN and help 22 avoid uncontrolled control plane load increase in the core routing 23 infrastructure. New procedures are proposed inspired from BGP 24 unicast route damping principles, but adapted to multicast. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in RFC 2119 [RFC2119]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on April 26, 2015. 49 Copyright Notice 51 Copyright (c) 2014 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 4. Existing mechanisms . . . . . . . . . . . . . . . . . . . . . 4 70 4.1. Rate-limiting of multicast control traffic . . . . . . . 4 71 4.2. Existing PIM, IGMP and MLD timers . . . . . . . . . . . . 4 72 4.3. BGP Route Damping . . . . . . . . . . . . . . . . . . . . 5 73 5. Procedures for multicast state damping . . . . . . . . . . . 6 74 5.1. PIM procedures . . . . . . . . . . . . . . . . . . . . . 6 75 5.2. Procedures for multicast VPN state dampening . . . . . . 9 76 6. Procedures for P-tunnel state damping . . . . . . . . . . . . 10 77 6.1. Damping mVPN P-tunnel change events . . . . . . . . . . . 10 78 6.2. Procedures for Ethernet VPNs . . . . . . . . . . . . . . 11 79 7. Operational considerations . . . . . . . . . . . . . . . . . 11 80 7.1. Enabling and configuring multicast damping . . . . . . . 11 81 7.2. Troubleshooting and monitoring . . . . . . . . . . . . . 11 82 7.3. Default and maximum values . . . . . . . . . . . . . . . 11 83 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 84 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 85 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 86 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 87 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 88 11.2. Informative References . . . . . . . . . . . . . . . . . 14 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 91 1. Introduction 93 In a multicast VPN [RFC6513] deployed with BGP-based procedures 94 [RFC6514], when receivers in VPN sites join and leave a said 95 multicast group or channel through multicast membership control 96 protocols (IGMP, MLD), multicast routing protocols accordingly adjust 97 multicast routing states and P-multicast tree states, to forward or 98 prune multicast traffic to these receivers. 100 In VPN contexts, providing isolation between customers of a shared 101 infrastructure is a core requirement resulting in stringent 102 expectations with regards to risks of denial of service attacks. 103 Hence, mechanisms need to be put in place to ensure that the load put 104 on the BGP control plane, and on the P-tunnel setup control plane, 105 remains under control regardless of the frequency at which multicast 106 memberships changes are made by end hosts. By nature multicast 107 memberships change based on the behavior of multicast applications 108 running on end hosts, hence the frequency of membership changes can 109 legitimately be much higher than the typical churn of unicast routing 110 states. Section 16 of [RFC6514] specifically spells out the need for 111 damping the activity of C-multicast and Leaf Auto-discovery routes. 113 This document describes procedures, remotely inspired from existing 114 BGP route damping, aimed at protecting these control planes while at 115 the same time avoiding negative effects on the service provided, 116 although at the expense of a minimal increase in average of bandwidth 117 use in the network. 119 The base principle is described in Section 3. Existing mechanisms 120 that could be relied upon are discussed in Section 4. Section 5 121 details the procedures introduced by these specifications. 123 Section 6 provide specific details related to the damping of 124 multicast VPNs P-tunnel state. 126 Finally, Section 7 discusses operational considerations related to 127 the proposed mechanism. 129 2. Terminology 131 TBC 133 3. Overview 135 The procedures described in this document allows the network operator 136 to configure multicast VPN PEs so that they can delay the propagation 137 of multicast state prune messages, when faced with a rate of 138 multicast state dynamicity exceeding a certain configurable 139 threshold. Assuming that the number of multicast states that can be 140 created by a receiver is bounded, delaying the propagation of 141 multicast state pruning results in setting up an upper bound to the 142 average frequency at which the router will send state updates to an 143 upstream router. 145 From the point of view of a downstream router, such as a CE, this 146 approach has no impact: the multicast routing states changes that it 147 solicits to its PE will be honored without any additional delay. 148 Indeed the propagation of joins is not impacted by the proposed 149 defined procedures, and having the upstream router delay state prune 150 propagation to its own upstream does not affect what traffic is sent 151 to the downstream router. In particular, the amount of bandwidth 152 used on the PE-CE link downstream to a PE applying this damping 153 technique is not increased. 155 This approach increases the average bandwidth utilization on a link 156 upstream to a PE applying this technique, such as a PE-PE link: 157 indeed, a said multicast flow will be forwarded for a longer time 158 than if no damping was applied. That said, it is expected that this 159 technique will allow to meet the goals of protecting the multicast 160 routing infrastructure control plane without a significant average 161 increase of bandwidth; for instance, damping events happening at a 162 frequency higher than one event per X second, can be done without 163 increasing by more than X second the time during which a multicast 164 flow is present on a link. 166 To be practical, such a mechanism requires configurability, in 167 particular, needs to offer means to control when damping is 168 triggered, and to allow delaying a multicast state Prune for a time 169 increasing with the churn of this multicast state. 171 4. Existing mechanisms 173 This section describes mechanisms that could be considered to address 174 the issue, but that end up appearing as not suitable or not efficient 175 enough. 177 4.1. Rate-limiting of multicast control traffic 179 [RFC4609] examines multicast security threats and among other things 180 the risk described in Section 1. A mechanism relying on rate- 181 limiting PIM messages is proposed in section 5.3.3 [RFC4609], but has 182 the identified drawbacks of impacting the service delivered and 183 having side-effects on legitimate users. 185 4.2. Existing PIM, IGMP and MLD timers 187 In the context of PIM multicast routing protocols [RFC4601], a 188 mechanism exists that in some context may offer a form of de facto 189 damping mechanism for multicast states. Indeed, when active, the 190 prune override mechanism consists in having a PIM upstream router 191 introduce a delay ("prune override interval") before taking into 192 account a PIM Prune message sent by a downstream neighbor. 194 This mechanism has not been designed specifically for the purpose of 195 damping multicast state, but as a means to allow PIM to operate on 196 multi-access networks. See [RFC4601] section 4.3.3. However, when 197 active, this mechanism will prevent a downstream router to produce 198 multicast routing protocol messages that would cause, for a said 199 multicast state, the upstream router to send to its own 200 upstreamrouter, multicast routing protocol messages at a rate higher 201 than 1/[prune override interval], thus providing de-facto a form of 202 damping. 204 Similarly, the IGMP and MLD multicast membership control protocols 205 can provide a similar behavior, under the right conditions. 207 These mechanisms are not considered suitable to meet the goals 208 spelled out in Section 1, the main reasons being that: 210 o when enabled these mechanisms require additional bandwidth on the 211 local link on which the effect of a Prune is delayed (in our case 212 the PE-CE link) 214 o when enabled these mechanisms require disabling explicit tracking, 215 even though enabling this feature may otherwise be desired 217 o on certain implementations, these mechanisms are incompatible with 218 behavior that cannot be turned off 220 o they do not provide a suitable level of configurability 222 o they do not provide a way to discriminate between multicast flows 223 based on estimation of their dynamicity 225 4.3. BGP Route Damping 227 The procedures defined in [RFC2439] and [RFC7196] for BGP route flap 228 damping are useful for operators who want to control the impact of 229 unicast route churn on the routing infrastructure, and offer a 230 standardized set of parameters to control damping. 232 These procedures are not directly relevant in a multicast context, 233 for the following reasons: 235 o they are not specified for multicast routing protocol in general 237 o even in contexts where BGP routes are used to carry multicast 238 routing states (e.g. [RFC6514]), these procedures do not allow to 239 implement the principle described in this document, the main 240 reason being that a damped route becomes suppressed, while the 241 target behavior would be to keep advertising when damping is 242 triggered on a multicast route 244 However, the set of parameters standardized to control the thresholds 245 of the exponential decay mechanism can be relevantly reused. This is 246 the approach proposed for the procedures described in this document 247 (Section 5). Motivations for doing so is to help the network 248 operator deploy this feature based on consistent configuration 249 parameter, and obtain predictable results, without the drawbacks of 250 exposed in Section 4.1 and Section 4.2. 252 5. Procedures for multicast state damping 254 5.1. PIM procedures 256 This section describes procedures for multicast state damping 257 satisfying the goals spelled out in Section 1. This section spells 258 out procedures for (S,G) states in the PIM-SM protocol ([RFC4601] ; 259 they apply unchanged for such states created based on multicast group 260 management protocols (IGMP [RFC3376], MLD [RFC3810]) on downstream 261 interfaces. The same procedures are applied to (*,G) states in the 262 context of PIM-SM ASM groups (damping is not applied to (S,G,Rpt) 263 Prune state). 265 The following notions introduced in [RFC2439] are reused in these 266 procedures: 268 figure-of-merit: a number reflecting the current estimation of past 269 recent activity of an (S,G) multicast routing state, which evolves 270 based on routing events related to this state and based an 271 exponential decay algorithm ; the activation or inactivation of 272 damping on the state is based on this number ; this number is 273 associated to the upstream state machine for (S,G) 275 cutoff-threshold: value of the *figure-of-merit* over which damping 276 is applied (configurable parameter) 278 reuse-threshold: value of the *figure-of-merit* under which damping 279 stops being applied (configurable parameter) 281 decay-half-life: period of time used to control how fast is the 282 exponential decay of the *figure-of-merit* (configurable 283 parameter) 285 Additionally to these values, a configurable "*increment-factor*" 286 parameter is introduced, that controls by how much the *figure-of- 287 merit* is incremented on multicast state update events. 289 Section Section 7.3 proposes default and maximum values for the 290 configurable parameters. 292 On reception of updated multicast membership or routing information 293 on a downstream interface I for a said (S,G) state, that results in a 294 change of the state of the PIM downstream state machine (see section 295 4.5.3 of [RFC4601]), a router implementing these procedures MUST: 297 o apply unchanged procedures for everything relating to what 298 multicast traffic ends up being sent on downstream interfaces, 299 including interface I 301 o increasing the *figure-of-merit* for the (S,G) by the *increment- 302 factor* (updating the *figure-of-merit* based on the decay 303 algorithm must be done prior to this increment) 305 o update the damping state for the (S,G) state: damping becomes 306 active on the state if the recomputed *figure-of-merit* is above 307 the configured *cutoff-threshold* 309 o if damping is inactive on (S,G) state, update the upstream state 310 machine as usual (as per section 4.5.7 of [RFC4601]) 312 o if damping becomes active for the (S,G) state: 314 * if the received message has caused the upstream state machine 315 to transition to Joined state, update the upstream state 316 machine for (S,G) (applying usual PIM procedures in section 317 4.5.7 of [RFC4601], including sending a PIM Join to the 318 upstream neighbor) 320 * if the received message has caused the upstream state machine 321 to transition to NotJoined state, do not update the upstream 322 state machine for (S,G) 324 * then freeze the upstream state machine in Joined state, and and 325 setup a trigger to update it once damping later becomes 326 inactive again. The effect is that in the meantime, PIM Join 327 messages will be sent as refreshes to the upstream neighbor, 328 but no PIM Prune message will be sent. 330 o if damping was already active: do not update the upstream state 331 machine for (S,G) (the upstream state machine was frozen after 332 processing the previous message) 334 Once the *figure-of-merit* for (S,G) damping state decays to a value 335 below the configured *reuse-threshold*, the upstream state machine 336 for (S,G) is recomputed based on states of downstream state machines, 337 eventually leading to a PIM Join or Prune message to be sent to the 338 upstream neighbor. 340 Same techniques as the ones described in [RFC2439] can be applied to 341 determine when the figure-of-merit value is recomputed based on the 342 exponential decay algorithm and the configured *decay-half-life*. 344 Given the specificity of multicast applications, it is REQUIRED for 345 the implementation to let the operator configure the *decay-half- 346 life* in seconds, rather than in minutes. When the recomputation is 347 done periodically, the period should be low enough to not 348 significantly delay the inactivation of damping on a multicast state 349 beyond what the operator wanted to configure (i.e. for a half-life of 350 10s, recomputing the *figure-of-merit* each minute would result in a 351 multicast state to remained damped for a much longer time than what 352 the parameters are supposed to command). 354 PIM implementations typically follow [RFC4601] suggestion that 355 "implementations will only maintain state when it is relevant to 356 forwarding operations - for example, the 'NoInfo' state might be 357 assumed from the lack of other state information, rather than being 358 held explicitly" (Section 4.1 of [RFC4601]). To properly implement 359 implement damping procedures, an implementation MUST keep an explicit 360 (S,G) state as long as damping is active on an (S,G). Once an (S,G) 361 state expires, and damping becomes inactive on this state, its 362 associated *figure-of-merit* and damping state are removed as well. 364 Note that these procedures: 366 o do not impact PIM procedures related to refreshes or expiration of 367 multicast routing states: PIM Prune messages triggered by the 368 expiration of the (S,G) keep-alive timer, are not suppressed or 369 delayed, and the reception of Join messages not causing transition 370 of state on the downstream interface does not lead to incrementing 371 the *figure-of-merit*; 373 o do not impact the PIM assert mechanism, in particular PIM Prune 374 messages triggered by a change of the PIM assert winner on the 375 upstream interface, are not suppressed or delayed; 377 o do not impact PIM Prune messages that are sent when the RPF 378 neighbor is updated for a said multicast flow; 380 o do not impact PIM Prune messages that are sent in the context of 381 switching between a Rendez-vous Point Tree and a Shortest Path 382 Tree. 384 Note also that no action is triggered based on the reception of PIM 385 Prune messages (or corresponding IGMP/MLD messages) that relate to 386 non-existing (S,G) state, in particular, no *figure-of-merit* or 387 damping state is created in this case. 389 5.2. Procedures for multicast VPN state dampening 391 The procedures described in Section 5.1 can be applied in the VRF 392 PIM-SM implementation (in the "C-PIM instance"), with the 393 corresponding action to suppressing the emission of a Prune(S,G) 394 message being to not withdraw the C-multicast Source Tree Join 395 (C-S,C-G) BGP route. Implementation of [RFC6513] relying on the use 396 of PIM to carry C-multicast routing information MUST support this 397 technique. 399 In the context of [RFC6514] where BGP is used to distribute 400 C-multicast routing information, the following procedure is proposed 401 as an alternative and consists in applying damping in the BGP 402 implementation, based on existing BGP damping mechanism, applied to 403 C-multicast Source Tree Join routes and Shared Tree Join routes (and 404 as well to Leaf A-D routes - see Section 6), and modified to 405 implement the behavior described in Section 3 along the following 406 guidelines: 408 o not withdrawing (instead of not advertising) damped routes 410 o providing means to configure the half-life in seconds if that 411 option is not already available 413 o using parameters for the exponential decay that are specific to 414 multicast, based on default values and multicast specific 415 configuration 417 While these procedures would typically be implemented on PE routers, 418 in a context where BGP Route Reflectors are used it can be considered 419 useful to also be able to apply damping on RRs as well. 420 Additionally, for mVPN Inter-AS deployments, it can be needed to 421 protect one AS from the dynamicity of multicast VPN routing events 422 from other ASes. In that perspective, it is RECOMMENDED for 423 implementations to support damping mVPN C-multicast routes directly 424 into BGP, without relying on the PIM-SM state machine. 426 When not all routers in a deployment have the capability to drop 427 traffic coming from the wrong PE (as spelled out in section 9.1.1 of 428 [RFC6513]), then the withdrawal of a C-multicast route resulting from 429 a change in the UMH SHOULD NOT be damped. An implementation of these 430 specs MUST whether, not damp these withdrawals by default, or 431 alternatively provide a tuning knob to disable then damping of these 432 withdrawals. Additionally, in such a context, it is RECOMMENDED to 433 *not* enable any multicast VPN route damping on RRs and ASBRs, since 434 these equipments cannot distinguish these events. 436 The choice to implement damping based on BGP routes or the procedures 437 described in Section 5, is up to the implementor, but at least one of 438 the two MUST be implemented; keeping in mind that in contexts where 439 damping on RRs and ASBRs the BGP approach is RECOMMENDED. 441 Note well that damping SHOULD NOT be applied to BGP routes of the 442 following sub-types: "Intra-AS I-PMSI A-D Route", "Inter-AS I-PMSI 443 A-D Route", "S-PMSI A-D Route", and "Source Active A-D Route". 445 6. Procedures for P-tunnel state damping 447 6.1. Damping mVPN P-tunnel change events 449 When selective P-tunnels are used (see section 7 of [RFC6513]), the 450 effect of updating the upstream state machine for a said (C-S,C-G) 451 state on a PE connected to multicast receivers, is not only to 452 generate activity to propagate C-multicast routing information to the 453 source connected PE, but also to possibly trigger changes related to 454 the P-tunnels carrying (C-S,C-G) traffic. Protecting the provider 455 network from an excessive amount of change in the state of P-tunnels 456 is required, and this section details how this can be done. 458 A PE implementing these procedures for mVPN MUST damp Leaf A-D 459 routes, in the same manner as it would for C-multicast routes (see 460 Section 5.2). 462 A PE implementing these procedures for mVPN MUST damp the activity 463 related to removing itself from a P-tunnel. Possible ways to do so 464 depend on the type of P-tunnel, and local implementation details are 465 left up to the implementor. 467 The following is proposed as example of how the above can be 468 achieved. 470 o For P-tunnels implemented with the PIM protocol, this consists in 471 applying multicast state damping techniques described in 472 Section 5.1 to the P-PIM instance, at least for (S,G) states 473 corresponding to P-tunnels. 475 o For P-tunnels implemented with the mLDP protocol, this consists in 476 applying damping techniques completely similar as the one 477 described in Section 5, but generalized to apply to mLDP states 479 o For root-initiated P-tunnels (P-tunnels implemented with the P2MP 480 RSVP-TE, or relying on ingress replication), no particular action 481 needs to be implemented to damp P-tunnels membership, if the 482 activity of Leaf A-D route themselves is damped 484 o Another possibility is to base the decision to join or not join 485 the P-tunnel to which a said (C-S,C-G) is bound, and to advertise 486 or not advertise a Leaf A-D route related to (C-S,C-G), based on 487 whether or not a C-multicast Source Tree Join route is being 488 advertised for (C-S,C-G), rather than by relying on the state of 489 the C-PIM Upstream state machine for (C-S,C-G) 491 6.2. Procedures for Ethernet VPNs 493 Specifications exists to support or optimize multicast and broadcast 494 in the context of Ethernet VPNs [RFC7117], relying on the use of 495 S-PMSI and P-tunnels. For the same reasons as for IP multicast VPNs, 496 an implementation of these procedures MUST follow the procedures 497 described in this section.Section 6.1. 499 7. Operational considerations 501 7.1. Enabling and configuring multicast damping 503 In the context of multicast VPNs, these procedures would be enabled 504 on PE routers. Additionally in the case of C-multicast routing based 505 on BGP extensions ([RFC6514]) these procedures can be enabled on 506 ASBRs, and possibly Route Reflectors as well. 508 7.2. Troubleshooting and monitoring 510 Implementing the damping mechanisms described in this document should 511 be complemented by appropriate tools to observe and troubleshoot 512 damping activity. 514 More specifically it is RECOMMENDED to complement the existing 515 interface providing information on multicast states with information 516 on eventual damping of corresponding states (e.g. MRIB states): 517 C-multicast routing states and P-tunnel states. 519 7.3. Default and maximum values 521 The following values are RECOMMENDED to adopt as default conservative 522 values: 524 o increment-factor: 1000 526 o cutoff-threshold: 3000 527 o decay-half-life: 10s 529 o reuse-threshold: 1500 531 For unicast damping, it is common to set an upper bound to the time 532 during which a route is suppressed. In the case of multicast state 533 damping, which relies on not withdrawing a damped route, it may be 534 desirable to avoid a situation were a multicast flow would keep 535 flowing in a portion of the network for a very large time in the 536 absence of receivers. 538 The proposed default maximum value for the figure-of-merit is 539 20x, i.e. 20000 with the proposed default 540 increment-factor of 1000. 542 The following values are proposed as maximums: 544 o decay half-life: 60s 546 o cutoff-threshold: 50000 548 8. IANA Considerations 550 This document makes no request of IANA. 552 Note to RFC Editor: this section may be removed on publication as an 553 RFC. 555 9. Security Considerations 557 The procedures defined in this document do not introduce additional 558 security issues not already present in the contexts addressed, and 559 actually aim at addressing some of the identified risks without 560 introducing as much denial of service risk as some of the mechanisms 561 already defined. 563 The protection provided relates to the control plane of the multicast 564 routing protocols, including the components implementing the routing 565 protocols and the components responsible for updating the multicast 566 forwarding plane. 568 The procedures describe are meant to provide some level of protection 569 for the router on which they are enabled by reducing the amount of 570 routing state updates that it needs to send to its upstream neighbor 571 or peers, but do not provide any reduction of the control plane load 572 related to processing routing information from downstream neighbors. 573 Protecting routers from an increase in control plane load due to 574 activity on downstream interfaces toward core routers (or in the 575 context of BGP-based mVPN C-multicast routing, BGP peers) shall rely 576 upon the activation of damping on corresponding downstream neighbors 577 (or BGP peers) and/or at the edge of the network. Protecting routers 578 from an increase in control plane load due to activity on customer- 579 facing downstream interfaces or downstream interfaces to routers in 580 another administrative domain, is out of the scope of this document 581 and should rely upon already defined mechanisms (see [RFC4609]). 583 To be effective the procedures described here must be complemented by 584 configuration limiting the number of multicast states that can be 585 created on a multicast router through protocol interactions with 586 multicast receivers, neighbor routers in adjacent ASes, or in 587 multicast VPN contexts with multicast CEs. Note well that the two 588 mechanism may interact: state for which Prune has been requested may 589 still remain taken into account for some time if damping has been 590 triggered and hence result in otherwise acceptable new state from 591 being successfully created. 593 Additionally, it is worth noting that these procedures are not meant 594 to protect against peaks of control plane load, but only address 595 averaged load. For instance, assuming a set of multicast states 596 submitted to the same Join/Prune events, damping can prevent more 597 than a certain number of Join/Prune messages to be sent upstream in 598 the period of time that elapses between the reception of Join/Prune 599 messages triggering the activation of damping on these states and 600 when damping becomes inactive after decay. 602 10. Acknowledgements 604 We would like to thank Bruno Decraene and Lenny Giuliano for 605 discussions that helped shape this proposal. We would also like to 606 thank Yakov Rekhter and Eric Rosen for their reviews and helpful 607 comments. Thanks to Wim Henderickx for his comments and support of 608 this proposal. 610 11. References 612 11.1. Normative References 614 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 615 Requirement Levels", BCP 14, RFC 2119, March 1997. 617 [RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route 618 Flap Damping", RFC 2439, November 1998. 620 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 621 Thyagarajan, "Internet Group Management Protocol, Version 622 3", RFC 3376, October 2002. 624 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 625 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 627 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 628 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 629 Protocol Specification (Revised)", RFC 4601, August 2006. 631 [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP 632 VPNs", RFC 6513, February 2012. 634 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 635 Encodings and Procedures for Multicast in MPLS/BGP IP 636 VPNs", RFC 6514, February 2012. 638 [RFC7117] Aggarwal, R., Kamite, Y., Fang, L., Rekhter, Y., and C. 639 Kodeboniya, "Multicast in Virtual Private LAN Service 640 (VPLS)", RFC 7117, February 2014. 642 [RFC7196] Pelsser, C., Bush, R., Patel, K., Mohapatra, P., and O. 643 Maennel, "Making Route Flap Damping Usable", RFC 7196, May 644 2014. 646 11.2. Informative References 648 [RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol 649 Independent Multicast - Sparse Mode (PIM-SM) Multicast 650 Routing Security Issues and Enhancements", RFC 4609, 651 October 2006. 653 Authors' Addresses 655 Thomas Morin (editor) 656 Orange 657 2, avenue Pierre Marzin 658 Lannion 22307 659 France 661 Email: thomas.morin@orange.com 663 Stephane Litkowski 664 Orange 665 France 667 Email: stephane.litkowski@orange.com 668 Keyur Patel 669 Cisco Systems 670 170 W. Tasman Drive 671 San Jose, CA 95134 672 USA 674 Email: keyupate@cisco.com 676 Jeffrey (Zhaohui) Zhang 677 Juniper Networks Inc. 678 10 Technology Park Drive 679 Westford, MA 01886 680 USA 682 Email: zzhang@juniper.net 684 Robert Kebler 685 Juniper Networks Inc. 686 10 Technology Park Drive 687 Westford, MA 01886 688 USA 690 Email: rkebler@juniper.net 692 Jeff Haas 693 Juniper Networks 695 Email: jhaas@juniper.net