idnits 2.17.1 draft-rosen-l3vpn-mvpn-wildcards-03.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, 2011) is 4826 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) == Outdated reference: A later version (-03) exists of draft-rosen-l3vpn-mvpn-bidir-02 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 L3VPN Working Group Yiqun Cai 3 Internet Draft Eric C. Rosen (Editor) 4 Intended Status: Proposed Standard IJsbrand Wijnands 5 Expires: August 1, 2011 Cisco Systems, Inc. 7 February 1, 2011 9 MVPN: S-PMSI Wild Card Selectors 11 draft-rosen-l3vpn-mvpn-wildcards-03.txt 13 Abstract 15 In the procedures for Multicast Virtual Private Networks, individual 16 customer multicast flows can be assigned to specific multicast 17 tunnels through a service provider network. This document specifies 18 the encoding and semantics of "wild card selectors", which can be 19 used to assign certain sets of customer multicast flows as a group to 20 specific multicast tunnels. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 Copyright and License Notice 45 Copyright (c) 2011 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1 Specification of requirements ......................... 3 61 2 Introduction .......................................... 3 62 3 Encoding of Wild Cards ................................ 5 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 ....................................... 7 70 9 Authors' Addresses .................................... 7 71 10 Normative References .................................. 7 72 11 Informative References ................................ 8 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 It is also useful to be able to use an S-PMSI A-D route to say "by 114 default, all multicast traffic (within a given VPN) that has not been 115 bound to any other P-tunnel is bound to the specified P-tunnel". To 116 do this we, need to have a way to express that we want (C-*, C-*) 117 traffic bound to the P-tunnel. 119 When an MVPN customer is using BIDIR-PIM, it is useful to be able to 120 use an S-PMSI A-D route to say "by default, all BIDIR-PIM multicast 121 traffic (within a given VPN) that has not been bound to any other 122 P-tunnel is bound to the specified P-tunnel". To do this we, need to 123 have a way to express a (C-*, C-*) wildcard that is restricted to 124 BIDIR-PIM C-groups. 126 The Wild Card Selectors specified in this document provide additional 127 functionality: 129 - One can send an S-PMSI A-D route or S-PMSI Join Message whose 130 semantics are "assign all the traffic traveling the (C-*,C-G) 131 tree to this S-PMSI". 133 - One can send an S-PMSI A-D route or S-PMSI Join Message whose 134 semantics are "use this S-PMSI as the default method for carrying 135 any (C-S,C-G) or (C-*,C-G) traffic that isn't assigned to a 136 different S-PMSI". That is, it allows for the use of S-PMSIs as 137 the default PMSIs for carrying data traffic. It is also possible 138 to separately assign BIDIR-PIM C-groups by default to a 139 particular P-Tunnel. 141 This document specifies the encoding of the wild card selectors, and 142 provides rules for their usage and interpretation when S-PMSIs are 143 instantiated as unidirectional P-tunnels. Rules for their usage and 144 interpretation when S-PMSIs are instantiated as bidirectional 145 P-tunnels may be found in [MVPN-BIDIR]. 147 Note that, per [MVPN-BGP], an S-PMSI A-D route is carried in the 148 Network Layer Reachability Information (NLRI) field of an 149 MP_REACH_NLRI attribute (see [BGP-MP]). Every S-PMSI A-D route has a 150 particular address family (IPv4 or IPv6), as specified in the Address 151 Family Information AFI field of the MP_REACH_NLRI attribute. A wild 152 card selector in a particular S-PMSI A-D route always refers only to 153 multicast flows of that same address family. 155 In the following, we will sometimes talk of a PE receiving traffic 156 from a PMSI and then discarding it. If PIM is being used as the 157 multicast control protocol between PEs, this always implies that the 158 discarded traffic will not be seen by PIM on the receiving PE. 160 In the following, we will sometimes speak of an S-PMSI A-D route 161 being "ignored". When we say the route is "ignored", we do not mean 162 that its normal BGP processing is not done, but that the route is not 163 considered when determining which P-tunnel to use when sending 164 multicast data, and that the MPLS label values it conveys are not 165 used. We will generally use "ignore" in quotes to indicate this 166 meaning. 168 3. Encoding of Wild Cards 170 This specification therefore establishes the following conventions: 172 - In an S-PMSI A-D route, the use of a zero length source or group 173 field is to be interpreted as specifying a wild card value for 174 the respective field. 176 - An S-PMSI A-D route that has a zero length source field, a group 177 field of length 1, and a group field value of 1, is to be 178 interpreted as specifying a wild card meaning "all BIDIR-PIM 179 groups". 181 - In an S-PMSI Join message, the use of an all-zero C-Source or 182 C-Group field is to be interpreted as specifying a wild card 183 value for the respective field. A wild card represents all 184 C-Source or C-group values of a particular address family (IPv4 185 or IPv6), as specified by the S-PMSI Join message type. 187 When wildcards are used, the following two combinations MUST BE 188 supported: 190 - (C-*,C-G): Source Wildcard, Group specified. 192 - (C-*,C-*): Source Wildcard, Group Wildcard. 194 If support for customer BIDIR-PIM flows is being provided, support 195 for the "all BIDIR-PIM" wildcard is also REQUIRED. With regard to 196 the procedures of section 4.2, the "all BIDIR-PIM" wildcard is 197 treated identically to the (C-*,C-*) wildcard, except that it applies 198 only to BIDIR-PIM flows. 200 This specification does not provide support for the combination of a 201 specified source and a group wildcard. A received S-PMSI A-D route 202 or S-PMSI Join message specifying this combination will be "ignored". 204 4. Binding Wild Cards to Unidirectional P-Tunnels 206 4.1. Binding (C-*,C-G) to a Unidirectional P-Tunnel 208 Consider an S-PMSI A-D Route whose NLRI specifies (C-*,C-G), and that 209 contains a PMSI Tunnel Attribute (PTA) [MVPN-BGP] that specifies a 210 unidirectional P-tunnel. The P-tunnel may be a P2MP LSP, or it may 211 be a unidirectional PIM-created multicast distribution tree specified 212 either as (P-*,P-G) or as (P-S,P-G). 214 Alternately, consider an S-PMSI Join message, whose C-Source and 215 C-Group fields specify (C-*,C-G), and that specifies a unidirectional 216 P-tunnel (either a P2MP LSP or a unidirectional PIM-created multicast 217 distribution tree.) 219 If C-G is known to be an SSM group address, the S-PMSI A-D route or 220 S-PMSI Join message is "ignored". 222 The semantics of binding (C-*,C-G) to a unidirectional P-tunnel are 223 the following: the originator of the S-PMSI A-D route or S-PMSI Join 224 message is saying that if it receives, over a VRF interface, any 225 traffic that is traveling on the (C-*,C-G) shared tree, and if it is 226 to forward such traffic to other PEs, then it will transmit such 227 traffic on the specified P-tunnel. Any PE interested in receiving 228 (C-*,C-G) traffic from the originator (i.e., if the originator is 229 PE's upstream multicast hop for the (C-*,C-G) state) MUST join that 230 P-tunnel. 232 4.2. Binding (C-*,C-*) to a Unidirectional P-Tunnel 234 The originator of an S-PMSI A-D Route or an S-PMSI Join message that 235 binds (C-*,C-*) to a unidirectional P-tunnel is saying that by 236 default, if it is required by its C-PIM instance to forward multicast 237 traffic to any other PE, then by default it will send the traffic on 238 the specified tunnel. The default applies to any traffic that has 239 not been explicitly assigned to another P-tunnel. 241 5. Use of Wild Cards with Bidirectional P-Tunnels 243 The specification for the use of wild cards with bidirectional 244 P-Tunnels can be found in [MVPN_BIDIR]. 246 6. IANA Considerations 248 This document requires no actions of IANA. 250 7. Security Considerations 252 There are no additional security considerations beyond those of 253 [MVPN] and [MVPN-BGP]. 255 8. Acknowledgments 257 The authors wish to thank Arjen Boers for many helpful discussions. 259 9. Authors' Addresses 261 Yiqun Cai 262 Cisco Systems, Inc. 263 170 Tasman Drive 264 San Jose, CA, 95134 265 E-mail: ycai@cisco.com 267 Eric C. Rosen 268 Cisco Systems, Inc. 269 1414 Massachusetts Avenue 270 Boxborough, MA, 01719 271 E-mail: erosen@cisco.com 273 IJsbrand Wijnands 274 Cisco Systems, Inc. 275 De kleetlaan 6a Diegem 1831 276 Belgium 277 E-mail: ice@cisco.com 279 10. Normative References 281 [BIDIR-PIM] "Bidirectional Protocol Independent Multicast", Handley, 282 Kouvelas, Speakman, Vicisano, RFC 5015, October 2007 284 [BGP-MP] "Multiprotocol Extensions for BGP-4", T. Bates, R. Chandra, 285 D. Katz, Y. Rekhter, RFC 4760, January 2007 287 [MVPN] "Multicast in MPLS/BGP IP VPNs", Rosen, Aggarwal, et. al., 288 draft-ietf-l3vpn-2547bis-mcast-10.txt, January 2010 290 [MVPN-BGP] "BGP Encodings and Procedures for Multicast in MPLS/BGP IP 291 VPNs", Aggarwal, Rosen, Morin, Rekhter, Kodeboniya, 292 draft-ietf-l3vpn-2547bis-mcast-bgp-08.txt, September 2009 294 [PIM] "Protocol Independent Multicast - Sparse Mode (PIM-SM): 295 Protocol Specification (Revised)", Fenner, Handley, Holbrook, 296 Kouvelas, RFC 4601, August 2006 298 [RFC2119] "Key words for use in RFCs to Indicate Requirement 299 Levels.", Bradner, March 1997 301 11. Informative References 303 [MVPN-BIDIR] "MVPN: Using Bidirectional P-Tunnels", Cai, Rosen, 304 Wijnands, draft-rosen-l3vpn-mvpn-bidir-02.txt, January 2011