idnits 2.17.1 draft-rekhter-mvpn-wildcard-spmsi-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 2 errors (**), 0 flaws (~~), 2 warnings (==), 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: January 2010 Praveen Muley (Alcatel-Lucent) 5 Intended Status: Proposed Standard Yakov Rekhter (Juniper Networks) 7 Use of Wildcard in S-PMSI Auto-Discovery Routes 9 draft-rekhter-mvpn-wildcard-spmsi-00.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright and License Notice 33 Copyright (c) 2009 IETF Trust and the persons identified as the 34 document authors. All rights reserved. 36 This document is subject to BCP 78 and the IETF Trust's Legal 37 Provisions Relating to IETF Documents in effect on the date of 38 publication of this document (http://trustee.ietf.org/license-info). 39 Please review these documents carefully, as they describe your rights 40 and restrictions with respect to this document. 42 This document may contain material from IETF Documents or IETF 43 Contributions published or made publicly available before November 44 10, 2008. The person(s) controlling the copyright in some of this 45 material may not have granted the IETF Trust the right to allow 46 modifications of such material outside the IETF Standards Process. 47 Without obtaining an adequate license from the person(s) controlling 48 the copyright in such materials, this document may not be modified 49 outside the IETF Standards Process, and derivative works of it may 50 not be created outside the IETF Standards Process, except to format 51 it for publication as an RFC or to translate it into languages other 52 than English. 54 Abstract 56 The current MVPN specifications do not define encoding and procedures 57 for advertising in a single route binding of multiple multicast 58 streams of a given MVPN customer to a single provider's tunnel. This 59 document defines such encoding and procedures. These procedures allow 60 in certain situations to reduce MVPN control plane load (note though 61 that these procedures have no impact on the data plane load). The 62 procedures specified in this document assume that BGP is used for 63 transmission of MVPN customers' routing information within the 64 service provider(s) infrastructure. 66 Specification of Requirements 68 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 69 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 70 document are to be interpreted as described in RFC 2119 [RFC2119]. 72 1. Introduction 74 An S-PMSI auto-discovery route (A-D route), as defined in [MVPN-BGP], 75 advertises binding of a given MVPN customer multicast flow (C- 76 multicast flow) to a particular provider tunnel (P-tunnel). While the 77 definition and procedures specified in [MVPN-BGP] support binding of 78 multiple C-multicast flows to the same P-tunnel (by having multiple 79 S-PMSI A-D routes advertise the same P-tunnel), they do not support 80 the ability to advertise such a binding in a single S-PMSI A-D route. 82 The ability of a PE to advertise binding of multiple C-multicast 83 flows, all originating from the site(s) of a given MVPN connected to 84 that PE, to a single P-tunnel in a single S-PMSI A-D route, rather 85 than in multiple S-PMSI A-D routes (one per each C-multicast flow) 86 improves control plane scalability, as it reduces the number of S- 87 PMSI A-D routes. Note however, that the ability to advertise binding 88 of multiple C-multicast flows to a single P-tunnel in a single S-PMSI 89 A-D route has no impact on the forwarding/data plane scalability, as 90 it does not reduces the number of P-tunnels, relative to the scenario 91 where each C-multicast flow is advertised via its own S-PMSI A-D 92 route, while all these routes advertise the same P-tunnel. 94 One possible application of advertising binding of multiple C- 95 multicast flows to a single P-tunnel in a single S-PMSI A-D route is 96 when a customer is using ASM multicast. In this case a PE router 97 connected to an MVPN customer's site that contains customer's RP (C- 98 RP) could bind all the C-multicast flows traveling along a customer's 99 RPT tree to a single P-tunnel, and advertise such binding in a single 100 S-PMSI A-D route. Likewise, a PE router connected to an MVPN 101 customer's site that contains multiple (multicast) sources, all 102 sending to the same (multicast) group, could bind all the C-mulicast 103 flows for that group originated by these sources to a single P- 104 tunnel, and advertise such binding in a single S-PMSI A-D route. 106 Another possible application of advertising binding of multiple C- 107 multicast flows to a single P-tunnel in a single S-PMSI A-D route is 108 when a customer is using PIM-Bidir. In this case a PE router could 109 bind to a single P-tunnel all the C-multicast flows for the same 110 (multicast) group that have been originated within the site(s) of a 111 given MVPN connected to that PE, and advertise such binding in a 112 single S-PMSI A-D route. 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 encoding and procedures for advertising in a 120 single S-PMSI A-D route binding of multiple C-multicast flows to a 121 single P-tunnel. The encoding and procedures are based on the notion 122 of a "wildcard". 124 The procedures specified in this document assume that BGP is used for 125 transmission of MVPN customers' multicast (C-multicast) routing 126 information within the service provider(s) infrastructure among the 127 PE routers ([MVPN-BGP]). 129 2. Encoding of wildcard in S-PMSI A-D routes 131 As specified in [MVPN-BGP], the NLRI of an S-PMSI A-D route has the 132 following format: 134 +-----------------------------------+ 135 | RD (8 octets) | 136 +-----------------------------------+ 137 | Multicast Source Length (1 octet) | 138 +-----------------------------------+ 139 | Multicast Source (Variable) | 140 +-----------------------------------+ 141 | Multicast Group Length (1 octet) | 142 +-----------------------------------+ 143 | Multicast Group (Variable) | 144 +-----------------------------------+ 145 | Originating Router's IP Addr | 146 +-----------------------------------+ 148 This document uses a zero value in Mutlicast Source Length or 149 Multicast Group Length field to indicate a wildcard value for the 150 respective field. This document defines procedures for the following 151 two combinations of wildcard S-PMSI encodings: 153 + (C-*, C-G): Source Wildcard, Group specified 155 + (C-*, C-*): Source Wildcard, Group Wildcard 157 3. Procedures for (C-*, C-G) S-PMSI A-D routes 159 When a PE advertises an S-PMSI A-D route whose NLRI specifies (C-*, 160 C-G), the PE MUST use the P-tunnel advertised in this route for 161 sending any C-multicast flows for that C-G that it needs to send 162 (downstream) to other PEs, except for the C-multicast flows that the 163 PE already bound to specific (C-S, C-G)s S-PMSIs. 165 When a PE receives an S-PMSI A-D route whose NLRI specifies (C-*, C- 166 G), the PE follows the procedures specified in [MVPN-BGP], except for 167 the case where the PE does not originate a Shared Tree Join C- 168 multicast route for (C-*, C-G), and for every Source Tree Join C- 169 multicast route for (C-S, C-G) originated by the PE, the PE already 170 accepted a (specific) (C-S, C-G) S-PMSI A-D route. In that case the 171 PE need not take any further action upon receiving the S-PMSI A-D 172 route with (C-*, C-G) NLRI. 174 4. Procedures for (C-*, C-*) S-PMSI A-D routes 176 When a PE advertises an S-PMSI A-D route whose NLRI specifies (C-*, 177 C-*), the PE MUST use the P-tunnel advertised in this route for 178 sending any C-multicast flows that it needs to send (downstream) to 179 other PEs, except for the C-multicast flows that the PE already bound 180 to either specific (C-*, C-G)s S-PMSIs, or specific (C-S, C-G)s S- 181 PMSIs. 183 To facilitate description of the procedures for receiving (C-*, C-*) 184 S-PMSI A-D routes, we introduce the following definitions: 186 + We say that an (C-S, C-G) S-PMSI A-D route received by a PE 187 "matches" a Source Tree Join C-multicast route for (C-S, C-G) 188 originated by that PE if the upstream PE of that route is the PE 189 that originates the S-PMSI A-D route. 191 + We say that an (C-*, C-G) S-PMSI A-D route received by a PE 192 "matches" a Source Tree Join C-multicast route for (C-S, C-G) 193 originated by that PE if the upstream PE of that route is the PE 194 that originates the S-PMSI A-D route. 196 + We say that an (C-*, C-G) S-PMSI A-D route received by a PE 197 "matches" a Shared Tree Join C-multicast route for (C-*, C-G) 198 originated by that PE if the upstream PE of that route is the PE 199 that originates the S-PMSI A-D route. 201 When a PE receives an S-PMSI A-D route whose NLRI specifies (C-*, 202 C-*), the PE follows the procedures specified in [MVPN-BGP], except 203 when: 205 + for all the Source Tree Join C-multicast routes originated by the 206 PE, the PE already accepted either a matching (C-S, C-G), or a 207 matching (C-*, C-G) S-PMSI A-D route, AND 209 + for all the Shared tree Join C-multicast routes originated by the 210 PE, the PE already accepted a matching (C-*, C-G) S-PMSI A-D 211 route, 213 in which case the PE need not take any further action upon receiving 214 the S-PMSI A-D route with NLRI (C-*, C-*). 216 5. IANA Considerations 218 This document introduces no new IANA Considerations. 220 6. Security Considerations 222 This document introduces no new Security Considerations, above and 223 beyond what is already specified in [MVPN] and [MVPN-BGP]. 225 7. Acknowledgements 227 TBD 229 8. Normative References 231 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 232 Requirement Levels", BCP 14, RFC 2119, March 1997. 234 [MVPN] E. Rosen, R. Aggarwal [Editors], "Multicast in MPLS/BGP IP 235 VPNs", draft-ietf-l3vpn-2547bis-mcast, work in progress 237 [MVPN-BGP], R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter, "BGP 238 Encodings for Multicast in MPLS/BGP IP VPNs", draft-ietf- 239 l3vpn-2547bis-mcast-bgp, work in progress 241 9. Non-normative References 243 10. Author Information 245 Rahul Aggarwal 246 Juniper Networks, Inc. 247 e-mail: rahul@juniper.net 249 Wim Henderickx 250 Alcatel-Lucent 251 e-mail: wim.henderickx@alcatel-lucent.be 253 Praveen Muley 254 Alcatel-Lucent 255 e-mail: Praveen.Muley@alcatel-lucent.com 257 Yakov Rekhter 258 Juniper Networks, Inc. 259 e-mail: yakov@juniper.net