draft-ietf-bess-multicast-damping-01.txt   draft-ietf-bess-multicast-damping-02.txt 
Network Working Group T. Morin, Ed. Network Working Group T. Morin, Ed.
Internet-Draft S. Litkowski Internet-Draft S. Litkowski
Intended status: Standards Track Orange Intended status: Standards Track Orange
Expires: February 4, 2016 K. Patel Expires: June 20, 2016 K. Patel
Cisco Systems Cisco Systems
Z. Zhang Z. Zhang
R. Kebler R. Kebler
J. Haas J. Haas
Juniper Networks Juniper Networks
August 03, 2015 December 18, 2015
Multicast VPN state damping Multicast VPN state damping
draft-ietf-bess-multicast-damping-01 draft-ietf-bess-multicast-damping-02
Abstract Abstract
This document describes procedures to damp multicast VPN routing This document describes procedures to damp multicast VPN routing
state changes and control the effect of the churn due to the state changes and control the effect of the churn due to the
multicast dynamicity in customer site. The procedures described in multicast dynamicity in customer site. The procedures described in
this document are applicable to BGP-based multicast VPN and help this document are applicable to BGP-based multicast VPN and help
avoid uncontrolled control plane load increase in the core routing avoid uncontrolled control plane load increase in the core routing
infrastructure. New procedures are proposed inspired from BGP infrastructure. New procedures are proposed inspired from BGP
unicast route damping principles, but adapted to multicast. unicast route damping principles, but adapted to multicast.
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 4, 2016. This Internet-Draft will expire on June 20, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 31 skipping to change at page 2, line 31
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Existing mechanisms . . . . . . . . . . . . . . . . . . . . . 4 4. Existing mechanisms . . . . . . . . . . . . . . . . . . . . . 4
4.1. Rate-limiting of multicast control traffic . . . . . . . 4 4.1. Rate-limiting of multicast control traffic . . . . . . . 4
4.2. Existing PIM, IGMP and MLD timers . . . . . . . . . . . . 4 4.2. Existing PIM, IGMP and MLD timers . . . . . . . . . . . . 4
4.3. BGP Route Damping . . . . . . . . . . . . . . . . . . . . 5 4.3. BGP Route Damping . . . . . . . . . . . . . . . . . . . . 5
5. Procedures for multicast state damping . . . . . . . . . . . 6 5. Procedures for multicast state damping . . . . . . . . . . . 6
5.1. PIM procedures . . . . . . . . . . . . . . . . . . . . . 6 5.1. PIM procedures . . . . . . . . . . . . . . . . . . . . . 6
5.2. Procedures for multicast VPN state dampening . . . . . . 9 5.2. Procedures for multicast VPN state damping . . . . . . . 9
6. Procedures for P-tunnel state damping . . . . . . . . . . . . 10 6. Procedures for P-tunnel state damping . . . . . . . . . . . . 10
6.1. Damping mVPN P-tunnel change events . . . . . . . . . . . 10 6.1. Damping mVPN P-tunnel change events . . . . . . . . . . . 10
6.2. Procedures for Ethernet VPNs . . . . . . . . . . . . . . 11 6.2. Procedures for Ethernet VPNs . . . . . . . . . . . . . . 11
7. Operational considerations . . . . . . . . . . . . . . . . . 11 7. Operational considerations . . . . . . . . . . . . . . . . . 11
7.1. Enabling and configuring multicast damping . . . . . . . 11 7.1. Enabling multicast damping . . . . . . . . . . . . . . . 11
7.2. Troubleshooting and monitoring . . . . . . . . . . . . . 11 7.2. Troubleshooting and monitoring . . . . . . . . . . . . . 11
7.3. Default and maximum values . . . . . . . . . . . . . . . 12 7.3. Default and maximum values . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . 14 11.1. Normative References . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . 14 11.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
skipping to change at page 3, line 30 skipping to change at page 3, line 30
This document describes procedures, remotely inspired from existing This document describes procedures, remotely inspired from existing
BGP route damping, aimed at protecting these control planes while at BGP route damping, aimed at protecting these control planes while at
the same time avoiding negative effects on the service provided, the same time avoiding negative effects on the service provided,
although at the expense of a minimal increase in average of bandwidth although at the expense of a minimal increase in average of bandwidth
use in the network. use in the network.
The base principle is described in Section 3. Existing mechanisms The base principle is described in Section 3. Existing mechanisms
that could be relied upon are discussed in Section 4. Section 5 that could be relied upon are discussed in Section 4. Section 5
details the procedures introduced by these specifications. details the procedures introduced by these specifications.
Section 6 provide specific details related to the damping of Section 6 provides specific details related to the damping of
multicast VPNs P-tunnel state. multicast VPNs P-tunnel state.
Finally, Section 7 discusses operational considerations related to Finally, Section 7 discusses operational considerations related to
the proposed mechanism. the proposed mechanism.
2. Terminology 2. Terminology
This document reuses terminology from [RFC4601] and [RFC6514]. This document reuses terminology from [RFC4601] and [RFC6514].
3. Overview 3. Overview
The procedures described in this document allows the network operator The procedures described in this document allow the network operator
to configure multicast VPN PEs so that they can delay the propagation to configure multicast VPN PEs (Provider Edge routers) so that they
of multicast state prune messages, when faced with a rate of can delay the propagation of multicast state prune messages between
multicast state dynamicity exceeding a certain configurable PEs, when faced with a rate of multicast state dynamicity exceeding a
threshold. Assuming that the number of multicast states that can be certain configurable threshold. Assuming that the number of
created by a receiver is bounded, delaying the propagation of multicast states that can be created by a receiver is bounded,
multicast state pruning results in setting up an upper bound to the delaying the propagation of multicast state pruning results in
average frequency at which the router will send state updates to an setting up an upper bound to the average frequency at which the
upstream router. router will send state updates to an upstream router.
From the point of view of a downstream router, such as a CE, this From the point of view of a downstream router, such as a CE (Customer
approach has no impact: the multicast routing states changes that it Edge router), this approach has no impact: the multicast routing
solicits to its PE will be honored without any additional delay. states changes that it solicits to its PE will be honored without any
Indeed the propagation of joins is not impacted by the proposed additional delay. Indeed the propagation of joins is not impacted by
defined procedures, and having the upstream router delay state prune the procedures specified here, and having the upstream router delay
propagation to its own upstream does not affect what traffic is sent state prune propagation to its own upstream router does not affect
to the downstream router. In particular, the amount of bandwidth what traffic is sent to the downstream router. In particular, the
used on the PE-CE link downstream to a PE applying this damping amount of bandwidth used on the PE-CE link downstream to a PE
technique is not increased. applying this damping technique is not increased.
This approach increases the average bandwidth utilization on a link This approach increases the average bandwidth utilization on a link
upstream to a PE applying this technique, such as a PE-PE 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 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 than if no damping was applied. That said, it is expected that this
technique will allow to meet the goals of protecting the multicast technique will allow to meet the goals of protecting the multicast
routing infrastructure control plane without a significant average routing infrastructure control plane without a significant average
increase of bandwidth; for instance, damping events happening at a increase of bandwidth; for instance, damping events happening at a
frequency higher than one event per X second, can be done without frequency higher than one event per X second, can be done without
increasing by more than X second the time during which a multicast increasing by more than X second the time during which a multicast
flow is present on a link. flow is present on a link.
To be practical, such a mechanism requires configurability, in To be practical, such a mechanism requires configurability. In
particular, needs to offer means to control when damping is particular, means are required to control when damping is triggered,
triggered, and to allow delaying a multicast state Prune for a time and to allow delaying a multicast state Prune for a time increasing
increasing with the churn of this multicast state. with the churn of this multicast state. This will allow control the
tradeoff made between minimizing the dynamicity and reducing
bandwidth consumption.
4. Existing mechanisms 4. Existing mechanisms
This section describes mechanisms that could be considered to address This section describes mechanisms that could be considered to address
the issue, but that end up appearing as not suitable or not efficient the issue, but that end up appearing as not suitable or not efficient
enough. enough.
4.1. Rate-limiting of multicast control traffic 4.1. Rate-limiting of multicast control traffic
[RFC4609] examines multicast security threats and among other things PIM-SM specifications [RFC4609] examine multicast security threats
the risk described in Section 1. A mechanism relying on rate- and among other things the risk described in Section 1. A mechanism
limiting PIM messages is proposed in section 5.3.3 of [RFC4609], but relying on rate-limiting PIM messages is proposed in section 5.3.3 of
has the identified drawbacks of impacting the service delivered and [RFC4609], but has the identified drawbacks of impacting the service
having side-effects on legitimate users. delivered and having side-effects on legitimate users.
4.2. Existing PIM, IGMP and MLD timers 4.2. Existing PIM, IGMP and MLD timers
In the context of PIM multicast routing protocols [RFC4601], a In the context of PIM multicast routing protocols [RFC4601], a
mechanism exists that in some context may offer a form of de facto mechanism exists that may offer a form of de-facto damping of
damping mechanism for multicast states. Indeed, when active, the multicast states, under some conditions. Indeed, when active, the
prune override mechanism consists in having a PIM upstream router prune override mechanism consists in having a PIM upstream router
introduce a delay ("prune override interval") before taking into introduce a delay ("prune override interval") before taking into
account a PIM Prune message sent by a downstream neighbor. account a PIM Prune message sent by a downstream neighbor.
This mechanism has not been designed specifically for the purpose of This mechanism has not been designed specifically for the purpose of
damping multicast state, but as a means to allow PIM to operate on damping multicast state, but as a means to allow PIM to operate on
multi-access networks. See [RFC4601] section 4.3.3. However, when multi-access networks. See [RFC4601] section 4.3.3. However, when
active, this mechanism will prevent a downstream router to produce active, this mechanism will prevent a downstream router to produce
multicast routing protocol messages that would cause, for a said multicast routing protocol messages that would cause, for a said
multicast state, the upstream router to send to its own multicast state, the upstream router to send to its own upstream
upstreamrouter, multicast routing protocol messages at a rate higher router, multicast routing protocol messages at a rate higher than
than 1/[prune override interval], thus providing de-facto a form of 1/[prune override interval]. This provides de-facto a form of
damping. damping.
Similarly, the IGMP and MLD multicast membership control protocols Similarly, the IGMP and MLD multicast membership control protocols
can provide a similar behavior, under the right conditions. can provide a similar behavior, under the right conditions.
These mechanisms are not considered suitable to meet the goals These mechanisms are not considered suitable to meet the goals
spelled out in Section 1, the main reasons being that: spelled out in Section 1, the main reasons being that:
o when enabled these mechanisms require additional bandwidth on the o when enabled these mechanisms require additional bandwidth on the
local link on which the effect of a Prune is delayed (in our case local link on which the effect of a prune is delayed (in our case
the PE-CE link) the PE-CE link)
o when enabled these mechanisms require disabling explicit tracking, o when enabled these mechanisms require disabling explicit tracking,
even though enabling this feature may otherwise be desired even though enabling this feature may otherwise be desired
o on certain implementations, these mechanisms are incompatible with o on certain implementations, these mechanisms are incompatible with
behavior that cannot be turned off behavior that cannot be turned off (e.g. implementation applying a
fast-leave behavior on interfaces with only two neighbors)
o they do not provide a suitable level of configurability o they do not provide a suitable level of configurability
o they do not provide a way to discriminate between multicast flows o they do not provide a way to discriminate between multicast flows
based on estimation of their dynamicity based on estimation of their dynamicity
4.3. BGP Route Damping 4.3. BGP Route Damping
The procedures defined in [RFC2439] and [RFC7196] for BGP route flap The procedures defined in [RFC2439] and [RFC7196] for BGP route flap
damping are useful for operators who want to control the impact of damping are useful for operators who want to control the impact of
skipping to change at page 6, line 23 skipping to change at page 6, line 27
relying on rate-limiting of multicast control protocol exchanges (as relying on rate-limiting of multicast control protocol exchanges (as
exposed in Section 4.1) or on the use of existing PIM/IGMP timers (as exposed in Section 4.1) or on the use of existing PIM/IGMP timers (as
exposed in Section 4.2). exposed in Section 4.2).
5. Procedures for multicast state damping 5. Procedures for multicast state damping
5.1. PIM procedures 5.1. PIM procedures
This section describes procedures for multicast state damping This section describes procedures for multicast state damping
satisfying the goals spelled out in Section 1. This section spells satisfying the goals spelled out in Section 1. This section spells
out procedures for (S,G) states in the PIM-SM protocol ([RFC4601] ; out procedures for (S,G) states in the PIM-SM protocol [RFC4601] ;
they apply unchanged for such states created based on multicast group they apply unchanged for such states created based on multicast group
management protocols (IGMP [RFC3376], MLD [RFC3810]) on downstream management protocols (IGMP [RFC3376], MLD [RFC3810]) on downstream
interfaces. The same procedures are applied to (*,G) states in the 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) context of PIM-SM ASM groups (damping is not applied to (S,G,Rpt)
Prune state). Prune state).
The following notions introduced in [RFC2439] are reused in these The following notions introduced in [RFC2439] are reused in these
procedures: procedures:
figure-of-merit: a number reflecting the current estimation of past figure-of-merit: a number reflecting the current estimation of past
recent activity of an (S,G) multicast routing state, which evolves recent activity of an (S,G) multicast routing state, which evolves
based on routing events related to this state and based an based on routing events related to this state and based an
exponential decay algorithm ; the activation or inactivation of exponential decay algorithm ; the activation or inactivation of
damping on the state is based on this number ; this number is damping on the state is based on this number ; this number is
associated to the upstream state machine for (S,G) associated to the upstream state machine for (S,G) and is
initialized to a value of zero on state creation
cutoff-threshold: value of the *figure-of-merit* over which damping cutoff-threshold: value of the *figure-of-merit* over which damping
is applied (configurable parameter) is applied (configurable parameter)
reuse-threshold: value of the *figure-of-merit* under which damping reuse-threshold: value of the *figure-of-merit* under which damping
stops being applied (configurable parameter) stops being applied (configurable parameter)
decay-half-life: period of time used to control how fast is the decay-half-life: period of time used to control how fast is the
exponential decay of the *figure-of-merit* (configurable exponential decay of the *figure-of-merit* (configurable
parameter) parameter)
Additionally to these values, a configurable "*increment-factor*" Additionally to these values, a configurable "*increment-factor*"
parameter is introduced, that controls by how much the *figure-of- parameter is introduced, that controls by how much the *figure-of-
merit* is incremented on multicast state update events. merit* is incremented on multicast state update events.
Section Section 7.3 proposes default and maximum values for the Section 7.3 proposes default and maximum values for the configurable
configurable parameters. parameters.
On reception of updated multicast membership or routing information On reception of updated multicast membership or routing information
on a downstream interface I for a said (S,G) state, that results in a 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 section change of the state of the PIM downstream state machine (see section
4.5.3 of [RFC4601]), a router implementing these procedures MUST: 4.5.3 of [RFC4601]), a router implementing these procedures MUST:
o apply unchanged procedures for everything relating to what o apply unchanged procedures for everything relating to what
multicast traffic ends up being sent on downstream interfaces, multicast traffic ends up being sent on downstream interfaces,
including interface I including interface I
o increasing the *figure-of-merit* for the (S,G) by the *increment- o increasing the *figure-of-merit* for the (S,G) by the *increment-
factor* (updating the *figure-of-merit* based on the decay factor* (updating the *figure-of-merit* based on the decay
algorithm must be done prior to this increment) algorithm must be done prior to this increment)
o update the damping state for the (S,G) state: damping becomes o update the damping state for the (S,G) state: damping becomes
active on the state if the recomputed *figure-of-merit* is above active on the state if the recomputed *figure-of-merit* is
the configured *cutoff-threshold* strictly above the configured *cutoff-threshold*
o if damping is inactive on (S,G) state, update the upstream state * if damping remains inactive on (S,G) state, update the upstream
machine as usual (as per section 4.5.7 of [RFC4601]) state machine as usual (as per section 4.5.7 of [RFC4601])
o if damping becomes active for the (S,G) state: * if damping becomes active for the (S,G) state:
* if the received message has caused the upstream state machine + if the received message has caused the upstream state
to transition to Joined state, update the upstream state machine to transition to Joined state, update the upstream
machine for (S,G) (applying usual PIM procedures in section state machine for (S,G) (applying usual PIM procedures in
4.5.7 of [RFC4601], including sending a PIM Join to the section 4.5.7 of [RFC4601], including sending a PIM Join to
upstream neighbor) the upstream neighbor)
* if the received message has caused the upstream state machine + if the received message has caused the upstream state
to transition to NotJoined state, do not update the upstream machine to transition to NotJoined state, do not update the
state machine for (S,G) upstream state machine for (S,G)
* then freeze the upstream state machine in Joined state, and and + then freeze the upstream state machine in Joined state, and
setup a trigger to update it once damping later becomes setup a trigger to update it once damping later becomes
inactive again. The effect is that in the meantime, PIM Join inactive again. The effect is that in the meantime, PIM
messages will be sent as refreshes to the upstream neighbor, Join messages will be sent as refreshes to the upstream
but no PIM Prune message will be sent. neighbor, but no PIM Prune message will be sent.
o if damping was already active: do not update the upstream state * if damping was already active: do not update the upstream state
machine for (S,G) (the upstream state machine was frozen after machine for (S,G) (the upstream state machine was frozen after
processing the previous message) processing the previous message)
Once the *figure-of-merit* for (S,G) damping state decays to a value Once the *figure-of-merit* for (S,G) damping state decays to a value
below the configured *reuse-threshold*, the upstream state machine strictly below the configured *reuse-threshold*, the upstream state
for (S,G) is recomputed based on states of downstream state machines, machine for (S,G) is recomputed based on states of downstream state
eventually leading to a PIM Join or Prune message to be sent to the machines, eventually leading to a PIM Join or Prune message to be
upstream neighbor. sent to the upstream neighbor.
Same techniques as the ones described in [RFC2439] can be applied to Same techniques as the ones described in [RFC2439] can be applied to
determine when the figure-of-merit value is recomputed based on the determine when the *figure-of-merit* value is recomputed based on the
exponential decay algorithm and the configured *decay-half-life*. exponential decay algorithm and the configured *decay-half-life*.
Given the specificity of multicast applications, it is REQUIRED for Given the specificity of multicast applications, it is REQUIRED for
the implementation to let the operator configure the *decay-half- the implementation to let the operator configure the *decay-half-
life* in seconds, rather than in minutes. When the recomputation is life* in seconds, rather than in minutes. When the recomputation is
done periodically, the period should be low enough to not done periodically, the period should be low enough to not
significantly delay the inactivation of damping on a multicast state significantly delay the inactivation of damping on a multicast state
beyond what the operator wanted to configure (i.e. for a half-life of beyond what the operator wanted to configure (i.e. for a *decay-half-
10s, recomputing the *figure-of-merit* each minute would result in a life* of 10s, recomputing the *figure-of-merit* each minute would
multicast state to remained damped for a much longer time than what result in a multicast state to remained damped for a much longer time
the parameters are supposed to command). than what the parameters are supposed to command).
PIM implementations typically follow [RFC4601] suggestion that PIM implementations typically follow [RFC4601] suggestion that
"implementations will only maintain state when it is relevant to "implementations will only maintain state when it is relevant to
forwarding operations - for example, the 'NoInfo' state might be forwarding operations - for example, the 'NoInfo' state might be
assumed from the lack of other state information, rather than being assumed from the lack of other state information, rather than being
held explicitly" (Section 4.1 of [RFC4601]). To properly implement held explicitly" (Section 4.1 of [RFC4601]). To properly implement
implement damping procedures, an implementation MUST keep an explicit damping procedures, an implementation MUST keep an explicit (S,G)
(S,G) state as long as damping is active on an (S,G). Once an (S,G) state as long as damping is active on an (S,G). Once an (S,G) state
state expires, and damping becomes inactive on this state, its expires, and damping becomes inactive on this state, its associated
associated *figure-of-merit* and damping state are removed as well. *figure-of-merit* and damping state are removed as well.
Note that these procedures: Note that these procedures:
o do not impact PIM procedures related to refreshes or expiration of o do not impact PIM procedures related to refreshes or expiration of
multicast routing states: PIM Prune messages triggered by the multicast routing states: PIM Prune messages triggered by the
expiration of the (S,G) keep-alive timer, are not suppressed or expiration of the (S,G) keep-alive timer, are not suppressed or
delayed, and the reception of Join messages not causing transition delayed, and the reception of Join messages not causing transition
of state on the downstream interface does not lead to incrementing of state on the downstream interface does not lead to incrementing
the *figure-of-merit*; the *figure-of-merit*;
skipping to change at page 9, line 14 skipping to change at page 9, line 17
o do not impact PIM Prune messages that are sent in the context of o do not impact PIM Prune messages that are sent in the context of
switching between a Rendez-vous Point Tree and a Shortest Path switching between a Rendez-vous Point Tree and a Shortest Path
Tree. Tree.
Note also that no action is triggered based on the reception of PIM Note also that no action is triggered based on the reception of PIM
Prune messages (or corresponding IGMP/MLD messages) that relate to Prune messages (or corresponding IGMP/MLD messages) that relate to
non-existing (S,G) state, in particular, no *figure-of-merit* or non-existing (S,G) state, in particular, no *figure-of-merit* or
damping state is created in this case. damping state is created in this case.
5.2. Procedures for multicast VPN state dampening 5.2. Procedures for multicast VPN state damping
The procedures described in Section 5.1 can be applied in the VRF The procedures described in Section 5.1 can be applied in the VRF
PIM-SM implementation (in the "C-PIM instance"), with the PIM-SM implementation (in the "C-PIM instance"), with the
corresponding action to suppressing the emission of a Prune(S,G) corresponding action to suppressing the emission of a Prune(S,G)
message being to not withdraw the C-multicast Source Tree Join message being to not withdraw the C-multicast Source Tree Join
(C-S,C-G) BGP route. Implementation of [RFC6513] relying on the use (C-S,C-G) BGP route. Implementation of [RFC6513] relying on the use
of PIM to carry C-multicast routing information MUST support this of PIM to carry C-multicast routing information MUST support this
technique. technique.
In the context of [RFC6514] where BGP is used to distribute In the context of [RFC6514] where BGP is used to distribute
C-multicast routing information, the following procedure is proposed C-multicast routing information, the following procedure is proposed
as an alternative and consists in applying damping in the BGP as an alternative to the procedures in Section 5.1 and consists in
implementation, based on existing BGP damping mechanism, applied to applying damping in the BGP implementation, based on existing BGP
C-multicast Source Tree Join routes and Shared Tree Join routes (and damping mechanism, applied to C-multicast Source Tree Join routes and
as well to Leaf A-D routes - see Section 6), and modified to Shared Tree Join routes (and as well to Leaf A-D routes - see
implement the behavior described in Section 3 along the following Section 6), and modified to implement the behavior described in
guidelines: Section 3 along the following guidelines:
o not withdrawing (instead of not advertising) damped routes o not withdrawing (instead of not advertising) damped routes
o providing means to configure the half-life in seconds if that o providing means to configure the decay-half-life in seconds if
option is not already available that option is not already available
o using parameters for the exponential decay that are specific to o using parameters for the exponential decay that are specific to
multicast, based on default values and multicast specific multicast, based on default values and multicast specific
configuration configuration
While these procedures would typically be implemented on PE routers, While these procedures would typically be implemented on PE routers,
in a context where BGP Route Reflectors are used it can be considered in a context where BGP Route Reflectors (RRs) are used it can be
useful to also be able to apply damping on RRs as well. considered useful to also be able to apply damping on RRs as well.
Additionally, for mVPN Inter-AS deployments, it can be needed to Additionally, for mVPN Inter-AS deployments, it can be needed to
protect one AS from the dynamicity of multicast VPN routing events protect one AS from the dynamicity of multicast VPN routing events
from other ASes. In that perspective, it is RECOMMENDED for from other ASes.
implementations to support damping mVPN C-multicast routes directly
into BGP, without relying on the PIM-SM state machine. The choice to implement damping based on BGP routes or the procedures
described in Section 5, 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.
When not all routers in a deployment have the capability to drop When not all routers in a deployment have the capability to drop
traffic coming from the wrong PE (as spelled out in section 9.1.1 of traffic coming from the wrong PE (as spelled out in section 9.1.1 of
[RFC6513]), then the withdrawal of a C-multicast route resulting from [RFC6513]), then the withdrawal of a C-multicast route resulting from
a change in the UMH SHOULD NOT be damped. An implementation of these a change in the Upstream Multicast Hop or Upstream Multicast PE
specs MUST whether, not damp these withdrawals by default, or SHOULD NOT be damped. An implementation of the specification in this
alternatively provide a tuning knob to disable then damping of these 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 withdrawals. Additionally, in such a context, it is RECOMMENDED to
*not* enable any multicast VPN route damping on RRs and ASBRs, since not enable any multicast VPN route damping on RRs and ASBRs, since
these equipments cannot distinguish these events. these equipments cannot distinguish these events.
The choice to implement damping based on BGP routes or the procedures
described in Section 5, 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.
Note well that damping SHOULD NOT be applied to BGP routes of the 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 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". A-D Route", "S-PMSI A-D Route", and "Source Active A-D Route".
6. Procedures for P-tunnel state damping 6. Procedures for P-tunnel state damping
6.1. Damping mVPN P-tunnel change events 6.1. Damping mVPN P-tunnel change events
When selective P-tunnels are used (see section 7 of [RFC6513]), the When selective P-tunnels are used (see section 7 of [RFC6513]), the
effect of updating the upstream state machine for a said (C-S,C-G) effect of updating the upstream state machine for a said (C-S,C-G)
skipping to change at page 11, line 6 skipping to change at page 11, line 8
The following is proposed as example of how the above can be The following is proposed as example of how the above can be
achieved. achieved.
o For P-tunnels implemented with the PIM protocol, this consists in o For P-tunnels implemented with the PIM protocol, this consists in
applying multicast state damping techniques described in applying multicast state damping techniques described in
Section 5.1 to the P-PIM instance, at least for (S,G) states Section 5.1 to the P-PIM instance, at least for (S,G) states
corresponding to P-tunnels. corresponding to P-tunnels.
o For P-tunnels implemented with the mLDP protocol, this consists in o For P-tunnels implemented with the mLDP protocol, this consists in
applying damping techniques completely similar as the one applying damping techniques completely similar to the one
described in Section 5, but generalized to apply to mLDP states described in Section 5, but generalized to apply to mLDP states
o For root-initiated P-tunnels (P-tunnels implemented with the P2MP o For root-initiated P-tunnels (P-tunnels implemented with the P2MP
RSVP-TE, or relying on ingress replication), no particular action RSVP-TE, or relying on ingress replication), no particular action
needs to be implemented to damp P-tunnels membership, if the needs to be implemented to damp P-tunnels membership, if the
activity of Leaf A-D route themselves is damped activity of Leaf A-D route themselves is damped
o Another possibility is to base the decision to join or not join o 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 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 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 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 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) the C-PIM Upstream state machine for (C-S,C-G)
6.2. Procedures for Ethernet VPNs 6.2. Procedures for Ethernet VPNs
Specifications exists to support or optimize multicast and broadcast Specifications exist to support or optimize multicast and broadcast
in the context of Ethernet VPNs [RFC7117], relying on the use of in the context of Ethernet VPNs [RFC7117], relying on the use of
S-PMSI and P-tunnels. For the same reasons as for IP multicast VPNs, S-PMSI and P-tunnels. For the same reasons as for IP multicast VPNs,
an implementation of these procedures MUST follow the procedures an implementation of these procedures MUST follow the procedures
described in this section.Section 6.1. described in Section 6.1.
7. Operational considerations 7. Operational considerations
7.1. Enabling and configuring multicast damping 7.1. Enabling multicast damping
In the context of multicast VPNs, these procedures would be enabled In the context of multicast VPNs, these procedures would be enabled
on PE routers. Additionally in the case of C-multicast routing based on PE routers. Additionally in the case of C-multicast routing based
on BGP extensions ([RFC6514]) these procedures can be enabled on on BGP extensions ([RFC6514]) these procedures can be enabled on
ASBRs, and possibly Route Reflectors as well. ASBRs and Route Reflectors.
7.2. Troubleshooting and monitoring 7.2. Troubleshooting and monitoring
Implementing the damping mechanisms described in this document should Implementing the damping mechanisms described in this document should
be complemented by appropriate tools to observe and troubleshoot be complemented by appropriate tools to observe and troubleshoot
damping activity. damping activity.
More specifically it is RECOMMENDED to complement the existing More specifically it is RECOMMENDED to complement the existing
interface providing information on multicast states with information interface providing information on multicast states with information
on eventual damping of corresponding states (e.g. MRIB states): on eventual damping of corresponding states (e.g. MRIB states):
skipping to change at page 12, line 21 skipping to change at page 12, line 21
o cutoff-threshold: 3000 o cutoff-threshold: 3000
o decay-half-life: 10s o decay-half-life: 10s
o reuse-threshold: 1500 o reuse-threshold: 1500
For unicast damping, it is common to set an upper bound to the time 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 during which a route is suppressed. In the case of multicast state
damping, which relies on not withdrawing a damped route, it may be damping, which relies on not withdrawing a damped route, it may be
desirable to avoid a situation were a multicast flow would keep 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 flowing in a portion of the network for a very large time in the
absence of receivers. absence of receivers.
The proposed default maximum value for the figure-of-merit is The proposed default maximum value for the figure-of-merit is
20x<increment-factor>, i.e. 20000 with the proposed default 20x<increment-factor>, i.e. 20000 with the proposed default
increment-factor of 1000. increment-factor of 1000.
The following values are proposed as maximums: The following values are proposed as maxima:
o decay half-life: 60s o decay-half-life: 60s
o cutoff-threshold: 50000 o cutoff-threshold: 50000
8. IANA Considerations 8. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an Note to RFC Editor: this section may be removed on publication as an
RFC. RFC.
 End of changes. 46 change blocks. 
111 lines changed or deleted 114 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/