idnits 2.17.1 draft-rosen-l3vpn-mvpn-wildcards-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 1, 2010) is 5169 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4601 (ref. 'PIM') (Obsoleted by RFC 7761) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Yiqun Cai 3 Internet Draft Eric C. Rosen (Editor) 4 Intended Status: Proposed Standard IJsbrand Wijnands 5 Expires: August 1, 2010 Cisco Systems, Inc. 7 February 1, 2010 9 MVPN: S-PMSI Wild Card Selectors 11 draft-rosen-l3vpn-mvpn-wildcards-00.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Copyright and License Notice 36 Copyright (c) 2010 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Abstract 51 In the procedures for Multicast Virtual Private Networks, individual 52 customer multicast flows can be assigned to specific multicast 53 tunnels through a service provider network. This document specifies 54 the encoding and semantics of "wild card selectors", which can be 55 used to assign certain sets of customer multicast flows as a group to 56 specific multicast tunnels. 58 Table of Contents 60 1 Specification of requirements ......................... 3 61 2 Introduction .......................................... 3 62 3 Encoding of Wild Cards ................................ 4 63 4 Binding Wild Cards to Unidirectional P-Tunnels ........ 5 64 4.1 Binding (C-*,C-G) to a Unidirectional P-Tunnel ........ 5 65 4.2 Binding (C-*,C-*) to a Unidirectional P-Tunnel ........ 6 66 5 Use of Wild Cards with Bidirectional P-Tunnels ........ 6 67 6 IANA Considerations ................................... 6 68 7 Security Considerations ............................... 6 69 8 Acknowledgments ....................................... 6 70 9 Authors' Addresses .................................... 6 71 10 Normative References .................................. 7 72 11 Informative References ................................ 7 73 1. Specification of requirements 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in [RFC2119]. 79 2. Introduction 81 Note: this document uses terminology from [MVPN], and in particular 82 uses the prefixes "C-" and "P-" as specified in section 3.1 of 83 [MVPN]. 85 As specified in [MVPN] and [MVPN-BGP], one can use an S-PMSI A-D 86 route or an S-PMSI Join Message to assign a particular C-multicast 87 flow, identified as (C-S,C-G), to a particular S-PMSI. 89 However, [MVPN-BGP] does not specify any means of encoding wild cards 90 ("*", in multicast terminology) in the Source or Group fields. 91 Similarly, [MVPN] does not specify any means of encoding wild cards 92 in the C-Source or C-Group fields of the S-PMSI Join messages. 94 This omission makes it difficult to provide optimized multicast 95 routing for customers that use ASM ("Any Source Multicast") 96 multicasts, in which flows may be traveling along "shared" C-trees. 97 We use the term "shared C-trees" to refer both to the the 98 unidirectional "RPT trees" used in "PIM sparse mode" [PIM], and to 99 the bidirectional trees used in BIDIR-PIM [BIDIR-PIM]. 101 When a customer is using ASM multicast, it is useful to be able to 102 select the set of flows that are traveling along a shared C-tree, and 103 to bind that entire set of flows to a specified P-tunnel. 104 Conceptually, we would like to have a way to express that we want 105 (C-*,C-G) traffic bound to the specified P-tunnel. A multicast data 106 packet whose source address is C-S and whose destination address is 107 an ASM group address is said to be traveling a shared C-tree from the 108 perspective of a given router if that router's decision to forward 109 the packet is based upon (C-*,C-G) state rather than upon (C-S,C-G) 110 state. Creation and use of these multicast states is specified in 111 [PIM] and/or [MVPN-BGP]. 113 Another useful feature would be a way of using an S-PMSI A-D route to 114 say "by default, all multicast traffic (within a given VPN) that has 115 not been bound to any other P-tunnel is bound to the specified 116 P-tunnel". To do this we, need to have a way to express that we want 117 (C-*, C-*) traffic bound to the P-tunnel. 119 The Wild Card Selectors specified in this document provide additional 120 functionality: 122 - One can send an S-PMSI A-D route or S-PMSI Join Message whose 123 semantics are "assign all the traffic traveling the (C-*,C-G) 124 tree to this S-PMSI". 126 - One can send an S-PMSI A-D route or S-PMSI Join Message whose 127 semantics are "use this S-PMSI as the default method for carrying 128 any (C-S,C-G) or (C-*,C-G) traffic that isn't assigned to a 129 different S-PMSI". That is, it allows for the use of S-PMSIs as 130 the default PMSIs for carrying data traffic. 132 This document specifies the encoding of the wild card selectors, and 133 provides rules for their usage and interpretation when S-PMSIs are 134 instantiated as unidirectional P-tunnels. Rules for their usage and 135 interpretation when S-PMSIs are instantiated as bidirectional 136 P-tunnels may be found in [MVPN_BIDIR]. 138 In the following, we will sometimes talk of a PE receiving traffic 139 from a PMSI and then discarding it. If PIM is being used as the 140 multicast control protocol between PEs, this always implies that the 141 discarded traffic will not be seen by PIM on the receiving PE. 143 In the following, we will sometimes speak of an S-PMSI A-D route 144 being "ignored". When we say the route is "ignored", we do not mean 145 that its normal BGP processing is not done, but that the route is not 146 considered when determining which P-tunnel to use when sending 147 multicast data, and that the MPLS label values it conveys are not 148 used. We will generally use "ignore" in quotes to indicate this 149 meaning. 151 3. Encoding of Wild Cards 153 This specification therefore establishes the following conventions: 155 - In an S-PMSI A-D route, the use of a zero length source or group 156 field is to be interpreted as specifying a wild card value for 157 the respective field. A single wild card represents all Multicast 158 Source or Multicast Group values of all address families; there 159 is no need to use a different wild card for IPv4 addresses than 160 is used for IPv6 addresses. 162 - In an S-PMSI Join message, the use of an all-zero C-Source or 163 C-Group field is to be interpreted as specifying a wild card 164 value for the respective field. A wild card represents all 165 C-Source or C-group values of a particular address family (IPv4 166 or IPv6), as specified by the S-PMSI Join message type. 168 When wildcards are used, the following two combinations MUST BE 169 supported: 171 - (C-*,C-G): Source Wildcard, Group specified. 173 - (C-*,C-*): Source Wildcard, Group Wildcard. 175 This specification does not provide support for the combination of a 176 specified source and a group wildcard. A received S-PMSI A-D route 177 or S-PMSI Join message specifying this combination will be "ignored". 179 4. Binding Wild Cards to Unidirectional P-Tunnels 181 4.1. Binding (C-*,C-G) to a Unidirectional P-Tunnel 183 Consider an S-PMSI A-D Route whose NLRI specifies (C-*,C-G), and that 184 contains a PMSI Tunnel Attribute (PTA) [MVPN-BGP] that specifies a 185 unidirectional P-tunnel. The P-tunnel may be a P2MP LSP, or it may 186 be a unidirectional PIM-created multicast distribution tree specified 187 either as (P-*,P-G) or as (P-S,P-G). 189 Alternately, consider an S-PMSI Join message, whose C-Source and 190 C-Group fields specify (C-*,C-G), and that specifies a unidirectional 191 P-tunnel (either a P2MP LSP or a unidirectional PIM-created multicast 192 distribution tree.) 194 If C-G is known to be an SSM group address, the S-PMSI A-D route or 195 S-PMSI Join message is "ignored". 197 The semantics of binding (C-*,C-G) to a unidirectional P-tunnel are 198 the following: the originator of the S-PMSI A-D route or S-PMSI Join 199 message is saying that if it receives, over a VRF interface, any 200 traffic that is traveling on the (C-*,C-G) shared tree, and if it is 201 to forward such traffic to other PEs, then it will transmit such 202 traffic on the specified P-tunnel. Any PE interested in receiving 203 (C-*,C-G) traffic from the originator (i.e., if the originator is 204 PE's upstream multicast hop for the (C-*,C-G) state) MUST join that 205 P-tunnel. 207 4.2. Binding (C-*,C-*) to a Unidirectional P-Tunnel 209 The originator of an S-PMSI A-D Route or an S-PMSI Join message that 210 binds (C-*,C-*) to a unidirectional P-tunnel is saying that by 211 default, if it is required by its C-PIM instance to forward multicast 212 traffic to any other PE, then by default it will send the traffic on 213 the specified tunnel. The default applies to any traffic that has 214 not been explicitly assigned to another P-tunnel. 216 5. Use of Wild Cards with Bidirectional P-Tunnels 218 The specification for the use of wild cards with bidirectional 219 P-Tunnels can be found in [MVPN_BIDIR]. 221 6. IANA Considerations 223 This document requires no actions of IANA. 225 7. Security Considerations 227 There are no additional security considerations beyond those of 228 [MVPN] and [MVPN-BGP]. 230 8. Acknowledgments 232 The authors wish to thank Arjen Boers for many helpful discussions. 234 9. Authors' Addresses 236 Yiqun Cai 237 Cisco Systems, Inc. 238 170 Tasman Drive 239 San Jose, CA, 95134 240 E-mail: ycai@cisco.com 242 Eric C. Rosen 243 Cisco Systems, Inc. 244 1414 Massachusetts Avenue 245 Boxborough, MA, 01719 246 E-mail: erosen@cisco.com 247 IJsbrand Wijnands 248 Cisco Systems, Inc. 249 De kleetlaan 6a Diegem 1831 250 Belgium 251 E-mail: ice@cisco.com 253 10. Normative References 255 [BIDIR-PIM] "Bidirectional Protocol Independent Multicast", Handley, 256 Kouvelas, Speakman, Vicisano, RFC 5015, October 2007 258 [MVPN] "Multicast in MPLS/BGP IP VPNs", Rosen, Aggarwal, et. al., 259 draft-ietf-l3vpn-2547bis-mcast-10.txt, January 2010 261 [MVPN-BGP] "BGP Encodings and Procedures for Multicast in MPLS/BGP IP 262 VPNs", Aggarwal, Rosen, Morin, Rekhter, Kodeboniya, 263 draft-ietf-l3vpn-2547bis-mcast-bgp-08.txt, September 2009 265 [PIM] "Protocol Independent Multicast - Sparse Mode (PIM-SM): 266 Protocol Specification (Revised)", Fenner, Handley, Holbrook, 267 Kouvelas, RFC 4601, August 2006 269 [RFC2119] "Key words for use in RFCs to Indicate Requirement 270 Levels.", Bradner, March 1997 272 11. Informative References 274 [MVPN_BIDIR] "Bidirectional P-Tunnels in MVPN", Cai, Rosen, Wijnands, 275 draft-rosen-l3vpn-mvpn-bidir-ptunnels-00.txt, January 2010