idnits 2.17.1 draft-rosen-l3vpn-mvpn-wildcards-05.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 3, 2011) is 4830 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 3, 2011 Cisco Systems, Inc. 7 February 3, 2011 9 MVPN: S-PMSI Wild Card Selectors 11 draft-rosen-l3vpn-mvpn-wildcards-05.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 ........ 6 64 4.1 Binding (C-*,C-G) to a Unidirectional P-Tunnel ........ 6 65 4.2 Binding (C-*,C-*) to a Unidirectional P-Tunnel ........ 7 66 5 Use of Wild Cards with Bidirectional P-Tunnels ........ 7 67 6 IANA Considerations ................................... 7 68 7 Security Considerations ............................... 7 69 8 Acknowledgments ....................................... 7 70 9 Authors' Addresses .................................... 7 71 10 Normative References .................................. 8 72 11 Informative References ................................ 9 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 Per [MVPN-BGP] section 4.3, the MCAST-VPN NLRI in an S-PMSI A-D route 171 is encoded as follows: 173 +-----------------------------------+ 174 | RD (8 octets) | 175 +-----------------------------------+ 176 | Multicast Source Length (1 octet) | 177 +-----------------------------------+ 178 | Multicast Source (Variable) | 179 +-----------------------------------+ 180 | Multicast Group Length (1 octet) | 181 +-----------------------------------+ 182 | Multicast Group (Variable) | 183 +-----------------------------------+ 184 | Originating Router's IP Addr | 185 +-----------------------------------+ 187 In S-PMSI A-D routes, the wild card selectors are encoded as follows: 189 - A source wildcard is encoded as a zero-length source field. That 190 is, the "multicast source length" field contains the value 0x00, 191 and the "multicast source" field is omitted. 193 - A group wildcard is encoded as a zero-length group field. That 194 is, the "multicast group length" field contains the value 0x00, 195 and the "multicast group" field is omitted. 197 - We also define a special value of the group wildcard, whose 198 meaning is "all BIDIR-PIM groups". The "BIDIR-PIM group 199 wildcard" is encoded as a group field whose length is 8 bits and 200 whose value is zero. That is, the "multicast group length" field 201 contains the value 0x08, and the "multicast group" field is a 202 single octet containing the value 0x00. 204 In S-PMSI Join messages, the use of an all-zero C-Source or C-Group 205 field is to be interpreted as specifying a wild card value for the 206 respective field. A wild card represents all C-Source or C-group 207 values of a particular address family (IPv4 or IPv6), as specified by 208 the S-PMSI Join message type. A "BIDIR-PIM group wildcard" for the 209 S-PMSI Join message is not defined in this document. 211 An implementation that supports wildcards at all MUST support the 212 following two uses of wildcards: 214 - (C-*,C-G): Source Wildcard, Group specified. 216 - (C-*,C-*): Source Wildcard, Group Wildcard. 218 Additionally, if support for customer BIDIR-PIM flows is being 219 provided, support for the "all BIDIR-PIM groups" wildcard is also 220 REQUIRED. With regard to the procedures of section 4.2, the "all 221 BIDIR-PIM groups" wildcard is treated identically to the (C-*,C-*) 222 wildcard, except that it applies only to BIDIR-PIM groups. 224 This specification does not provide support for the combination of a 225 specified source and a group wildcard. A received S-PMSI A-D route 226 or S-PMSI Join message specifying this combination will be "ignored". 228 4. Binding Wild Cards to Unidirectional P-Tunnels 230 4.1. Binding (C-*,C-G) to a Unidirectional P-Tunnel 232 Consider an S-PMSI A-D Route whose NLRI specifies (C-*,C-G), and that 233 contains a PMSI Tunnel Attribute (PTA) [MVPN-BGP] that specifies a 234 unidirectional P-tunnel. The P-tunnel may be a P2MP LSP, or it may 235 be a unidirectional PIM-created multicast distribution tree specified 236 either as (P-*,P-G) or as (P-S,P-G). 238 Alternately, consider an S-PMSI Join message, whose C-Source and 239 C-Group fields specify (C-*,C-G), and that specifies a unidirectional 240 P-tunnel (either a P2MP LSP or a unidirectional PIM-created multicast 241 distribution tree.) 243 If C-G is known to be an SSM group address, the S-PMSI A-D route or 244 S-PMSI Join message is "ignored". 246 The semantics of binding (C-*,C-G) to a unidirectional P-tunnel are 247 the following: the originator of the S-PMSI A-D route or S-PMSI Join 248 message is saying that if it receives, over a VRF interface, any 249 traffic that is traveling on the (C-*,C-G) shared tree, and if it is 250 to forward such traffic to other PEs, then it will transmit such 251 traffic on the specified P-tunnel. Any PE interested in receiving 252 (C-*,C-G) traffic from the originator (i.e., if the originator is 253 PE's upstream multicast hop for the (C-*,C-G) state) MUST join that 254 P-tunnel. 256 4.2. Binding (C-*,C-*) to a Unidirectional P-Tunnel 258 The originator of an S-PMSI A-D Route or an S-PMSI Join message that 259 binds (C-*,C-*) to a unidirectional P-tunnel is saying that by 260 default, if it is required by its C-PIM instance to forward multicast 261 traffic to any other PE, then by default it will send the traffic on 262 the specified tunnel. The default applies to any traffic that has 263 not been explicitly assigned to another P-tunnel. 265 5. Use of Wild Cards with Bidirectional P-Tunnels 267 The specification for the use of wild cards with bidirectional 268 P-Tunnels can be found in [MVPN_BIDIR]. 270 6. IANA Considerations 272 This document requires no actions of IANA. 274 7. Security Considerations 276 There are no additional security considerations beyond those of 277 [MVPN] and [MVPN-BGP]. 279 8. Acknowledgments 281 The authors wish to thank Arjen Boers, Dongling Duan, Apoorva Karan, 282 Keyur Patel, and Karthik Subramanian for many helpful discussions. 284 9. Authors' Addresses 286 Yiqun Cai 287 Cisco Systems, Inc. 288 170 Tasman Drive 289 San Jose, CA, 95134 290 E-mail: ycai@cisco.com 291 Eric C. Rosen 292 Cisco Systems, Inc. 293 1414 Massachusetts Avenue 294 Boxborough, MA, 01719 295 E-mail: erosen@cisco.com 297 IJsbrand Wijnands 298 Cisco Systems, Inc. 299 De kleetlaan 6a Diegem 1831 300 Belgium 301 E-mail: ice@cisco.com 303 10. Normative References 305 [BIDIR-PIM] "Bidirectional Protocol Independent Multicast", Handley, 306 Kouvelas, Speakman, Vicisano, RFC 5015, October 2007 308 [BGP-MP] "Multiprotocol Extensions for BGP-4", T. Bates, R. Chandra, 309 D. Katz, Y. Rekhter, RFC 4760, January 2007 311 [MVPN] "Multicast in MPLS/BGP IP VPNs", Rosen, Aggarwal, et. al., 312 draft-ietf-l3vpn-2547bis-mcast-10.txt, January 2010 314 [MVPN-BGP] "BGP Encodings and Procedures for Multicast in MPLS/BGP IP 315 VPNs", Aggarwal, Rosen, Morin, Rekhter, Kodeboniya, 316 draft-ietf-l3vpn-2547bis-mcast-bgp-08.txt, September 2009 318 [PIM] "Protocol Independent Multicast - Sparse Mode (PIM-SM): 319 Protocol Specification (Revised)", Fenner, Handley, Holbrook, 320 Kouvelas, RFC 4601, August 2006 322 [RFC2119] "Key words for use in RFCs to Indicate Requirement 323 Levels.", Bradner, March 1997 325 11. Informative References 327 [MVPN-BIDIR] "MVPN: Using Bidirectional P-Tunnels", Cai, Rosen, 328 Wijnands, draft-rosen-l3vpn-mvpn-bidir-02.txt, January 2011