Wildcards in Multicast VPN Auto-Discovery Routes
RFC 6625

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>,
    l3vpn mailing list <l3vpn@ietf.org>,
    l3vpn chair <l3vpn-chairs@tools.ietf.org>
Subject: Protocol Action: 'Wildcards in Multicast VPN Auto-Discovery Routes' to Proposed Standard (draft-ietf-l3vpn-mvpn-wildcards-02.txt)

The IESG has approved the following document:
- 'Wildcards in Multicast VPN Auto-Discovery Routes'
  (draft-ietf-l3vpn-mvpn-wildcards-02.txt) as a Proposed Standard

This document is the product of the Layer 3 Virtual Private Networks
Working Group.

The IESG contact persons are Stewart Bryant and Adrian Farrel.

A URL of this Internet Draft is:

Technical Summary

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.

Working Group Summary

This document is a product of L3VPN WG. There were 
no technical concerns raised  during the  WG Last Call.

Document Quality
There are no known concerns with the quality of this document.


Ben Niven-Jenkins (ben@niven-jenkins.co.uk) is the Document Shepherd 
for this document
Stewart Bryant is the Responsible Area Director.