draft-ietf-bess-multicast-damping-05.txt   draft-ietf-bess-multicast-damping-06.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: November 5, 2016 Cisco Systems Expires: November 10, 2016 Cisco Systems
Z. Zhang Z. Zhang
R. Kebler R. Kebler
J. Haas J. Haas
Juniper Networks Juniper Networks
May 04, 2016 May 09, 2016
Multicast VPN state damping Multicast VPN state damping
draft-ietf-bess-multicast-damping-05 draft-ietf-bess-multicast-damping-06
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 November 5, 2016. This Internet-Draft will expire on November 10, 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 6 skipping to change at page 3, line 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
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 given [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 [RFC3376], MLD[RFC3810]), multicast routing protocols protocols (IGMP [RFC3376], MLD[RFC3810]), multicast routing protocols
accordingly adjust multicast routing states and P-multicast tree accordingly adjust multicast routing states and P-multicast tree
states, to forward or prune multicast traffic to these receivers. states, to forward or prune multicast traffic to these receivers.
Similar challenges arise in the context of multicast specification
for VPLS [RFC7117].
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.
By nature multicast memberships change based on the behavior of By nature multicast memberships change based on the behavior of
multicast applications running on end hosts, hence the frequency of multicast applications running on end hosts, hence the frequency of
membership changes can legitimately be much higher than the typical membership changes can legitimately be much higher than the typical
churn of unicast routing states. churn of unicast routing states.
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,
remains under control regardless of the frequency at which multicast remains under control regardless of the frequency at which multicast
memberships changes are made by end hosts. memberships changes are made by end hosts.
This document describes procedures, inspired from existing BGP route This document describes procedures, inspired from existing BGP route
damping [RFC2439], aimed at offering means to set an upper bound to damping [RFC2439], aimed at offering means to set an upper bound to
the amount of processing for the mVPN control plane protocols the amount of processing for the mVPN control plane protocols, more
([RFC6514], and the P-tunnel control plane protocol in certain cases precisely the BGP control plane in [RFC6514], and the P-tunnel
as well), while at the same time preserving the service provided control plane protocol in the contexts of [RFC6514] and multicast
(delivering the multicast stream as requested by Customer Edge specification for VPLS [RFC7117]. This aims to be achieved while at
devices), although at the expense of a minimal increase of average the same time preserving the service provided (delivering the
bandwidth use in the provider network. The upper bound to the multicast stream as requested by Customer Edge devices), although at
control plane load due to the processing of a given multicast state, the expense of a minimal increase of average bandwidth use in the
is controlled indirectly via configurable parameters. provider network. The upper bound to the control plane load due to
the processing of a given multicast state, 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, is 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
 End of changes. 6 change blocks. 
12 lines changed or deleted 16 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/