idnits 2.17.1 draft-zzhang-mboned-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 (February 16, 2013) is 4087 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- 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 Zhang 3 Internet-Draft Giuliano 4 Intended status: Informational Juniper Networks 5 Expires: August 20, 2013 Pacella 6 Verizon 7 February 16, 2013 9 Global Table Multicast with BGP-MVPN Procedures 10 draft-zzhang-mboned-mvpn-global-table-mcast-00.txt 12 Abstract 14 This document describes a way to implement Global Table Multicast, 15 aka Internet Multicast, using BGP encodings and procedures for MVPN 16 as specified in [RFC6514]. 18 No protocol modification/extension is required. This is purely for 19 informational and clarifying purposes only. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on August 20, 2013. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 57 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3.1. IBGP session between BRs and non-BRs . . . . . . . . . . . 5 59 3.2. Non-BGP RPF Routes or BGP RPF routes not originated by 60 the BRs . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 63 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 66 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 69 1. Introduction 71 [RFC6513] and [RFC6514] specify procedures and encodings to implement 72 Multicast for L3VPNs (MVPN). [RFC6513] specifies general concepts 73 and procedures that apply to PIM-based and/or BGP-based C-Multicast 74 State Signaling (referred to PIM-MVPN and BGP-MVPN respectively), and 75 [RFC6514] specifies BGP procedures and encodings used by both PIM- 76 MVPN and BGP-MVPN. 78 While [RFC6513] and [RFC6514] assume the context of VPN, they can be 79 used to implement Global (vs. VRF) Table Multicast as well, without 80 any protocol modification/extension, even though the RFCs do not 81 explicitly mention it. 83 Consider a provider network where the "core" part of it uses MPLS 84 P2MP LSPs or Ingress Replication over either P2P LSPs (with RSVP-TE) 85 or MP2P LSPs (with LDP) instead of PIM to carry multicast traffic 86 among the border routers (BRs) of the core. Those BRs run PIM on 87 interfaces connected to other routers outside the core. 89 This document describes how Global Table Multicast can be implemented 90 using BGP-MVPN procedures. We start with a simple reference scenario 91 below, and also discuss one slightly different scenario and another 92 special one. 94 With Global Table Multicast implemented by BGP-MVPN procedures, all 95 the features/characteristics of BGP-MVPN apply, including scaling, 96 aggregation, flexible choice of provider tunnels, support for PIM-DM/ 97 ASM/SSM/Bidir as PE-CE multicast protocol, BSR and AUTO-RP as RP-to- 98 group mapping protocols, etc. 100 2. Requirements Language 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [RFC2119]. 106 3. Operation 108 In the simplest reference scenario, the BRs advertise to each other 109 RPF routes to multicast sources via iBGP (with or without RRs in the 110 middle) with Next Hop set to themselves. The routes could have been 111 learned from other non-BRs via eBGP or IGP. 113 Conceptually and functionally, those BRs are just like MVPN PEs: 114 connections to other routers outside the core can be treated as PE-CE 115 interfaces and MVPN procedures can run among the PEs (i.e., BRs) for 116 Discovery, Tunnel Binding, and Multicast State Signaling. 118 With that, using BGP-MVPN procedures for Global Table Multicast is 119 straightforward and requires almost no further clarification. 120 However, some popular practices are described below. 122 By default, RD 0:0 is used when advertising A-D routes for Global 123 Table Multicast, though an implementation MAY support the 124 configuration and use of a different RD value. 126 Similarly, when constructing the C-multicast Import RT as specified 127 in Section 7 of [RFC6514], it is RECOMMENDED that the Local 128 Administrator field is set to 0, though an implementation MAY use any 129 value that can uniquely associate it to the global routing table (vs. 130 a VRF). 132 3.1. IBGP session between BRs and non-BRs 134 In the simple reference scenario above, it is assumed that the BRs 135 learn RPF routes from non-BRs via eBGP or IGP. The assumption is to 136 illustrate the analogy to a true VPN environment. In another 137 deployment scenario, the BRs could have learned the RPF routes over 138 those iBGP sessions to non-BRs. If the BRs act as RRs and reflect 139 the RPF routes to other BRs with polices to attach VRF Route Import 140 Extended Community and Source AS Extended Community, BGP-MVPN 141 procedures can still be used as described earlier. Even if the BRs 142 do not act as RRs, the scenario could be considered analogous to what 143 [RFC6368] describes. As long as BRs re-advertise those RPF routes 144 with the above mentioned communities, BGP-MVPN procedures can be used 145 as described earlier. Note that they do not even need to use the 146 push/pop procedures in [RFC6368] - the only requirement is for the 147 BRs to re-advertise the routes learned over iBGP sessions from non- 148 BRs to other BRs over iBGP sessions. 150 3.2. Non-BGP RPF Routes or BGP RPF routes not originated by the BRs 152 With true MVPN, the PEs advertise the RPF routes themselves as VPN-IP 153 routes, and attach a VRF Route Import Extended Community that has the 154 C-multicast Import RT value for the VRF associated with the routes. 155 The VRF Route Import Extended Community is extracted by egress PEs 156 and attached to their C-Multicast Routes as Route Target Extended 157 Community to control the distribution to and importation by relevant 158 ingress PEs. 160 With Global Table Multicast, in both the simple reference scenario 161 and the above mentioned variance, the BRs do (re-)advertise the RPF 162 routes as required for BGP-MVPN. However, in other situations, it is 163 possible that the RPF routes are not advertised by the BRs via BGP at 164 all, hence they may not carry the VRF Route Import Extended 165 Community. 167 Consider the following example: 169 |---- Site 1 -------| 171 EBGP 172 src--CPE1-----GW1/CE1 -------BR1/PE1 173 \ /| 174 |\ / | 175 | \IBGP / | 176 | \ / | 177 | \ / | 178 | X | 179 | / \ | 180 | / \ | 181 | / \ | 182 |/ \ | 183 / \| 184 rcv--CPE2-----GW2/CE2 -------BR2/PE2 185 EBGP IBGP 187 |---- Site 2 -------| 189 There is a full-mesh of IBGP sessions among provider routers GW1/BR1/ 190 BR2/GW2. EBGP sessions run between CPE1/GW1 and between CPE2/GW2. 191 Border routers BR1/BR2 run BGP-MVPN procedures for Global Table 192 Multicast. GW1 learns of BGP route to the src from CPE1 and 193 advertises it to BRx/GW2. 195 Because GW1 does not run MVPN, BR2's route to the src (learned from 196 GW1 instead of BR1) does not have the VRF Route Import Extended 197 Community. Therefore, it would not be able to correctly attach a 198 Route Target Extended Community corresponding to BR1 in its 199 C-Multicast Routes. 201 To handle that situation, BR2 performs the following recursively. 202 Note that the route in the following procedure is either the RPF 203 route for the source itself, or the route to the Next Hop of the BGP 204 route in the previous recursion. 206 o If the route is a BGP route with a VRF Route Import Extended 207 Community, that VRF Route Import Extended Community is used. 209 o If the route is a BGP route without a VRF Route Import Extended 210 Community, get the route to the Next Hop and recurse. 212 o If the route is an IGP route with a RSVP-TE LSP as next hop, and 213 the LSP endpoint is a BR that advertises an Intra-AS I-PMSI A-D 214 route (BR1 in the above example), a VRF Route Import Extended 215 Community is constructed as BR_addr:0 to be associated with the 216 RPF route, where the BR_addr is the Originating Router's IP 217 Address of the Intra-AS I-PMSI A-D route. 219 If the above procedure does not produce a usable VRF Route Import 220 Extended Community, then the RPF route is considered a local route 221 (vs. a remote route that is associated with a remote BR). Note that 222 the special process is necessary only if the BRs (that run MVPN 223 procedures) do not advertise the RPF routes via BGP and include VRF 224 Route Import Extended Community in such routes. 226 Constructing the VRF Route Import as BR_addr:0 by an egress BR in the 227 above special situation explains why it is RECOMMENDED that the Local 228 Administrator is set to 0 when an ingress BR constructs its 229 C-Multicast Import RT - the zero value is a special value agreed on 230 apriori by all (vs. a local value that is normally picked by the 231 ingress router and signaled via the VRF Route Import Extended 232 Community). 234 4. Security Considerations 236 This document raises no new security issues. Security considerations 237 for the base protocol are covered in [RFC6514]. 239 5. IANA Considerations 241 This document has no IANA considerations. 243 This section should be removed by the RFC Editor prior to final 244 publication. 246 6. Acknowledgements 248 The authors would like to thank Rahul Aggarwal and Yakov Rehkter for 249 their comments and suggestions. 251 7. References 253 7.1. Normative References 255 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 256 Requirement Levels", BCP 14, RFC 2119, March 1997. 258 [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP 259 VPNs", RFC 6513, February 2012. 261 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 262 Encodings and Procedures for Multicast in MPLS/BGP IP 263 VPNs", RFC 6514, February 2012. 265 7.2. Informative References 267 [RFC6368] Marques, P., Raszuk, R., Patel, K., Kumaki, K., and T. 268 Yamagata, "Internal BGP as the Provider/Customer Edge 269 Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)", 270 RFC 6368, September 2011. 272 Authors' Addresses 274 Jeffrey Zhang 275 Juniper Networks 276 10 Technology Park Dr. 277 Westford, MA 01886 278 US 280 Email: zzhang@juniper.net 282 Lenny Giuliano 283 Juniper Networks 284 2251 Corporate Park Drive 285 Herndon, VA 20171 286 US 288 Email: lenny@juniper.net 290 Dante J. Pacella 291 Verizon Communications 292 22001 Loudoun County Parkway 293 Ashburn, VA 20147 295 Email: dante.j.pacella@verizonbusiness.com