idnits 2.17.1 draft-raggarwa-l3vpn-bgp-mvpn-extranet-08.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([BGP-MVPN]), 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 -- 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 (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Aggarwal 3 Internet Draft Juniper Networks 4 Intended status: Standards Track 5 Expires: February 2013 Y. Rekhter 6 Juniper Networks 8 T. Morin 9 France Telecom 11 W. Henderickx 12 Alcatel-Lucent 14 P. Muley 15 Alcatel-Lucent 17 R. Qiu 18 Huawei 20 August 1 2012 22 Extranet in BGP Multicast VPN (MVPN) 24 draft-raggarwa-l3vpn-bgp-mvpn-extranet-08.txt 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that other 33 groups may also distribute working documents as Internet-Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Abstract 63 This document describes clarifications and extensions to the 64 procedures in [BGP-MVPN] for supporting extranets. The procedures 65 specified in this document assume that BGP is used for transmission 66 of MVPN customers' multicast routing information within the service 67 provider(s) infrastructure. 69 Table of Contents 71 1 Specification of requirements ......................... 3 72 2 Introduction .......................................... 4 73 3 Extranet Service Model ................................ 4 74 4 Routing Exchange in Support of Extranets .............. 5 75 4.1 Exchange of Unicast Routes ............................ 5 76 4.2 Exchange of Source Active and S-PMSI auto-discovery routes 6 77 4.3 Exchange of I-PMSI auto-discovery routes .............. 6 78 5 Originating C-multicast routes ........................ 7 79 6 Multicast Extranet over Selective P-tunnels ........... 7 80 6.1 Non-aggregated S-PMSIs ................................ 7 81 6.2 Aggregated S-PMSIs .................................... 7 82 7 Multicast Extranet over Inclusive P-tunnels ........... 8 83 7.1 Option 1 .............................................. 8 84 7.2 Option 2 .............................................. 8 85 7.3 Option 3 .............................................. 9 86 7.4 Option 4 .............................................. 10 87 8 Multiple Extranet VRFs on the same PE ................. 11 88 9 IANA Considerations ................................... 11 89 10 Security Considerations ............................... 11 90 11 Acknowledgements ...................................... 11 91 12 References ............................................ 12 92 12.1 Normative References .................................. 12 93 12.2 Informative References ................................ 12 94 13 Authors' Addresses .................................... 12 96 1. Specification of requirements 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 2. Introduction 104 The extranet functionality that allows a MVPN site to receive/send 105 multicast traffic from/to sites of other MVPNs is a requirement of 106 RFC4834 [RFC4834] (section 5.1.6). 108 This document describes clarifications and extensions to the 109 procedures in [BGP-MVPN] for supporting extranets. The procedures 110 described in this document assume that BGP is used for transmission 111 of MVPN customers' multicast routing information within the service 112 provider(s) infrastructure [BGP-MVPN]. 114 3. Extranet Service Model 116 In the context of MVPN the term "extranet" refers to the ability for 117 multicast sources in one MVPN to send multicast traffic to multicast 118 receivers in other MVPN(s), and likewise, the ability for multicast 119 receivers in one MVPN to receive multicast traffic from multicast 120 sources in other MVPN(s). Such multicast sources are referred to as 121 "extranet sources". The multicast groups to which the extranet 122 sources generate traffic are referred to as "extranet groups". The 123 receivers that receive multicast traffic from extranet sources are 124 referred to as "extranet receivers". 126 If a given VRF has (multicast) receivers behind attached CEs that can 127 receive multicast traffic sourced in the configured set of extranet 128 MVPNs, then the (unicast) addresses of these sources MUST be 129 unambiguous both among these extranet MVPNs, as well as between any 130 of these extranet MVPNs and the MVPN of the VRF. 132 Moreover, if a given VRF has (multicast) receivers behind attached 133 CEs that can receive multicast traffic sourced in the configured set 134 of extranet MVPNs, then the group addresses within the ASM range that 135 these receivers can join MUST be unambiguous both among these 136 extranet MVPNs, as well as between any of these extranet MVPNs and 137 the MVPN of the VRF. 139 4. Routing Exchange in Support of Extranets 141 If a given VRF has (multicast) receivers behind attached CEs that can 142 receive multicast traffic sourced in the configured set of extranet 143 MVPNs, then this VRF MUST be able to import the "necessary" unicast 144 and BGP MVPN auto-discovery routes advertised by other PEs for the 145 MVPNs that contain the extranet sources. 147 The "necessary" routes are the routes required by the VRF to receive 148 multicast traffic for the extranet sources and groups from other 149 MVPNs. This includes unicast VPN-IP routes to the extranet sources, 150 as well as BGP MVPN Source Active auto-discovery routes for the 151 extranet sources and groups. It also includes Intra-AS, Inter-AS and 152 S-PMSI auto-discovery routes that carry P-Tunnel attributes for the 153 P-Tunnels used by the other MVPNs for sending multicast traffic for 154 multicast sources and groups. 156 4.1. Exchange of Unicast Routes 158 Case 1: PIM-SM in SSM mode. To fit the SSM model, if a given (C-S, C- 159 G) is in the extranet, then C-S should be in the extranet as well (or 160 to be more precise, the VPN-IP route to C-S has to be advertised in 161 the extranet). 163 Case 2: PIM-SM in ASM mode. To fit the ASM model, if a given C-G is 164 in the extranet, then the C-RP for that C-G and all the C-Ss sending 165 to that C-G should be in the extranet as well (or to be more precise, 166 all the VPN-IP routes to C-RP and these C-Ss have to advertised in 167 the extranet). Note that for a given C-G that is part of the extranet 168 formed by several MVPNs, C-Ss for that C-G may be present in any of 169 these MVPNs. 171 For both ASM and SSM modes, the VRFs connected to the sites that have 172 extranet receivers for a given extranet source MUST be able to import 173 a VPN-IP route to that source. In addition, for the ASM mode the VRFs 174 connected to the sites that have extranet receivers for a given 175 extranet group MUST be able to import a VPN-IP route to the C-RP of 176 that extranet group. 178 4.2. Exchange of Source Active and S-PMSI auto-discovery routes 180 When all the VPN-IP routes originated by the same VRF carry the same 181 set of RTs, then as long as the Source Active auto-discovery routes 182 and S-PMSI auto-discovery routes use the default setting for their 183 RTs (as specified in [BGP-MVPN]), setting up the appropriate RTs for 184 the VPN-IP routes, would also result in the appropriate import of 185 Source Active auto-discovery routes and S-PMSI auto-discovery routes. 187 When different VPN-IP routes originated by the same VRF carry 188 different RTs, then the following rules result in the appropriate 189 import of Source Active auto-discovery routes and S-PMSI auto- 190 discovery routes: 192 + By default a Source Active auto-discovery route for a given (C-S, 193 C-G) MUST carry the same RT(s) as the VPN-IP route for C-S. 195 + By default an S-PMSI auto-discovery route for a given (C-S, C-G) 196 or (C-S, C-*) MUST carry the same RT(s) as the VPN-IP route for 197 C-S. 199 + By default an S-PMSI auto-discovery route for a given (C-*, C-G) 200 MUST carry the same RT(s) as the VPN-IP route(s) for the 201 multicast sources that are in the sites connected to that VRF and 202 that originate (multicast) traffic for that C-G. 204 4.3. Exchange of I-PMSI auto-discovery routes 206 A VRF connected to the site(s) that have extranet receivers for a 207 given extranet source MUST be able to import the I-PMSI auto- 208 discovery route originated by the VRF connected to the source. Note 209 that as long as the I-PMSI auto-discovery routes use the default 210 setting for their RTs (as specified in [BGP-MVPN]), setting up the 211 appropriate RTs for the VPN-IP routes, would also result in the 212 appropriate import of I-PMSI auto-discovery routes. 214 If a given VRF connected to a given extranet source uses P2MP RSVP-TE 215 as an inclusive P-tunnel to carry (multicast) traffic from that 216 source, then the RT(s) carried by the I-PMSI auto-discovery routes 217 originated by the VRFs connected to the sites that have the extranet 218 receivers for that source, and the import RT(s) of the VRF connected 219 to the (extranet) source MUST be such that these routes will be 220 imported into that VRF. 222 5. Originating C-multicast routes 224 Procedures specified in section "Constructing the rest of the C- 225 multicast route" of [BGP-MVPN] are modified as follows. If the local 226 and the upstream PEs are in different ASes, then the local PE has to 227 find in its VRF not just an Inter-AS I-PMSI A-D route whose Source AS 228 field carries the autonomous system number of the upstream PE (as 229 specified in section 11.1.3 of [BGP-MVPN]), but an Inter-AS I-PMSI A- 230 D route whose Source AS field carries the autonomous system number of 231 the upstream PE, and whose RTs form a non-empty intersection with the 232 RTs carried in the VPN-IP route imported into that VRF for the 233 address carried in the Multicast Source field of MCAST-VPN NLRI. 235 6. Multicast Extranet over Selective P-tunnels 237 In the following we consider only the S-PMSI auto-discovery routes 238 used for the extranets. 240 6.1. Non-aggregated S-PMSIs 242 When each S-PMSI auto-discovery routes originated from a VRF on a 243 given PE advertises a distinct P-tunnel in the PMSI Tunnel attribute, 244 the procedures in [BGP-MVPN], along with the routing exchange 245 clarifications described above, are sufficient to support the 246 scenario when the multicast extranet traffic is carried over 247 selective P-tunnels (P-tunnels advertised by the S-PMSI auto- 248 discovery routes). 250 An implementation MUST support multicast extranets with non- 251 aggregated S-PMSIs. 253 6.2. Aggregated S-PMSIs 255 When multiple S-PMSI auto-discovery routes originated from a VRF on a 256 given PE advertise the same P-tunnel in the PMSI Tunnel attribute, 257 and each such route also advertises a distinct (upstream assigned) 258 label in the attribute, then the procedures in [BGP-MVPN], along with 259 the routing exchange clarifications described above, are sufficient. 261 When multiple S-PMSI auto-discovery routes originated from a VRF on a 262 given PE advertise the same P-tunnel in the PMSI Tunnel attribute, 263 and the PMSI Tunnel attribute of each of these routes does not carry 264 a distinct (upstream assigned) label per route, then in addition to 265 the procedures in [BGP-MVPN] and the routing exchange clarifications 266 described above, the following is required. 268 When the local PE receives from some other PE (C-S, C-G) traffic on a 269 P-tunnel that the other PE advertised in an S-PMSI auto-discovery 270 route that has been imported into a VRF on the local PE, the local PE 271 performs procedures specified in section 12.3 of [BGP-MVPN] only if: 272 (1) the VRF does contain an S-PMSI auto-discovery route for (C-S, C- 273 G), and (2) the (C-S, C-G) traffic is received on the P-tunnel 274 advertised in the PMSI Tunnel attribute of that route, and (3) RTs of 275 that route form a non-empty intersection with the RTs carried in the 276 VPN-IP route for C-S imported into that VRF. Otherwise, if at least 277 one of the above conditions is false, the local PE MUST discard (and 278 not forward) this traffic. 280 An implementation SHOULD support multicast extranets with aggregated 281 S-PMSI. 283 7. Multicast Extranet over Inclusive P-tunnels 285 There are (at least) four possible ways to support extranet multicast 286 over inclusive P-tunnels. 288 7.1. Option 1 290 This option assumes that the set of the extranet sources within a 291 given VRF is the same as the set of the multicast sources within that 292 VRF. 294 Procedures in [BGP-MVPN], along with the routing exchange 295 clarifications described above, are sufficient to support this 296 option. 298 An implementation MUST support this option. 300 7.2. Option 2 302 Each VRF that has set of extranet sources being part of that VRF uses 303 not one, but two inclusive P-tunnels for sending multicast traffic. 304 The first one is used for sending multicast traffic from the non- 305 extranet sources; the second is used for sending multicast traffic 306 from the extranet sources. 308 Each of these P-tunnels is advertised by its own I-PMSI auto- 309 discovery route. Therefore, these two routes MUST NOT use the same 310 RD. The distribution scope of the second route SHOULD include all the 311 VRFs that are within the scope of the first route, plus all the other 312 VRFs that have the extranet receivers for the extranet sources of the 313 VRF that originates the route. Thus the P-tunnel advertised by the 314 second route spans all the VRFs spanned by the P-tunnel advertised by 315 the first route, plus all the VRFs that have the extranet receivers 316 for the extranet sources of the VRF that originates the route. 318 The set of RTs carried by the first I-PMSI auto-discovery route 319 follows the rules specified in [BGP-MVPN]. The set of RTs carried by 320 the second I-PMSI auto-discovery route MUST form a non-empty 321 intersection with the RTs carried by the VPN-IP routes for the 322 extranet multicast sources in the VRF that originates the route. 324 To carry (C-S, C-G) multicast traffic the PE by default should use 325 the P-tunnel that the PE advertises in the I-PMSI auto-discovery 326 route that has the same set of RTs as the VPN-IP route to C-S 327 advertised by the PE. 329 When the local PE receives from other PEs (multicast) traffic 330 corresponding to the (multicast) state advertised in the C-multicast 331 route originated from given VRF on the local PE, the PE MUST discard 332 (and not forward) this traffic if it was received on a P-tunnel that 333 is advertised by an I-PMSI auto-discovery route that has been 334 imported into the VRF, and whose RTs form an empty intersection with 335 the RTs carried in the VPN-IP route imported into that VRF for the 336 address carried in the Multicast Source field of MCAST-VPN NLRI. 337 Note that this check is in addition to the checks specified in 338 section 9.1 of [MVPN-ARCH]. 340 An implementation SHOULD support this option. 342 7.3. Option 3 344 Each VRF has just one inclusive P-tunnel that is used to send data 345 originated by the sites connected to that VRF. In this case if the 346 set of extranet multicast sources are part of that VRF, then all 347 other VRFs that are part of the extranet must be able to receive data 348 on that P-tunnel (all these VRFs must be able import the I-PMSI auto- 349 discovery route that advertises this P-tunnel). 351 In addition to the rules specified in [BGP-MVPN], the set of RTs 352 carried by the I-PMSI auto-discovery route that advertises this P- 353 tunnel MUST form a non-empty intersection with the RTs carried by the 354 VPN-IP routes for the extranet multicast sources in that VRF. 356 Moreover, with this option the set of RTs of the I-PMSI auto- 357 discovery routes originated by the VRFs that contain extranet 358 multicast sources MUST be the same as in the absence of the extranet. 359 The route import policy for both intra-AS and inter-AS I-PMSI auto- 360 discovery routes on the VRFs that have receivers for the (multicast) 361 traffic originated by these sources MUST be such that these VRF MUST 362 be able to import these routes. 364 A VRF that is receiving traffic on an inclusive P-tunnel from the 365 extranet sources connected to another VRF may also receive on that P- 366 tunnel the non-extranet traffic from that VRF. Such traffic will be 367 dropped by the receiving VRF anyway if it doesn't have (C-S, C-G) or 368 (C-*, C-G) forwarding state for this non-extranet traffic. However, 369 the receiving VRF may have forwarding state for such traffic if the 370 address space for the non-extranet sources connected to the sending 371 VRF overlaps with the address space of the sources in the receiving 372 VRF's MVPN. To take care of this case the receiving VRF MUST be able 373 to drop the non-extranet traffic if it arrives on the unexpected P- 374 Tunnel. The following describes how the unexpected P-Tunnel is 375 determined. 377 When the local PE receives from other PEs (multicast) traffic 378 corresponding to the (multicast) state advertised in the C-multicast 379 route originated from given VRF on the local PE, the PE MUST discard 380 (and not forward) this traffic if it was received on a P-tunnel that 381 is advertised by an I-PMSI auto-discovery route that has been 382 imported into the VRF, and whose RTs form an empty intersection with 383 the RTs carried in the VPN-IP route imported into that VRF for the 384 address carried in the Multicast Source field of MCAST-VPN NLRI. 385 Note that this check is in addition to the checks specified in 386 section 9.1 of [MVPN-ARCH]. 388 An implementation SHOULD support this option. 390 7.4. Option 4 392 Each VRF that has set of extranet multicast sources being part of 393 that VRF is a root of as many inclusive P-tunnels as the number of 394 MVPNs in the extranet. A given (C-S, C-G) multicast traffic has to be 395 sent over each of these P-tunnels. From the point of view of the 396 number of P-tunnels, and the amount of replication required this is 397 the least desirable option, and is included here just for the sake of 398 completeness. 400 8. Multiple Extranet VRFs on the same PE 402 When multiple VRFs that contain extranet receivers for a given 403 extranet source are present on the same PE, this PE becomes a single 404 leaf of the P-tunnel used for sending (multicast) traffic from that 405 source to these extranet receivers. Specific procedures for 406 replicating this traffic on that PE to these multiple VRFs are a 407 purely local to the PE matter, and thus are out of the scope of this 408 document. 410 For a given extranet the site(s) that contain the extranet source(s) 411 and the site(s) that contain the extranet receiver(s) may be 412 connected to the same PE. In this scenario the procedures by which 413 (multicast) traffic from these sources is delivered to these 414 receivers is purely local matter to the PE matter, and thus are 415 outside the scope of this document. 417 An implementation MUST support multiple extranet VRFs on a PE. 419 9. IANA Considerations 421 This document does not impose any new IANA considerations. 423 10. Security Considerations 425 A VRF must be able to drop non-extranet traffic, if it receives such 426 traffic from another PE. The procedures for dropping such traffic are 427 described in this document. 429 11. Acknowledgements 431 The authors would like to thank Eric Rosen for his comments. 433 12. References 435 12.1. Normative References 437 [RFC2119] "Key words for use in RFCs to Indicate Requirement 438 Levels.", Bradner, March 1997 440 [MVPN-ARCH] E. Rosen, R. Aggarwal [Editors], "Multicast in MPLS/BGP 441 IP VPNs", draft-ietf-l3vpn-2547bis-mcast, work in progress 443 [BGP-MVPN], R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter, "BGP 444 Encodings for Multicast in MPLS/BGP IP VPNs", draft-ietf- 445 l3vpn-2547bis-mcast-bgp, work in progress 447 12.2. Informative References 449 [RFC4834] T. Morin, Ed., "Requirements for Multicast in L3 Provider- 450 Provisioned VPNs", RFC 4834, April 2007 452 13. Authors' Addresses 454 Rahul Aggarwal 455 Email: raggarwa_1@yahoo.com 457 Yakov Rekhter 458 Juniper Networks 459 1194 North Mathilda Ave. 460 Sunnyvale, CA 94089 461 Email: yakov@juniper.net 463 Thomas Morin 464 France Telecom - Orange Labs 465 2, avenue Pierre-Marzin 466 22307 Lannion Cedex 467 France 468 Email: thomas.morin@orange-ftgroup.com 470 Wim Henderickx 471 Alcatel-Lucent 472 e-mail: wim.henderickx@alcatel-lucent.be 474 Praveen Muley 475 Alcatel-Lucent 476 e-mail: Praveen.Muley@alcatel-lucent.com 477 Ray (Lei) Qiu 478 2330 Central Expressway 479 Santa Clara, CA 95050 480 USA 481 e-mail: rayq@huawei.com