One document matched: draft-ietf-bess-multicast-damping-00.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-00" ipr="trust200902">
<front>
<title abbrev="Multicast VPN 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="Jeffrey (Zhaohui) Zhang" initials="J" 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="10" month="February" year="2015"/>
<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 site. 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 said multicast group or channel through multicast membership
control protocols (IGMP, MLD), multicast routing protocols accordingly
adjust multicast routing states and P-multicast tree states, to forward
or prune multicast traffic to these receivers.</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. 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. 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. <xref target="RFC6514">Section
16 of</xref> specifically spells out the need for damping the activity
of C-multicast and Leaf Auto-discovery routes.</t>
<t>This document describes procedures, remotely inspired from existing
BGP route damping, aimed at protecting these control planes while at the
same time avoiding negative effects on the service provided, although at
the expense of a minimal increase in average of bandwidth use in the
network.</t>
<t>The base principle 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 these specifications.</t>
<t>Section <xref format="counter" target="ptunnel"/> provide 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>TBC</t>
</section>
<section anchor="overview" title="Overview">
<t>The procedures described in this document allows the network operator
to configure multicast VPN PEs so that they can delay the propagation of
multicast state prune messages, 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, 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 proposed defined
procedures, and having the upstream router delay state prune propagation
to its own upstream 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 said multicast flow will be forwarded for a longer time than if no
damping was applied. That said, it is expected that this technique will
allow to 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>To be practical, such a mechanism requires configurability, in
particular, needs to offer means to control when damping is triggered,
and to allow delaying a multicast state Prune for a time increasing with
the churn of this multicast state.</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="RFC4609"/> examines multicast security threats and
among other things the risk described in <xref target="intro"/>. A
mechanism relying on rate-limiting PIM messages is proposed in <xref target="RFC4609">section 5.3.3</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 [RFC4601], a
mechanism exists that in some context may offer a form of de facto
damping mechanism for multicast states. 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="RFC4601"/> 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
said multicast state, the upstream router to send to its own
upstreamrouter, multicast routing protocol messages at a rate
higher than 1/[prune override interval], thus providing 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, even though enabling this feature may otherwise be
desired</t>
<t>on certain implementations, these mechanisms are incompatible
with behavior that cannot be turned off</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 exposed in <xref target="rate-limiting"/> and
<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="RFC4601"/> ; 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 introduced in <xref target="RFC2439"/> are
reused in these procedures:<list style="hanging">
<t hangText="figure-of-merit:">a number reflecting the current
estimation of past recent activity of an (S,G) multicast routing
state, which evolves based on routing events related to this state
and based an exponential decay algorithm ; 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)</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>
<t hangText="decay-half-life:">period of time used to control how
fast is the exponential decay of the <spanx style="strong">figure-of-merit</spanx>
(configurable parameter)</t>
</list></t>
<t>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>Section <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 said (S,G) state, that results in a
change of the state of the PIM downstream state machine (see <xref target="RFC4601">section 4.5.3 of </xref>), a router implementing
these procedures MUST:<list style="symbols">
<t>apply unchanged procedures for everything relating to what
multicast traffic ends up being sent on downstream interfaces,
including interface I</t>
<t>increasing the <spanx style="strong">figure-of-merit</spanx>
for the (S,G) by the <spanx style="strong">increment-factor</spanx>
(updating the <spanx style="strong">figure-of-merit</spanx> based
on the decay algorithm must be done prior to this increment)</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 above the configured <spanx style="strong">cutoff-threshold</spanx></t>
<t>if damping is inactive on (S,G) state, update the upstream
state machine as usual (as per <xref target="RFC4601">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="RFC4601">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>then freeze the upstream state machine in Joined state, and
and setup a trigger to update it once damping later becomes
inactive again. The effect is that in the meantime, PIM Join
messages will be sent as refreshes to the upstream neighbor,
but 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>
<t>Once the <spanx style="strong">figure-of-merit</spanx> for (S,G)
damping state decays to a value 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>Same techniques as the ones described in <xref target="RFC2439"/>
can be applied to determine when the figure-of-merit value is
recomputed based on the exponential decay algorithm and the configured
<spanx style="strong">decay-half-life</spanx>.</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. When the recomputation is done periodically, the period
should be low enough to not significantly delay the inactivation of
damping on a multicast state beyond what the operator wanted to
configure (i.e. for a half-life 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 what
the parameters are supposed to command).</t>
<t>PIM implementations typically follow <xref target="RFC4601"/>
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="RFC4601">Section 4.1 of
</xref>). To properly implement 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 said 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 dampening">
<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. Implementation of <xref target="RFC6513"/>
relying on the use of PIM to carry C-multicast routing information
MUST support this technique.</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 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 half-life 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 are used it can be
considered useful to also be able to apply damping on RRs as well.
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. In that perspective, it is RECOMMENDED for
implementations to support damping mVPN C-multicast routes directly
into BGP, without relying on the PIM-SM state machine.</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 UMH SHOULD NOT be
damped. An implementation of these specs MUST whether, not damp these
withdrawals by default, or alternatively provide a tuning knob to
disable then damping of these withdrawals. Additionally, in such a
context, it is RECOMMENDED to <spanx style="strong">not</spanx> enable
any multicast VPN route damping on RRs and ASBRs, since these
equipments cannot distinguish these events.</t>
<t>The choice to implement damping based on BGP routes or the
procedures described in <xref target="procedures"/>, is up to the
implementor, but at least one of the two MUST be implemented; keeping
in mind that in contexts where damping on RRs and ASBRs the BGP
approach is RECOMMENDED.</t>
<t>Note well that damping SHOULD NOT be applied to BGP routes of the
following sub-types: "Intra-AS I-PMSI A-D Route", "Inter-AS I-PMSI A-D
Route", "S-PMSI A-D Route", and "Source Active A-D Route".</t>
</section>
</section>
<section anchor="ptunnel" title="Procedures for P-tunnel state damping">
<t/>
<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 said (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 as 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 said (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 exists 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 these procedures MUST
follow the procedures described in this section.<xref target="ptunnel-mvpn"/>.</t>
</section>
</section>
<section anchor="operational" title="Operational considerations">
<section title="Enabling and configuring 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 possibly Route Reflectors as well.</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>More specifically it is RECOMMENDED to complement the existing
interface providing information on multicast states with information
on eventual damping of corresponding states (e.g. MRIB states):
C-multicast routing states and P-tunnel states.</t>
</section>
<section anchor="default-max-values" title="Default and maximum values">
<t>The following values are RECOMMENDED to adopt as default
conservative values:</t>
<t><list style="symbols">
<t>increment-factor: 1000</t>
<t>cutoff-threshold: 3000</t>
<t>decay-half-life: 10s</t>
<t>reuse-threshold: 1500</t>
</list>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 were 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 figure-of-merit is
20x<increment-factor>, i.e. 20000 with the proposed default
increment-factor of 1000.</t>
<t>The following values are proposed as maximums:</t>
<t><list style="symbols">
<t>decay half-life: 60s</t>
<t>cutoff-threshold: 50000</t>
</list></t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document makes no request of IANA.</t>
<t>Note to 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) shall rely upon 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
rely upon 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.</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 initials="S." surname="Bradner" fullname="Scott 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 year="1997" month="March"/>
<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 type="TXT" octets="4723" target="http://www.rfc-editor.org/rfc/rfc2119.txt"/>
<format type="HTML" octets="17970" target="http://xml.resource.org/public/rfc/html/rfc2119.html"/>
<format type="XML" octets="5777" target="http://xml.resource.org/public/rfc/xml/rfc2119.xml"/>
</reference><!-- End inclusion reference.RFC.2119.xml. -->
<!-- Begin inclusion reference.RFC.2439.xml. --><reference anchor="RFC2439">
<front>
<title>BGP Route Flap Damping</title>
<author initials="C." surname="Villamizar" fullname="Curtis Villamizar">
<organization>ANS</organization>
<address>
<email>curtis@ans.net</email></address></author>
<author initials="R." surname="Chandra" fullname="Ravi Chandra">
<organization>Cisco Systems</organization>
<address>
<email>rchandra@cisco.com</email></address></author>
<author initials="R." surname="Govindan" fullname="Ramesh Govindan">
<organization>ISI</organization>
<address>
<email>govindan@isi.edu</email></address></author>
<date year="1998" month="November"/>
<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 type="TXT" octets="86376" target="http://www.rfc-editor.org/rfc/rfc2439.txt"/>
<format type="XML" octets="86919" target="http://xml.resource.org/public/rfc/xml/rfc2439.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 initials="C." surname="Pelsser" fullname="C. Pelsser">
<organization/></author>
<author initials="R." surname="Bush" fullname="R. Bush">
<organization/></author>
<author initials="K." surname="Patel" fullname="K. Patel">
<organization/></author>
<author initials="P." surname="Mohapatra" fullname="P. Mohapatra">
<organization/></author>
<author initials="O." surname="Maennel" fullname="O. Maennel">
<organization/></author>
<date year="2014" month="May"/>
<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 type="TXT" octets="15202" target="http://www.rfc-editor.org/rfc/rfc7196.txt"/>
</reference><!-- End inclusion reference.RFC.7196.xml. -->
<!-- Begin inclusion reference.RFC.4601.xml. --><reference anchor="RFC4601">
<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>
<date year="2006" month="August"/>
<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 optionally creates shortest-path trees per source.</t><t> This document obsoletes RFC 2362, an Experimental version of PIM-SM. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name="RFC" value="4601"/>
<format type="TXT" octets="340632" target="http://www.rfc-editor.org/rfc/rfc4601.txt"/>
<format type="PDF" octets="304538" target="http://www.rfc-editor.org/rfc/rfc4601.pdf"/>
</reference><!-- End inclusion reference.RFC.4601.xml. -->
<!-- Begin inclusion reference.RFC.3376.xml. --><reference anchor="RFC3376">
<front>
<title>Internet Group Management Protocol, Version 3</title>
<author initials="B." surname="Cain" fullname="B. Cain">
<organization/></author>
<author initials="S." surname="Deering" fullname="S. Deering">
<organization/></author>
<author initials="I." surname="Kouvelas" fullname="I. Kouvelas">
<organization/></author>
<author initials="B." surname="Fenner" fullname="B. Fenner">
<organization/></author>
<author initials="A." surname="Thyagarajan" fullname="A. Thyagarajan">
<organization/></author>
<date year="2002" month="October"/></front>
<seriesInfo name="RFC" value="3376"/>
<format type="TXT" octets="119726" target="http://www.rfc-editor.org/rfc/rfc3376.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 initials="R." surname="Vida" fullname="R. Vida">
<organization/></author>
<author initials="L." surname="Costa" fullname="L. Costa">
<organization/></author>
<date year="2004" month="June"/>
<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 type="TXT" octets="153579" target="http://www.rfc-editor.org/rfc/rfc3810.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 initials="E." surname="Rosen" fullname="E. Rosen">
<organization/></author>
<author initials="R." surname="Aggarwal" fullname="R. Aggarwal">
<organization/></author>
<date year="2012" month="February"/>
<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 type="TXT" octets="213780" target="http://www.rfc-editor.org/rfc/rfc6513.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 initials="R." surname="Aggarwal" fullname="R. Aggarwal">
<organization/></author>
<author initials="E." surname="Rosen" fullname="E. Rosen">
<organization/></author>
<author initials="T." surname="Morin" fullname="T. Morin">
<organization/></author>
<author initials="Y." surname="Rekhter" fullname="Y. Rekhter">
<organization/></author>
<date year="2012" month="February"/>
<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 type="TXT" octets="145112" target="http://www.rfc-editor.org/rfc/rfc6514.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 initials="R." surname="Aggarwal" fullname="R. Aggarwal">
<organization/></author>
<author initials="Y." surname="Kamite" fullname="Y. Kamite">
<organization/></author>
<author initials="L." surname="Fang" fullname="L. Fang">
<organization/></author>
<author initials="Y." surname="Rekhter" fullname="Y. Rekhter">
<organization/></author>
<author initials="C." surname="Kodeboniya" fullname="C. Kodeboniya">
<organization/></author>
<date year="2014" month="February"/>
<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 type="TXT" octets="126280" target="http://www.rfc-editor.org/rfc/rfc7117.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 initials="P." surname="Savola" fullname="P. Savola">
<organization/></author>
<author initials="R." surname="Lehtonen" fullname="R. Lehtonen">
<organization/></author>
<author initials="D." surname="Meyer" fullname="D. Meyer">
<organization/></author>
<date year="2006" month="October"/>
<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 type="TXT" octets="49812" target="http://www.rfc-editor.org/rfc/rfc4609.txt"/>
</reference><!-- End inclusion reference.RFC.4609.xml. -->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:24:28 |