idnits 2.17.1 draft-morin-l3vpn-mvpn-considerations-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 772. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 783. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 790. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 796. 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 are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (October 09, 2007) is 6036 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC4364' is mentioned on line 518, but not defined == Outdated reference: A later version (-10) exists of draft-ietf-l3vpn-2547bis-mcast-03 == Outdated reference: A later version (-15) exists of draft-rosen-vpn-mcast-08 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Morin, Ed. 3 Internet-Draft France Telecom R&D 4 Intended status: Informational B. Niven-Jenkins, Ed. 5 Expires: April 11, 2008 BT 6 Y. Kamite 7 NTT Communications 8 R. Zhang 9 BT 10 N. Leymann 11 Deutsche Telekom 12 October 09, 2007 14 Considerations about Multicast for BGP/MPLS VPN Standardization 15 draft-morin-l3vpn-mvpn-considerations-01 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on April 11, 2008. 42 Copyright Notice 44 Copyright (C) The IETF Trust (2007). 46 Abstract 48 The current proposal for multicast in BGP/MPLS includes multiple 49 alternative mechanisms for some of the required building blocks of 50 the solution. The aim of this document is to leverage previously 51 documented requirements to identify the key elements and help move 52 forward solution design, toward the definition of a standard having a 53 well defined set of mandatory procedures. The different proposed 54 alternative mechanisms are examined in the light of requirements 55 identified for multicast in L3VPNs, and suggestions are made about 56 which of these mechanisms standardization should favor. Issues 57 related to existing deployments of early implementations are also 58 addressed. 60 Requirements Language 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 64 document are to be interpreted as described in [RFC2119]. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Examining alternatives mechanisms for MVPN functions . . . . . 4 71 3.1. MVPN auto-discovery . . . . . . . . . . . . . . . . . . . 4 72 3.2. S-PMSI Signaling . . . . . . . . . . . . . . . . . . . . . 6 73 3.3. PE-PE Transmission of C-Multicast Routing . . . . . . . . 8 74 3.4. Encapsulation techniques for P-multicast trees . . . . . . 11 75 3.5. Inter-AS deployments options . . . . . . . . . . . . . . . 12 76 4. Co-located RPs . . . . . . . . . . . . . . . . . . . . . . . . 14 77 5. Existing deployments . . . . . . . . . . . . . . . . . . . . . 15 78 6. Summary of recommendations . . . . . . . . . . . . . . . . . . 15 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 81 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 82 10. Informative References . . . . . . . . . . . . . . . . . . . . 16 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 84 Intellectual Property and Copyright Statements . . . . . . . . . . 19 86 1. Introduction 88 The current proposal for multicast in BGP/MPLS 89 [I-D.ietf-l3vpn-2547bis-mcast] includes multiple alternative 90 mechanisms for some of the required building blocks of the solution. 91 However, it does not identify the core set of mechanisms which must 92 be implemented in order to ensure interoperability. This may lead to 93 a situation where implementations may support different subsets of 94 the available optional mechanisms leading to implementations that do 95 not interoperate. 97 The aim of this document is to leverage the already expressed 98 requirements [RFC4834] to identify the mechanisms that the authors 99 believe are good candidates for being part of a core set of mandatory 100 mechanisms which can be used to provide a base for interoperable 101 solutions. 103 This document will go through the different building blocks of the 104 solution and provide the authors' recommendations as to which 105 mechanisms the authors' favor for each building block, while 106 considering the requirements already defined and the goal of a fully- 107 interoperable standard. 109 Considering the history of the multicast VPN proposals and 110 implementations, the authors also consider it useful to discuss how 111 existing deployments of early implementations 112 [I-D.rosen-vpn-mcast][I-D.raggarwa-l3vpn-2547-mvpn] can fit in the 113 picture, and provide suggestions in this respect. 115 2. Terminology 117 Please refer to [I-D.ietf-l3vpn-2547bis-mcast] and [RFC4834]. 119 3. Examining alternatives mechanisms for MVPN functions 121 3.1. MVPN auto-discovery 123 Section 5.2.10 of [RFC4834] states "The operation of a multicast VPN 124 solution SHALL be as light as possible and providing automatic 125 configuration and discovery SHOULD be a priority when designing a 126 multicast VPN solution. Particularly the operational burden of 127 setting up multicast on a PE or for a VR/VRF SHOULD be as low as 128 possible". 130 The current solution document [I-D.ietf-l3vpn-2547bis-mcast] 131 addresses this requirement by proposing two different mechanisms for 132 MVPN auto-discovery: 134 1. BGP-based auto-discovery (described in section 4). 136 2. Discovery using PIM running on a MI-PMSI implemented with a 137 shared tree using multicast ASM, or MP2MP LDP with the same 138 common tree identifier configured in all VRFs of an MVPN. 140 It is the recommendation of the authors that BGP-based auto-discovery 141 is the preferred solution for auto-discovery and should be supported 142 by all implementations while PIM/shared-tree based auto-discovery 143 should be optionally considered for migration purpose only. 145 Part of the rationale for this recommendation is also based on 146 section 5.2.10 of [RFC4834] which states "as far as possible, the 147 design of a solution SHOULD carefully consider the number of 148 protocols within the core network: if any additional protocols are 149 introduced compared with the unicast VPN service, the balance between 150 their advantage and operational burden SHOULD be examined 151 thoroughly". 153 BGP is the auto-discovery protocol used in unicast (RFC4364) VPNs and 154 therefore the use of BGP-based auto-discovery within multicast VPNs 155 avoids the introduction of an additional auto-discovery protocol that 156 would require additional OAM processes and tools. Service providers 157 with deployed unicast (RFC4364) VPNs already have extensive 158 deployment and operations experience of using BGP as an auto- 159 discovery protocol including OAM processes and tools. Such processes 160 and tools will require modifications in order to support multicast 161 auto-discovery but those modifications are anticipated to be less 162 than those required to develop new processes and tools for a specific 163 auto-discovery protocol. Additionally, BGP supports MD5 164 authentication of its peers for additional security. In contrast, 165 there are no obvious authentication mechanisms to secure PIM 166 communications in any known implementation. 168 Furthermore, PIM based discovery is only applicable to deployments 169 using a shared tree on an MI-PMSI, whereas BGP-based auto-discovery 170 does not place any restrictions on the type of multicast trees that 171 can be used. BGP-based auto-discovery is independent of the type of 172 P-multicast tree used thus satisfying the requirement in section 173 5.2.4.1 of [RFC4834] that "a multicast VPN solution SHOULD be 174 designed so that control and forwarding planes are not 175 interdependent". Additionally, it is to be noted that a number of 176 service providers have chosen to use SSM-based trees for the default 177 MDTs within their current deployments, therefore relying already on 178 BGP-based auto-discovery. 180 When shared trees are used, the use of BGP auto-discovery would allow 181 inconsistencies in the addresses/identifiers used for the shared 182 trees to be detected (e.g. the same shared tree identifier being used 183 for different VPNs with distinct BGP route targets). This is 184 particularly attractive in the context of inter-AS VPNs where the 185 impact of any misconfiguration could be magnified and where a single 186 service provider may not operate all the ASs. 188 The authors note that, in order to support the coexistence of both 189 protocols (for example during migration scenarios), implementations 190 could support both alternatives by providing a per-VRF configuration 191 knob that would allow recognizing new PIM neighbors based on the 192 reception of PIM hellos on a shared P-multicast tree, even for 193 neighbors that did not advertise a BGP auto-discovery route. 195 3.2. S-PMSI Signaling 197 The current solution document [I-D.ietf-l3vpn-2547bis-mcast] proposes 198 two mechanisms for S-PMSI Signaling: 200 1. A new UDP-based TLV protocol specifically for S-PMSI signaling 201 (described in section 7.2.1). 203 2. A BGP-based mechanism for S-PMSI signaling (described in section 204 7.2.2). 206 It is the recommendation of the authors that BGP is the preferred 207 solution for S-PMSI signaling and should be supported by all 208 implementations while the UDP-based S-PMSI signaling protocol should 209 be considered optional. 211 Part of the rationale for this recommendation is similar to that for 212 BGP-based auto-discovery and is based on section 5.2.10 of [RFC4834] 213 and the desire to avoid introducing and deploying additional 214 protocols unless strictly necessary. 216 Furthermore: 218 o The BGP-based S-PMSI signaling mechanism can be used within MVPNs 219 using either a UI-PMSI or a MI-PMSI while the UDP-based protocol 220 is restricted to use within MVPNs using an MI-PMSI. 222 o The BGP-based S-PMSI signaling mechanism can be efficiently used 223 in an inter-AS option B deployment context while the use of the 224 UDP-based protocol does not preserve AS routing independence when 225 used in an inter-AS option B context (i.e. the decision by a PE in 226 an AS to use an S-PMSI for a given customer flow will impact 227 routing state in other ASes). Co-existence with unicast inter-AS 228 VPN options is strongly encouraged by section 5.2.6 of [RFC4834]. 230 o The BGP-based S-PMSI signaling supports all the functionality and 231 all the operational contexts that are supported by UDP-based 232 protocol (and more). 234 o BGP supports MD5 authentication of its peers for additional 235 security. In contrast, there are no obvious authentication 236 mechanisms to secure PIM communications in any known 237 implementation. 239 Therefore, it is the opinion of the authors that BGP is the preferred 240 solution for performing S-PMSI signaling. 242 However, the authors recognize that the UDP-based protocol has been 243 in deployment for some time and would recommend that implementations 244 supporting both protocols optionally provide a per-VRF configuration 245 knob to allow an implementation to use the UDP-based TLV protocol for 246 S-PMSI signaling for specific VRFs in order to support the 247 coexistence of both protocols (for example during migration 248 scenarios). 250 Apart from such migration-facilitating mechanisms, the authors 251 specifically do not recommend extending the already proposed UDP- 252 based TLV protocol to new types of P-multicast trees. 254 Section 7.2.2.3 of [I-D.ietf-l3vpn-2547bis-mcast] proposes two 255 approaches for how a source PE can decide when to start transmitting 256 customer multicast traffic on a S-PMSI: 258 1. The source PE sends multicast packets for the on both 259 the I-PMSI P-multicast tree and the S-PMSI P-multicast tree 260 simultaneously for a pre-configured period of time, letting the 261 receiver PEs select the new tree for reception, before switching 262 to only the S-PMSI. 264 2. The source PE waits for a pre-configured period of time after 265 advertising the entry bound to the S-PMSI before fully 266 switching the traffic onto the S-PMSI-bound P-multicast tree. 268 The first alternative has essentially two drawbacks: 270 o traffic is sent twice for some period of time, which 271 would appear to be at odds with the motivation for switching to an 272 S-PMSI in order to optimize the bandwidth used by the multicast 273 tree for that stream. 275 o It is unlikely that the switchover can occur without packet loss 276 or duplication if the transit delays of the I-PMSI P-multicast 277 tree and the S-PMSI P-multicast tree differ. 279 By contrast, the second alternative has none of these drawbacks, and 280 satisfy the requirement in section 5.1.3 of [RFC4834], which states 281 that "[...] a multicast VPN solution SHOULD as much as possible 282 ensure that client multicast traffic packets are neither lost nor 283 duplicated, even when changes occur in the way a client multicast 284 data stream is carried over the provider network". The second 285 alternative also happen to be the one used in existing deployments. 287 For these reasons, it is the authors' recommendation to mandate the 288 implementation of the second alternative for switching to S-PMSI. 290 3.3. PE-PE Transmission of C-Multicast Routing 292 The current solution document [I-D.ietf-l3vpn-2547bis-mcast] proposes 293 multiple mechanisms for PE-PE transmission of customer multicast 294 routing information: 296 1. Full per-MVPN PIM peering across an MI-PMSI (described in section 297 5.2.1). 299 2. Lightweight PIM peering across an MI-PMSI (described in section 300 5.2.2) 302 3. The unicasting of PIM C-Join/Prune messages (described in section 303 5.2.3) 305 4. The use of BGP for carrying C-Multicast routing (described in 306 section 5.3). 308 The first mechanism (full per-MVPN PIM peering across an MI-PMSI) is 309 the mechanism used by [I-D.rosen-vpn-mcast] and therefore it is 310 deployed and operating in MVPNs today. The authors recognize that 311 because full per-MVPN PIM peering has been in deployment for some 312 time support for this mechanism may be required for backwards 313 compatibility and in order to facilitate migration towards 314 alternative PE-PE protocols. 316 Section 4.2.4 of [RFC4834] recommends that "a multicast VPN solution 317 SHOULD support several hundreds of PEs per multicast VPN, and MAY 318 usefully scale up to thousands" and section 4.2.5 states that "a 319 solution SHOULD scale up to thousands of PEs having multicast service 320 enabled". 322 At those scales of multicast deployment within a large VPN, the first 323 and third mechanisms require PEs to maintain a large number of PIM 324 adjacencies with other PEs within the same MVPN and to regularly 325 exchange PIM hellos with each other and refresh C-Join/Prune state. 327 The third mechanism would reduce the amount of C-Join/Prune 328 processing by PEs when they are not the upstream neighbor for a given 329 multicast flow, but would : 331 a. require explicit tracking related state to be maintained by PEs 332 when they are the upstream PE for a said customer flow, and 334 b. require refresh reduction mechanisms to be used to be applicable. 336 The second mechanism (lightweight PIM peering across an MI-PMSI) 337 would operate in a similar manner to full per-MVPN PIM peering except 338 that PIM hellos are not transmitted and PIM C-Join/Prune refresh 339 reduction would be used, thereby improving scalability. 341 The fourth mechanism (the use of BGP for carrying C-Multicast 342 routing) has to solve roughly the same intrinsic scalability related 343 difficulties as the other three mechanisms, but because it is based 344 on TCP it has no refresh-related scalability limit, and inherits some 345 BGP features that are expected to improve scalability through, for 346 instance, providing a means to offload some of the processing burden 347 associated with client multicast routing onto BGP route reflectors. 349 Furthermore, co-existence with unicast inter-AS VPN options, and an 350 equal level of security for multicast and unicast including in an 351 inter-AS context, are specifically mentioned in sections 5.2.6, 5.2.8 352 and 5.2.12 of [RFC4834]. The first three mechanisms impose direct PE 353 to PE communications which means that they do not apply well to an 354 inter-AS option B context, because of security and robustness issues 355 that are involved by such a level of reachability and interaction 356 between PEs in different ASes. Their use in an inter-AS context is 357 possible, but not without limitations or additional engineering 358 design trade-offs depending upon the interconnect types. By 359 comparison, the fourth option (the use of BGP for carrying 360 C-Multicast routing) does not have any of the above limitations 361 related to inter-AS deployments, and also provides an additional 362 alternative to facilitate such deployments through the possibility of 363 using segmented inter-AS trees. 365 Moreover, mechanisms one and two are restricted to use within MVPNs 366 using an MI-PMSI, thereby necessitating: 368 a. The use of a P-multicast tree technique that allows shared trees 369 (for example PIM-SM in ASM mode or MP2MP LDP). 371 b. The use of one P-multicast tree per PE per VPN, even for PEs that 372 do not have sources in their directly attached sites for that 373 VPN. 375 By comparison, the fourth mechanism doesn't impose either of these 376 restrictions. 378 Additionally, the fourth mechanism (the use of BGP for carrying 379 C-Multicast routing) would appear to fit well with the current 380 unicast architecture as BGP is the customer routing distribution 381 protocol used in unicast VPNs and therefore using BGP for customer 382 routing distribution within multicast VPNs avoids the introduction of 383 an additional protocol that would require additional OAM processes 384 and tools. Service provider's with deployed unicast (RFC4364) VPNs 385 already have extensive deployment and operations experience of using 386 BGP as a customer routing distribution protocol including OAM 387 processes and tools. Such processes and tools will require 388 modification in order to support customer multicast routing but those 389 modifications are anticipated to be less than those required to 390 develop new processes and tools for a distinct customer routing 391 protocol. It should be noted that because PIM will be used as the 392 CE-PE customer routing distribution protocol, service providers will 393 still need OAM processes and tools in order to manage the PIM 394 protocol, so this rationale only applies to a subset of the tools and 395 processes already in place. Additionally, BGP supports MD5 396 authentication of its peers for additional security. In contrast, 397 there are no obvious authentication mechanisms to secure PIM 398 communications in any known implementation. 400 An illustrative example of the benefit brought by consistency with 401 unicast design is how the "extranet" feature can be implemented : 402 when BGP-based mechanisms are used, the well defined and well 403 understood BGP route target import/export semantics are just reused. 404 By contrast, it is not specified how implementing the same feature 405 would be done in the context of other alternative mechanism, and 406 unclear if this is possible without significant engineering trade- 407 offs. Note that the support for such a feature is stated as a MUST 408 in sections 5.1.6 of [RFC4834]. 410 Section 5.2.10 of [RFC4834] states that "as far as possible, the 411 design of a solution SHOULD carefully consider the number of 412 protocols within the core network: if any additional protocols are 413 introduced compared with the unicast VPN service, the balance between 414 their advantage and operational burden SHOULD be examined 415 thoroughly". Considering that the recommendation of the authors 416 would be BGP for auto-discovery and S-PMSI signalling, the choice of 417 BGP for customer multicast routing would be consistent with the 418 protocol choice for unicast VPNs and would adequately address this 419 requirement. 421 BGP-based customer multicast routing clearly presents some advantages 422 over the PIM-based alternatives. However it has yet to be deployed 423 within an operational MVPN, and service providers currently lack 424 experience of its implementation. By contrast, experience proves 425 that PIM-based mechanisms are operationally viable, but with well 426 identified limitations. Some of those limitations may be improved 427 upon (although there is currently no clearly defined proposal to do 428 this), however some of the limitations appear to be intrinsic to the 429 approach. 431 Moreover to improve the clarity of the proposed specifications, 432 considering that neither hello suppression nor refresh reduction 433 procedures are currently specified or documented and that it is not 434 clear what the impact to the PIM state machine of these additional 435 procedures may be, the authors recommend that the proposals for 436 lightweight PIM peering across an MI-PMSI (the second mechanism) and 437 for the unicasting of PIM C-Join/Prune messages (the third mechanism) 438 be removed from the current solution document 439 [I-D.ietf-l3vpn-2547bis-mcast] until the additional PIM hello and 440 refresh reduction procedures have been well specified and both their 441 impact and benefit on an MPVN deployment is understood. 443 Consequently, at the present time and until there is experience with 444 all of the proposed mechanisms it is not clear which of the above 445 mechanisms should be recommended as the preferred solution to 446 implementers. However, it would appear prudent for implementations 447 to consider supporting both the fourth (BGP-based) and first (full 448 per-MPVN PIM peering) mechanisms. Further experience on both 449 implementation is likely to be required before some best practice can 450 be defined. 452 3.4. Encapsulation techniques for P-multicast trees 454 In this section the authors will not make any restricting 455 recommendations as the appropriateness of a specific core (P) data 456 plane technology will depend on a large number of factors, for 457 example the service provider's currently deployed unicast data plane, 458 many of which are service provider specific. 460 However, implementations should not unreasonably restrict the data 461 plane technology that can be used, and should not force the use of 462 the same technology for different VPNs attached to a single PE. 463 Initial implementations may only support a reduced set of 464 encapsulation techniques and data plane technologies but this should 465 not be considered a limiting factor that hinders future support for 466 other encapsulation techniques, data plane technologies or 467 interoperability. 469 Section 5.2.4.1 of [RFC4834] states "In a multicast VPN solution 470 extending a unicast L3 PPVPN solution, consistency in the tunneling 471 technology has to be favored: such a solution SHOULD allow the use of 472 the same tunneling technology for multicast as for unicast. 473 Deployment consistency, ease of operation and potential migrations 474 are the main motivations behind this requirement." 476 Current unicast VPN deployments use a variety of LDP, RSVP-TE and 477 GRE/IP for encapsulating customer packets for transport across the 478 provider core of VPN services. It is recommended that 479 implementations support the three corresponding multicast tree 480 encapsulations techniques, namely: mLDP, P2MP RSVP-TE and GRE/IP 481 multicast in order to allow the same encapsulations to be used for 482 unicast and multicast traffic as well as facilitating migration from 483 [I-D.rosen-vpn-mcast] to an MPLS label based encapsulation. 485 3.5. Inter-AS deployments options 487 There are a number of scenarios that lead to the requirement for 488 inter-AS multicast VPNs, including: 490 1. A service provider may have a large network that they have 491 segmented into a number of ASs. 493 2. A service provider's multicast VPN may consist of a number of ASs 494 due to aquisitions and mergers with other service providers. 496 3. A service provider may wish to interconnect their multicast VPN 497 platform with that of another service provider. 499 The first scenario can be considered the "simplest" because the 500 network is wholly managed by a single service provider under a single 501 strategy and is therefore likely to use a consistent set of 502 technologies across each AS. 504 The second scenario may be more complex than the first because the 505 strategy and technology choices made for each AS may have been 506 different due to their differing history and the service provider may 507 not have (or may be unwilling to) unified the strategy and technology 508 choices for each AS. 510 The third scenario is the most complex because in addition to the 511 complexity of the second scenario, the ASs are managed by different 512 service providers and therefore may be subject to a different trust 513 model than the other scenarios. 515 Section 5.2.6 of [RFC4834] states "A solution MUST support inter-AS 516 multicast VPNs, and SHOULD support inter-provider multicast VPNs. 517 Considerations about coexistence with unicast inter-AS VPN Options A, 518 B and C (as described in section 10 of [RFC4364]) are strongly 519 encouraged." and "A multicast VPN solution SHOULD provide inter-AS 520 mechanisms requiring the least possible coordination between 521 providers, and keep the need for detailed knowledge of providers' 522 networks to a minimum - all this being in comparison with 523 corresponding unicast VPN options." 525 Section 8 of [I-D.ietf-l3vpn-2547bis-mcast] addresses these 526 requirements by proposing two approaches for mVPN inter-AS 527 deployments: 529 1. Segmented inter-AS tunnels where each AS constructs its own 530 separate multicast tunnels which are then 'stitched' together by 531 the ASBRs (described in section 8.2). 533 2. Non-segmented inter-AS tunnels where the multicast tunnels are 534 end-to-end across ASes, so even though the PEs belonging to a 535 given MVPN may be in different ASs the ASBRs play no special role 536 and function merely as P routers (described in section 8.1). 538 Section 5.2.6 of [RFC4834] also states "Within each service provider 539 the service provider SHOULD be able on its own to pick the most 540 appropriate tunneling mechanism to carry (multicast) traffic among 541 PEs (just like what is done today for unicast)". Segmented inter-AS 542 tunnels is the only solution that is capable of meeting this 543 requirement. 545 The segmented inter-AS solution would appear to offer the largest 546 degree of deployment flexibility to operators, however the non- 547 segmented inter-AS solution can simplify deployment in a restricted 548 number of scenarios and [I-D.rosen-vpn-mcast] only supports the non- 549 segmented inter-AS solution and therefore the non-segmented inter-AS 550 solution is likely to be required by some operators for backward 551 compatibility and during migration from [I-D.rosen-vpn-mcast] to 552 [I-D.ietf-l3vpn-2547bis-mcast]. 554 The applicability of segmented or non-segmented inter-AS tunnels to a 555 given deployment or inter-provider interconnect will depend on a 556 number of factors specific to each service provider. However, due to 557 the additional deployment flexibility offered by segmented inter-AS 558 tunnels, it is the recommendation of the authors that all 559 implementations should support the segmented inter-AS model. 560 Additionally, the authors recommend that implementations should 561 consider supporting the non-segmented inter-AS model in order to 562 facilitate co-existence with existing deployments, and as a feature 563 to provide a lighter engineering in a restricted set of scenarios, 564 although it is recognised that initial implementations may only 565 support one or the other. 567 Additionally, the authors note that the proposed BGP-based approaches 568 for S-PMSI signaling and C-multicast routing information distribution 569 provide a good fit with both segmented and non-segmented inter-AS 570 tunnels. In contrast the UDP-TLV based approach for S-PMSI signaling 571 appears to be incompatible with segmented inter-AS tunnels, and it is 572 unclear if the proposed PIM-based approaches for C-multicast routing 573 information distribution would be fully applicable to segmented 574 inter-AS tunnels. 576 4. Co-located RPs 578 Section 5.1.10.1 of [RFC4834] states "In the case of PIM-SM in ASM 579 mode, engineering of the RP function requires the deployment of 580 specific protocols and associated configurations. A service provider 581 may offer to manage customers' multicast protocol operation on their 582 behalf. This implies that it is necessary to consider cases where a 583 customer's RPs are outsourced (e.g., on PEs). Consequently, a VPN 584 solution MAY support the hosting of the RP function in a VR or VRF." 586 Co-locating a customer's RP on a PE can provide some benefits to the 587 customer as outlined in section 5.1.10.3 of [RFC4834] which states 588 "In the case of PIM-SM, when a source starts to emit traffic toward a 589 group (in ASM mode), if sources and receivers are located in VPN 590 sites that are different than that of the RP, then traffic may 591 transiently flow twice through the SP network and the CE-PE link of 592 the RP (from source to RP, and then from RP to receivers). This 593 traffic peak, even short, may not be convenient depending on the 594 traffic and link bandwidth. 596 However, customers who have already deployed multicast within their 597 networks and have therefore already deployed their own internal RPs 598 are often reluctant to hand over the control of their RPs to their 599 service provider and make use of a co-located RP model. 601 Also, providing colocating the RP on PE will require the activation 602 of MSDP or the processing of PIM Registers on the PE. Securing the 603 PE routers for such acitivity requires special care, additional work, 604 and will likely rely on specific features to be provided by the 605 routers themselves. 607 The applicability of the co-located RP model to a given MVPN will 608 thus depend on a number of factors specific to each customer and 609 service provider. It is therefore the recommendation of the authors 610 that implementations should support a co-located RP model, but that 611 support for a co-located RP model within an implementation should not 612 restrict deployments to using a co-located RP model, and 613 implementations should also support deployments when no RP is co- 614 located on a PE router and where all RPs are deployed within the 615 customers' networks. 617 5. Existing deployments 619 Some suggestions provided in this document can be used to 620 incrementally modify currently deployed implementations without 621 hindering these deployments, and without hindering the consistency of 622 the standardized solution by providing optional per-VRF configuration 623 knobs to support modes of operation compatible with currently 624 deployed implementations, while at the same time using the 625 recommended approach on implementations supporting the standard. 627 In cases where this may not be easily achieved, a recommended 628 approach would be to provide a per-VRF configuration knob that allows 629 incremental per-VPN migration of the mechanisms used by a PE device, 630 which would allow migration with some per-VPN interruption of service 631 (e.g. during a maintenance window). 633 Mechanisms allowing "live" migration by providing concurrent use of 634 multiple alternatives for a given PE and a given VPN, is not seen as 635 a priority considering the expected implementation complexity 636 associated with such mechanisms. However, if there happen to be 637 cases where they could be viably implemented relatively simply, such 638 mechanisms may help improve migration management. 640 6. Summary of recommendations 642 The following list summarizes the authors' recommendations. These 643 recommendations are not intended to prevent the implementation of 644 alternative solutions, rather they are the authors' recommendations 645 for the mechanisms that should be made mandatory in 646 [I-D.ietf-l3vpn-2547bis-mcast] and therefore be supported by all 647 implementations. 649 It is the authors' recommendation: 651 o that BGP-based auto-discovery be the mandated solution for auto- 652 discovery; 654 o that BGP be the mandated solution for S-PMSI signaling; 655 o that the mandated solution for S-PMSI switch-over be the mechanism 656 based on the source-connected PE switching traffic from the I-PMSI 657 tunnel to the S-PMSI tunnel, without transmitting traffic on both 658 at the time; 660 o that implementations support both the BGP-based and the full per- 661 MPVN PIM peering solutions for PE-PE transmission of customer 662 multicast routing until further operational experience is gained 663 with both solutions; 665 o that implementations support the following multicast tree 666 encapsulations: mLDP, P2MP RSVP-TE and GRE/IP; 668 o that implementations support segmented inter-AS tunnels and 669 consider supporting non-segmented inter-AS tunnels[[in order to 670 maintain backwards compatibility and for migration]]. 672 o that implementations support a co-located RP model, but that 673 implementations should not restrict deployments to having to use a 674 co-located RP model. 676 7. IANA Considerations 678 This document makes no request of IANA. 680 Note to RFC Editor: this section may be removed on publication as an 681 RFC. 683 8. Security Considerations 685 This document does not by itself raise any particular security 686 considerations. 688 9. Acknowledgements 690 [To be completed] 692 10. Informative References 694 [I-D.ietf-l3vpn-2547bis-mcast] 695 Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP 696 VPNs", draft-ietf-l3vpn-2547bis-mcast-03 (work in 697 progress), October 2006. 699 [I-D.raggarwa-l3vpn-2547-mvpn] 700 Aggarwal, R., "Base Specification for Multicast in BGP/ 701 MPLS VPNs", draft-raggarwa-l3vpn-2547-mvpn-00 (work in 702 progress), June 2004. 704 [I-D.rosen-vpn-mcast] 705 Rosen, E., "Multicast in MPLS/BGP VPNs", 706 draft-rosen-vpn-mcast-08 (work in progress), 707 December 2004. 709 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 710 Requirement Levels", BCP 14, RFC 2119, March 1997. 712 [RFC4834] Morin, T., "Requirements for Multicast in L3 Provider- 713 Provisioned Virtual Private Networks (PPVPNs)", RFC 4834, 714 April 2007. 716 Authors' Addresses 718 Thomas Morin (editor) 719 France Telecom R&D 720 2 rue Pierre Marzin 721 Lannion 22307 722 France 724 Email: thomas.morin@orange-ftgroup.com 726 Ben Niven-Jenkins (editor) 727 BT 728 208 Callisto House, Adastral Park 729 Ipswich, Suffolk IP5 3RE 730 UK 732 Email: benjamin.niven-jenkins@bt.com 734 Yuji Kamite 735 NTT Communications Corporation 736 Tokyo Opera City Tower 737 3-20-2 Nishi Shinjuku, Shinjuku-ku 738 Tokyo 163-1421 739 Japan 741 Email: y.kamite@ntt.com 742 Raymond Zhang 743 BT 744 2160 E. Grand Ave. 745 El Segundo CA 90025 746 USA 748 Email: raymond.zhang@bt.com 750 Nicolai Leymann 751 Deutsche Telekom 752 Goslarer Ufer 35 753 10589 Berlin 754 Germany 756 Email: nicolai.leymann@t-systems.com 758 Full Copyright Statement 760 Copyright (C) The IETF Trust (2007). 762 This document is subject to the rights, licenses and restrictions 763 contained in BCP 78, and except as set forth therein, the authors 764 retain all their rights. 766 This document and the information contained herein are provided on an 767 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 768 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 769 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 770 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 771 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 772 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 774 Intellectual Property 776 The IETF takes no position regarding the validity or scope of any 777 Intellectual Property Rights or other rights that might be claimed to 778 pertain to the implementation or use of the technology described in 779 this document or the extent to which any license under such rights 780 might or might not be available; nor does it represent that it has 781 made any independent effort to identify any such rights. Information 782 on the procedures with respect to rights in RFC documents can be 783 found in BCP 78 and BCP 79. 785 Copies of IPR disclosures made to the IETF Secretariat and any 786 assurances of licenses to be made available, or the result of an 787 attempt made to obtain a general license or permission for the use of 788 such proprietary rights by implementers or users of this 789 specification can be obtained from the IETF on-line IPR repository at 790 http://www.ietf.org/ipr. 792 The IETF invites any interested party to bring to its attention any 793 copyrights, patents or patent applications, or other proprietary 794 rights that may cover technology that may be required to implement 795 this standard. Please address the information to the IETF at 796 ietf-ipr@ietf.org. 798 Acknowledgment 800 Funding for the RFC Editor function is provided by the IETF 801 Administrative Support Activity (IASA).