idnits 2.17.1 draft-zzhang-l3vpn-mvpn-global-table-mcast-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6514]), 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 (July 12, 2013) is 3941 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC6625' is defined on line 348, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 4601 (Obsoleted by RFC 7761) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Zhang 3 Internet-Draft Giuliano 4 Intended status: Informational Juniper Networks 5 Expires: January 13, 2014 Pacella 6 Verizon 7 Schiller 8 Google 9 July 12, 2013 11 Global Table Multicast with BGP-MVPN Procedures 12 draft-zzhang-l3vpn-mvpn-global-table-mcast-00.txt 14 Abstract 16 This document describes a way to implement Global Table Multicast, 17 aka Internet Multicast, using BGP encodings and procedures for MVPN 18 as specified in [RFC6514]. 20 No protocol modification/extension is required. This is purely for 21 informational and clarifying purposes only. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 13, 2014. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 59 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3.1. Considerations for GTM with BGP-MVPN . . . . . . . . . . . 6 61 3.2. IBGP session between MBRs and non-MBRs . . . . . . . . . . 6 62 3.3. Non-BGP UMH Routes or BGP UMH routes not originated by 63 the MBRs . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 66 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 69 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 72 1. Introduction 74 [RFC6513] and [RFC6514] specify procedures and encodings to implement 75 Multicast for L3VPNs (MVPN). [RFC6513] specifies general concepts 76 and procedures that apply to PIM-based and/or BGP-based C-Multicast 77 State Signaling (referred to PIM-MVPN and BGP-MVPN respectively), and 78 [RFC6514] specifies BGP procedures and encodings used by both PIM- 79 MVPN and BGP-MVPN. 81 While [RFC6513] and [RFC6514] assume the context of VPN, they can be 82 used to implement Global (vs. VRF) Table Multicast as well, without 83 any protocol modification/extension, even though the RFCs do not 84 explicitly mention it. 86 Consider a provider network in which the "core" part of it uses MPLS 87 P2MP LSPs or Ingress Replication over either P2P LSPs (with RSVP-TE) 88 or MP2P LSPs (with LDP) instead of PIM to carry multicast traffic 89 among the MPLS Border Routers (MBRs) of the core. Those MBRs run PIM 90 on interfaces connected to other routers outside the core. 92 This document describes how Global Table Multicast can be implemented 93 using BGP-MVPN procedures. We start with a simple reference scenario 94 below, and also discuss one slightly different scenario and another 95 special one. 97 With Global Table Multicast (GTM) implemented by BGP-MVPN procedures, 98 most of the features/characteristics of BGP-MVPN apply, including 99 scaling, aggregation, flexible choice of provider tunnels, wild-card 100 S-PMSI, support for PIM-DM/ASM/SSM/Bidir as PE-CE multicast protocol, 101 support for both IPv4 and IPv6 with IPv4 infrastructure, support for 102 unsolicited flooded data, including support for BSR as RP-to-group 103 mapping protocols, etc. While it is different from the GTM procedure 104 specified in [seamless-mcast], the two can co-exist. 106 In the rest of the document, the term MBR (MPLS Border Router) is 107 used to denote a router that runs BGP-MVPN procedures for Global 108 Table Multicast, analogous to a PE in a true VPN Environment. In 109 other words, MBRs border the BGP-MVPN domain, which could even be 110 inter-AS. 112 2. Requirements Language 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [RFC2119]. 118 3. Operation 120 In the simplest reference scenario, PIM runs between the MBRs and 121 their adjacent non-MBRs, and the MBRs advertise to each other Reverse 122 Path Forwarding (RPF) routes to multicast sources via iBGP (with or 123 without RRs in the middle) with Next Hop set to themselves. The 124 routes are learned from routers outside of the core via eBGP or IGP. 125 Note that with BGP-MVPN, the RPF routes are referred to as UMH 126 (Upstream Multicast Hop) Routes. In this document the two terms are 127 used interchangeably. 129 Conceptually and functionally, those MBRs resemble MVPN PEs: 130 connections to other routers outside the core can be treated as PE-CE 131 interfaces and MVPN procedures can run among the PEs (i.e., MBRs) for 132 Discovery, Tunnel Binding, and Multicast State Signaling. 134 RFC 6514 specifies that MCAST-VPN I/S-PMSI A-D routes and Source 135 Active A-D routes carry certain Route Targets, allowing them to be 136 imported into appropriate VRFs. By default, the Route Targets are 137 the same as for unicast routing, but any configured set of Route 138 Targets can be used. For GTM using procedures in this document, 139 Route Targets are used to associate the A-D routes with GTM the same 140 way as a configured set of Route Targets are used as specified in RFC 141 6514. By default, an (auto-)configured Route Target is used: an IPv4 142 Address Specific Extented Community with both the Global and Local 143 Administrative Fields being 0. 145 RFC 6514 specifies that MCAST-VPN routes carry a Route Distinguisher 146 (RD). For GTM, it SHOULD be possible to configure an RD that is used 147 only for MCAST-VPN A-D routes for the global table. The RD can be 148 defaulted to a special 64-bit all-zero value (denoted as RD 0:0). 149 Note that RD 0:0 is not valid as a VRF RD, and unlike in 150 [seamless-mcast] the use of RD 0:0 per this docuement does not modify 151 the semantics of any BGP route in which it appears. Obviously, while 152 using RD 0:0 per this document, the GTM procedures specified in 153 [seamless-mcast] cannot be used for the global table. 155 Unlike in VPN case, the unicast routes in global table are not 156 advertised with RDs. As a result, for C-multicast routes, the above 157 mentioned configured RD value (including the special RD 0:0) is used 158 when the originating MBR and the Upstream MBR is in the same AS. For 159 comparison, RFC 6514 specifies in section 11.1.3 that the RD of the 160 VPN-IP route is used. 162 Additionally, due to the lack of RD in the unicast route 163 advertisements, an egress PE may not receive all advertisements from 164 all the MBRs that a multicast source or RP is multi-homed to. This 165 may be the case even when BGP add-path is used. As a result, the 166 Single Forwarder Selection procedure in RFC 6513 may not guarantee 167 that all egress MBRs select the same Upstream MBR. Therefore, 168 procedures in Section 9.1.1 of RFC 6513 MUST be used to ensure that 169 an egress PE only forward traffic sent by the Upstream MBR that it 170 selects. 172 When an MBR advertises UMH routes via BGP over the core, it attaches 173 a VRF Route Import Extended Community and Source AS Extended 174 Community. as specified in Section 7 of RFC 6514. When constructing 175 the C-multicast Import RT as specified in Section 7 of [RFC6514], it 176 is RECOMMENDED that the Local Administrator field is set to 0, though 177 an implementation MAY use any value that can uniquely associate it to 178 the global routing table (vs. a VRF). 180 3.1. Considerations for GTM with BGP-MVPN 182 The following should be considered when using BGP-MVPN for GTM. 184 o As mentioned above, Single Forwarder Selection procedure cannot be 185 used. This is a limitation when multiple MBRs may be the Upstream 186 MBR for the same source or RP. 188 o There are potentially many more MBRs for GTM than PEs for a 189 particular VPN. As a result, use of inclusive tunnels should be 190 avoided (or with fan-out reduced by using tunnel segmentation as 191 specified in [seamless-mcast]). 193 o Internet providers often make extensive use of BGP communities 194 (ie, adding, deleting, modifying communities throughout a 195 network). As such, care should be taken to avoid deleting or 196 modifying the VRF Route Import Extended Community and Source AS 197 Extended Community. 199 3.2. IBGP session between MBRs and non-MBRs 201 In the simple reference scenario above, it is assumed that the MBRs 202 learn UMH routes from non-MBRs via eBGP or IGP. This assumption 203 helps illustrate the analogy to a true VPN environment. In a 204 different deployment scenario, the MBRs could have learned the UMH 205 routes over iBGP sessions to non-MBRs. If the MBRs act as RRs and 206 reflect the UMH routes to other MBRs with polices to attach VRF Route 207 Import Extended Community and Source AS Extended Community, BGP-MVPN 208 procedures can still be used as described earlier. Even if the MBRs 209 do not act as RRs, the scenario could be considered analogous to what 210 [RFC6368] describes. As long as MBRs re-advertise those UMH routes 211 with the above mentioned communities, BGP-MVPN procedures can be used 212 as described earlier. Note that they do not even need to use the 213 push/pop procedures in [RFC6368] - the only requirement is for the 214 MBRs to re-advertise the routes learned over iBGP sessions from non- 215 MBRs to other MBRs over iBGP sessions. 217 3.3. Non-BGP UMH Routes or BGP UMH routes not originated by the MBRs 219 With true MVPN, the PEs advertise the UMH routes themselves as VPN-IP 220 routes, and attach a VRF Route Import Extended Community that has the 221 C-multicast Import RT value for the VRF associated with the routes. 222 The VRF Route Import Extended Community is extracted by egress PEs 223 and attached to their C-Multicast Routes as Route Target Extended 224 Community to control the distribution to and importation by relevant 225 upstream PEs. 227 With Global Table Multicast, in both the simple reference scenario 228 and the above mentioned variance, the MBRs do (re-)advertise the UMH 229 routes as required for BGP-MVPN. However, in other situations, it is 230 possible that the UMH routes are not advertised by the MBRs via BGP 231 at all, hence they may not carry the VRF Route Import Extended 232 Community. 234 Consider the following example: 236 |---- Site 1 -------| 238 EBGP 239 src----R3------R1/CE1 -------MBR1/PE1 240 \ /| 241 |\ / | 242 | \IBGP / | 243 | \ / | 244 | \ / | 245 | X | 246 | / \ | 247 | / \ | 248 | /mesh \ | 249 |/ \ | 250 / \| 251 rcv----R4------R2/CE2 -------MBR2/PE2 252 EBGP 254 |---- Site 2 -------| 256 There is a full-mesh of IBGP sessions among provider routers R1/MBR1/ 257 MBR2/R2. EBGP sessions run between R3/R1 and between R4/R2. MBR1/ 258 MBR2 run BGP-MVPN procedures for Global Table Multicast. R1 learns 259 of BGP route to the source from R3 and advertises it to MBRx/R2. 261 Because R1 does not run MVPN, MBR2's route to the source (learned 262 from R1 instead of MBR1) does not have the VRF Route Import Extended 263 Community. Therefore, it would not be able to correctly attach a 264 Route Target Extended Community corresponding to MBR1 in its 265 C-Multicast Routes. 267 To handle that situation, MBR2 performs the following recursively to 268 potentially identify the Upstream MBR and derive a VRF Route Import 269 Extended Community. Note that the route in the following procedure 270 is either the UMH-eligible route for the source itself, or the route 271 to the Next Hop of the BGP route in the previous recursion. 273 o If the route is a BGP route with a VRF Route Import Extended 274 Community, that VRF Route Import Extended Community is used. 276 o If the route is a BGP route without a VRF Route Import Extended 277 Community, get the route to the Next Hop and recurse. 279 o If the route is an IGP route with a RSVP-TE LSP as next hop, and 280 the LSP endpoint is a MBR (MBR1 in the above example) that 281 advertises an Intra-AS I-PMSI or an S-PMSI A-D route, a VRF Route 282 Import Extended Community is constructed as MBR_addr:0 to be 283 associated with the UMH-eligible route, where the MBR_addr is the 284 Originating Router's IP Address of the Intra-AS I-PMSI or S-PMSI 285 A-D route. 287 Constructing the VRF Route Import as MBR_addr:0 by an egress MBR in 288 the above special situation explains why it is RECOMMENDED that the 289 Local Administrator is set to 0 when an upstream MBR constructs its 290 C-Multicast Import RT - the zero value is a special value agreed on 291 apriori by all (vs. a local value that is normally picked by the 292 upstream MBR and signaled via the VRF Route Import Extended 293 Community). 295 If the above procedure does not produce a usable VRF Route Import 296 Extended Community, then the UMH route is considered a local route 297 (vs. a remote route that is associated with an Upstream MBR). If the 298 UMH is indeed remote (over the core) but considered as local by the 299 above procedure, then the above scenario will obviously not work. 301 Note that the above procedure is necessary only if the MBRs (that run 302 MVPN procedures) do not advertise the UMH routes via BGP and include 303 VRF Route Import Extended Community in such routes. The egress MBRs 304 can obtain/derive the VRF Route Import Extended Community as long as 305 the UMH-eligible route is or resolves recursively to one of the 306 folllowing: 308 o A BGP route that carries a VRF Route Import Extended Community 309 (this route could even be to an MBR and advertised by the MBR 310 itself). Or, 312 o An IGP route with a RSVP-TE LSP as next hop, and the LSP endpoint 313 matches the Originating Router's IP Address of an Intra-AS I-PMSI 314 or S-PMSI A-D route. 316 4. Security Considerations 318 This document raises no new security issues. Security considerations 319 for the base protocols are covered in [RFC6514], [RFC4601], and 320 [RFC5294]. 322 5. IANA Considerations 324 This document has no IANA considerations. 326 This section should be removed by the RFC Editor prior to final 327 publication. 329 6. Acknowledgements 331 The authors would like to thank Rahul Aggarwal, Yakov Rehkter and 332 Eric Rosen for their comments and suggestions. 334 7. References 336 7.1. Normative References 338 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 339 Requirement Levels", BCP 14, RFC 2119, March 1997. 341 [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP 342 VPNs", RFC 6513, February 2012. 344 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 345 Encodings and Procedures for Multicast in MPLS/BGP IP 346 VPNs", RFC 6514, February 2012. 348 [RFC6625] Rosen, E., Rekhter, Y., Hendrickx, W., and R. Qiu, 349 "Wildcards in Multicast VPN Auto-Discovery Routes", 350 RFC 6625, May 2012. 352 7.2. Informative References 354 [RFC6368] Marques, P., Raszuk, R., Patel, K., Kumaki, K., and T. 355 Yamagata, "Internal BGP as the Provider/Customer Edge 356 Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)", 357 RFC 6368, September 2011. 359 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 360 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 361 Protocol Specification (Revised)", RFC 4601, August 2006. 363 [RFC5294] Savola, P. and J. Lingard, "Host Threats to Protocol 364 Independent Multicast (PIM)", RFC 5294, August 2008. 366 [seamless-mcast] 367 Rekhter, Y., "Inter-Area P2MP Segmented LSPs", 368 draft-ietf-mpls-seamless-mcast-06.txt. 370 Authors' Addresses 372 Jeffrey Zhang 373 Juniper Networks 374 10 Technology Park Dr. 375 Westford, MA 01886 376 US 378 Email: zzhang@juniper.net 380 Lenny Giuliano 381 Juniper Networks 382 2251 Corporate Park Drive 383 Herndon, VA 20171 384 US 386 Email: lenny@juniper.net 388 Dante J. Pacella 389 Verizon 390 Verizon Communications 391 22001 Loudoun County Parkway 392 Ashburn, VA 20147 393 US 395 Email: dante.j.pacella@verizonbusiness.com 397 Jason Schiller 398 Google 399 1818 Library Street 400 Suite 400 401 Reston, VA 20190 402 US 404 Email: jschiller@google.com