Internet Engineering Task Force (IETF) E. Rosen, Ed. Request for Comments: 6625 Cisco Systems, Inc. Updates: 6514 Y. Rekhter, Ed. Category: Standards Track Juniper Networks, Inc. ISSN: 2070-1721 W. Henderickx Alcatel-Lucent R. Qiu Huawei May 2012 Wildcards in Multicast VPN Auto-Discovery Routes 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. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6625. Rosen, et al. Standards Track [Page 1]
RFC 6625 Wildcards in MVPN A-D Routes May 2012 Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction ....................................................3 1.1. Terminology ................................................3 1.2. Wildcards in S-PMSI A-D Routes .............................5 1.3. Use Cases ..................................................5 2. Encoding of Wildcards ...........................................7 3. Finding the Matching S-PMSI A-D Route ...........................8 3.1. Finding the Match for Data Transmission ....................8 3.2. Finding the Match for Data Reception .......................9 3.2.1. Finding the Match for (C-S,C-G) .....................9 3.2.2. Finding the Wildcard Match for (C-*,C-G) ............9 4. Procedures for S-PMSI A-D Routes with Wildcards ................10 4.1. Procedures for All Kinds of Wildcards .....................10 4.2. Procedures for (C-*,C-G) S-PMSI A-D Routes ................11 4.3. Procedures for (C-S,C-*) S-PMSI A-D Routes ................12 4.4. Procedures for (C-*,C-*) S-PMSI A-D Routes ................13 5. Security Considerations ........................................15 6. Acknowledgments ................................................15 7. Normative References ...........................................15 Rosen, et al. Standards Track [Page 2]
RFC 6625 Wildcards in MVPN A-D Routes May 2012 1. Introduction 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. 1.1. Terminology This document uses terminology from [MVPN] and, in particular, uses the prefixes "C-" and "P-", as specified in Section 3.1 of [MVPN], to distinguish addresses in the "customer address space" from addresses in the "provider address space". The following terminology and acronyms are particularly important in this document: - MVPN Multicast Virtual Private Network -- a VPN [L3VPN] in which multicast service is offered. - VRF VPN Routing and Forwarding table [L3VPN]. - SP Service Provider. - P-tunnel A tunnel through the network of one or more SPs. - C-S Multicast Source. A multicast source address, in the address space of a customer network. Rosen, et al. Standards Track [Page 3]
RFC 6625 Wildcards in MVPN A-D Routes May 2012 - C-G Multicast Group. A multicast group address (destination address) in the address space of a customer network. - C-multicast flow or C-flow A customer multicast flow. Each C-flow is identified by the ordered pair (source address, group address), where each address is in the customer's address space. The identifier of a particular C-flow is usually written as (C-S,C-G). - RP A "Rendezvous Point", as defined in [PIM]. - C-RP A Rendezvous Point whose address is in the customer's address space. - Selective P-tunnel A P-tunnel that is joined only by Provider Edge (PE) routers that need to receive one or more of the C-flows that are traveling through that P-tunnel. - Inclusive P-tunnel A P-tunnel that is joined by all PE routers that attach to sites of a given MVPN. - S-PMSI A-D route Selective Provider Multicast Service Interface Auto-Discovery route. Carried in BGP Update messages, these routes are used to advertise the fact that particular C-flows are bound to (i.e., are traveling through) particular P-tunnels. Familiarity with multicast concepts and terminology [PIM] is also presupposed. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Rosen, et al. Standards Track [Page 4]
RFC 6625 Wildcards in MVPN A-D Routes May 2012 1.2. Wildcards in S-PMSI A-D Routes As specified in [MVPN] and [MVPN-BGP], an S-PMSI A-D route advertises that a particular C-flow is bound to a particular selective P-tunnel. The identifier of the specified C-flow, e.g., (C-S,C-G), is encoded into the Network Layer Reachability Information (NLRI) of the S-PMSI A-D route. The identifier of the specified P-tunnel is encoded into an attribute (the "PMSI Tunnel Attribute") of the S-PMSI A-D route. Each S-PMSI A-D route thus specifies a single C-flow. To bind multiple C-flows to a single P-tunnel, it is necessary to advertise one S-PMSI A-D route for each C-flow, specifying the same P-tunnel in each such route. This document defines OPTIONAL extensions to the procedures and encodings specified in [MVPN] and [MVPN-BGP]. These extensions enable a single S-PMSI A-D route to advertise that multiple C-multicast flows are bound to a single P-tunnel. The extensions specified in this document are based on the notion of allowing the NLRI of an S-PMSI A-D route to contain a "wildcard". In the NLRI encoding, a wildcard can replace the C-S, the C-G, or both. We use the notation "C-*" to denote a wildcard. The extensions allow the NLRI to encode three kinds of wildcards: (C-*,C-*), (C-S,C-*), and (C-*,C-G). By using wildcards, a PE may be able to reduce the number of S-PMSI A-D routes it originates, thereby improving the scalability of the control plane. There is, however, no impact on data plane scalability, as the number of P-tunnels is not reduced. Encoding and detailed procedures are specified in subsequent sections of this document. 1.3. Use Cases There are a number of situations in which it can be useful to use wildcards in the NLRI of an S-PMSI A-D route. - Using a selective P-tunnel as the default tunnel. There are procedures in [MVPN] and [MVPN-BGP] that allow a PE to advertise that it is going to use an inclusive P-tunnel as the P-tunnel on which it will transmit all C-flows by "default". However, those documents do not provide any way for a PE to advertise that it is going to use a selective P-tunnel as the P-tunnel on which it will transmit all C-flows by "default". Using the extensions defined in this document, a PE can Rosen, et al. Standards Track [Page 5]
RFC 6625 Wildcards in MVPN A-D Routes May 2012 advertise that it is going to use a selective P-tunnel as its default P-tunnel. It does so by advertising an S-PMSI A-D route whose NLRI contains (C-*,C-*). - Binding multiple C-flows traveling along a customer's Protocol Independent Multicast - Sparse Mode (PIM-SM) shared tree to a single P-tunnel. A PE router may be connected to an MVPN site that contains a customer RP (C-RP). The C-RP may be the root of one or more shared trees. In multicast terminology, these are known as (*,G) trees. By advertising a single S-PMSI A-D route whose NLRI contains the (C-*,C-G) wildcard, the PE can bind all the C-flows traveling along a customer's (*,G) tree to a single P-tunnel. This use case applies only when C-G is a non-bidirectional ASM (Any Source Multicast) group. - Binding multiple C-flows with the same C-group address to a single P-tunnel, even if each such C-flow is traveling along a customer's PIM source tree. A PE router may be connected to an MVPN site containing several multicast sources that are all sending to a common multicast group, along a customer's PIM source trees. Alternatively, the PE may be connected to several sites, each containing at least one source sending to the common multicast group. By advertising a single S-PMSI A-D route whose NLRI contains (C-*,C-G), the PE can bind these C-flows to a single P-tunnel. This use case applies only when the C-group is a non-bidirectional ASM group. - Binding multiple C-flows with the same C-group address to a single P-tunnel, when those C-flows are traveling along a customer's BIDIR-PIM shared tree. This use case applies only when the C-group is a BIDIR-PIM group. - Binding multiple C-flows from a given C-source to a given P-tunnel, irrespective of whether those C-flows all have the same C-group address. This can be useful when the C-group addresses are SSM (Single Source Multicast) addresses. Suppose, for example, that a given source transmits multiple "channels" of information, each with Rosen, et al. Standards Track [Page 6]
RFC 6625 Wildcards in MVPN A-D Routes May 2012 its own C-group address. It may be desirable to bind all these channels to a single P-tunnel, without having to advertise an S-PMSI A-D route for each one. Of course, a specific C-flow, (C-S,C-G), can always be assigned individually to a particular P-tunnel by advertising an S-PMSI A-D route whose NLRI contains (C-S,C-G). In Section 4, we will sometimes speak of an S-PMSI A-D route being ignored. When we say the route is "ignored", we do not mean that its normal BGP processing is not done, but that the route is not considered when determining which P-tunnel to use when receiving multicast data, and that the MPLS label values it conveys are not used. We will use "ignore" in quotes to indicate this meaning. This document provides procedures only for the case where the P-tunnels are "unidirectional", i.e., point-to-multipoint. The use of "bidirectional" (multipoint-to-multipoint) P-tunnels is outside the scope of this document. 2. Encoding of Wildcards Per [MVPN-BGP] Section 4.3, the MCAST-VPN NLRI in an S-PMSI A-D route is encoded as follows: +-----------------------------------+ | RD (8 octets) | +-----------------------------------+ | Multicast Source Length (1 octet) | +-----------------------------------+ | Multicast Source (variable) | +-----------------------------------+ | Multicast Group Length (1 octet) | +-----------------------------------+ | Multicast Group (variable) | +-----------------------------------+ | Originating Router's IP Addr | +-----------------------------------+ where the "source length" and "group length" fields always have a non-zero value. This document specifies that a "zero-length" source or group represents the corresponding wildcard. Specifically, - A source wildcard is encoded as a zero-length source field. That is, the "multicast source length" field contains the value 0x00, and the "multicast source" field is omitted. Rosen, et al. Standards Track [Page 7]