draft-ietf-bess-multicast-damping-02.txt   draft-ietf-bess-multicast-damping-03.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: June 20, 2016 K. Patel Expires: July 8, 2016 K. Patel
Cisco Systems Cisco Systems
Z. Zhang Z. Zhang
R. Kebler R. Kebler
J. Haas J. Haas
Juniper Networks Juniper Networks
December 18, 2015 January 05, 2016
Multicast VPN state damping Multicast VPN state damping
draft-ietf-bess-multicast-damping-02 draft-ietf-bess-multicast-damping-03
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 June 20, 2016. This Internet-Draft will expire on July 8, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 50 skipping to change at page 2, line 50
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
1. Introduction 1. Introduction
In a multicast VPN [RFC6513] deployed with BGP-based procedures In a multicast VPN [RFC6513] deployed with BGP-based procedures
[RFC6514], when receivers in VPN sites join and leave a said [RFC6514], when receivers in VPN sites join and leave a given
multicast group or channel through multicast membership control multicast group or channel through multicast membership control
protocols (IGMP, MLD), multicast routing protocols accordingly adjust protocols (IGMP, MLD), multicast routing protocols accordingly adjust
multicast routing states and P-multicast tree states, to forward or multicast routing states and P-multicast tree states, to forward or
prune multicast traffic to these receivers. prune multicast traffic to these receivers.
In VPN contexts, providing isolation between customers of a shared In VPN contexts, providing isolation between customers of a shared
infrastructure is a core requirement resulting in stringent infrastructure is a core requirement resulting in stringent
expectations with regards to risks of denial of service attacks. expectations with regards to risks of denial of service attacks.
Hence, mechanisms need to be put in place to ensure that the load put 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, on the BGP control plane, and on the P-tunnel setup control plane,
skipping to change at page 4, line 17 skipping to change at page 4, line 17
states changes that it solicits to its PE will be honored without any states changes that it solicits to its PE will be honored without any
additional delay. Indeed the propagation of joins is not impacted by additional delay. Indeed the propagation of joins is not impacted by
the procedures specified here, and having the upstream router delay the procedures specified here, and having the upstream router delay
state prune propagation to its own upstream router does not affect state prune propagation to its own upstream router does not affect
what traffic is sent to the downstream router. In particular, the what traffic is sent to the downstream router. In particular, the
amount of bandwidth used on the PE-CE link downstream to a PE amount of bandwidth used on the PE-CE link downstream to a PE
applying this damping 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 given 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, means are required to control when damping is triggered, particular, means are required to control when damping is triggered,
and to allow delaying a multicast state Prune for a time increasing and to allow delaying the pruning of a multicast state for a time
with the churn of this multicast state. This will allow control the increasing with the churn of this multicast state. This will let the
tradeoff made between minimizing the dynamicity and reducing operator control the tradeoff made between minimizing the dynamicity
bandwidth consumption. 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
PIM-SM specifications [RFC4609] examine multicast security threats PIM-SM specifications [RFC4609] examine multicast security threats
skipping to change at page 5, line 11 skipping to change at page 5, line 11
mechanism exists that may offer a form of de-facto damping of mechanism exists that may offer a form of de-facto damping of
multicast states, under some conditions. 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 given
multicast state, the upstream router to send to its own upstream multicast state, the upstream router to send to its own upstream
router, multicast routing protocol messages at a rate higher than router, multicast routing protocol messages at a rate higher than
1/[prune override interval]. This provides 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 (e.g. implementation applying a behaviors that cannot be turned off (e.g. implementation applying
fast-leave behavior on interfaces with only two neighbors) 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 7, line 9 skipping to change at page 7, line 9
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 7.3 proposes default and maximum values for the configurable Section 7.3 proposes default and maximum values for the 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 given (S,G) state, that results in
change of the state of the PIM downstream state machine (see section a change of the state of the PIM downstream state machine (see
4.5.3 of [RFC4601]), a router implementing these procedures MUST: section 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
skipping to change at page 9, line 6 skipping to change at page 9, line 10
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*;
o do not impact the PIM assert mechanism, in particular PIM Prune o do not impact the PIM assert mechanism, in particular PIM Prune
messages triggered by a change of the PIM assert winner on the messages triggered by a change of the PIM assert winner on the
upstream interface, are not suppressed or delayed; upstream interface, are not suppressed or delayed;
o do not impact PIM Prune messages that are sent when the RPF o do not impact PIM Prune messages that are sent when the RPF
neighbor is updated for a said multicast flow; neighbor is updated for a given multicast flow;
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.
skipping to change at page 9, line 38 skipping to change at page 9, line 42
C-multicast routing information, the following procedure is proposed C-multicast routing information, the following procedure is proposed
as an alternative to the procedures in Section 5.1 and consists in as an alternative to the procedures in Section 5.1 and consists in
applying damping in the BGP implementation, based on existing BGP applying damping in the BGP implementation, based on existing BGP
damping mechanism, applied to C-multicast Source Tree Join routes and damping mechanism, applied to C-multicast Source Tree Join routes and
Shared Tree Join routes (and as well to Leaf A-D routes - see Shared Tree Join routes (and as well to Leaf A-D routes - see
Section 6), and modified to implement the behavior described in Section 6), and modified to implement the behavior described in
Section 3 along the following 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 decay-half-life in seconds if o providing means to configure the *decay-half-life* in seconds if
that 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 (RRs) are used it can be 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. 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
skipping to change at page 10, line 31 skipping to change at page 10, line 33
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 given (C-S,C-G)
state on a PE connected to multicast receivers, is not only to state on a PE connected to multicast receivers, is not only to
generate activity to propagate C-multicast routing information to the generate activity to propagate C-multicast routing information to the
source connected PE, but also to possibly trigger changes related to source connected PE, but also to possibly trigger changes related to
the P-tunnels carrying (C-S,C-G) traffic. Protecting the provider 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 network from an excessive amount of change in the state of P-tunnels
is required, and this section details how this can be done. is required, and this section details how this can be done.
A PE implementing these procedures for mVPN MUST damp Leaf A-D 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 routes, in the same manner as it would for C-multicast routes (see
Section 5.2). Section 5.2).
skipping to change at page 11, line 17 skipping to change at page 11, line 20
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 to 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 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 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 exist 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,
skipping to change at page 12, line 10 skipping to change at page 12, line 10
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):
C-multicast routing states and P-tunnel states. C-multicast routing states and P-tunnel states.
7.3. Default and maximum values 7.3. Default and maximum values
The following values are RECOMMENDED to adopt as default conservative The following values are RECOMMENDED to adopt as default conservative
values: values:
o increment-factor: 1000 o *increment-factor*: 1000
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 where 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 maxima: 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.
9. Security Considerations 9. Security Considerations
skipping to change at page 13, line 47 skipping to change at page 13, line 47
the period of time that elapses between the reception of Join/Prune the period of time that elapses between the reception of Join/Prune
messages triggering the activation of damping on these states and messages triggering the activation of damping on these states and
when damping becomes inactive after decay. when damping becomes inactive after decay.
10. Acknowledgements 10. Acknowledgements
We would like to thank Bruno Decraene and Lenny Giuliano for We would like to thank Bruno Decraene and Lenny Giuliano for
discussions that helped shape this proposal. We would also like to discussions that helped shape this proposal. We would also like to
thank Yakov Rekhter and Eric Rosen for their reviews and helpful thank Yakov Rekhter and Eric Rosen for their reviews and helpful
comments. Thanks to Wim Henderickx for his comments and support of comments. Thanks to Wim Henderickx for his comments and support of
this proposal. this proposal, and Martin Vigoureux and Gunter Van De Velde for their
reviews.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route [RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route
Flap Damping", RFC 2439, November 1998. Flap Damping", RFC 2439, November 1998.
 End of changes. 24 change blocks. 
32 lines changed or deleted 34 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/