draft-ietf-bess-multicast-damping-00.txt   draft-ietf-bess-multicast-damping-01.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: August 14, 2015 K. Patel Expires: February 4, 2016 K. Patel
Cisco Systems Cisco Systems
J. Zhang Z. Zhang
R. Kebler R. Kebler
J. Haas J. Haas
Juniper Networks Juniper Networks
February 10, 2015 August 03, 2015
Multicast VPN state damping Multicast VPN state damping
draft-ietf-bess-multicast-damping-00 draft-ietf-bess-multicast-damping-01
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 August 14, 2015. This Internet-Draft will expire on February 4, 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 38 skipping to change at page 2, line 38
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 dampening . . . . . . 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 and configuring multicast damping . . . . . . . 11
7.2. Troubleshooting and monitoring . . . . . . . . . . . . . 11 7.2. Troubleshooting and monitoring . . . . . . . . . . . . . 11
7.3. Default and maximum values . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . 13 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 said
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
skipping to change at page 3, line 38 skipping to change at page 3, line 38
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 provide 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
TBC 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 allows the network operator
to configure multicast VPN PEs so that they can delay the propagation to configure multicast VPN PEs so that they can delay the propagation
of multicast state prune messages, when faced with a rate of of multicast state prune messages, when faced with a rate of
multicast state dynamicity exceeding a certain configurable multicast state dynamicity exceeding a certain configurable
threshold. Assuming that the number of multicast states that can be threshold. Assuming that the number of multicast states that can be
created by a receiver is bounded, delaying the propagation of created by a receiver is bounded, delaying the propagation of
multicast state pruning results in setting up an upper bound to the multicast state pruning results in setting up an upper bound to the
skipping to change at page 4, line 41 skipping to change at page 4, line 41
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 [RFC4609] examines multicast security threats and among other things
the risk described in Section 1. A mechanism relying on rate- the risk described in Section 1. A mechanism relying on rate-
limiting PIM messages is proposed in section 5.3.3 [RFC4609], but has limiting PIM messages is proposed in section 5.3.3 of [RFC4609], but
the identified drawbacks of impacting the service delivered and has the identified drawbacks of impacting the service delivered and
having side-effects on legitimate users. 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 in some context may offer a form of de facto
damping mechanism for multicast states. Indeed, when active, the damping mechanism for multicast states. 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.
skipping to change at page 6, line 13 skipping to change at page 6, line 13
reason being that a damped route becomes suppressed, while the reason being that a damped route becomes suppressed, while the
target behavior would be to keep advertising when damping is target behavior would be to keep advertising when damping is
triggered on a multicast route triggered on a multicast route
However, the set of parameters standardized to control the thresholds However, the set of parameters standardized to control the thresholds
of the exponential decay mechanism can be relevantly reused. This is of the exponential decay mechanism can be relevantly reused. This is
the approach proposed for the procedures described in this document the approach proposed for the procedures described in this document
(Section 5). Motivations for doing so is to help the network (Section 5). Motivations for doing so is to help the network
operator deploy this feature based on consistent configuration operator deploy this feature based on consistent configuration
parameter, and obtain predictable results, without the drawbacks of parameter, and obtain predictable results, without the drawbacks of
exposed in Section 4.1 and Section 4.2. 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.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
skipping to change at page 15, line 4 skipping to change at page 15, line 17
Lannion 22307 Lannion 22307
France France
Email: thomas.morin@orange.com Email: thomas.morin@orange.com
Stephane Litkowski Stephane Litkowski
Orange Orange
France France
Email: stephane.litkowski@orange.com Email: stephane.litkowski@orange.com
Keyur Patel Keyur Patel
Cisco Systems Cisco Systems
170 W. Tasman Drive 170 W. Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: keyupate@cisco.com Email: keyupate@cisco.com
Jeffrey (Zhaohui) Zhang Zhaohui Zhang
Juniper Networks Inc. Juniper Networks Inc.
10 Technology Park Drive 10 Technology Park Drive
Westford, MA 01886 Westford, MA 01886
USA USA
Email: zzhang@juniper.net Email: zzhang@juniper.net
Robert Kebler Robert Kebler
Juniper Networks Inc. Juniper Networks Inc.
10 Technology Park Drive 10 Technology Park Drive
 End of changes. 12 change blocks. 
13 lines changed or deleted 16 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/