One document matched: draft-ietf-bess-multicast-damping-03.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-03" ipr="trust200902">
<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="05" month="January" 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 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 given 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"/> 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="RFC4601"/> and
<xref target="RFC6514"/>.</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
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, 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="RFC4609">PIM-SM specifications</xref> examine
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 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 [RFC4601], 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="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
given multicast state, the upstream router to send to its own upstream
router, multicast routing protocol messages at a rate higher than
1/[prune 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, 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="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)
and is initialized to a value of zero on state creation</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><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="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 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="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 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>
</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>Same techniques as the ones described in <xref target="RFC2439"/>
can be applied to determine when the <spanx style="strong">figure-of-merit</spanx>
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 <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 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 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. 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 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) 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.</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. 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 the specification in this document 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
context, it is RECOMMENDED to not enable any multicast VPN route
damping on RRs and ASBRs, since these equipments cannot distinguish
these events.</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">
<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 these procedures MUST follow the
procedures described in <xref target="ptunnel-mvpn"/>.</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>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><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>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>The following values are proposed as maxima:</t>
<t><list style="symbols">
<t><spanx style="strong">decay-half-life</spanx>: 60s</t>
<t><spanx style="strong">cutoff-threshold</spanx>: 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,
and Martin Vigoureux and Gunter Van De Velde for their reviews.</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.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.4601.xml. -->
<reference anchor="RFC4601">
<front>
<title>Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)</title>
<author fullname="B. Fenner" initials="B." surname="Fenner">
<organization/>
</author>
<author fullname="M. Handley" initials="M." surname="Handley">
<organization/>
</author>
<author fullname="H. Holbrook" initials="H." surname="Holbrook">
<organization/>
</author>
<author fullname="I. Kouvelas" initials="I." surname="Kouvelas">
<organization/>
</author>
<date month="August" year="2006"/>
<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 octets="340632" target="http://www.rfc-editor.org/rfc/rfc4601.txt" type="TXT"/>
<format octets="304538" target="http://www.rfc-editor.org/rfc/rfc4601.pdf" type="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 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. -->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:22:38 |