doc: Add RFC documents

1 files changed, 1011 insertions, 0 deletions

diff --git a/doc/rfc/rfc7899.txt b/doc/rfc/rfc7899.txt
new file mode 100644
index 0000000..8bff1d3
--- /dev/null
+++ b/doc/rfc/rfc7899.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                     T. Morin, Ed.
+Request for Comments: 7899                                  S. Litkowski
+Updates: 6514                                                     Orange
+Category: Standards Track                                       K. Patel
+ISSN: 2070-1721                                            Cisco Systems
+                                                                Z. Zhang
+                                                               R. Kebler
+                                                                 J. Haas
+                                                        Juniper Networks
+                                                               June 2016
+
+
+                      Multicast VPN State Damping
+
+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 Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7899.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Morin, et al.                Standards Track                    [Page 1]
+
+RFC 7899                      MVPN Damping                     June 2016
+
+
+Copyright Notice
+
+   Copyright (c) 2016 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) 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
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
+   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
+   3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
+   4.  Existing Mechanisms . . . . . . . . . . . . . . . . . . . . .   5
+     4.1.  Rate-Limiting Multicast Control Traffic . . . . . . . . .   5
+     4.2.  Existing PIM, IGMP, and MLD Timers  . . . . . . . . . . .   6
+     4.3.  BGP Route Damping . . . . . . . . . . . . . . . . . . . .   6
+   5.  Procedures for Multicast State Damping  . . . . . . . . . . .   7
+     5.1.  PIM Procedures  . . . . . . . . . . . . . . . . . . . . .   7
+     5.2.  Procedures for Multicast VPN State Damping  . . . . . . .  10
+   6.  Procedures for P-Tunnel State Damping . . . . . . . . . . . .  12
+     6.1.  Damping MVPN P-Tunnel Change Events . . . . . . . . . . .  12
+     6.2.  Procedures for Ethernet VPNs  . . . . . . . . . . . . . .  13
+   7.  Operational Considerations  . . . . . . . . . . . . . . . . .  13
+     7.1.  Enabling Multicast Damping  . . . . . . . . . . . . . . .  13
+     7.2.  Troubleshooting and Monitoring  . . . . . . . . . . . . .  13
+     7.3.  Default and Maximum Values  . . . . . . . . . . . . . . .  13
+   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
+   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
+     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  16
+     9.2.  Informative References  . . . . . . . . . . . . . . . . .  17
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  17
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18
+
+
+
+
+
+
+
+
+
+
+
+Morin, et al.                Standards Track                    [Page 2]
+
+RFC 7899                      MVPN Damping                     June 2016
+
+
+1.  Introduction
+
+   In a multicast VPN [RFC6513] deployed with BGP-based procedures
+   [RFC6514], when receivers in VPN sites join and leave a given
+   multicast group or channel through multicast membership control
+   protocols (Internet Group Management Protocol (IGMP) [RFC3376] and
+   Multicast Listener Discovery (MLD) [RFC3810]), 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) [RFC7117].
+
+   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 [RFC2439] 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 [RFC6514], the
+   P-tunnel control-plane protocol in the contexts of [RFC6514], and the
+   multicast specification for VPLS [RFC7117].  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.
+
+   Section 16 of [RFC6514] 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 [RFC6514].
+
+
+
+
+
+
+Morin, et al.                Standards Track                    [Page 3]
+
+RFC 7899                      MVPN Damping                     June 2016
+
+
+   The base principle of this specification is described in Section 3.
+   Existing mechanisms that could be relied upon are discussed in
+   Section 4.  Section 5 details the procedures introduced by this
+   specification.
+
+   Section 6 provides specific details related to the damping of
+   multicast VPNs P-tunnel state.
+
+   Finally, Section 7 discusses operational considerations related to
+   the proposed mechanism.
+
+2.  Terminology
+
+   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 RFC 2119 [RFC2119].
+
+   This document reuses terminology from [RFC7761] and [RFC6514].
+
+   In this specification, damping of a multicast state will be said to
+   be "active" or "inactive".  Note that in [RFC2439], 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.
+
+3.  Overview
+
+   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.
+
+
+
+
+
+Morin, et al.                Standards Track                    [Page 4]
+
+RFC 7899                      MVPN Damping                     June 2016
+
+
+   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.
+
+4.  Existing Mechanisms
+
+   This section describes mechanisms that could be considered to address
+   the issue but that end up appearing as not suitable or not efficient
+   enough.
+
+4.1.  Rate-Limiting Multicast Control Traffic
+
+   The Protocol Independent Multicast - Sparse Mode (PIM-SM)
+   specification [RFC7761] examines multicast security threats and,
+   among other things, the risk of denial-of-service attacks described
+   in Section 1.  A mechanism relying on rate-limiting PIM messages is
+   proposed in Section 5.3.3 of [RFC4609] but has the identified
+   drawbacks of impacting the service delivered and having side-effects
+   on legitimate users.
+
+
+
+
+
+
+
+
+Morin, et al.                Standards Track                    [Page 5]
+
+RFC 7899                      MVPN Damping                     June 2016
+
+
+4.2.  Existing PIM, IGMP, and MLD Timers
+
+   In the context of PIM multicast routing protocols [RFC7761], 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 Section 4.3.3 of [RFC7761].  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 Section 1, 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 Section 4.3.3 of [RFC7761]), 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.
+
+4.3.  BGP Route Damping
+
+   The procedures defined in [RFC2439] and [RFC7196] 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.
+
+
+
+Morin, et al.                Standards Track                    [Page 6]
+
+RFC 7899                      MVPN Damping                     June 2016
+
+
+   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., [RFC6514]), 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
+   (Section 5).  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 Section 4.1) or on the use of existing PIM/IGMP timers (as
+   is exposed in Section 4.2).
+
+5.  Procedures for Multicast State Damping
+
+5.1.  PIM Procedures
+
+   This section describes procedures for multicast state damping
+   satisfying the goals spelled out in Section 1.  This section
+   describes procedures for (S,G) states in the PIM-SM protocol
+   [RFC7761]; they apply unchanged for such states created based on
+   multicast group management protocols (IGMP [RFC3376], MLD [RFC3810])
+   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 [RFC2439] 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.
+
+
+
+
+
+Morin, et al.                Standards Track                    [Page 7]
+
+RFC 7899                      MVPN Damping                     June 2016
+
+
+   exponential decay function:  A mathematical function as defined in
+      Section 2.3 of [RFC2439] (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.
+
+   Section 7.3 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
+   Section 4.5.3 of [RFC7761]), a router implementing these procedures
+   MUST:
+
+   o  apply procedures of [RFC7761] 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 Section 4.5.7 of [RFC7761]).
+
+
+
+
+
+
+Morin, et al.                Standards Track                    [Page 8]
+
+RFC 7899                      MVPN Damping                     June 2016
+
+
+      *  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
+            Section 4.5.7 of [RFC7761] 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 [RFC7761] 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 [RFC2439] 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).
+
+
+
+
+Morin, et al.                Standards Track                    [Page 9]
+
+RFC 7899                      MVPN Damping                     June 2016
+
+
+   PIM implementations typically follow the suggestion from Section 4.1
+   of [RFC7761] 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.
+
+5.2.  Procedures for Multicast VPN State Damping
+
+   The procedures described in Section 5.1 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 [RFC6513]
+   relying on the use of PIM to carry C-multicast routing information
+   MUST support this technique to be compliant with this specification.
+
+
+
+Morin, et al.                Standards Track                   [Page 10]
+
+RFC 7899                      MVPN Damping                     June 2016
+
+
+   In the context of [RFC6514], where BGP is used to distribute
+   C-multicast routing information, the following procedure is proposed
+   as an alternative to the procedures in Section 5.1 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
+   Section 6) and modified to implement the behavior described in
+   Section 3 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) [RFC4456] 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 Section 5.1 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 Section 9.1.1 of
+   [RFC6513]), 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.
+
+
+
+
+Morin, et al.                Standards Track                   [Page 11]
+
+RFC 7899                      MVPN Damping                     June 2016
+
+
+   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.
+
+6.  Procedures for P-Tunnel State Damping
+
+6.1.  Damping MVPN P-Tunnel Change Events
+
+   When selective P-tunnels are used (see Section 7 of [RFC6513]), 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
+   Section 5.2).
+
+   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
+      Section 5.1 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 Section 5 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.
+
+
+
+
+
+
+
+Morin, et al.                Standards Track                   [Page 12]
+
+RFC 7899                      MVPN Damping                     June 2016
+
+
+   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).
+
+6.2.  Procedures for Ethernet VPNs
+
+   Specifications exist to support or optimize multicast and broadcast
+   in the context of Ethernet VPNs [RFC7117] 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
+   [RFC7117] MUST follow the procedures described in Section 6.1 to be
+   compliant with this specification.
+
+7.  Operational Considerations
+
+7.1.  Enabling Multicast Damping
+
+   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 ([RFC6514]), these procedures can be enabled
+   on ASBRs and RRs.
+
+7.2.  Troubleshooting and Monitoring
+
+   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.
+
+7.3.  Default and Maximum Values
+
+   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
+
+
+
+Morin, et al.                Standards Track                   [Page 13]
+
+RFC 7899                      MVPN Damping                     June 2016
+
+
+   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.
+
+
+
+
+
+
+Morin, et al.                Standards Track                   [Page 14]
+
+RFC 7899                      MVPN Damping                     June 2016
+
+
+   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*.
+
+8.  Security Considerations
+
+   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 [RFC4609]).
+
+   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.
+
+
+
+Morin, et al.                Standards Track                   [Page 15]
+
+RFC 7899                      MVPN Damping                     June 2016
+
+
+   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.
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC2439]  Villamizar, C., Chandra, R., and R. Govindan, "BGP Route
+              Flap Damping", RFC 2439, DOI 10.17487/RFC2439, November
+              1998, <http://www.rfc-editor.org/info/rfc2439>.
+
+   [RFC3376]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
+              Thyagarajan, "Internet Group Management Protocol, Version
+              3", RFC 3376, DOI 10.17487/RFC3376, October 2002,
+              <http://www.rfc-editor.org/info/rfc3376>.
+
+   [RFC3810]  Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
+              Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
+              DOI 10.17487/RFC3810, June 2004,
+              <http://www.rfc-editor.org/info/rfc3810>.
+
+   [RFC6513]  Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
+              BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
+              2012, <http://www.rfc-editor.org/info/rfc6513>.
+
+   [RFC6514]  Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
+              Encodings and Procedures for Multicast in MPLS/BGP IP
+              VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
+              <http://www.rfc-editor.org/info/rfc6514>.
+
+   [RFC7117]  Aggarwal, R., Ed., Kamite, Y., Fang, L., Rekhter, Y., and
+              C. Kodeboniya, "Multicast in Virtual Private LAN Service
+              (VPLS)", RFC 7117, DOI 10.17487/RFC7117, February 2014,
+              <http://www.rfc-editor.org/info/rfc7117>.
+
+
+
+
+
+
+Morin, et al.                Standards Track                   [Page 16]
+
+RFC 7899                      MVPN Damping                     June 2016
+
+
+   [RFC7196]  Pelsser, C., Bush, R., Patel, K., Mohapatra, P., and O.
+              Maennel, "Making Route Flap Damping Usable", RFC 7196,
+              DOI 10.17487/RFC7196, May 2014,
+              <http://www.rfc-editor.org/info/rfc7196>.
+
+   [RFC7761]  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, RFC 7761, DOI 10.17487/RFC7761, March
+              2016, <http://www.rfc-editor.org/info/rfc7761>.
+
+9.2.  Informative References
+
+   [RFC4456]  Bates, T., Chen, E., and R. Chandra, "BGP Route
+              Reflection: An Alternative to Full Mesh Internal BGP
+              (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006,
+              <http://www.rfc-editor.org/info/rfc4456>.
+
+   [RFC4609]  Savola, P., Lehtonen, R., and D. Meyer, "Protocol
+              Independent Multicast - Sparse Mode (PIM-SM) Multicast
+              Routing Security Issues and Enhancements", RFC 4609,
+              DOI 10.17487/RFC4609, October 2006,
+              <http://www.rfc-editor.org/info/rfc4609>.
+
+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
+
+
+
+
+
+
+
+
+
+Morin, et al.                Standards Track                   [Page 17]
+
+RFC 7899                      MVPN Damping                     June 2016
+
+
+   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]
+