GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7899

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7899.txt · Last modified: 2016/06/28 20:05 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki