One document matched: draft-ietf-bess-multicast-damping-06.xml
<?xml version="1.0"?>
<?rfc toc="yes"?><?rfc tocompact="yes"?><?rfc tocdepth="3"?><?rfc tocindent="yes"?><?rfc symrefs="yes"?><?rfc sortrefs="yes"?><?rfc comments="yes"?><?rfc inline="yes"?><?rfc compact="yes"?><?rfc subcompact="no"?><rfc category="std" docName="draft-ietf-bess-multicast-damping-06" ipr="trust200902" updates="6514">
<front>
<title abbrev="mVPN damping">Multicast VPN state damping</title>
<author fullname="Thomas Morin" initials="T" role="editor" surname="Morin">
<organization>Orange</organization>
<address>
<postal>
<street>2, avenue Pierre Marzin</street>
<city>Lannion</city>
<code>22307</code>
<country>France</country>
</postal>
<email>thomas.morin@orange.com</email>
</address>
</author>
<author fullname="Stephane Litkowski" initials="S" surname="Litkowski">
<organization>Orange</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country>France</country>
</postal>
<email>stephane.litkowski@orange.com</email>
</address>
</author>
<author fullname="Keyur Patel" initials="K" surname="Patel">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>170 W. Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>keyupate@cisco.com</email>
</address>
</author>
<author fullname="Zhaohui Zhang" initials="Z" surname="Zhang">
<organization abbrev="Juniper Networks">Juniper Networks
Inc.</organization>
<address>
<postal>
<street>10 Technology Park Drive</street>
<city>Westford</city>
<region>MA</region>
<code>01886</code>
<country>USA</country>
</postal>
<email>zzhang@juniper.net</email>
</address>
</author>
<author fullname="Robert Kebler" initials="R" surname="Kebler">
<organization abbrev="Juniper Networks">Juniper Networks
Inc.</organization>
<address>
<postal>
<street>10 Technology Park Drive</street>
<city>Westford</city>
<region>MA</region>
<code>01886</code>
<country>USA</country>
</postal>
<email>rkebler@juniper.net</email>
</address>
</author>
<author fullname="Jeff Haas" initials="J" surname="Haas">
<organization>Juniper Networks</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<email>jhaas@juniper.net</email>
</address>
</author>
<date day="09" month="May" year="2016"/>
<abstract>
<t>This document describes procedures to damp multicast VPN 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. New
procedures are proposed inspired from BGP unicast route damping
principles, but adapted to multicast.</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>In a multicast VPN <xref target="RFC6513"/> deployed with BGP-based
procedures <xref target="RFC6514"/>, when receivers in VPN sites join
and leave a given multicast group or channel through multicast
membership control protocols (IGMP <xref target="RFC3376"/>, MLD<xref target="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 <xref target="RFC7117">multicast specification for
VPLS</xref>.</t>
<t>In VPN contexts, providing isolation between customers of a shared
infrastructure is a core requirement resulting in stringent expectations
with regards to risks of denial of service attacks.</t>
<t>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.</t>
<t>Hence, 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
memberships changes are made by end hosts.</t>
<t>This document describes procedures, inspired from existing BGP route
damping <xref target="RFC2439"/>, 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 <xref target="RFC6514"/>, and the P-tunnel control plane protocol in the
contexts of <xref target="RFC6514"/> and <xref target="RFC7117">multicast specification for VPLS</xref>. This aims to
be achieved while at the same time 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.</t>
<t><xref target="RFC6514">Section 16 of</xref> 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, and for this reason, is an update to <xref target="RFC6514"/>.</t>
<t>The base principle of this specification is described in <xref target="overview"/>. Existing mechanisms that could be relied upon are
discussed in <xref target="existing"/>. <xref target="procedures"/>
details the procedures introduced by this specification.</t>
<t>Section <xref format="counter" target="ptunnel"/> provides specific
details related to the damping of multicast VPNs P-tunnel state.</t>
<t>Finally, <xref target="operational"/> discusses operational
considerations related to the proposed mechanism.</t>
</section>
<section title="Terminology">
<t>This document reuses terminology from <xref target="RFC7761"/> and
<xref target="RFC6514"/>.</t>
<t>In this specification, damping of a multicast state will be said to
be "active" or "inactive". Note that in <xref target="RFC2439"/>, the
term used for a unicast route which is dampened is "suppressed", but we
will avoid this term in this specification given that the proposed
solution consist in holding active a damped multicast state.</t>
</section>
<section anchor="overview" title="Overview">
<t>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.</t>
<t>From the point of view of a downstream router, such as a CE (Customer
Edge router), this approach has no impact: the multicast routing states
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.</t>
<t>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 second, can be done without increasing by more than X second the
time during which a multicast flow is present on a link.</t>
<t>That said, simulation of the exponential decay algorithm show 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.</t>
<t>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 tradeoff made between minimizing the dynamicity and reducing
bandwidth consumption.</t>
</section>
<section anchor="existing" title="Existing mechanisms">
<t>This section describes mechanisms that could be considered to address
the issue, but that end up appearing as not suitable or not efficient
enough.</t>
<section anchor="rate-limiting" title="Rate-limiting of multicast control traffic">
<t><xref target="RFC7761">PIM-SM specification</xref> examine
multicast security threats and among other things the risk of denial
of service attacks described in <xref target="intro"/>. A mechanism
relying on rate-limiting PIM messages is proposed in <xref target="RFC4609">section 5.3.3 of </xref>, but has the identified
drawbacks of impacting the service delivered and having side-effects
on legitimate users.</t>
</section>
<section anchor="existing-timers" title="Existing PIM, IGMP and MLD timers">
<t>In the context of PIM multicast routing protocols <xref target="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.</t>
<t>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 <xref target="RFC7761"/> section 4.3.3.
However, when active, this mechanism will prevent a downstream router
to produce 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 de-facto a form of
damping.</t>
<t>Similarly, the IGMP and MLD multicast membership control protocols
can provide a similar behavior, under the right conditions.</t>
<t>These mechanisms are not considered suitable to meet the goals
spelled out in <xref target="intro"/>, the main reasons being
that:<list style="symbols">
<t>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)</t>
<t>when enabled, these mechanisms require disabling explicit
tracking (see <xref target="RFC7761">Section 4.3.3 of</xref>),
even though enabling this feature may otherwise be desired</t>
<t>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)</t>
<t>they do not provide a suitable level of configurability</t>
<t>they do not provide a way to discriminate between multicast
flows based on estimation of their dynamicity</t>
</list></t>
</section>
<section anchor="unicast-damping" title="BGP Route Damping">
<t>The procedures defined in <xref target="RFC2439"/> and <xref target="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.</t>
<t>These procedures are not directly relevant in a multicast context,
for the following reasons:<list style="symbols">
<t>they are not specified for multicast routing protocol in
general</t>
<t>even in contexts where BGP routes are used to carry multicast
routing states (e.g. <xref target="RFC6514"/>), these procedures
do not allow to implement 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</t>
</list></t>
<t>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 (<xref target="procedures"/>). Motivations for doing so
is to help the network operator deploy this feature based on
consistent configuration parameter, and obtain predictable results,
without the drawbacks of relying on rate-limiting of multicast control
protocol exchanges (as exposed in <xref target="rate-limiting"/>) or
on the use of existing PIM/IGMP timers (as exposed in <xref target="existing-timers"/>).</t>
</section>
</section>
<section anchor="procedures" title="Procedures for multicast state damping">
<section anchor="pim-procedures" title="PIM procedures">
<t>This section describes procedures for multicast state damping
satisfying the goals spelled out in <xref target="intro"/>. This
section spells out procedures for (S,G) states in the PIM-SM protocol
<xref target="RFC7761"/>; they apply unchanged for such states created
based on multicast group management protocols (IGMP <xref target="RFC3376"/>, MLD <xref target="RFC3810"/>) on downstream
interfaces. The same procedures are applied to (*,G) states in the
context of PIM-SM ASM groups (damping is not applied to (S,G,Rpt)
Prune state).</t>
<t>The following notions of <xref target="RFC2439"/> are reused in
these procedures:<list style="hanging">
<t hangText="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 between these events decreases 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 to the upstream state machine for (S,G) and is
initialized to a value of zero on state creation</t>
<t hangText="exponential decay function:">a mathematical function
as defined in<xref target="RFC2439"> Section 2.3 of</xref>
(ignoring the first paragraph of that section that does not apply
here)</t>
<t hangText="decay-half-life:">duration used to control how fast
is the exponential decay of the <spanx style="strong">figure-of-merit</spanx>
; this parameter of the exponential decay function is the time
duration during which the <spanx style="strong">figure-of-merit</spanx>
will be reduced by half, in the absence of a routing event
(configurable parameter)</t>
<t hangText="cutoff-threshold:">value of the <spanx style="strong">figure-of-merit</spanx> over which damping is
applied (configurable parameter)</t>
<t hangText="reuse-threshold:">value of the <spanx style="strong">figure-of-merit</spanx>
under which damping stops being applied (configurable
parameter)</t>
</list>Additionally to these values, a configurable <spanx style="strong">increment-factor</spanx> parameter is introduced, that
controls by how much the <spanx style="strong">figure-of-merit</spanx>
is incremented on multicast state update events.</t>
<t><xref target="default-max-values"/> proposes default and maximum
values for the configurable parameters.</t>
<t>On reception of updated multicast membership or routing information
on a downstream interface I for a given (S,G) state, that results in a
change of the state of the PIM downstream state machine (see <xref target="RFC7761">section 4.5.3 of </xref>), a router implementing
these procedures MUST:<list style="symbols">
<t>apply procedures of <xref target="RFC7761"/> unchanged, for
everything relating to what multicast traffic ends up being sent
on downstream interfaces, including interface I</t>
<t>update the <spanx style="strong">figure-of-merit</spanx>
following the exponential decay algorithm</t>
<t>increase the <spanx style="strong">figure-of-merit</spanx> for
the (S,G) by the <spanx style="strong">increment-factor</spanx></t>
<t>update the damping state for the (S,G) state: damping becomes
active on the state if the recomputed <spanx style="strong">figure-of-merit</spanx>
is strictly above the configured <spanx style="strong">cutoff-threshold</spanx><list style="symbols">
<t>if damping remains inactive on (S,G) state, update the
upstream state machine as usual (as per <xref target="RFC7761">section 4.5.7 of</xref>)</t>
<t>if damping becomes active for the (S,G) state:<list style="symbols">
<t>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
<xref target="RFC7761">section 4.5.7 of</xref>, including
sending a PIM Join to the upstream neighbor)</t>
<t>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)</t>
<t>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 <xref target="RFC7761"/>
SHOULD be ignored until the <spanx style="strong">reuse-threshold</spanx>
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.</t>
</list></t>
<t>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)</t>
</list></t>
</list></t>
<t>Once the <spanx style="strong">figure-of-merit</spanx> for (S,G)
damping state decays to a value strictly below the configured <spanx style="strong">reuse-threshold</spanx>, 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.</t>
<t>Given the specificity of multicast applications, it is REQUIRED for
the implementation to let the operator configure the <spanx style="strong">decay-half-life</spanx> in seconds, rather than in
minutes.</t>
<t>This specification does not impose the use of a particular
technique to update the <spanx style="strong">figure-of-merit</spanx>
following the exponential decay controlled by the configured <spanx style="strong">decay-half-life</spanx>. For instance, the same
techniques as the ones described in <xref target="RFC2439"/> can be
applied. The only requirement is that the <spanx style="strong">figure-of-merit</spanx>
has to be updated prior to increasing it, and that its decay below the
<spanx style="strong">reuse-threshold</spanx> has to be timely reacted
upon: 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 <spanx style="strong">decay-half-life</spanx> of 10s, recomputing the <spanx style="strong">figure-of-merit</spanx> each minute would result in a
multicast state to remained damped for a much longer time than
specified).</t>
<t>PIM implementations typically follow <xref target="RFC7761"/>
suggestion 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" (<xref target="RFC7761">Section 4.1 of
</xref>). 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 <spanx style="strong">figure-of-merit</spanx>
and damping state are removed as well.</t>
<t>Note that these procedures:</t>
<t><list style="symbols">
<t>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 <spanx style="strong">figure-of-merit</spanx>;</t>
<t>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;</t>
<t>do not impact PIM Prune messages that are sent when the RPF
neighbor is updated for a given multicast flow;</t>
<t>do not impact PIM Prune messages that are sent in the context
of switching between a Rendez-vous Point Tree and a Shortest Path
Tree.</t>
</list></t>
<t>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 <spanx style="strong">figure-of-merit</spanx>
or damping state is created in this case.</t>
</section>
<section anchor="mvpn-procedures" title="Procedures for multicast VPN state damping">
<t>The procedures described in <xref target="pim-procedures"/> can be
applied in the 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 <xref target="RFC6513"/> relying on the use of PIM to carry C-multicast
routing information MUST support this technique, to be compliant with
this specification.</t>
<t>In the context of <xref target="RFC6514"/> where BGP is used to
distribute C-multicast routing information, the following procedure is
proposed as an alternative to the procedures in <xref target="pim-procedures"/> and consists in applying damping in the BGP
implementation, based on existing BGP damping mechanism, applied to
C-multicast Source Tree Join routes and Shared Tree Join routes (and
as well to Leaf A-D routes - see <xref target="ptunnel"/>), and
modified to implement the behavior described in <xref target="overview"/> along the following guidelines:<list style="symbols">
<t>not withdrawing (instead of not advertising) damped routes</t>
<t>providing means to configure the <spanx style="strong">decay-half-life</spanx>
in seconds if that option is not already available</t>
<t>using parameters for the exponential decay that are specific to
multicast, based on default values and multicast specific
configuration</t>
</list></t>
<t>While these procedures would typically be implemented on PE
routers, in a context where BGP Route Reflectors (RRs, <xref target="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 AS from the
dynamicity of multicast VPN routing events from other ASes.</t>
<t>The choice to implement damping based on BGP routes or the
procedures described in <xref target="pim-procedures"/>, 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 ASBRs,
implementing the BGP approach is recommended.</t>
<t>When not all routers in a deployment have the capability to drop
traffic coming from the wrong PE (as spelled out in <xref target="RFC6513">section 9.1.1 of</xref>), 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 whether, not damp these withdrawals by
default, or alternatively provide a tuning knob to disable the damping
of these withdrawals. Additionally, in such a deployment context, it
is RECOMMENDED to not enable any multicast VPN route damping on RRs
and ASBRs, since these equipments cannot distinguish the event having
caused a C-multicast to be withdrawn.</t>
<t>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.</t>
</section>
</section>
<section anchor="ptunnel" title="Procedures for P-tunnel state damping">
<section anchor="ptunnel-mvpn" title="Damping mVPN P-tunnel change events">
<t>When selective P-tunnels are used (see <xref target="RFC6513">section 7 of</xref>), 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.</t>
<t>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
<xref target="mvpn-procedures"/>).</t>
<t>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.</t>
<t>The following is proposed as example of how the above can be
achieved:</t>
<t><list style="symbols">
<t>For P-tunnels implemented with the PIM protocol, this consists
in applying multicast state damping techniques described in <xref target="pim-procedures"/> to the P-PIM instance, at least for
(S,G) states corresponding to P-tunnels.</t>
<t>For P-tunnels implemented with the mLDP protocol, this consists
in applying damping techniques completely similar to the one
described in <xref target="procedures"/>, but generalized to apply
to mLDP states</t>
<t>For root-initiated P-tunnels (P-tunnels implemented with the
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</t>
<t>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)</t>
</list></t>
</section>
<section anchor="ptunnel-evpn" title="Procedures for Ethernet VPNs">
<t>Specifications exist to support or optimize multicast and broadcast
in the context of Ethernet VPNs <xref target="RFC7117"/>, relying on
the use of S-PMSI and P-tunnels. For the same reasons as for IP
multicast VPNs, an implementation of <xref target="RFC7117"/> MUST
follow the procedures described in <xref target="ptunnel-mvpn"/>, to
be compliant with this specification.</t>
</section>
</section>
<section anchor="operational" title="Operational considerations">
<section title="Enabling multicast damping">
<t>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 (<xref target="RFC6514"/>) these procedures can be
enabled on ASBRs and Route Reflectors.</t>
</section>
<section title="Troubleshooting and monitoring">
<t>Implementing the damping mechanisms described in this document
should be complemented by appropriate tools to observe and
troubleshoot damping activity.</t>
<t>Complementing the existing interface providing information on
multicast states with information on eventual damping of corresponding
states (e.g. MRIB states) is RECOMMENDED: C-multicast routing states
and P-tunnel states.</t>
</section>
<section anchor="default-max-values" title="Default and maximum values">
<t>Considering that, by design multicast streams will be delivered
unchanged to the end user, independently 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.</t>
<t>This section proposes default and maximum values, conservative so
as to not significantly impact network dimensioning but still prevent
multicast state churn going beyond what can be considered a reasonably
low churn for a multicast state (see below for illustrations in order
of magnitude of the effect of these values).</t>
<t>The following values are RECOMMENDED to adopt as default
values:</t>
<t><list style="symbols">
<t><spanx style="strong">increment-factor</spanx>: 1000</t>
<t><spanx style="strong">cutoff-threshold</spanx>: 3000</t>
<t><spanx style="strong">decay-half-life</spanx>: 10s</t>
<t><spanx style="strong">reuse-threshold</spanx>: 1500</t>
</list></t>
<t>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 large time in the
absence of receivers.</t>
<t>The proposed default maximum value for the <spanx style="strong">figure-of-merit</spanx>
is 20x<spanx style="strong">increment-factor</spanx>, i.e. 20000 with
the proposed default <spanx style="strong">increment-factor</spanx> of
1000.</t>
<t>As illustrations, with these values:<list style="symbols">
<t>a multicast state updated less frequently than once every 6s
will not be damped at all</t>
<t>a multicast state changing once per second for 3s, and then not
changing, will not be damped</t>
<t>a multicast state changing once per second for 4s, and then not
changing, will be damped after the fourth change for approximately
13s</t>
<t>a multicast state changing twice per second for 15s, and then
not changing, will be damped after the fourth change for
approximately 50s</t>
<t>a multicast state changing at a fast pace for a long time will
reach the maximum of <spanx style="strong">figure-of-merit</spanx>;
once the activity on this state stops, corresponding traffic may
still flow in the network for approximately 37s before dampening
stops being active</t>
</list></t>
<t>The following values are proposed as maxima:<list style="symbols">
<t><spanx style="strong">decay-half-life</spanx>: 60s</t>
<t><spanx style="strong">cutoff-threshold</spanx>: 50000</t>
</list></t>
<t>More aggressive protection against the risk of denial of service
can be achieved by increasing the <spanx style="strong">increment-factor</spanx>
or the <spanx style="strong">decay-half-life</spanx>, or reducing the
<spanx style="strong">cutoff-threshold</spanx> and/or <spanx style="strong">reuse-threshold</spanx>.</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document makes no request to IANA.</t>
<t>Note to the RFC Editor: this section may be removed on publication as
an RFC.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>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.</t>
<t>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.</t>
<t>The procedures describe 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 <xref target="RFC4609"/>).</t>
<t>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 mechanism may
interact: 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 otherwise acceptable new state from being successfully
created.</t>
<t>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
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.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>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.</t>
</section>
</middle>
<back>
<references title="Normative References">
<!-- Begin inclusion reference.RFC.2119.xml. -->
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate
Requirement Levels</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date month="March" year="1997"/>
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>In many standards track documents several words are used to
signify the requirements in the specification. These words are
often capitalized. This document defines these words as they
should be interpreted in IETF documents. Authors who follow these
guidelines should incorporate this phrase near the beginning of
their document: <list>
<t>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.</t>
</list></t>
<t>Note that the force of these words is modified by the
requirement level of the document in which they are used.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<format octets="4723" target="http://www.rfc-editor.org/rfc/rfc2119.txt" type="TXT"/>
<format octets="17970" target="http://xml.resource.org/public/rfc/html/rfc2119.html" type="HTML"/>
<format octets="5777" target="http://xml.resource.org/public/rfc/xml/rfc2119.xml" type="XML"/>
</reference>
<!-- End inclusion reference.RFC.2119.xml. -->
<!-- Begin inclusion reference.RFC.7761.xml. --><reference anchor="RFC7761" target="http://www.rfc-editor.org/info/rfc7761">
<front>
<title>Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)</title>
<author initials="B." surname="Fenner" fullname="B. Fenner"><organization/></author>
<author initials="M." surname="Handley" fullname="M. Handley"><organization/></author>
<author initials="H." surname="Holbrook" fullname="H. Holbrook"><organization/></author>
<author initials="I." surname="Kouvelas" fullname="I. Kouvelas"><organization/></author>
<author initials="R." surname="Parekh" fullname="R. Parekh"><organization/></author>
<author initials="Z." surname="Zhang" fullname="Z. Zhang"><organization/></author>
<author initials="L." surname="Zheng" fullname="L. Zheng"><organization/></author>
<date year="2016" month="March"/>
<abstract><t>This document specifies Protocol Independent Multicast - Sparse Mode (PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast-capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and it optionally creates shortest-path trees per source.</t><t>This document obsoletes RFC 4601 by replacing it, addresses the errata filed against it, removes the optional (*,*,RP), PIM Multicast Border Router features and authentication using IPsec that lack sufficient deployment experience (see Appendix A), and moves the PIM specification to Internet Standard.</t></abstract>
</front>
<seriesInfo name="STD" value="83"/>
<seriesInfo name="RFC" value="7761"/>
<seriesInfo name="DOI" value="10.17487/RFC7761"/>
</reference><!-- End inclusion reference.RFC.7761.xml. -->
<!-- Begin inclusion reference.RFC.2439.xml. -->
<reference anchor="RFC2439">
<front>
<title>BGP Route Flap Damping</title>
<author fullname="Curtis Villamizar" initials="C." surname="Villamizar">
<organization>ANS</organization>
<address>
<email>curtis@ans.net</email>
</address>
</author>
<author fullname="Ravi Chandra" initials="R." surname="Chandra">
<organization>Cisco Systems</organization>
<address>
<email>rchandra@cisco.com</email>
</address>
</author>
<author fullname="Ramesh Govindan" initials="R." surname="Govindan">
<organization>ISI</organization>
<address>
<email>govindan@isi.edu</email>
</address>
</author>
<date month="November" year="1998"/>
<area>Routing</area>
<keyword>border gateway protocol</keyword>
<keyword>BGP</keyword>
<keyword>routing</keyword>
<abstract>
<t>A usage of the BGP routing protocol is described which is
capable of reducing the routing traffic passed on to routing peers
and therefore the load on these peers without adversely affecting
route convergence time for relatively stable routes. This
technique has been implemented in commercial products supporting
BGP. The technique is also applicable to IDRP.</t>
<t>The overall goals are: <list>
<t>o to provide a mechanism capable of reducing router
processing load caused by instability</t>
<t>o in doing so prevent sustained routing oscillations</t>
<t>o to do so without sacrificing route convergence time for
generally well behaved routes.</t>
</list></t>
<t>This must be accomplished keeping other goals of BGP in mind:
<list>
<t>o pack changes into a small number of updates</t>
<t>o preserve consistent routing</t>
<t>o minimal addition space and computational overhead</t>
</list></t>
<t>An excessive rate of update to the advertised reachability of a
subset of Internet prefixes has been widespread in the Internet.
This observation was made in the early 1990s by many people
involved in Internet operations and remains the case. These
excessive updates are not necessarily periodic so route
oscillation would be a misleading term. The informal term used to
describe this effect is "route flap". The techniques described
here are now widely deployed and are commonly referred to as
"route flap damping".</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2439"/>
<format octets="86376" target="http://www.rfc-editor.org/rfc/rfc2439.txt" type="TXT"/>
<format octets="86919" target="http://xml.resource.org/public/rfc/xml/rfc2439.xml" type="XML"/>
</reference>
<!-- End inclusion reference.RFC.2439.xml. -->
<!-- Begin inclusion reference.RFC.7196.xml. -->
<reference anchor="RFC7196">
<front>
<title>Making Route Flap Damping Usable</title>
<author fullname="C. Pelsser" initials="C." surname="Pelsser">
<organization/>
</author>
<author fullname="R. Bush" initials="R." surname="Bush">
<organization/>
</author>
<author fullname="K. Patel" initials="K." surname="Patel">
<organization/>
</author>
<author fullname="P. Mohapatra" initials="P." surname="Mohapatra">
<organization/>
</author>
<author fullname="O. Maennel" initials="O." surname="Maennel">
<organization/>
</author>
<date month="May" year="2014"/>
<abstract>
<t>Route Flap Damping (RFD) was first proposed to reduce BGP churn
in routers. Unfortunately, RFD was found to severely penalize
sites for being well connected because topological richness
amplifies the number of update messages exchanged. Many operators
have turned RFD off. Based on experimental measurement, this
document recommends adjusting a few RFD algorithmic constants and
limits in order to reduce the high risks with RFD. The result is
damping a non-trivial amount of long-term churn without penalizing
well-behaved prefixes' normal convergence process.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7196"/>
<format octets="15202" target="http://www.rfc-editor.org/rfc/rfc7196.txt" type="TXT"/>
</reference>
<!-- End inclusion reference.RFC.7196.xml. -->
<!-- Begin inclusion reference.RFC.3376.xml. -->
<reference anchor="RFC3376">
<front>
<title>Internet Group Management Protocol, Version 3</title>
<author fullname="B. Cain" initials="B." surname="Cain">
<organization/>
</author>
<author fullname="S. Deering" initials="S." surname="Deering">
<organization/>
</author>
<author fullname="I. Kouvelas" initials="I." surname="Kouvelas">
<organization/>
</author>
<author fullname="B. Fenner" initials="B." surname="Fenner">
<organization/>
</author>
<author fullname="A. Thyagarajan" initials="A." surname="Thyagarajan">
<organization/>
</author>
<date month="October" year="2002"/>
</front>
<seriesInfo name="RFC" value="3376"/>
<format octets="119726" target="http://www.rfc-editor.org/rfc/rfc3376.txt" type="TXT"/>
</reference>
<!-- End inclusion reference.RFC.3376.xml. -->
<!-- Begin inclusion reference.RFC.3810.xml. -->
<reference anchor="RFC3810">
<front>
<title>Multicast Listener Discovery Version 2 (MLDv2) for
IPv6</title>
<author fullname="R. Vida" initials="R." surname="Vida">
<organization/>
</author>
<author fullname="L. Costa" initials="L." surname="Costa">
<organization/>
</author>
<date month="June" year="2004"/>
<abstract>
<t>This document updates RFC 2710, and it specifies Version 2 of
the ulticast Listener Discovery Protocol (MLDv2). MLD is used by
an IPv6 router to discover the presence of multicast listeners on
directly attached links, and to discover which multicast addresses
are of interest to those neighboring nodes. MLDv2 is designed to
be interoperable with MLDv1. MLDv2 adds the ability for a node to
report interest in listening to packets with a particular
multicast address only from specific source addresses or from all
sources except for specific source addresses.
[STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3810"/>
<format octets="153579" target="http://www.rfc-editor.org/rfc/rfc3810.txt" type="TXT"/>
</reference>
<!-- End inclusion reference.RFC.3810.xml. -->
<!-- Begin inclusion reference.RFC.6513.xml. -->
<reference anchor="RFC6513">
<front>
<title>Multicast in MPLS/BGP IP VPNs</title>
<author fullname="E. Rosen" initials="E." surname="Rosen">
<organization/>
</author>
<author fullname="R. Aggarwal" initials="R." surname="Aggarwal">
<organization/>
</author>
<date month="February" year="2012"/>
<abstract>
<t>In order for IP multicast traffic within a BGP/MPLS IP VPN
(Virtual Private Network) to travel from one VPN site to another,
special protocols and procedures must be implemented by the VPN
Service Provider. These protocols and procedures are specified in
this document. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6513"/>
<format octets="213780" target="http://www.rfc-editor.org/rfc/rfc6513.txt" type="TXT"/>
</reference>
<!-- End inclusion reference.RFC.6513.xml. -->
<!-- Begin inclusion reference.RFC.6514.xml. -->
<reference anchor="RFC6514">
<front>
<title>BGP Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs</title>
<author fullname="R. Aggarwal" initials="R." surname="Aggarwal">
<organization/>
</author>
<author fullname="E. Rosen" initials="E." surname="Rosen">
<organization/>
</author>
<author fullname="T. Morin" initials="T." surname="Morin">
<organization/>
</author>
<author fullname="Y. Rekhter" initials="Y." surname="Rekhter">
<organization/>
</author>
<date month="February" year="2012"/>
<abstract>
<t>This document describes the BGP encodings and procedures for
exchanging the information elements required by Multicast in
MPLS/BGP IP VPNs, as specified in RFC 6513. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6514"/>
<format octets="145112" target="http://www.rfc-editor.org/rfc/rfc6514.txt" type="TXT"/>
</reference>
<!-- End inclusion reference.RFC.6514.xml. -->
<!-- Begin inclusion reference.RFC.7117.xml. -->
<reference anchor="RFC7117">
<front>
<title>Multicast in Virtual Private LAN Service (VPLS)</title>
<author fullname="R. Aggarwal" initials="R." surname="Aggarwal">
<organization/>
</author>
<author fullname="Y. Kamite" initials="Y." surname="Kamite">
<organization/>
</author>
<author fullname="L. Fang" initials="L." surname="Fang">
<organization/>
</author>
<author fullname="Y. Rekhter" initials="Y." surname="Rekhter">
<organization/>
</author>
<author fullname="C. Kodeboniya" initials="C." surname="Kodeboniya">
<organization/>
</author>
<date month="February" year="2014"/>
<abstract>
<t>RFCs 4761 and 4762 describe a solution for Virtual Private LAN
Service (VPLS) multicast that relies on the use of point-to-point
or multipoint-to-point unicast Label Switched Paths (LSPs) for
carrying multicast traffic. This solution has certain limitations
for certain VPLS multicast traffic profiles. For example, it may
result in highly non-optimal bandwidth utilization when a large
amount of multicast traffic is to be
transported.</t><t> This document describes solutions
for overcoming a subset of the limitations of the existing VPLS
multicast solution. It describes procedures for VPLS multicast
that utilize multicast trees in the service provider (SP) network.
The solution described in this document allows sharing of one such
multicast tree among multiple VPLS instances. Furthermore, the
solution described in this document allows a single multicast tree
in the SP network to carry traffic belonging only to a specified
set of one or more IP multicast streams from one or more VPLS
instances.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7117"/>
<format octets="126280" target="http://www.rfc-editor.org/rfc/rfc7117.txt" type="TXT"/>
</reference>
<!-- End inclusion reference.RFC.7117.xml. -->
</references>
<references title="Informative References">
<!-- Begin inclusion reference.RFC.4609.xml. -->
<reference anchor="RFC4609">
<front>
<title>Protocol Independent Multicast - Sparse Mode (PIM-SM)
Multicast Routing Security Issues and Enhancements</title>
<author fullname="P. Savola" initials="P." surname="Savola">
<organization/>
</author>
<author fullname="R. Lehtonen" initials="R." surname="Lehtonen">
<organization/>
</author>
<author fullname="D. Meyer" initials="D." surname="Meyer">
<organization/>
</author>
<date month="October" year="2006"/>
<abstract>
<t>This memo describes security threats for the larger
(intra-domain or inter-domain) multicast routing infrastructures.
Only Protocol Independent Multicast - Sparse Mode (PIM-SM) is
analyzed, in its three main operational modes: the traditional
Any-Source Multicast (ASM) model, the source-specific multicast
(SSM) model, and the ASM model enhanced by the Embedded Rendezvous
Point (Embedded-RP) group-to-RP mapping mechanism. This memo also
describes enhancements to the protocol operations that mitigate
the identified threats. This memo provides information for the
Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4609"/>
<format octets="49812" target="http://www.rfc-editor.org/rfc/rfc4609.txt" type="TXT"/>
</reference>
<!-- End inclusion reference.RFC.4609.xml. -->
<!-- Begin inclusion reference.RFC.4456.xml. --><reference anchor="RFC4456" target="http://www.rfc-editor.org/info/rfc4456">
<front>
<title>BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)</title>
<author initials="T." surname="Bates" fullname="T. Bates"><organization/></author>
<author initials="E." surname="Chen" fullname="E. Chen"><organization/></author>
<author initials="R." surname="Chandra" fullname="R. Chandra"><organization/></author>
<date year="2006" month="April"/>
<abstract><t>The Border Gateway Protocol (BGP) is an inter-autonomous system routing protocol designed for TCP/IP internets. Typically, all BGP speakers within a single AS must be fully meshed so that any external routing information must be re-distributed to all other routers within that Autonomous System (AS). This represents a serious scaling problem that has been well documented with several alternatives proposed.</t><t>This document describes the use and design of a method known as "route reflection" to alleviate the need for "full mesh" Internal BGP (IBGP).</t><t>This document obsoletes RFC 2796 and RFC 1966. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name="RFC" value="4456"/>
<seriesInfo name="DOI" value="10.17487/RFC4456"/>
</reference><!-- End inclusion reference.RFC.4456.xml. -->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:22:18 |