datatracker.ietf.org
Sign In
Version 4.51.p2, 2013-06-11
Report a bug

Wildcards in Multicast VPN Auto-Discovery Routes
draft-ietf-l3vpn-mvpn-wildcards-02

RFC
Document Stream: IETF
Last updated: 2012-02-09
Replaces: draft-rekhter-mvpn-wildcard-spmsi, draft-rosen-l3vpn-mvpn-wildcards, draft-rosen-l3vpn-mvpn-wldcds-cmbind
Intended RFC status: Proposed Standard
Other versions: (expired, archived): plain text, pdf, html

IETF State: Submitted to IESG for Publication (l3vpn)
Document shepherd:(None)
Shepherd writeup
Consensus:Unknown

IESG State: RFC 6625
IANA Action State: No IC 
On agenda of 2012-03-01 IESG telechat
Responsible AD: Stewart Bryant
IESG Note: Ben Niven-Jenkins (ben@niven-jenkins.co.uk) is the Document Shepherd
Send notices to: l3vpn-chairs@tools.ietf.org, draft-ietf-l3vpn-mvpn-wildcards@tools.ietf.org

This Internet-Draft is no longer active. Unofficial copies of old Internet-Drafts can be found here:
http://tools.ietf.org/id/draft-ietf-l3vpn-mvpn-wildcards.

Abstract:
In Multicast Virtual Private Networks (MVPNs), customer multicast flows are carried in "tunnels" through a service provider's network. The base specifications for MVPN define BGP multicast VPN "auto-discovery routes" and specify how to use an auto-discovery route to advertise the fact that an individual customer multicast flow is being carried in a particular tunnel. However, those specifications do not provide a way to specify, in a single such route, that multiple customer flows are being carried in a single tunnel. Those specifications also do not provide a way to advertise that a particular tunnel is to be used by default to carry all customer flows, except in the case where that tunnel is joined by all the provider edge routers of the MVPN. This document eliminates these restrictions by specifying the use of "wildcard" elements in the customer flow identifiers. With wildcard elements, a single auto-discovery route can refer to multiple customer flows or even to all customer flows. [STANDARDS-TRACK]

Authors:
Ray Qiu <rayq@huawei.com>
Eric Rosen <erosen@cisco.com>
Yakov Rekhter <yakov@juniper.net>

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid)