idnits 2.17.1 draft-rekhter-mvpn-wildcard-spmsi-04.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 14, 2011) is 4818 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) No issues found here. 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 Rahul Aggarwal (Juniper Networks) 3 Internet Draft Wim Henderickx (Alcatel-Lucent) 4 Expiration Date: August 2011 Praveen Muley (Alcatel-Lucent) 5 Intended Status: Proposed Standard Ray Qiu (Huawei) 6 Yakov Rekhter (Juniper Networks) 7 February 14, 2011 9 Use of Wildcard in S-PMSI Auto-Discovery Routes 11 draft-rekhter-mvpn-wildcard-spmsi-04.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 other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Copyright Notice 35 Copyright (c) 2010 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Abstract 50 The current MVPN specifications do not define encoding and procedures 51 for advertising in a single route binding of multiple multicast 52 streams of a given MVPN customer to a single provider's tunnel. This 53 document defines such encoding and procedures. These procedures allow 54 in certain situations to reduce MVPN control plane load (note though 55 that these procedures have no impact on the data plane load). The 56 procedures specified in this document assume that BGP is used for 57 transmission of MVPN customers' routing information within the 58 service provider(s) infrastructure. 60 Specification of Requirements 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 64 document are to be interpreted as described in RFC 2119 [RFC2119]. 66 1. Introduction 68 An S-PMSI auto-discovery route (A-D route), as defined in [MVPN-BGP], 69 advertises binding of a given MVPN customer multicast flow (C- 70 multicast flow) to a particular provider tunnel (P-tunnel). While the 71 definition and procedures specified in [MVPN-BGP] support binding of 72 multiple C-multicast flows to the same P-tunnel (by having multiple 73 S-PMSI A-D routes advertise the same P-tunnel), they do not support 74 the ability to advertise such a binding in a single S-PMSI A-D route. 76 The ability of a PE to advertise binding of multiple C-multicast 77 flows, all originating from the site(s) of a given MVPN connected to 78 that PE, to a single P-tunnel in a single S-PMSI A-D route, rather 79 than in multiple S-PMSI A-D routes (one per each C-multicast flow), 80 improves control plane scalability, as it reduces the number of S- 81 PMSI A-D routes. Note however, that the ability to advertise binding 82 of multiple C-multicast flows to a single P-tunnel in a single S-PMSI 83 A-D route has no impact on the forwarding/data plane scalability, as 84 it does not reduces the number of P-tunnels, relative to the scenario 85 where each C-multicast flow is advertised via its own S-PMSI A-D 86 route, while all these routes advertise the same P-tunnel. 88 One possible application of advertising binding of multiple C- 89 multicast flows to a single P-tunnel in a single S-PMSI A-D route is 90 when these are PIM-SM in ASM mode flows. In this case a PE router 91 connected to an MVPN customer's site that contains customer's RP (C- 92 RP) could bind all the C-multicast flows traveling along a customer's 93 RPT tree to a single P-tunnel, and advertise such binding in a single 94 S-PMSI A-D route. Likewise, a PE router connected to an MVPN 95 customer's site that contains multiple (multicast) sources, all 96 sending to the same (multicast) group, could bind all the C-mulicast 97 flows for that group originated by these sources to a single P- 98 tunnel, and advertise such binding in a single S-PMSI A-D route. 100 Another possible application of advertising binding of multiple C- 101 multicast flows to a single P-tunnel in a single S-PMSI A-D route is 102 when these are PIM-Bidir flows. In this case a PE router could bind 103 to a single P-tunnel all the C-multicast flows for the same 104 (multicast) group that have been originated within the site(s) of a 105 given MVPN connected to that PE, and advertise such binding in a 106 single S-PMSI A-D route. 108 Another possible application of advertising binding of multiple C- 109 multicast flows to a single P-tunnel in a single S-PMSI A-D route is 110 when these are PIM-SM in SSM mode flows. In this case a PE router 111 could bind to a single P-tunnel all the C-multicast flows coming from 112 a given (multicast) source located in a site connected to that PE. 114 Yet another possible application of advertising binding of multiple 115 C-multicast flows to a single P-tunnel in a single S-PMSI A-D route 116 is to carry in that P-tunnel all the C-multicast flows originated 117 within the site(s) of a given MVPN connected to a given PE. 119 This document defines OPTIONAL extensions to the procedures specified 120 in [MVPN-BGP]. These extensions allow to advertise in a single S-PMSI 121 A-D route binding of multiple C-multicast flows to a single P-tunnel. 122 The extensions are based on the notion of a "wildcard". 124 In order to use the extensions specified in this document with a 125 particular MVPN, all the PEs that have sites of that MVPN MUST 126 support these extensions. 128 The procedures specified in this document assume that BGP is used for 129 transmission of MVPN customers' multicast (C-multicast) routing 130 information within the service provider(s) infrastructure among the 131 PE routers ([MVPN-BGP]). 133 2. Encoding of wildcard in S-PMSI A-D routes 135 As specified in [MVPN-BGP], the NLRI of an S-PMSI A-D route has the 136 following format: 138 +-----------------------------------+ 139 | RD (8 octets) | 140 +-----------------------------------+ 141 | Multicast Source Length (1 octet) | 142 +-----------------------------------+ 143 | Multicast Source (Variable) | 144 +-----------------------------------+ 145 | Multicast Group Length (1 octet) | 146 +-----------------------------------+ 147 | Multicast Group (Variable) | 148 +-----------------------------------+ 149 | Originating Router's IP Addr | 150 +-----------------------------------+ 152 This document uses a zero value in Mutlicast Source Length or 153 Multicast Group Length field to indicate a wildcard value for the 154 respective field. This document defines procedures for the following 155 two combinations of wildcard S-PMSI encodings: 157 + (C-*, C-G): Source Wildcard, Group specified 159 + (C-S, C-*): Source specified, Group Wildcard 161 + (C-*, C-*): Source Wildcard, Group Wildcard 163 3. Procedures for (C-*, C-G) S-PMSI A-D routes 165 This document covers the use of (C-*, C-G) S-PMSI A-D routes for only 166 the C-multicast flows when C-G is not in the SSM range. Use of (C-*, 167 C-G) S-PMSI A-D routes for other C-multicast flows is outside the 168 scope of this document. 170 When a PE advertises an S-PMSI A-D route whose NLRI specifies (C-*, 171 C-G), the PE MUST use the P-tunnel advertised in this route for 172 sending any PIM-SM in ASM mode or PIM-Bidir C-multicast flows for 173 that C-G that it needs to send (downstream) to other PEs, except for 174 the C-multicast flows that the PE already bound to specific (C-S, C- 175 G)s S-PMSIs. Just like with (C-S, C-G) S-PMSI A-D routes, the 176 criteria for originating (C-*, C-G) S-PMSI A-D routes is local to the 177 originating PE. 179 When a PE receives an S-PMSI A-D route whose NLRI specifies (C-*, C- 180 G), the PE follows the procedures specified in [MVPN-BGP], except for 181 the case where the PE does not originate a Shared Tree Join C- 182 multicast route for (C-*, C-G), and for every Source Tree Join C- 183 multicast route for (C-S, C-G) originated by the PE, the PE already 184 accepted a (specific) (C-S, C-G) S-PMSI A-D route. In that case the 185 PE need not take any further action upon receiving the S-PMSI A-D 186 route with (C-*, C-G) NLRI. 188 If an implementation supports (C-*, C-G) S-PMSI A-D routes, then the 189 implementation MUST support receiving (C-S, C-*) and (C-*, C-*) S- 190 PMSI A-D routes, and MAY support originating (C-S, C-*) and (C-*, 191 C-*) S-PMSI A-D routes. 193 4. Procedures for (C-S, C-*) S-PMSI A-D routes 195 This document covers the use of (C-S, C-*) S-PMSI A-D routes for only 196 the C-multicast flows when C-G is in the SSM range. Use of (C-S, 197 C-*) S-PMSI A-D routes for other C-multicast flows is outside the 198 scope of this document. 200 When a PE advertises an S-PMSI A-D route whose NLRI specifies (C-S, 201 C-*), the PE MUST use the P-tunnel advertised in this route for 202 sending any PIM-SM in SSM mode C-multicast flows for that C-S that it 203 needs to send (downstream) to other PEs, except for the C-multicast 204 flows that the PE already bound to specific (C-S, C-G)s S-PMSIs. 205 Just like with (C-S, C-G) S-PMSI A-D routes, the criteria for 206 originating (C-S, C-*) S-PMSI A-D routes is local to the originating 207 PE. 209 When a PE receives an S-PMSI A-D route whose NLRI specifies (C-S, 210 C-*), the PE follows the procedures specified in [MVPN-BGP], except 211 for the case where for every Source Tree Join C-multicast route for 212 (C-S, C-G) originated by the PE, the PE already accepted a (specific) 213 (C-S, C-G) S-PMSI A-D route. In that case the PE need not take any 214 further action upon receiving the S-PMSI A-D route with (C-S, C-*) 215 NLRI. 217 If an implementation supports (C-S, C-*) S-PMSI A-D routes, then the 218 implementation MUST support receiving (C-*, C-G) and (C-*, C-*) S- 219 PMSI A-D routes, and MAY support originating (C-*, C-G) and (C-*, 220 C-*) S-PMSI A-D routes. 222 5. Procedures for (C-*, C-*) S-PMSI A-D routes 224 (C-*, C-*) S-PMSI A-D routes are expected to be used when for a given 225 MVPN a PE has a policy not to use I-PMSI for carrying multicast 226 traffic originated in the MVPN's site(s) connected to that PE (this 227 is known as "S-PMSI only" mode). 229 When a PE advertises an S-PMSI A-D route whose NLRI specifies (C-*, 230 C-*), the PE MUST use the P-tunnel advertised in this route for 231 sending any C-multicast flows that it needs to send (downstream) to 232 other PEs, except for the C-multicast flows that the PE already bound 233 to either specific (C-*, C-G)s S-PMSIs, or specific (C-S, C-G)s S- 234 PMSIs. 236 Just like with (C-S, C-G) S-PMSI A-D routes, the criteria for 237 originating (C-*, C-*) S-PMSI A-D routes is local to the originating 238 PE. However, the following criteria must be implemented: 240 + An implementation MUST support the ability to trigger origination 241 of a (C-*, C-*) S-PMSI A-D route from a given VRF on a given PE 242 when this PE receives (from some other PE(s)) either a Source 243 Tree Join C-multicast route with the C-S carried in the route 244 being reachable via one of the PE-CE interfaces of that VRF, or a 245 Shared Tree Join C-multicast route with the C-RP carried in that 246 route being reachable via one of the PE-CE interfaces on that 247 VRF. 249 + An implementation MUST also support the ability to trigger 250 origination of a (C-*, C-*) S-PMSI A-D route from a given VRF on 251 a given PE at provisioning time on that PE. 253 To facilitate description of the procedures for receiving (C-*, C-*) 254 S-PMSI A-D routes, we introduce the following definitions: 256 + We say that an (C-S, C-G) S-PMSI A-D route received by a PE 257 "matches" a Source Tree Join C-multicast route for (C-S, C-G) 258 originated by that PE if the upstream PE of that route is the PE 259 that originates the S-PMSI A-D route. 261 + We say that an (C-*, C-G) S-PMSI A-D route received by a PE 262 "matches" a Source Tree Join C-multicast route for (C-S, C-G) 263 originated by that PE if the upstream PE of that route is the PE 264 that originates the S-PMSI A-D route, and C-G is not in the SSM 265 range. 267 + We say that an (C-*, C-G) S-PMSI A-D route received by a PE 268 "matches" a Shared Tree Join C-multicast route for (C-*, C-G) 269 originated by that PE if the upstream PE of that route is the PE 270 that originates the S-PMSI A-D route, and C-G is not in the SSM 271 range. 273 + We say that an (C-S, C-*) S-PMSI A-D route received by a PE 274 "matches" a Source Tree Join C-multicast route for (C-S, C-G) 275 originated by that PE if the upstream PE of that route is the PE 276 that originates the S-PMSI A-D route, and C-G is in the SSM 277 range. 279 When a PE receives an S-PMSI A-D route whose NLRI specifies (C-*, 280 C-*), the PE follows the procedures specified in [MVPN-BGP], except 281 when: 283 + for all the Source Tree Join C-multicast routes originated by the 284 PE, the PE already accepted either a matching (C-S, C-G), or a 285 matching (C-*, C-G), or a matching (C-S, C-*) S-PMSI A-D route, 286 AND 288 + for all the Shared tree Join C-multicast routes originated by the 289 PE, the PE already accepted a matching (C-*, C-G) S-PMSI A-D 290 route, 292 in which case the PE need not take any further action upon receiving 293 the S-PMSI A-D route with NLRI (C-*, C-*). 295 If an implementation supports (C-*, C-*) S-PMSI A-D routes, then the 296 implementation MUST support receiving (C-*, C-G) and (C-S, C-*) S- 297 PMSI A-D routes, and MAY support originating (C-*, C-G) and (C-S, 298 C-*) S-PMSI A-D routes. 300 6. IANA Considerations 302 This document introduces no new IANA Considerations. 304 7. Security Considerations 306 This document introduces no new Security Considerations, above and 307 beyond what is already specified in [MVPN] and [MVPN-BGP]. 309 8. Acknowledgements 311 Many thanks to Thomas Morin for his contributions, review, and 312 comments. 314 9. Normative References 316 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 317 Requirement Levels", BCP 14, RFC 2119, March 1997. 319 [MVPN] E. Rosen, R. Aggarwal [Editors], "Multicast in MPLS/BGP IP 320 VPNs", draft-ietf-l3vpn-2547bis-mcast, work in progress 322 [MVPN-BGP], R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter, "BGP 323 Encodings for Multicast in MPLS/BGP IP VPNs", draft-ietf- 324 l3vpn-2547bis-mcast-bgp, work in progress 326 10. Non-normative References 328 11. Authors' Addresses 330 Rahul Aggarwal 331 Juniper Networks, Inc. 332 e-mail: rahul@juniper.net 334 Wim Henderickx 335 Alcatel-Lucent 336 e-mail: wim.henderickx@alcatel-lucent.be 338 Praveen Muley 339 Alcatel-Lucent 340 e-mail: Praveen.Muley@alcatel-lucent.com 342 Ray (Lei) Qiu 343 2330 Central Expressway 344 Santa Clara, CA 95050 345 USA 346 e-mail: rayq@huawei.com 348 Yakov Rekhter 349 Juniper Networks, Inc. 350 e-mail: yakov@juniper.net