Wildcards in Multicast VPN Auto-Discovery Routes
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: RFC Editor <email@example.com>, l3vpn mailing list <firstname.lastname@example.org>, l3vpn chair <email@example.com> 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: http://datatracker.ietf.org/doc/draft-ietf-l3vpn-mvpn-wildcards/
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. Personnel Ben Niven-Jenkins (firstname.lastname@example.org) is the Document Shepherd for this document Stewart Bryant is the Responsible Area Director.