L3VPN Working Group Yiqun Cai Internet Draft Eric C. Rosen (Editor) Intended Status: Proposed Standard IJsbrand Wijnands Expires: July 24, 2011 Cisco Systems, Inc. January 24, 2011 MVPN: S-PMSI Wild Card Selectors draft-rosen-l3vpn-mvpn-wildcards-02.txt Abstract In the procedures for Multicast Virtual Private Networks, individual customer multicast flows can be assigned to specific multicast tunnels through a service provider network. This document specifies the encoding and semantics of "wild card selectors", which can be used to assign certain sets of customer multicast flows as a group to specific multicast tunnels. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Rosen, et al. [Page 1] Internet Draft draft-rosen-l3vpn-mvpn-wildcards-02.txt January 2011 Copyright and License Notice Copyright (c) 2011 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 Specification of requirements ......................... 3 2 Introduction .......................................... 3 3 Encoding of Wild Cards ................................ 4 4 Binding Wild Cards to Unidirectional P-Tunnels ........ 5 4.1 Binding (C-*,C-G) to a Unidirectional P-Tunnel ........ 5 4.2 Binding (C-*,C-*) to a Unidirectional P-Tunnel ........ 6 5 Use of Wild Cards with Bidirectional P-Tunnels ........ 6 6 IANA Considerations ................................... 6 7 Security Considerations ............................... 6 8 Acknowledgments ....................................... 6 9 Authors' Addresses .................................... 6 10 Normative References .................................. 7 11 Informative References ................................ 7 Rosen, et al. [Page 2] Internet Draft draft-rosen-l3vpn-mvpn-wildcards-02.txt January 2011 1. Specification of requirements 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]. 2. Introduction Note: this document uses terminology from [MVPN], and in particular uses the prefixes "C-" and "P-" as specified in section 3.1 of [MVPN]. As specified in [MVPN] and [MVPN-BGP], one can use an S-PMSI A-D route or an S-PMSI Join Message to assign a particular C-multicast flow, identified as (C-S,C-G), to a particular S-PMSI. However, [MVPN-BGP] does not specify any means of encoding wild cards ("*", in multicast terminology) in the Source or Group fields. Similarly, [MVPN] does not specify any means of encoding wild cards in the C-Source or C-Group fields of the S-PMSI Join messages. This omission makes it difficult to provide optimized multicast routing for customers that use ASM ("Any Source Multicast") multicasts, in which flows may be traveling along "shared" C-trees. We use the term "shared C-trees" to refer both to the the unidirectional "RPT trees" used in "PIM sparse mode" [PIM], and to the bidirectional trees used in BIDIR-PIM [BIDIR-PIM]. When a customer is using ASM multicast, it is useful to be able to select the set of flows that are traveling along a shared C-tree, and to bind that entire set of flows to a specified P-tunnel. Conceptually, we would like to have a way to express that we want (C-*,C-G) traffic bound to the specified P-tunnel. A multicast data packet whose source address is C-S and whose destination address is an ASM group address is said to be traveling a shared C-tree from the perspective of a given router if that router's decision to forward the packet is based upon (C-*,C-G) state rather than upon (C-S,C-G) state. Creation and use of these multicast states is specified in [PIM] and/or [MVPN-BGP]. Another useful feature would be a way of using an S-PMSI A-D route to say "by default, all multicast traffic (within a given VPN) that has not been bound to any other P-tunnel is bound to the specified P-tunnel". To do this we, need to have a way to express that we want (C-*, C-*) traffic bound to the P-tunnel. The Wild Card Selectors specified in this document provide additional Rosen, et al. [Page 3] Internet Draft draft-rosen-l3vpn-mvpn-wildcards-02.txt January 2011 functionality: - One can send an S-PMSI A-D route or S-PMSI Join Message whose semantics are "assign all the traffic traveling the (C-*,C-G) tree to this S-PMSI". - One can send an S-PMSI A-D route or S-PMSI Join Message whose semantics are "use this S-PMSI as the default method for carrying any (C-S,C-G) or (C-*,C-G) traffic that isn't assigned to a different S-PMSI". That is, it allows for the use of S-PMSIs as the default PMSIs for carrying data traffic. This document specifies the encoding of the wild card selectors, and provides rules for their usage and interpretation when S-PMSIs are instantiated as unidirectional P-tunnels. Rules for their usage and interpretation when S-PMSIs are instantiated as bidirectional P-tunnels may be found in [MVPN_BIDIR]. In the following, we will sometimes talk of a PE receiving traffic from a PMSI and then discarding it. If PIM is being used as the multicast control protocol between PEs, this always implies that the discarded traffic will not be seen by PIM on the receiving PE. In the following, 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 sending multicast data, and that the MPLS label values it conveys are not used. We will generally use "ignore" in quotes to indicate this meaning. 3. Encoding of Wild Cards This specification therefore establishes the following conventions: - In an S-PMSI A-D route, the use of a zero length source or group field is to be interpreted as specifying a wild card value for the respective field. A single wild card represents all Multicast Source or Multicast Group values of all address families; there is no need to use a different wild card for IPv4 addresses than is used for IPv6 addresses. - In an S-PMSI Join message, the use of an all-zero C-Source or C-Group field is to be interpreted as specifying a wild card value for the respective field. A wild card represents all C-Source or C-group values of a particular address family (IPv4 or IPv6), as specified by the S-PMSI Join message type. Rosen, et al. [Page 4] Internet Draft draft-rosen-l3vpn-mvpn-wildcards-02.txt January 2011 When wildcards are used, the following two combinations MUST BE supported: - (C-*,C-G): Source Wildcard, Group specified. - (C-*,C-*): Source Wildcard, Group Wildcard. This specification does not provide support for the combination of a specified source and a group wildcard. A received S-PMSI A-D route or S-PMSI Join message specifying this combination will be "ignored". 4. Binding Wild Cards to Unidirectional P-Tunnels 4.1. Binding (C-*,C-G) to a Unidirectional P-Tunnel Consider an S-PMSI A-D Route whose NLRI specifies (C-*,C-G), and that contains a PMSI Tunnel Attribute (PTA) [MVPN-BGP] that specifies a unidirectional P-tunnel. The P-tunnel may be a P2MP LSP, or it may be a unidirectional PIM-created multicast distribution tree specified either as (P-*,P-G) or as (P-S,P-G). Alternately, consider an S-PMSI Join message, whose C-Source and C-Group fields specify (C-*,C-G), and that specifies a unidirectional P-tunnel (either a P2MP LSP or a unidirectional PIM-created multicast distribution tree.) If C-G is known to be an SSM group address, the S-PMSI A-D route or S-PMSI Join message is "ignored". The semantics of binding (C-*,C-G) to a unidirectional P-tunnel are the following: the originator of the S-PMSI A-D route or S-PMSI Join message is saying that if it receives, over a VRF interface, any traffic that is traveling on the (C-*,C-G) shared tree, and if it is to forward such traffic to other PEs, then it will transmit such traffic on the specified P-tunnel. Any PE interested in receiving (C-*,C-G) traffic from the originator (i.e., if the originator is PE's upstream multicast hop for the (C-*,C-G) state) MUST join that P-tunnel. Rosen, et al. [Page 5] Internet Draft draft-rosen-l3vpn-mvpn-wildcards-02.txt January 2011 4.2. Binding (C-*,C-*) to a Unidirectional P-Tunnel The originator of an S-PMSI A-D Route or an S-PMSI Join message that binds (C-*,C-*) to a unidirectional P-tunnel is saying that by default, if it is required by its C-PIM instance to forward multicast traffic to any other PE, then by default it will send the traffic on the specified tunnel. The default applies to any traffic that has not been explicitly assigned to another P-tunnel. 5. Use of Wild Cards with Bidirectional P-Tunnels The specification for the use of wild cards with bidirectional P-Tunnels can be found in [MVPN_BIDIR]. 6. IANA Considerations This document requires no actions of IANA. 7. Security Considerations There are no additional security considerations beyond those of [MVPN] and [MVPN-BGP]. 8. Acknowledgments The authors wish to thank Arjen Boers for many helpful discussions. 9. Authors' Addresses Yiqun Cai Cisco Systems, Inc. 170 Tasman Drive San Jose, CA, 95134 E-mail: ycai@cisco.com Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA, 01719 E-mail: erosen@cisco.com Rosen, et al. [Page 6] Internet Draft draft-rosen-l3vpn-mvpn-wildcards-02.txt January 2011 IJsbrand Wijnands Cisco Systems, Inc. De kleetlaan 6a Diegem 1831 Belgium E-mail: ice@cisco.com 10. Normative References [BIDIR-PIM] "Bidirectional Protocol Independent Multicast", Handley, Kouvelas, Speakman, Vicisano, RFC 5015, October 2007 [MVPN] "Multicast in MPLS/BGP IP VPNs", Rosen, Aggarwal, et. al., draft-ietf-l3vpn-2547bis-mcast-10.txt, January 2010 [MVPN-BGP] "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", Aggarwal, Rosen, Morin, Rekhter, Kodeboniya, draft-ietf-l3vpn-2547bis-mcast-bgp-08.txt, September 2009 [PIM] "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", Fenner, Handley, Holbrook, Kouvelas, RFC 4601, August 2006 [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels.", Bradner, March 1997 11. Informative References [MVPN_BIDIR] "MVPN: Using Bidirectional P-Tunnels", Cai, Rosen, Wijnands, draft-rosen-l3vpn-mvpn-bidir-02.txt, January 2011 Rosen, et al. [Page 7]