idnits 2.17.1 draft-ietf-bess-multicast-damping-06.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC6514, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC6514, updated by this document, for RFC5378 checks: 2006-08-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 09, 2016) is 2902 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). 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 Updates: 6514 (if approved) Orange 5 Intended status: Standards Track K. Patel 6 Expires: November 10, 2016 Cisco Systems 7 Z. Zhang 8 R. Kebler 9 J. Haas 10 Juniper Networks 11 May 09, 2016 13 Multicast VPN state damping 14 draft-ietf-bess-multicast-damping-06 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 sites. 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 November 10, 2016. 49 Copyright Notice 51 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 4. Existing mechanisms . . . . . . . . . . . . . . . . . . . . . 5 70 4.1. Rate-limiting of multicast control traffic . . . . . . . 5 71 4.2. Existing PIM, IGMP and MLD timers . . . . . . . . . . . . 5 72 4.3. BGP Route Damping . . . . . . . . . . . . . . . . . . . . 6 73 5. Procedures for multicast state damping . . . . . . . . . . . 7 74 5.1. PIM procedures . . . . . . . . . . . . . . . . . . . . . 7 75 5.2. Procedures for multicast VPN state damping . . . . . . . 10 76 6. Procedures for P-tunnel state damping . . . . . . . . . . . . 11 77 6.1. Damping mVPN P-tunnel change events . . . . . . . . . . . 11 78 6.2. Procedures for Ethernet VPNs . . . . . . . . . . . . . . 12 79 7. Operational considerations . . . . . . . . . . . . . . . . . 12 80 7.1. Enabling multicast damping . . . . . . . . . . . . . . . 12 81 7.2. Troubleshooting and monitoring . . . . . . . . . . . . . 12 82 7.3. Default and maximum values . . . . . . . . . . . . . . . 13 83 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 84 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 85 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 86 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 87 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 88 11.2. Informative References . . . . . . . . . . . . . . . . . 16 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 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 given 95 multicast group or channel through multicast membership control 96 protocols (IGMP [RFC3376], MLD[RFC3810]), multicast routing protocols 97 accordingly adjust multicast routing states and P-multicast tree 98 states, to forward or prune multicast traffic to these receivers. 99 Similar challenges arise in the context of multicast specification 100 for VPLS [RFC7117]. 102 In VPN contexts, providing isolation between customers of a shared 103 infrastructure is a core requirement resulting in stringent 104 expectations with regards to risks of denial of service attacks. 106 By nature multicast memberships change based on the behavior of 107 multicast applications running on end hosts, hence the frequency of 108 membership changes can legitimately be much higher than the typical 109 churn of unicast routing states. 111 Hence, mechanisms need to be put in place to ensure that the load put 112 on the BGP control plane, and on the P-tunnel setup control plane, 113 remains under control regardless of the frequency at which multicast 114 memberships changes are made by end hosts. 116 This document describes procedures, inspired from existing BGP route 117 damping [RFC2439], aimed at offering means to set an upper bound to 118 the amount of processing for the mVPN control plane protocols, more 119 precisely the BGP control plane in [RFC6514], and the P-tunnel 120 control plane protocol in the contexts of [RFC6514] and multicast 121 specification for VPLS [RFC7117]. This aims to be achieved while at 122 the same time preserving the service provided (delivering the 123 multicast stream as requested by Customer Edge devices), although at 124 the expense of a minimal increase of average bandwidth use in the 125 provider network. The upper bound to the control plane load due to 126 the processing of a given multicast state, is controlled indirectly 127 via configurable parameters. 129 Section 16 of [RFC6514] specifically spells out the need for damping 130 the activity of C-multicast and Leaf Auto-discovery routes, and 131 outlines how to do it by "delaying the advertisement of withdrawals 132 of C-multicast routes". This specification provides appropriate 133 detail on how to implement this approach and how to provide control 134 to the operator, and for this reason, is an update to [RFC6514]. 136 The base principle of this specification is described in Section 3. 137 Existing mechanisms that could be relied upon are discussed in 138 Section 4. Section 5 details the procedures introduced by this 139 specification. 141 Section 6 provides specific details related to the damping of 142 multicast VPNs P-tunnel state. 144 Finally, Section 7 discusses operational considerations related to 145 the proposed mechanism. 147 2. Terminology 149 This document reuses terminology from [RFC7761] and [RFC6514]. 151 In this specification, damping of a multicast state will be said to 152 be "active" or "inactive". Note that in [RFC2439], the term used for 153 a unicast route which is dampened is "suppressed", but we will avoid 154 this term in this specification given that the proposed solution 155 consist in holding active a damped multicast state. 157 3. Overview 159 The procedures described in this document allow the network operator 160 to configure multicast VPN PEs (Provider Edge routers) so that they 161 can delay the propagation of multicast state prune messages between 162 PEs, when faced with a rate of multicast state dynamicity exceeding a 163 certain configurable threshold. Assuming that the number of 164 multicast states that can be created by a receiver is bounded, 165 delaying the propagation of multicast state pruning results in 166 setting up an upper bound to the average frequency at which the 167 router will send state updates to an upstream router. 169 From the point of view of a downstream router, such as a CE (Customer 170 Edge router), this approach has no impact: the multicast routing 171 states changes that it solicits to its PE will be honored without any 172 additional delay. Indeed the propagation of joins is not impacted by 173 the procedures specified here, and having the upstream router delay 174 state prune propagation to its own upstream router does not affect 175 what traffic is sent to the downstream router. In particular, the 176 amount of bandwidth used on the PE-CE link downstream to a PE 177 applying this damping technique is not increased. 179 This approach increases the average bandwidth utilization on a link 180 upstream to a PE applying this technique, such as a PE-PE link: 181 indeed, a given multicast flow will be forwarded for a longer time 182 than if no damping was applied. That said, it is expected that this 183 technique will meet the goals of protecting the multicast routing 184 infrastructure control plane without a significant average increase 185 of bandwidth; for instance, damping events happening at a frequency 186 higher than one event per X second, can be done without increasing by 187 more than X second the time during which a multicast flow is present 188 on a link. 190 That said, simulation of the exponential decay algorithm show that 191 the multicast state churn can be drastically reduced without 192 significantly increasing the duration for which multicast traffic is 193 forwarded. Hence, using this technique will efficiently protect the 194 multicast routing infrastructure control plane against the issues 195 described here, without a significant average increase of bandwidth. 196 The exception will be a scenario with strict constraints on multicast 197 bandwidth, where extending the time a multicast flow is forwarded 198 would result in congestion. 200 To be practical, such a mechanism requires configurability. In 201 particular, means are required to control when damping is triggered, 202 and to allow delaying the pruning of a multicast state for a time 203 increasing with the churn of this multicast state. This will let the 204 operator control the tradeoff made between minimizing the dynamicity 205 and reducing bandwidth consumption. 207 4. Existing mechanisms 209 This section describes mechanisms that could be considered to address 210 the issue, but that end up appearing as not suitable or not efficient 211 enough. 213 4.1. Rate-limiting of multicast control traffic 215 PIM-SM specification [RFC7761] examine multicast security threats and 216 among other things the risk of denial of service attacks described in 217 Section 1. A mechanism relying on rate-limiting PIM messages is 218 proposed in section 5.3.3 of [RFC4609], but has the identified 219 drawbacks of impacting the service delivered and having side-effects 220 on legitimate users. 222 4.2. Existing PIM, IGMP and MLD timers 224 In the context of PIM multicast routing protocols [RFC7761], a 225 mechanism exists that may offer a form of de-facto damping of 226 multicast states, under some conditions. Indeed, when active, the 227 prune override mechanism consists in having a PIM upstream router 228 introduce a delay ("prune override interval") before taking into 229 account a PIM Prune message sent by a downstream neighbor. 231 This mechanism has not been designed specifically for the purpose of 232 damping multicast state, but as a means to allow PIM to operate on 233 multi-access networks. See [RFC7761] section 4.3.3. However, when 234 active, this mechanism will prevent a downstream router to produce 235 multicast routing protocol messages that would cause, for a given 236 multicast state, the upstream router to send to its own upstream 237 router, multicast routing protocol messages at a rate higher than 238 1/[JP_Override_Interval]. This provides de-facto a form of damping. 240 Similarly, the IGMP and MLD multicast membership control protocols 241 can provide a similar behavior, under the right conditions. 243 These mechanisms are not considered suitable to meet the goals 244 spelled out in Section 1, the main reasons being that: 246 o when enabled, these mechanisms require additional bandwidth on the 247 local link on which the effect of a prune is delayed (in our case 248 the PE-CE link) 250 o when enabled, these mechanisms require disabling explicit tracking 251 (see Section 4.3.3 of [RFC7761]), even though enabling this 252 feature may otherwise be desired 254 o on certain implementations, these mechanisms are incompatible with 255 behaviors that cannot be turned off (e.g. implementation applying 256 a fast-leave behavior on interfaces with only two neighbors) 258 o they do not provide a suitable level of configurability 260 o they do not provide a way to discriminate between multicast flows 261 based on estimation of their dynamicity 263 4.3. BGP Route Damping 265 The procedures defined in [RFC2439] and [RFC7196] for BGP route flap 266 damping are useful for operators who want to control the impact of 267 unicast route churn on the routing infrastructure, and offer a 268 standardized set of parameters to control damping. 270 These procedures are not directly relevant in a multicast context, 271 for the following reasons: 273 o they are not specified for multicast routing protocol in general 275 o even in contexts where BGP routes are used to carry multicast 276 routing states (e.g. [RFC6514]), these procedures do not allow to 277 implement the principle described in this document, the main 278 reason being that a damped route becomes suppressed, while the 279 target behavior would be to keep advertising when damping is 280 triggered on a multicast route 282 However, the set of parameters standardized to control the thresholds 283 of the exponential decay mechanism can be relevantly reused. This is 284 the approach proposed for the procedures described in this document 285 (Section 5). Motivations for doing so is to help the network 286 operator deploy this feature based on consistent configuration 287 parameter, and obtain predictable results, without the drawbacks of 288 relying on rate-limiting of multicast control protocol exchanges (as 289 exposed in Section 4.1) or on the use of existing PIM/IGMP timers (as 290 exposed in Section 4.2). 292 5. Procedures for multicast state damping 294 5.1. PIM procedures 296 This section describes procedures for multicast state damping 297 satisfying the goals spelled out in Section 1. This section spells 298 out procedures for (S,G) states in the PIM-SM protocol [RFC7761]; 299 they apply unchanged for such states created based on multicast group 300 management protocols (IGMP [RFC3376], MLD [RFC3810]) on downstream 301 interfaces. The same procedures are applied to (*,G) states in the 302 context of PIM-SM ASM groups (damping is not applied to (S,G,Rpt) 303 Prune state). 305 The following notions of [RFC2439] are reused in these procedures: 307 figure-of-merit: a number reflecting the current estimation of 308 recent past activity of an (S,G) multicast routing state, which 309 increases based on routing events related to this state, and 310 between these events decreases following an exponential decay 311 function (see below); the activation or inactivation of damping on 312 the state is based on this number; this number is associated to 313 the upstream state machine for (S,G) and is initialized to a value 314 of zero on state creation 316 exponential decay function: a mathematical function as defined 317 inSection 2.3 of [RFC2439] (ignoring the first paragraph of that 318 section that does not apply here) 320 decay-half-life: duration used to control how fast is the 321 exponential decay of the *figure-of-merit* ; this parameter of the 322 exponential decay function is the time duration during which the 323 *figure-of-merit* will be reduced by half, in the absence of a 324 routing event (configurable parameter) 326 cutoff-threshold: value of the *figure-of-merit* over which damping 327 is applied (configurable parameter) 329 reuse-threshold: value of the *figure-of-merit* under which damping 330 stops being applied (configurable parameter) 332 Additionally to these values, a configurable *increment-factor* 333 parameter is introduced, that controls by how much the *figure-of- 334 merit* is incremented on multicast state update events. 336 Section 7.3 proposes default and maximum values for the configurable 337 parameters. 339 On reception of updated multicast membership or routing information 340 on a downstream interface I for a given (S,G) state, that results in 341 a change of the state of the PIM downstream state machine (see 342 section 4.5.3 of [RFC7761]), a router implementing these procedures 343 MUST: 345 o apply procedures of [RFC7761] unchanged, for everything relating 346 to what multicast traffic ends up being sent on downstream 347 interfaces, including interface I 349 o update the *figure-of-merit* following the exponential decay 350 algorithm 352 o increase the *figure-of-merit* for the (S,G) by the *increment- 353 factor* 355 o update the damping state for the (S,G) state: damping becomes 356 active on the state if the recomputed *figure-of-merit* is 357 strictly above the configured *cutoff-threshold* 359 * if damping remains inactive on (S,G) state, update the upstream 360 state machine as usual (as per section 4.5.7 of [RFC7761]) 362 * if damping becomes active for the (S,G) state: 364 + if the received message has caused the upstream state 365 machine to transition to Joined state, update the upstream 366 state machine for (S,G) (applying usual PIM procedures in 367 section 4.5.7 of [RFC7761], including sending a PIM Join to 368 the upstream neighbor) 370 + if the received message has caused the upstream state 371 machine to transition to NotJoined state, do not update the 372 upstream state machine for (S,G) 374 + hold the upstream state machine in Joined state until the 375 reuse threshold is reached : for the purpose of updating 376 this state machine, events that may result in updating the 377 state based on [RFC7761] SHOULD be ignored until the *reuse- 378 threshold* is reached. The effect is that in the meantime, 379 while PIM Join messages may be sent as refreshes to the 380 upstream neighbor, no PIM Prune message will be sent. 382 * if damping was already active: do not update the upstream state 383 machine for (S,G) (the upstream state machine was frozen after 384 processing the previous message) 386 Once the *figure-of-merit* for (S,G) damping state decays to a value 387 strictly below the configured *reuse-threshold*, the upstream state 388 machine for (S,G) is recomputed based on states of downstream state 389 machines, eventually leading to a PIM Join or Prune message to be 390 sent to the upstream neighbor. 392 Given the specificity of multicast applications, it is REQUIRED for 393 the implementation to let the operator configure the *decay-half- 394 life* in seconds, rather than in minutes. 396 This specification does not impose the use of a particular technique 397 to update the *figure-of-merit* following the exponential decay 398 controlled by the configured *decay-half-life*. For instance, the 399 same techniques as the ones described in [RFC2439] can be applied. 400 The only requirement is that the *figure-of-merit* has to be updated 401 prior to increasing it, and that its decay below the *reuse- 402 threshold* has to be timely reacted upon: in particular, if the 403 recomputation is done with a fixed time granularity, this granularity 404 should be low enough to not significantly delay the inactivation of 405 damping on a multicast state beyond what the operator wanted to 406 configure (e.g. for a *decay-half-life* of 10s, recomputing the 407 *figure-of-merit* each minute would result in a multicast state to 408 remained damped for a much longer time than specified). 410 PIM implementations typically follow [RFC7761] suggestion that 411 "implementations will only maintain state when it is relevant to 412 forwarding operations - for example, the 'NoInfo' state might be 413 assumed from the lack of other state information, rather than being 414 held explicitly" (Section 4.1 of [RFC7761]). To properly implement 415 damping procedures, an implementation MUST keep an explicit (S,G) 416 state as long as damping is active on an (S,G). Once an (S,G) state 417 expires, and damping becomes inactive on this state, its associated 418 *figure-of-merit* and damping state are removed as well. 420 Note that these procedures: 422 o do not impact PIM procedures related to refreshes or expiration of 423 multicast routing states: PIM Prune messages triggered by the 424 expiration of the (S,G) keep-alive timer, are not suppressed or 425 delayed, and the reception of Join messages not causing transition 426 of state on the downstream interface does not lead to incrementing 427 the *figure-of-merit*; 429 o do not impact the PIM assert mechanism, in particular PIM Prune 430 messages triggered by a change of the PIM assert winner on the 431 upstream interface, are not suppressed or delayed; 433 o do not impact PIM Prune messages that are sent when the RPF 434 neighbor is updated for a given multicast flow; 436 o do not impact PIM Prune messages that are sent in the context of 437 switching between a Rendez-vous Point Tree and a Shortest Path 438 Tree. 440 Note also that no action is triggered based on the reception of PIM 441 Prune messages (or corresponding IGMP/MLD messages) that relate to 442 non-existing (S,G) state, in particular, no *figure-of-merit* or 443 damping state is created in this case. 445 5.2. Procedures for multicast VPN state damping 447 The procedures described in Section 5.1 can be applied in the VRF 448 PIM-SM implementation (in the "C-PIM instance"), with the 449 corresponding action to suppressing the emission of a Prune(S,G) 450 message being to not withdraw the C-multicast Source Tree Join 451 (C-S,C-G) BGP route. An implementation of [RFC6513] relying on the 452 use of PIM to carry C-multicast routing information MUST support this 453 technique, to be compliant with this specification. 455 In the context of [RFC6514] where BGP is used to distribute 456 C-multicast routing information, the following procedure is proposed 457 as an alternative to the procedures in Section 5.1 and consists in 458 applying damping in the BGP implementation, based on existing BGP 459 damping mechanism, applied to C-multicast Source Tree Join routes and 460 Shared Tree Join routes (and as well to Leaf A-D routes - see 461 Section 6), and modified to implement the behavior described in 462 Section 3 along the following guidelines: 464 o not withdrawing (instead of not advertising) damped routes 466 o providing means to configure the *decay-half-life* in seconds if 467 that option is not already available 469 o using parameters for the exponential decay that are specific to 470 multicast, based on default values and multicast specific 471 configuration 473 While these procedures would typically be implemented on PE routers, 474 in a context where BGP Route Reflectors (RRs, [RFC4456]) are used it 475 can be considered useful to also be able to apply damping on RRs as 476 well to provide additional protection against activity created behind 477 multiple PEs. Additionally, for mVPN Inter-AS deployments, it can be 478 needed to protect one AS from the dynamicity of multicast VPN routing 479 events from other ASes. 481 The choice to implement damping based on BGP routes or the procedures 482 described in Section 5.1, is up to the implementor, but at least one 483 of the two MUST be implemented. In the perspective of allowing 484 damping to be done on RRs and ASBRs, implementing the BGP approach is 485 recommended. 487 When not all routers in a deployment have the capability to drop 488 traffic coming from the wrong PE (as spelled out in section 9.1.1 of 489 [RFC6513]), then the withdrawal of a C-multicast route resulting from 490 a change in the Upstream Multicast Hop or Upstream Multicast PE 491 SHOULD NOT be damped. An implementation of this specification MUST 492 whether, not damp these withdrawals by default, or alternatively 493 provide a tuning knob to disable the damping of these withdrawals. 494 Additionally, in such a deployment context, it is RECOMMENDED to not 495 enable any multicast VPN route damping on RRs and ASBRs, since these 496 equipments cannot distinguish the event having caused a C-multicast 497 to be withdrawn. 499 Note well that it is out of scope of this section to consider the 500 application of these damping techniques on mVPN BGP routes other than 501 C-multicast routes. 503 6. Procedures for P-tunnel state damping 505 6.1. Damping mVPN P-tunnel change events 507 When selective P-tunnels are used (see section 7 of [RFC6513]), the 508 effect of updating the upstream state machine for a given (C-S,C-G) 509 state on a PE connected to multicast receivers, is not only to 510 generate activity to propagate C-multicast routing information to the 511 source connected PE, but also to possibly trigger changes related to 512 the P-tunnels carrying (C-S,C-G) traffic. Protecting the provider 513 network from an excessive amount of change in the state of P-tunnels 514 is required, and this section details how this can be done. 516 A PE implementing these procedures for mVPN MUST damp Leaf A-D 517 routes, in the same manner as it would for C-multicast routes (see 518 Section 5.2). 520 A PE implementing these procedures for mVPN MUST damp the activity 521 related to removing itself from a P-tunnel. Possible ways to do so 522 depend on the type of P-tunnel, and local implementation details are 523 left up to the implementor. 525 The following is proposed as example of how the above can be 526 achieved: 528 o For P-tunnels implemented with the PIM protocol, this consists in 529 applying multicast state damping techniques described in 530 Section 5.1 to the P-PIM instance, at least for (S,G) states 531 corresponding to P-tunnels. 533 o For P-tunnels implemented with the mLDP protocol, this consists in 534 applying damping techniques completely similar to the one 535 described in Section 5, but generalized to apply to mLDP states 537 o For root-initiated P-tunnels (P-tunnels implemented with the P2MP 538 RSVP-TE, or relying on ingress replication), no particular action 539 needs to be implemented to damp P-tunnels membership, if the 540 activity of Leaf A-D route themselves is damped 542 o Another possibility is to base the decision to join or not join 543 the P-tunnel to which a given (C-S,C-G) is bound, and to advertise 544 or not advertise a Leaf A-D route related to (C-S,C-G), based on 545 whether or not a C-multicast Source Tree Join route is being 546 advertised for (C-S,C-G), rather than by relying on the state of 547 the C-PIM Upstream state machine for (C-S,C-G) 549 6.2. Procedures for Ethernet VPNs 551 Specifications exist to support or optimize multicast and broadcast 552 in the context of Ethernet VPNs [RFC7117], relying on the use of 553 S-PMSI and P-tunnels. For the same reasons as for IP multicast VPNs, 554 an implementation of [RFC7117] MUST follow the procedures described 555 in Section 6.1, to be compliant with this specification. 557 7. Operational considerations 559 7.1. Enabling multicast damping 561 In the context of multicast VPNs, these procedures would be enabled 562 on PE routers. Additionally in the case of C-multicast routing based 563 on BGP extensions ([RFC6514]) these procedures can be enabled on 564 ASBRs and Route Reflectors. 566 7.2. Troubleshooting and monitoring 568 Implementing the damping mechanisms described in this document should 569 be complemented by appropriate tools to observe and troubleshoot 570 damping activity. 572 Complementing the existing interface providing information on 573 multicast states with information on eventual damping of 574 corresponding states (e.g. MRIB states) is RECOMMENDED: C-multicast 575 routing states and P-tunnel states. 577 7.3. Default and maximum values 579 Considering that, by design multicast streams will be delivered 580 unchanged to the end user, independently of the value chosen for the 581 configurable parameters, and that the only trade-off being made is an 582 increase of bandwidth use, the default and maximum values do not have 583 to be perfectly tuned. 585 This section proposes default and maximum values, conservative so as 586 to not significantly impact network dimensioning but still prevent 587 multicast state churn going beyond what can be considered a 588 reasonably low churn for a multicast state (see below for 589 illustrations in order of magnitude of the effect of these values). 591 The following values are RECOMMENDED to adopt as default values: 593 o *increment-factor*: 1000 595 o *cutoff-threshold*: 3000 597 o *decay-half-life*: 10s 599 o *reuse-threshold*: 1500 601 For unicast damping, it is common to set an upper bound to the time 602 during which a route is suppressed. In the case of multicast state 603 damping, which relies on not withdrawing a damped route, it may be 604 desirable to avoid a situation where a multicast flow would keep 605 flowing in a portion of the network for a very large time in the 606 absence of receivers. 608 The proposed default maximum value for the *figure-of-merit* is 609 20x*increment-factor*, i.e. 20000 with the proposed default 610 *increment-factor* of 1000. 612 As illustrations, with these values: 614 o a multicast state updated less frequently than once every 6s will 615 not be damped at all 617 o a multicast state changing once per second for 3s, and then not 618 changing, will not be damped 620 o a multicast state changing once per second for 4s, and then not 621 changing, will be damped after the fourth change for approximately 622 13s 624 o a multicast state changing twice per second for 15s, and then not 625 changing, will be damped after the fourth change for approximately 626 50s 628 o a multicast state changing at a fast pace for a long time will 629 reach the maximum of *figure-of-merit*; once the activity on this 630 state stops, corresponding traffic may still flow in the network 631 for approximately 37s before dampening stops being active 633 The following values are proposed as maxima: 635 o *decay-half-life*: 60s 637 o *cutoff-threshold*: 50000 639 More aggressive protection against the risk of denial of service can 640 be achieved by increasing the *increment-factor* or the *decay-half- 641 life*, or reducing the *cutoff-threshold* and/or *reuse-threshold*. 643 8. IANA Considerations 645 This document makes no request to IANA. 647 Note to the RFC Editor: this section may be removed on publication as 648 an RFC. 650 9. Security Considerations 652 The procedures defined in this document do not introduce additional 653 security issues not already present in the contexts addressed, and 654 actually aim at addressing some of the identified risks without 655 introducing as much denial of service risk as some of the mechanisms 656 already defined. 658 The protection provided relates to the control plane of the multicast 659 routing protocols, including the components implementing the routing 660 protocols and the components responsible for updating the multicast 661 forwarding plane. 663 The procedures describe are meant to provide some level of protection 664 for the router on which they are enabled by reducing the amount of 665 routing state updates that it needs to send to its upstream neighbor 666 or peers, but do not provide any reduction of the control plane load 667 related to processing routing information from downstream neighbors. 669 Protecting routers from an increase in control plane load due to 670 activity on downstream interfaces toward core routers (or in the 671 context of BGP-based mVPN C-multicast routing, BGP peers) relies on 672 the activation of damping on corresponding downstream neighbors (or 673 BGP peers) and/or at the edge of the network. Protecting routers 674 from an increase in control plane load due to activity on customer- 675 facing downstream interfaces or downstream interfaces to routers in 676 another administrative domain, is out of the scope of this document 677 and should use already defined mechanisms (see [RFC4609]). 679 To be effective the procedures described here must be complemented by 680 configuration limiting the number of multicast states that can be 681 created on a multicast router through protocol interactions with 682 multicast receivers, neighbor routers in adjacent ASes, or in 683 multicast VPN contexts with multicast CEs. Note well that the two 684 mechanism may interact: state for which Prune has been requested may 685 still remain taken into account for some time if damping has been 686 triggered and hence result in otherwise acceptable new state from 687 being successfully created. 689 Additionally, it is worth noting that these procedures are not meant 690 to protect against peaks of control plane load, but only address 691 averaged load. For instance, assuming a set of multicast states 692 submitted to the same Join/Prune events, damping can prevent more 693 than a certain number of Join/Prune messages to be sent upstream in 694 the period of time that elapses between the reception of Join/Prune 695 messages triggering the activation of damping on these states and 696 when damping becomes inactive after decay. 698 10. Acknowledgements 700 We would like to thank Bruno Decraene and Lenny Giuliano for 701 discussions that helped shape this proposal. We would also like to 702 thank Yakov Rekhter and Eric Rosen for their reviews and helpful 703 comments. Thanks to Wim Henderickx for his comments and support of 704 this proposal. Additionally, Martin Vigoureux, Gunter Van De Velde 705 and Alvaro Retana provided useful comments to finalize the document. 707 11. References 709 11.1. Normative References 711 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 712 Requirement Levels", BCP 14, RFC 2119, March 1997. 714 [RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route 715 Flap Damping", RFC 2439, November 1998. 717 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 718 Thyagarajan, "Internet Group Management Protocol, Version 719 3", RFC 3376, October 2002. 721 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 722 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 724 [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP 725 VPNs", RFC 6513, February 2012. 727 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 728 Encodings and Procedures for Multicast in MPLS/BGP IP 729 VPNs", RFC 6514, February 2012. 731 [RFC7117] Aggarwal, R., Kamite, Y., Fang, L., Rekhter, Y., and C. 732 Kodeboniya, "Multicast in Virtual Private LAN Service 733 (VPLS)", RFC 7117, February 2014. 735 [RFC7196] Pelsser, C., Bush, R., Patel, K., Mohapatra, P., and O. 736 Maennel, "Making Route Flap Damping Usable", RFC 7196, May 737 2014. 739 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 740 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 741 Multicast - Sparse Mode (PIM-SM): Protocol Specification 742 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 743 2016, . 745 11.2. Informative References 747 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 748 Reflection: An Alternative to Full Mesh Internal BGP 749 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 750 . 752 [RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol 753 Independent Multicast - Sparse Mode (PIM-SM) Multicast 754 Routing Security Issues and Enhancements", RFC 4609, 755 October 2006. 757 Authors' Addresses 758 Thomas Morin (editor) 759 Orange 760 2, avenue Pierre Marzin 761 Lannion 22307 762 France 764 Email: thomas.morin@orange.com 766 Stephane Litkowski 767 Orange 768 France 770 Email: stephane.litkowski@orange.com 772 Keyur Patel 773 Cisco Systems 774 170 W. Tasman Drive 775 San Jose, CA 95134 776 USA 778 Email: keyupate@cisco.com 780 Zhaohui Zhang 781 Juniper Networks Inc. 782 10 Technology Park Drive 783 Westford, MA 01886 784 USA 786 Email: zzhang@juniper.net 788 Robert Kebler 789 Juniper Networks Inc. 790 10 Technology Park Drive 791 Westford, MA 01886 792 USA 794 Email: rkebler@juniper.net 796 Jeff Haas 797 Juniper Networks 799 Email: jhaas@juniper.net