idnits 2.17.1 draft-rosen-l3vpn-mvpn-profiles-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 29, 2009) is 5415 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) == Outdated reference: A later version (-15) exists of draft-ietf-mpls-ldp-p2mp-06 == Outdated reference: A later version (-10) exists of draft-ietf-l3vpn-2547bis-mcast-08 == Outdated reference: A later version (-08) exists of draft-ietf-l3vpn-2547bis-mcast-bgp-07 == Outdated reference: A later version (-10) exists of draft-rosen-l3vpn-mvpn-mspmsi-04 ** Obsolete normative reference: RFC 4601 (ref. 'PIM-SM') (Obsoleted by RFC 7761) == Outdated reference: A later version (-15) exists of draft-rosen-vpn-mcast-11 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Eric C. Rosen (Editor) 3 Internet Draft Arjen Boers 4 Intended Status: Proposed Standard Yiqun Cai 5 Expires: December 29, 2009 IJsbrand Wijnands 6 Cisco Systems, Inc. 8 June 29, 2009 10 MVPN Profiles Using PIM Control Plane 12 draft-rosen-l3vpn-mvpn-profiles-03.txt 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Copyright and License Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 The MVPN (Multicast Virtual Private Network) architecture is divided 49 into a number of functional "layers". At each layer, multiple 50 options are allowed. It is necessary to allow multiple options at 51 each layer because "one size doesn't fit all." However, it is not 52 expected that any particular implementation will support all the 53 possible combinations of options. To ensure multi-vendor 54 interoperability, it is useful to specify "profiles", where each 55 profile is a particular combination of options. The number of 56 specified profiles will be much less than the total number of 57 possible combination, and a given implementation can be characterized 58 by saying which profiles it supports. This document describes two 59 profiles that use a PIM control plane. 61 Table of Contents 63 1 Specification of requirements ......................... 4 64 2 Introduction .......................................... 4 65 3 The PIM+GRE Profile ................................... 5 66 3.1 Auto-discovery ........................................ 5 67 3.2 MI-PMSI Instantiation ................................. 5 68 3.2.1 Source Specific Multicast Mode ........................ 6 69 3.2.2 Any System Multicast Mode, Unidirectional ............. 6 70 3.2.3 Bidir ................................................. 7 71 3.3 Distribution of C-Multicast Routing Information ....... 7 72 3.4 Encapsulation ......................................... 7 73 3.5 S-PMSIs ............................................... 7 74 3.6 Inter-AS support ...................................... 7 75 3.7 Upstream Multicast Hop Determination .................. 8 76 4 The PIM+MPLS/MP2MP Profile: PIM over MS-PMSI .......... 8 77 4.1 Auto-discovery ........................................ 8 78 4.2 Joining an MP2MP LSP .................................. 9 79 4.2.1 Joining to Receive BSR Messages ....................... 10 80 4.2.2 Joining to Send PIM C-Join/Prune Messages ............. 10 81 4.2.3 Joining to Send Data Without Having Sent a C-J/P ...... 10 82 4.2.4 Pruning Oneself from a MP2MP LSP ...................... 11 83 4.3 Sending and Receiving C-Multicast Data ................ 11 84 4.4 Encapsulation ......................................... 12 85 4.5 Additional S-PMSIs .................................... 12 86 4.6 Inter-AS Support ...................................... 12 87 4.7 Upstream Multicast Hop Determination .................. 13 88 4.8 Extensions of this Profile ............................ 13 89 5 IANA Considerations ................................... 13 90 6 Security Considerations ............................... 13 91 7 Authors' Addresses .................................... 14 92 8 Normative References .................................. 15 93 9 Informative References ................................ 16 95 1. Specification of requirements 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC2119]. 101 2. Introduction 103 The MVPN (Multicast Virtual Private Network) architecture, as 104 specified in [MVPN] and [MVPN-MSPMSI], allows Service Providers (SPs) 105 to offer IP multicast service over the sort of Virtual Private 106 Networks (VPNs) that are specified in [VPN]. The MVPN architecture 107 contains a number of functional layers, and at each layer, multiple 108 options are allowed. 110 For example, one of the "functional layers" is the control protocol 111 which a Provider Edge (PE) router uses to distribute 112 Customer-multicast (C-multicast) routing to other PE routers. Two 113 options are allowed for this: (a) PIM and (b) BGP. Several 114 different variations of PIM are accommodated by the architecture as 115 well. 117 Another functional layer is the encapsulation which a PE router uses 118 to transmit a customer's multicast data to other PE routers. Both 119 MPLS and IP-based encapsulations are allowed by the architecture. 120 When MPLS encapsulation is used, transmission of user data is done 121 over Multipoint LSPs. There are however three very different kinds 122 of Multipoint LSPs that can be used. The LSPs can be MP2MP 123 (Multipoint-to-multipoint) LSPs set up by mLDP [MLDP], P2MP 124 (Point-to-Multipoint) LSPs set up by mLDP, or P2MP LSPs set up by 125 RSVP-TE [MP-RSVP-TE]. 127 Although the architecture allows any option at one layer to be used 128 with any option at another, it is not expected that any given 129 implementation will actually support the full set of options at each 130 layer, and in fact not all arbitrary combinations of options are 131 sensible. It is useful therefore to describe a set of MVPN 132 "Profiles", where each profile contains a single mandatory option at 133 each layer. Implementations can then be characterized by the set of 134 profiles they support. 136 The intention is that each profile be fully conformant to the [MVPN] 137 standard. 139 The profiles are described in the terminology of [MVPN], which is 140 presupposed by this document. 142 Deployments of MVPN based on the "PIM+GRE" profile (most precisely, 143 on a pre-standards version of that profile described in 144 [ORIGINAL-MVPN]) have existed since the turn of the century. The use 145 of PIM for distributing C-multicast routes has thus been proven in 146 deployment. Issues have been raised about whether this will be 147 adequate in the future if MVPN deployments greatly increase in scale. 148 However, the alternative of using BGP for distributing C-multicast 149 routes has not been proven in deployment, and the authors believe 150 that that alternative has a number of issues having to do with 151 functionality, scaling, and dynamic behavior that are not yet fully 152 understood. Until those are better understood, it does not seem 153 prudent to migrate quickly from PIM to BGP for distributing 154 C-multicast routes. The authors also believe that the ability to 155 deploy MPLS encapsulation for multicast VPN traffic should not be 156 gated by the need to deploy BGP as the C-multicast routing control 157 plane. Therefore we also specify a "PIM+MPLS" profile. 159 3. The PIM+GRE Profile 161 The PIM+GRE Profile corresponds closely to the "pre-standards" MVPN 162 deployments from Cisco Systems [ORIGINAL-MVPN], that have existed for 163 many years. The specification [ORIGINAL-MVPN] contains the precise 164 details of how the pre-standards version deviates slightly from the 165 later standard. 167 3.1. Auto-discovery 169 Auto-discovery is done by means of BGP, using the "Intra-AS I-PMSI 170 A-D routes" described in section 4 of [MVPN] and sections 4.1 and 8.1 171 of [MVPN-BGP]. Each PE attached to a particular MPVN is configured 172 with a PIM group address for that MVPN. The group address with which 173 a given PE is configured is carried in the PMSI Tunnel Attribute (see 174 [MVPN] section 4 and [MVPN-BGP] section 5) of the Intra-AS I-PMSI A-D 175 route originated by that PE. This PIM group address is used to 176 create the P-tunnels that instantiate the MVPN's MI-PMSI (see section 177 2.2). 179 3.2. MI-PMSI Instantiation 181 In the PIM+GRE profile, the PEs attached to a given MVPN are 182 connected via an MI-PMSI (see [MVPN] sections 3.3.1 and 3.3.2). The 183 P-tunnels that instantiate the MI-PMSIs are multicast distribution 184 trees constructed with PIM. Each MVPN VRF is configured with a PIM 185 Group P-address. The Intra-AS A-D route sent by each PE specifies 186 this group address. The P-tunnels may be created using the 187 Source-Specific Mode (SSM) service model, or the Any Source Mode 188 (ASM) service model. In the latter case, P-tunnels may be a mixture 189 of source-specific trees with unidirectional shared trees rooted at 190 Rendezvous Points (RPs) (this mixture is the normal result of 191 applying PIM "sparse mode" procedures). Alternatively, each MI-PMSI 192 may be instantiated by a single bidirectional tree (created by 193 BIDIR-PIM). The Intra-AS I-PMSI A-D route sent by each PE specifies 194 a PIM group address. Other PEs use PIM to join the specified group, 195 thereby creating the P-tunnels. The P-tunnels are thus created 196 automatically as a result of the auto-discovery process. 198 This profile does NOT require support for the capability to have a 199 single P-tunnel carry traffic from multiple VPNs. 201 Note that if the group address G used for the P-tunnels is an ASM 202 group, the BGP-based auto-discovery process is not strictly needed; 203 each PE MAY join the requisite set of P tunnels for a given MVPN just 204 by joining the (*,G) tree for the P-group address G that has been 205 configured for that VPN. However, for consistency, the 206 auto-discovery process SHOULD always take place. 208 3.2.1. Source Specific Multicast Mode 210 Consider the set of PEs that support a given MVPN. Each 211 pair is associated with a source specific mode PIM group address. If 212 the set of PEs supporting the given MVPN is PE1, ..., PEn, and the 213 corresponding set of group addresses is G1, ..., Gn, then PEk joins 214 each source tree for which 1 <= i <= n and i != k. That 215 is, the MI-PMSI is instantiated as a "full mesh" (i.e., containing 216 all the PEs attached to the MVPN) of source trees. The normal PIM 217 procedures specified in [PIM-SM] are used. 219 3.2.2. Any System Multicast Mode, Unidirectional 221 Each MVPN is associated with a non-SSM PIM group address. Each PE 222 attached to the MVPN joins the group, using the PIM sparse mode 223 procedures. If there are n PEs, the MI-PMSI is thus instantiated as 224 a shared tree plus a set of up to n source trees. The normal PIM 225 procedures specified in [PIM-SM] are used. 227 3.2.3. Bidir 229 Each MVPN is associated with a bidirectional mode PIM group address. 230 Each PE attached to the MVPN joins the group, using the BIDIR-PIM 231 procedures. If there are n PEs, the MI-PMSI is thus instantiated as 232 a shared tree plus a set of up to n source trees. The procedures for 233 setting up a BIDIR-PIM tree are specified in [PIM-BIDIR]. 235 3.3. Distribution of C-Multicast Routing Information 237 As already specified, an MI-PMSI is automatically created, containing 238 all the PEs belonging to a VPN. C-multicast routing information is 239 distributed by running PIM over the MI-PMSI, using standard PIM LAN 240 procedures. See sections 3.4.1.1, 5.1, and 5.2 of [MVPN]. 242 3.4. Encapsulation 244 All C-multicast data messages, and all C-PIM messages (i.e., PIM 245 messages carrying C-multicast routing information) are encapsulated 246 in GRE [GRE], precisely as specified in section 11.1.1 of the [MVPN]. 248 3.5. S-PMSIs 250 This profile supports non-aggregated S-PMSIs, where each S-PMSI is 251 instantiated as a PIM source tree in SSM mode. 253 The assignment of a particular C-multicast data stream to a 254 particular S-PMSI is done via the protocol specified in section 7.2.1 255 of [MVPN]. 257 3.6. Inter-AS support 259 Inter-AS support is provided via the non-segmented inter-as tunnels 260 described in section 8.1 of [MVPN]. Intra-AS A-D routes must 261 (despite their name) be distributed across AS boundaries. 263 To set up the inter-AS P-tunnels instantiating a PMSI, it is 264 necessary for a PE in one AS to send PIM control messages which 265 identify PEs in other ASes. In order to construct the multicast 266 distribution trees, P routers processing these messages need to 267 determine the (IGP) route to the identified PE router. However, in 268 inter-AS VPNs constructed according to option b of section 10 of RFC 269 4364, a given AS does not necessarily have routes to PEs in the other 270 ASes. Therefore, the PIM messages contain the "PIM MVPN Join 271 Attribute". This allows the multicast distribution tree to be 272 properly constructed even if routes to PEs in other ASes do not exist 273 in the given AS's IGP, and even if the routes to those PEs do not 274 exist in BGP. The use of an PIM MVPN Join Attribute in the PIM 275 messages allows the inter-AS trees to be built. The basic format of 276 a PIM Join Attribute is specified in [PIM-ATTRIB]. The details of 277 the PIM MVPN Join Attribute are specified in [MVPN]. 279 3.7. Upstream Multicast Hop Determination 281 According to section 5 of [MVPN], where the selected "Upstream 282 Multicast Hop" (UMH) route is the installed UMH route. The 283 procedures of section 5 for single forwarder selection are not 284 applied. Multicast data packets arriving from the "wrong" upstream 285 PE are not discarded. However, since PIM LAN procedures are run over 286 the MI-PMSI, the standard PIM "Assert" procedures will result in a 287 single choice of forwarder. Packet duplication is possible during 288 the Assert convergence period. 290 Although a given source will end up having a single PE as forwarder. 291 Load balancing is possible within that constraint. That is, if S1 292 and S2 are two different sources, and each source has both PE1 and 293 PE2 as an eligible UMH, and if PE3 needs to join the C-trees (S1, G1) 294 and (S2, G2), a form of load balancing can be providing by having PE3 295 join (S1, G1) via PE1 but having it join (S2, G2) via PE2. 297 4. The PIM+MPLS/MP2MP Profile: PIM over MS-PMSI 299 In this profile, as in the PIM+GRE profile, the PEs use PIM to convey 300 multicast routing information to each other. However, PIM is not 301 used to instantiate the P-tunnels. Rather, mLDP is used to create 302 Multipoint-to-Multipoint (MP2MP, or bidirectional) LSPs to serve as 303 the P-tunnels. Furthermore, an MI-PMSI is not used at all. PIM is 304 run over one or more MS-PMSIs (as specified in MVPN-MSPMSI), and 305 P-tunnels are only created if they are actually needed for carrying 306 multicast data. 308 4.1. Auto-discovery 310 Each PE that attaches to a given MVPN MUST originate an Intra-AS 311 I-PMSI A-D route that does NOT contain a PMSI Tunnel Attribute (PTA) 312 or a PE Distinguisher Labels Attribute. (I.e., there is no MI-PMSI.) 314 After the Intra-AS I-PMSI A-D route is originated, each such PE MUST 315 originate an S-PMSI A-D route whose PTA specifies a MP2MP LSP rooted 316 at the originating PE. The Tunnel Identifier for the MP2MP LSP 317 consists of an MLDP MP2MP FEC element [MLDP], which itself consists 318 of an IP address of the originating PE router, followed by an "opaque 319 value" identifying the MP2MP LSP in the context of that PE router. 320 This opaque value may be configured or autogenerated, and there is no 321 need for different PEs attached to a given MVPN to use the same 322 opaque value. The IP address which appears in the tunnel identifier 323 field of the PTA MUST be the same IP address that the PE uses for 324 sending and receiving PIM control messages. 326 The S-PMSI A-D route originated by PE1 specifies an MS-PMSI of which 327 PE1 is the root. 329 The S-PMSI A-D route MUST bind the LSP to the "double wildcard" 330 (*,*). Use and interpretation of the double wildcard when the PTA 331 specifies a MP2MP LSP is specified in section 4.1.4 [MVPN-MSPMSI]. 333 Per [MVPN-MSPMSI], the specified MS-PMSI becomes the default PMSI 334 that its root node uses to send a C-flow to the other PEs, as long as 335 the C-flow is traveling along a unidirectional C-tree. For C-flows 336 traveling along a bidirectional C-tree, the MS-PMSI is the default 337 PMSI for that any PE uses to transmit to other PEs, as long as the 338 root node is the selected upstream PE for the C-RPA. 340 The MS-PMSI is associated with a particular MVPN by means of the RTs 341 carried by the S-PMSI A-D route, exactly as specified in [MVPN] and 342 [MVPN-BGP]. 344 When PE1 is the root of an MS-PMSI, we will sometimes refer to the 345 MS-PMSI as "PE1's MS-PMSI". (Of course, a given PE may be the root 346 for more than one MS- PMSI, for the same or different MVPNs. Rules 347 governing the association of an S-PMSI A-D route with a given MVPN 348 are as specified in [MVPN] and [MVPN-BGP].) 350 This profile does not require support for the use of non-zero values 351 in the MPLS label field of the PTA, nor does this profile require the 352 use of the PE Distinguisher Labels attribute. 354 4.2. Joining an MP2MP LSP 356 When a PE receives one of the S-PMSI A-D routes mentioned in the 357 previous section, it may or may not need to invoke MLDP signaling 358 procedures to join the specified MP2MP LSP. In particular, a PE MUST 359 NOT join the specified MP2MP LSP unless and until it has a need to do 360 so. This is discussed in subsequent sub-sections. 362 4.2.1. Joining to Receive BSR Messages 364 Each PE attached to an MVPN needs to know the RP or RPA that 365 corresponds to each C-group address for which it may need to send or 366 receive traffic. This information may be preconfigured, but more 367 likely is known through some automated procedure such as BSR 368 (Bootstrap Routing Protocol for PIM [BSR]). 370 If a PE, say PE1, receives a BSR message from a CE which belongs to a 371 particular MVPN, it needs to transmit BSR messages to the other PEs 372 attached to that MVPN. It does so by sending the BSR messages over 373 the MS-PMSI for that MVPN of which it is the root. However, it MUST 374 also originate another S-PMSI A-D route, with the same PTA, but whose 375 C-source field specifies the address of the PE itself, and whose 376 C-group field specifies the ALL-PIM-ROUTERS address (224.0.0.13). 377 See section 5 of [MVPN]. When this S-PMSI A-D route is received by 378 the other PEs attached to the MVPN, those other PEs MUST as soon as 379 possible initiate the LDP signaling necessary to join the MP2MP LSP, 380 so that they can receive the BSR messages from PE1. of the LSP. 382 4.2.2. Joining to Send PIM C-Join/Prune Messages 384 If PE1 needs to direct a PIM C-Join/Prune message to PE2, PE1 MUST 385 join the LSP advertised in PE2's S-PMSI A-D route. The PIM J/P 386 messages MUST be sent over that LSP. 388 Note that multicast data cannot be received over a given LSP unless a 389 C-Join/Prune message has been sent over that LSP. (Except in the 390 case of BSR messages discussed previously.) Therefore these 391 procedures cause a PE to join a particular MP2MP LSP ONLY if the PE 392 needs to receive data on it. Thus the number of LSPs that actually 393 get created for a given MVPN is equal to the number of PEs that serve 394 as ingress PEs for the multicast traffic of that MVPN. In an MVPN 395 which has its multicast transmitters at a single site, only one LSP 396 would be required. 398 Any PIM Hellos that PE1 sends MUST be sent on the LSP advertised in 399 PE1's own S-PMSI A-D route (i.e., on PE1's MS-PMSI). Thus the need 400 to send Hellos does not trigger the joining of an LSP. 402 4.2.3. Joining to Send Data Without Having Sent a C-J/P 404 If a particular PE is on a "sender only" branch of a C-bidir tree, 405 then it may need to send C-data that is traveling on the C-bidir tree 406 without having previously sent a corresponding C-Join. A given PE, 407 PE1, still sends the data on PE2's LSP if and only if PE1 has 408 selected PE2 as the upstream PE for the RPA of the C-bidir tree. PE1 409 MAY join that tree when it first has data to send on it, or it MAY 410 join the tree when first recognizes that PE2 is the selected upstream 411 PE for some RPA of which it knows. 413 4.2.4. Pruning Oneself from a MP2MP LSP 415 A PE SHOULD prune itself from an MP2MP LSP whenever it no longer has 416 a need to send or receive data on that LSP. 418 4.3. Sending and Receiving C-Multicast Data 420 When a PE receives multicast data from a CE, it may need to forward 421 that data to the other PEs. If the data is traveling on a 422 unidirectional C-tree, the PE sends the data on its own MS-PMSI. 424 When PE1 receives, from PE2's MS-PMSI, C-multicast data that is 425 traveling on a unidirectional C-tree, PE MUST discard the data 426 (without PIM processing) if PE2 is not the PE from which the data was 427 expected (i.e., if PE2 is not the PE1's selected upstream PE for the 428 C-root of the C-tree on which the data is traveling). 430 If PE1 needs to send data traveling on a bidirectional C-tree, it 431 does so using the procedures specified in [MVPN] section 12.2.3. The 432 procedures specified therein also detail the conditions under which a 433 PE must discard data from a bidirectional group when that data is 434 received on the LSP. 436 Since data arriving on the "wrong LSP" is always discarded, Assert 437 processing will never occur. Since Assert processing does not occur, 438 "single forwarder selection" need not be used (see sections 9 and 5.1 439 of [MVPN]). That is, PE1 can receive, e.g., (S,G) traffic from PE2 440 while PE3 receives (S,G) traffic from PE4. This enables the use of 441 enhanced load balancing procedures. Also, the PIM+GRE profile, this 442 profile can support the use of anycast source address (e.g., 443 anycast-RP). 445 The Join Suppression and Prune Override procedures still operate as 446 they normally do on LANs. 448 4.4. Encapsulation 450 The encapsulation specified in [MVPN] section 11.1.3 is used. (See 451 also [MPLS-MCAST-ENCAPS]). Aggregation of multiple VPNs onto a 452 single set of P-tunnels is not required by this profile. 454 4.5. Additional S-PMSIs 456 This profile REQUIRES support for the use of additional, 457 "non-default", S-PMSIs, where each S-PMSI is instantiated as an 458 mLDP-created P2MP or MP2MP LSP. 460 P2MP LSPs MAY be used for carrying C-multicast traffic that is 461 traveling along unidirectional shared or source-specific C-trees. 463 MP2MP LSPs MAY used for carrying C-multicast that is traveling along 464 bidirectional C-trees. 466 Multiple data streams MAY be aggregated on a single MP2MP LSP, but 467 the profile does not require mandatory support for aggregation of 468 data streams from different VPNs. 470 The assignment of a particular C-flow or set of C-flows to a 471 particular S-PMSI MAY be done via the protocol specified in section 472 7.2.1 of [MVPN]. The protocol will be suitably extended so that it 473 can identify an mLDP-created MP2MP LSP, and can support the wild card 474 selectors defined in [MVPN-MSPMSI]. The assignment MAY also be done 475 by the use of S-PMSI A-D routes. Any given deployment MUST, by 476 configuration, choose one of these methods. 478 4.6. Inter-AS Support 480 Inter-AS support is provided via the non-segmented inter-as tunnels 481 described in section 8.1 of [MVPN]. Intra-AS I-PMSI A-D routes must 482 (despite their name) be distributed across AS boundaries. 484 To set up the inter-AS P-tunnels instantiating a PMSI, it is 485 necessary for a PE to send mLDP control messages which identify PEs 486 in other ASes. In order to construct the multicast distribution 487 trees, P routers processing these messages need to determine the 488 (IGP) route to the identified PE router. However, In inter-AS VPNs 489 constructed according to option b of section 10 of RFC 4364, a given 490 AS does not necessarily have routes to PEs in the other ASes. 491 Therefore, the mLDP messages will be extended along the lines of the 492 "PIM MVPN Join Attribute" discussed in section 2.9. This allows the 493 multicast distribution tree to be properly constructed even if routes 494 to PEs in other ASes do not exist in the given AS's IGP, and even if 495 the routes to those PEs do not exist in BGP. 497 4.7. Upstream Multicast Hop Determination 499 Upstream multicast hop determination is exactly as specified in 500 section 5 of [MVPN]. 502 4.8. Extensions of this Profile 504 This profile may be extended in the future to add the following 505 options: 507 1. Aggregation of traffic from multiple VPNs onto a single 508 MS-PMSI. This requires support for MPLS upstream-assigned 509 labels [MPLS-UPSTREAM-LABEL]. 511 2. Support for Segmented Inter-AS P-Tunnels, as described in 512 section 8.2 of [MVPN]. This will require support for the 513 "Inter-AS A-D Routes" described in section 8.2.1 of [MVPN]. 515 3. The use of RSVP-TE P2MP LSPs for instantiating S-PMSIs carrying 516 traffic which is traveling on a unidirectional shared or 517 source-specific C-tree. (With support of MPLS 518 upstream-assigned labels, traffic traveling on bidirectional 519 C-tree from the customer could also be carried over an RSVP-TE 520 P2MP LSP.) 522 5. IANA Considerations 524 This document does not require any actions of IANA. 526 6. Security Considerations 528 [VPN] discusses in general the security considerations that pertain 529 to when the RFC4364 type of VPN is deployed. 531 [PIM-SM] discusses the security considerations that pertain to the 532 use of PIM. 534 [MLDP] discusses the security considerations that pertain to the use 535 of LDP. 537 When the PIM+GRE profile is used, the security considerations of 539 [MPLS-in-GRE] and [VPN-GRE] also apply. 541 The security considerations of [MVPN] and [MVPN-BGP] apply. 543 7. Authors' Addresses 545 Arjen Boers 546 Cisco Systems, Inc. 547 170 Tasman Drive 548 San Jose, CA, 95134 549 E-mail: aboers@cisco.com 551 Yiqun Cai 552 Cisco Systems, Inc. 553 170 Tasman Drive 554 San Jose, CA, 95134 555 E-mail: ycai@cisco.com 557 Eric C. Rosen (Editor) 558 Cisco Systems, Inc. 559 1414 Massachusetts Avenue 560 Boxborough, MA, 01719 561 E-mail: erosen@cisco.com 563 IJsbrand Wijnands 564 Cisco Systems, Inc. 565 De kleetlaan 6a 566 Diegem 1831 567 Belgium 568 E-mail: ice@cisco.com 570 8. Normative References 572 [GRE] RFC 2784, "Generic Routing Encapsulation", D. Farinacci, et. 573 al., March 2000 575 [MLDP] "LDP Extensions for P2MP and MP2MP LSPs", I. Minei, K. 576 Kompella, I. Wijnands, B. Thomas, draft-ietf-mpls-ldp-p2mp-06.txt, 577 April 2009 579 [MPLS-MCAST-ENCAPS] "MPLS Multicast Encapsulations", T. Eckert, E. 580 Rosen, R. Aggarwal, Y. Rekhter, RFC 5332, August 2008 582 [MVPN] "Multicast in MPLS/BGP IP VPNs", E. Rosen, R. Aggarwal, et. 583 al., draft-ietf-l3vpn-2547bis-mcast-08.txt, March 2009 585 [MVPN-BGP] "BGP Encodings and Procedures for Multicast in MPLS/BGP IP 586 VPNs", R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter, C. Kodeboniya, 587 draft-ietf-l3vpn-2547bis-mcast-bgp-07.txt, April 2009 589 [MVPN-MSPMSI] "MVPN: Optimized use of PIM, Wild Card Selectors, 590 Bidirectional Tunnels", draft-rosen-l3vpn-mvpn-mspmsi-04.txt, June 591 2009 593 [PIM-ATTRIB] "The PIM Join Attribute Format", A. Boers, IJ. Wijnands, 594 E. Rosen, RFC 5384, November 2008 596 [PIM-BIDIR] RFC 5015, "Bidirectional Protocol Independent Multicast 597 (BIDIR-PIM)", M. Handley, I. Kouvelas, T. Speakman, L. Vicisano, 598 October 2007 600 [PIM-SM] RFC 4601 "Protocol Independent Multicast - Sparse Mode 601 (PIM-SM)", Fenner, Handley, Holbrook, Kouvelas, August 2006 603 [RFC2119] "Key words for use in RFCs to Indicate Requirement 604 Levels.", Bradner, March 1997 606 [VPN] RFC 4364, "BGP/MPLS IP VPNs", Rosen, Rekhter, et. al., February 607 2006 609 9. Informative References 611 [BSR], RFC 5059, "Bootstrap Router Mechanism for PIM", N. Bhaskar, A. 612 Gall, J. Lingard, S. Venaas, January 2008. 614 [MPLS-UPSTREAM-LABEL] "MPLS Upstream Label Assignment and 615 Context-Specific Label Space", R. Aggarwal, Y. Rekhter, E. Rosen, RFC 616 5331, August 2008 618 [MP-RSVP-TE] RFC 4875, "Extensions to RSVP-TE P2MP TE LSPs" R. 619 Aggarwal, Ed., D. Papadimitriou, Ed., S. Yasukawa, Ed.. May 2007 621 [MPLS-in-GRE] RFC 4023, "Encapsulating MPLS in IP or Generic Routing 622 Encapsulation (GRE)", T. Worster, Y. Rekhter, E. Rosen, March 2005 624 [VPN-GRE] RFC 4797, "Use of PE-PE GRE or IP in BGP/MPLS IP VPNs", Y. 625 Rekhter, R. Bonica, E. Rosen, January 2007 627 [ORIGINAL-MVPN] "Multicast in MPLS/BGP IP VPNs", E. Rosen, Y. Cai, 628 IJ. Wijnands, draft-rosen-vpn-mcast-11.txt, June 2009