draft-ietf-bess-multicast-damping-04.txt   draft-ietf-bess-multicast-damping-05.txt 
Network Working Group T. Morin, Ed. Network Working Group T. Morin, Ed.
Internet-Draft S. Litkowski Internet-Draft S. Litkowski
Updates: 6514 (if approved) Orange Updates: 6514 (if approved) Orange
Intended status: Standards Track K. Patel Intended status: Standards Track K. Patel
Expires: September 17, 2016 Cisco Systems Expires: November 5, 2016 Cisco Systems
Z. Zhang Z. Zhang
R. Kebler R. Kebler
J. Haas J. Haas
Juniper Networks Juniper Networks
March 16, 2016 May 04, 2016
Multicast VPN state damping Multicast VPN state damping
draft-ietf-bess-multicast-damping-04 draft-ietf-bess-multicast-damping-05
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 sites. The procedures described in multicast dynamicity in customer sites. 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 September 17, 2016. This Internet-Draft will expire on November 5, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
skipping to change at page 3, line 37 skipping to change at page 3, line 37
devices), although at the expense of a minimal increase of average devices), although at the expense of a minimal increase of average
bandwidth use in the provider network. The upper bound to the bandwidth use in the provider network. The upper bound to the
control plane load due to the processing of a given multicast state, control plane load due to the processing of a given multicast state,
is controlled indirectly via configurable parameters. is controlled indirectly via configurable parameters.
Section 16 of [RFC6514] specifically spells out the need for damping Section 16 of [RFC6514] specifically spells out the need for damping
the activity of C-multicast and Leaf Auto-discovery routes, and the activity of C-multicast and Leaf Auto-discovery routes, and
outlines how to do it by "delaying the advertisement of withdrawals outlines how to do it by "delaying the advertisement of withdrawals
of C-multicast routes". This specification provides appropriate of C-multicast routes". This specification provides appropriate
detail on how to implement this approach and how to provide control detail on how to implement this approach and how to provide control
to the operator, and for this reason, in an update to [RFC6514]. to the operator, and for this reason, is an update to [RFC6514].
The base principle of this specification is described in Section 3. The base principle of this specification is described in Section 3.
Existing mechanisms that could be relied upon are discussed in Existing mechanisms that could be relied upon are discussed in
Section 4. Section 5 details the procedures introduced by this Section 4. Section 5 details the procedures introduced by this
specification. specification.
Section 6 provides 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
skipping to change at page 4, line 41 skipping to change at page 4, line 41
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 given 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 meet the goals of protecting the multicast routing
routing infrastructure control plane without a significant average infrastructure control plane without a significant average increase
increase of bandwidth; for instance, damping events happening at a of bandwidth; for instance, damping events happening at a frequency
frequency higher than one event per X second, can be done without higher than one event per X second, can be done without increasing by
increasing by more than X second the time during which a multicast more than X second the time during which a multicast flow is present
flow is present on a link. on a link.
That said, simulation of the exponential decay algorithm show that That said, simulation of the exponential decay algorithm show that
the multicast state churn can be drastically reduced without the multicast state churn can be drastically reduced without
significantly increasing the duration for which multicast traffic is significantly increasing the duration for which multicast traffic is
forwarded. Hence, using this technique will efficiently protect the forwarded. Hence, using this technique will efficiently protect the
multicast routing infrastructure control plane against the issues multicast routing infrastructure control plane against the issues
described here, without a significant average increase of bandwidth. described here, without a significant average increase of bandwidth.
The exception will be a scenario with strict constraints on multicast The exception will be a scenario with strict constraints on multicast
bandwidth, where extending the time a multicast flow is forwarded bandwidth, where extending the time a multicast flow is forwarded
would result in congestion. would result in congestion.
skipping to change at page 12, line 49 skipping to change at page 12, line 49
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 Route Reflectors. 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 Complementing the existing interface providing information on
interface providing information on multicast states with information multicast states with information on eventual damping of
on eventual damping of corresponding states (e.g. MRIB states): corresponding states (e.g. MRIB states) is RECOMMENDED: C-multicast
C-multicast routing states and P-tunnel states. routing states and P-tunnel states.
7.3. Default and maximum values 7.3. Default and maximum values
Considering that, by design multicast streams will be delivered Considering that, by design multicast streams will be delivered
unchanged to the end user, independently of the value chosen for the unchanged to the end user, independently of the value chosen for the
configurable parameters, and that the only trade-off being made is an configurable parameters, and that the only trade-off being made is an
increase of bandwidth use, the default and maximum values do not have increase of bandwidth use, the default and maximum values do not have
to be perfectly tuned. to be perfectly tuned.
This section proposes default and maximum values, conservative so as This section proposes default and maximum values, conservative so as
to not significantly impact network dimentioning but still prevent to not significantly impact network dimensioning but still prevent
multicast state churn to go beyond what can be considered a multicast state churn going beyond what can be considered a
reasonably low churn for a multicast state (see below for reasonably low churn for a multicast state (see below for
illustrations in order of magnitude of the effect of these values). illustrations in order of magnitude of the effect of these values).
The following values are RECOMMENDED to adopt as default values: The following values are RECOMMENDED to adopt as default 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
skipping to change at page 14, line 51 skipping to change at page 14, line 51
protocols and the components responsible for updating the multicast protocols and the components responsible for updating the multicast
forwarding plane. forwarding plane.
The procedures describe are meant to provide some level of protection The procedures describe are meant to provide some level of protection
for the router on which they are enabled by reducing the amount of 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 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 or peers, but do not provide any reduction of the control plane load
related to processing routing information from downstream neighbors. related to processing routing information from downstream neighbors.
Protecting routers from an increase in control plane load due to Protecting routers from an increase in control plane load due to
activity on downstream interfaces toward core routers (or in the activity on downstream interfaces toward core routers (or in the
context of BGP-based mVPN C-multicast routing, BGP peers) shall rely context of BGP-based mVPN C-multicast routing, BGP peers) relies on
upon the activation of damping on corresponding downstream neighbors the activation of damping on corresponding downstream neighbors (or
(or BGP peers) and/or at the edge of the network. Protecting routers BGP peers) and/or at the edge of the network. Protecting routers
from an increase in control plane load due to activity on customer- from an increase in control plane load due to activity on customer-
facing downstream interfaces or downstream interfaces to routers in facing downstream interfaces or downstream interfaces to routers in
another administrative domain, is out of the scope of this document another administrative domain, is out of the scope of this document
and should rely upon already defined mechanisms (see [RFC4609]). and should use already defined mechanisms (see [RFC4609]).
To be effective the procedures described here must be complemented by To be effective the procedures described here must be complemented by
configuration limiting the number of multicast states that can be configuration limiting the number of multicast states that can be
created on a multicast router through protocol interactions with created on a multicast router through protocol interactions with
multicast receivers, neighbor routers in adjacent ASes, or in multicast receivers, neighbor routers in adjacent ASes, or in
multicast VPN contexts with multicast CEs. Note well that the two multicast VPN contexts with multicast CEs. Note well that the two
mechanism may interact: state for which Prune has been requested may mechanism may interact: state for which Prune has been requested may
still remain taken into account for some time if damping has been still remain taken into account for some time if damping has been
triggered and hence result in otherwise acceptable new state from triggered and hence result in otherwise acceptable new state from
being successfully created. being successfully created.
 End of changes. 10 change blocks. 
21 lines changed or deleted 21 lines changed or added

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