diff options
| author | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
|---|---|---|
| committer | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
| commit | 4bfd864f10b68b71482b35c818559068ef8d5797 (patch) | |
| tree | e3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc6517.txt | |
| parent | ea76e11061bda059ae9f9ad130a9895cc85607db (diff) | |
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc6517.txt')
| -rw-r--r-- | doc/rfc/rfc6517.txt | 2299 |
1 files changed, 2299 insertions, 0 deletions
diff --git a/doc/rfc/rfc6517.txt b/doc/rfc/rfc6517.txt new file mode 100644 index 0000000..a264e41 --- /dev/null +++ b/doc/rfc/rfc6517.txt @@ -0,0 +1,2299 @@ + + + + + + +Internet Engineering Task Force (IETF) T. Morin, Ed. +Request for Comments: 6517 France Telecom - Orange +Category: Informational B. Niven-Jenkins, Ed. +ISSN: 2070-1721 BT + Y. Kamite + NTT Communications + R. Zhang + Alcatel-Lucent + N. Leymann + Deutsche Telekom + N. Bitar + Verizon + February 2012 + + + Mandatory Features in a Layer 3 Multicast BGP/MPLS VPN Solution + +Abstract + + More that one set of mechanisms to support multicast in a layer 3 + BGP/MPLS VPN has been defined. These are presented in the documents + that define them as optional building blocks. + + To enable interoperability between implementations, this document + defines a subset of features that is considered mandatory for a + multicast BGP/MPLS VPN implementation. This will help implementers + and deployers understand which L3VPN multicast requirements are best + satisfied by each option. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6517. + + + + + + + +Morin, et al. Informational [Page 1] + +RFC 6517 Multicast VPN Mandatory Features February 2012 + + +Copyright Notice + + Copyright (c) 2012 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Examining Alternative Mechanisms for MVPN Functions . . . . . 4 + 3.1. MVPN Auto-Discovery . . . . . . . . . . . . . . . . . . . 4 + 3.2. S-PMSI Signaling . . . . . . . . . . . . . . . . . . . . . 5 + 3.3. PE-PE Exchange of C-Multicast Routing . . . . . . . . . . 7 + 3.3.1. PE-PE C-Multicast Routing Scalability . . . . . . . . 7 + 3.3.2. PE-CE Multicast Routing Exchange Scalability . . . . . 10 + 3.3.3. Scalability of P Routers . . . . . . . . . . . . . . . 10 + 3.3.4. Impact of C-Multicast Routing on Inter-AS Deployments 10 + 3.3.5. Security and Robustness . . . . . . . . . . . . . . . 11 + 3.3.6. C-Multicast VPN Join Latency . . . . . . . . . . . . . 12 + 3.3.7. Conclusion on C-Multicast Routing . . . . . . . . . . 14 + 3.4. Encapsulation Techniques for P-Multicast Trees . . . . . . 15 + 3.5. Inter-AS Deployments Options . . . . . . . . . . . . . . . 16 + 3.6. BIDIR-PIM Support . . . . . . . . . . . . . . . . . . . . 19 + 4. Co-Located RPs . . . . . . . . . . . . . . . . . . . . . . . . 20 + 5. Avoiding Duplicates . . . . . . . . . . . . . . . . . . . . . 21 + 6. Existing Deployments . . . . . . . . . . . . . . . . . . . . . 21 + 7. Summary of Recommendations . . . . . . . . . . . . . . . . . . 22 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 23 + Appendix A. Scalability of C-Multicast Routing Processing Load . 25 + A.1. Scalability with an Increased Number of PEs . . . . . . . 26 + A.1.1. SSM Scalability . . . . . . . . . . . . . . . . . . . 26 + A.1.2. ASM Scalability . . . . . . . . . . . . . . . . . . . 35 + A.2. Cost of PEs Leaving and Joining . . . . . . . . . . . . . 37 + Appendix B. Switching to S-PMSI . . . . . . . . . . . . . . . . . 40 + + + +Morin, et al. Informational [Page 2] + +RFC 6517 Multicast VPN Mandatory Features February 2012 + + +1. Introduction + + Specifications for multicast in BGP/MPLS [RFC6513] include multiple + alternative mechanisms for some of the required building blocks of + the solution. However, they do not identify which of these + mechanisms are mandatory to implement in order to ensure + interoperability. Not defining a set of mandatory-to-implement + mechanisms leads to a situation where implementations may support + different subsets of the available optional mechanisms that do not + interoperate, which is a problem for the numerous operators having + multi-vendor backbones. + + The aim of this document is to leverage the already expressed + requirements [RFC4834] and study the properties of each approach to + identify mechanisms that are good candidates for being part of a core + set of mandatory mechanisms that can be used to provide a base for + interoperable solutions. + + This document goes through the different building blocks of the + solution and concludes which mechanisms an implementation is required + to implement. Section 7 summarizes these requirements. + + Considering the history of the multicast VPN proposals and + implementations, it is also useful to discuss how existing + deployments of early implementations [RFC6037] [MVPN] can be + accommodated and provide suggestions in this respect. + +2. Terminology + + Please refer to [RFC6513] and [RFC4834]. As a reminder, in Section + 3.1 of [RFC6513], the "C-" and "P-" notations are used to + disambiguate between the provider scope and the scope of a specific + VPN customer; for instance, "C-PIM" designates a PIM protocol + instance in a VPN or VRF, while "P-PIM" would designate the instance + of PIM eventually deployed by the provider across its core between P + and PE routers. + + Other acronyms used in this document include the following: + + o LSP: Label Switched Path + + o P2MP: Point to Multipoint + + o MP2MP: Multipoint to Multipoint + + o GRE: Generic Routing Encapsulation + + o mLDP: Multicast LDP + + + +Morin, et al. Informational [Page 3] + +RFC 6517 Multicast VPN Mandatory Features February 2012 + + + o I-PMSI: Inclusive Provider Multiservice Interface + + o MI-PMSI: Multidirectional Inclusive Provider Multiservice + Interface + + o S-PMSI: Selective Provider Multiservice Interface + + o SSM: Source-Specific Multicast + + o ASM: Any-Source Multicast + + o PIM-SM: PIM Sparse Mode + + o PIM-SSM: PIM Sparse Mode in SSM Mode + + o BIDIR-PIM: Bidirectional PIM + + o AS: Autonomous System + + o ASBR: Autonomous System Border Router + + o VRF: VPN Routing and Forwarding + + o PE: Provider Edge + + o CE: Customer Edge + + o RPA: Rendezvous Point Address + + o RPL: Rendezvous Point Link + + Additionally, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", + "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + [RFC2119]. + +3. Examining Alternative Mechanisms for MVPN Functions + +3.1. MVPN Auto-Discovery + + The current solution document [RFC6513] proposes two different + mechanisms for Multicast VPN (MVPN) auto-discovery: + + 1. BGP-based auto-discovery + + 2. "PIM/shared P-tunnel": discovery done through the exchange of PIM + Hellos by C-PIM instances, across an MI-PMSI implemented with one + shared P-tunnel per VPN (using ASM or MP2MP LDP) + + + +Morin, et al. Informational [Page 4] + +RFC 6517 Multicast VPN Mandatory Features February 2012 + + + Both solutions address Section 5.2.10 of [RFC4834], which states that + "the operation of a multicast VPN solution SHALL be as light as + possible, and providing automatic configuration and discovery SHOULD + be a priority when designing a multicast VPN solution. Particularly, + the operational burden of setting up multicast on a PE or for a VR/ + VRF SHOULD be as low as possible". + + The key consideration is that PIM-based discovery is only applicable + to deployments using a shared P-tunnel to instantiate an MI-PMSI (it + is not applicable if only P2P, PIM-SSM, and P2MP LDP/RSVP-TE + P-tunnels are used, because contrary to ASM and MP2MP LDP, building + these types of P-tunnels cannot happen before the auto-discovery has + been done). In contrast, the BGP-based auto-discovery does not place + any constraint on the type of P-tunnel that would have to be used. + BGP-based auto-discovery is independent of the type of P-tunnel used, + thus satisfying the requirement in Section 5.2.4.1 of [RFC4834] that + "a multicast VPN solution SHOULD be designed so that control and + forwarding planes are not interdependent". + + Additionally, it is to be noted that a number of service providers + have chosen to use SSM-based P-tunnels for the default multicast + distribution trees within their current deployments, therefore + relying already on some BGP-based auto-discovery. + + Moreover, when shared P-tunnels are used, the use of BGP auto- + discovery would allow inconsistencies in the addresses/identifiers + used for the shared P-tunnel to be detected (e.g., the same shared + P-tunnel identifier being used for different VPNs with distinct BGP + route targets). This is particularly attractive in the context of + inter-AS VPNs where the impact of any misconfiguration could be + magnified and where a single service provider may not operate all the + ASes. Note that this technique to detect some misconfiguration cases + may not be usable during a transition period from a shared-P-tunnel + auto-discovery to a BGP-based auto-discovery. + + Thus, the recommendation is that implementation of the BGP-based + auto-discovery is mandated and should be supported by all MVPN + implementations. + +3.2. S-PMSI Signaling + + The current solution document [RFC6513] proposes two mechanisms for + signaling that multicast flows will be switched to a Selective PMSI + (S-PMSI): + + 1. a UDP-based TLV protocol specifically for S-PMSI signaling + (described in Section 7.4.2) + + + + +Morin, et al. Informational [Page 5] + +RFC 6517 Multicast VPN Mandatory Features February 2012 + + + 2. a BGP-based mechanism for S-PMSI signaling (described in Section + 7.4.1) + + Section 5.2.10 of [RFC4834] states that "as far as possible, the + design of a solution SHOULD carefully consider the number of + protocols within the core network: if any additional protocols are + introduced compared with the unicast VPN service, the balance between + their advantage and operational burden SHOULD be examined + thoroughly". The UDP-based mechanism would be an additional protocol + in the MVPN stack, which isn't the case for the BGP-based S-PMSI + switching signaling, since (a) BGP is identified as a requirement for + auto-discovery and (b) the BGP-based S-PMSI switching signaling + procedures are very similar to the auto-discovery procedures. + + Furthermore, the UDP-based S-PMSI switching signaling mechanism + requires an MI-PMSI, while the BGP-based protocol does not. In + practice, this mean that with the UDP-based protocol, a PE will have + to join to all P-tunnels of all PEs in an MVPN, while in the + alternative where BGP-based S-PMSI switching signaling is used, it + could delay joining a P-tunnel rooted at a PE until traffic from that + PE is needed, thus reducing the amount of state maintained on P + routers. + + S-PMSI switching signaling approaches can also be compared in an + inter-AS context (see Section 3.5). The proposed BGP-based approach + for S-PMSI switching signaling provides a good fit with both the + segmented and non-segmented inter-AS approaches (see Section 3.5). + By contrast, while the UDP-based approach for S-PMSI switching + signaling appears to be usable with segmented inter-AS tunnels, key + advantages of the segmented approach are lost: + + o ASes are no longer independent in their ability to choose when + S-PMSIs tunnels will be triggered in their AS (and thus control + the amount of state created on their P routers). + + o ASes are no longer independent in their ability to choose the + tunneling technique for the P-tunnels used for an S-PMSI. + + o In an inter-AS option B context, an isolation of ASes is obtained + as PEs in one AS don't have (direct) exchange of routing + information with PEs of other ASes. This property is not + preserved if UDP-based S-PMSI switching signaling is used. By + contrast, BGP-based C-multicast switching signaling does preserve + this property. + + Given all the above, it is the recommendation of the authors that BGP + is the preferred solution for S-PMSI switching signaling and should + be supported by all implementations. + + + +Morin, et al. Informational [Page 6] + +RFC 6517 Multicast VPN Mandatory Features February 2012 + + + If nothing prevents a fast-paced creation of S-PMSI, then S-PMSI + switching signaling with BGP would possibly impact the route + reflectors (RRs) used for MVPN routes. However, such a fast-paced + behavior would have an impact on P and PE routers resulting from + S-PMSI tunnels signaling, which will be the same independent of the + S-PMSI signaling approach that is used and which is certainly best to + avoid by setting up proper mechanisms. + + The UDP-based S-PMSI switching signaling protocol can also be + considered, as an option, given that this protocol has been in + deployment for some time. Implementations supporting both protocols + would be expected to provide a per-VRF (VPN Routing and Forwarding) + configuration knob to allow an implementation to use the UDP-based + TLV protocol for S-PMSI switching signaling for specific VRFs in + order to support the co-existence of both protocols (for example, + during migration scenarios). Apart from such migration-facilitating + mechanisms, the authors specifically do not recommend extending the + already proposed UDP-based TLV protocol to new types of P-tunnels. + +3.3. PE-PE Exchange of C-Multicast Routing + + The current solution document [RFC6513] proposes multiple mechanisms + for PE-PE exchange of customer multicast routing information + (C-multicast routing): + + 1. Full per-MVPN PIM peering across an MI-PMSI (described in Section + 3.4.1.1) + + 2. Lightweight PIM peering across an MI-PMSI (described in Section + 3.4.1.2) + + 3. The unicasting of PIM C-Join/Prune messages (described in Section + 3.4.1.3) + + 4. The use of BGP for carrying C-multicast routing (described in + Section 3.4.2) + +3.3.1. PE-PE C-Multicast Routing Scalability + + Scalability being one of the core requirements for multicast VPN, it + is useful to compare the proposed C-multicast routing mechanisms from + this perspective: Section 4.2.4 of [RFC4834] recommends that "a + multicast VPN solution SHOULD support several hundreds of PEs per + multicast VPN, and MAY usefully scale up to thousands" and Section + 4.2.5 states that "a solution SHOULD scale up to thousands of PEs + having multicast service enabled". + + + + + +Morin, et al. Informational [Page 7] + +RFC 6517 Multicast VPN Mandatory Features February 2012 + + + Scalability with an increased number of VPNs per PE, or with an + increased amount of multicast state per VPN, are also important but + are not focused on in this section since we didn't identify + differences between the various approaches for these matters: all + others things equal, the load on PE due to C-multicast routing + increases roughly linearly with the number of VPNs per PE and with + the amount of multicast state per VPN. + + This section presents conclusions related to PE-PE C-multicast + routing scalability. Appendix A provides more detailed explanations + on the differences in ways PIM-based approaches and the BGP-based + approach handle the C-multicast routing load, along with quantified + evaluations of the amount of state and messages with the different + approaches. Many points made in this section are detailed in + Appendix A.1. + + At high scales of multicast deployment, the first and third + mechanisms require the PEs to maintain a large number of PIM + adjacencies with other PEs of the same multicast VPN (which implies + the regular exchange of PIM Hellos with each other) and to + periodically refresh C-Join/Prune states, resulting in an increased + processing cost when the number of PEs increases (as detailed in + Appendix A.1). The second approach is less subject to this, and the + fourth approach is not subject to this. + + The third mechanism would reduce the amount of C-Join/Prune + processing for a given multicast flow for PEs that are not the + upstream neighbor for this flow but would require "explicit tracking" + state to be maintained by the upstream PE. It also isn't compatible + with the "Join suppression" mechanism. A possible way to reduce the + amount of signaling with this approach would be the use of a PIM + refresh-reduction mechanism. Such a mechanism, based on TCP, is + being specified by the PIM IETF Working Group ([PIM-PORT]); its use + in a multicast VPN context is not described in [RFC6513], but it is + expected that this approach will provide a scalability similar to the + BGP-based approach without RRs. + + The second mechanism would operate in a similar manner to full per- + MVPN PIM peering except that PIM Hello messages are not transmitted + and PIM C-Join/Prune refresh-reduction would be used, thereby + improving scalability, but this approach has yet to be fully + described. In any case, it seems that it only improves one thing + among the things that will impact scalability when the number of PEs + increases. + + The first and second mechanisms can leverage the "Join suppression" + behavior and thus improve the processing burden of an upstream PE, + sparing the processing of a Join refresh message for each remote PE + + + +Morin, et al. Informational [Page 8] + +RFC 6517 Multicast VPN Mandatory Features February 2012 + + + joined to a multicast stream. This improvement requires all PEs of a + multicast VPN to process all PIM Join and Prune messages sent by any + other PE participating in the same multicast VPN whether they are the + upstream PE or not. + + The fourth mechanism (the use of BGP for carrying C-multicast + routing) would have a comparable drawback of requiring all PEs to + process a BGP C-multicast route only interesting a specific upstream + PE. For this reason, Section 16 of [RFC6514] recommends the use of + the Route Target constrained BGP distribution [RFC4684] mechanisms, + which eliminate this drawback by having only the interested upstream + PE receive a BGP C-multicast route. Specifically, when Route Target + constrained BGP distribution is used, the fourth mechanism reduces + the total amount of the C-multicast routing processing load put on + the PEs by avoiding any processing of customer multicast routing + information on the "unrelated" PEs that are neither the joining PE + nor the upstream PE. + + Moreover, the fourth mechanism further reduces the total amount of + message processing load by avoiding the use of periodic refreshes and + by inheriting BGP features that are expected to improve scalability + (for instance, providing a means to offload some of the processing + burden associated with customer multicast routing onto one or many + BGP route reflectors). The advantages of the fourth mechanism come + at a cost of maintaining an amount of state linear with the number of + PEs joined to a stream. However, the use of route reflectors allows + this cost to be spread among multiple route reflectors, thus + eliminating the need for a single route reflector to maintain all + this state. + + However, the fourth mechanism is specific in that it offers the + possibility of offloading customer multicast routing processing onto + one or more BGP route reflector(s). When this is used, there is a + drawback of increasing the processing load placed on the route + reflector infrastructure. In the higher scale scenarios, it may be + required to adapt the route reflector infrastructure to the MVPN + routing load by using, for example: + + o a separation of resources for unicast and multicast VPN routing: + using dedicated MVPN route reflector(s) (or using dedicated MVPN + BGP sessions or dedicated MVPN BGP instances), and + + o the deployment of additional route reflector resources, for + example, increasing the processing resources on existing route + reflectors or deployment of additional route reflectors. + + The most straightforward approach is to consider the introduction of + route reflectors dedicated to the MVPN service and dimension them + + + +Morin, et al. Informational [Page 9] + +RFC 6517 Multicast VPN Mandatory Features February 2012 + + + according to the need of that service (but doing so is not required + and is left as an operator engineering decision). + +3.3.2. PE-CE Multicast Routing Exchange Scalability + + The overhead associated with the PE-CE exchange of C-multicast + routing is independent of the choice of the mechanism used for the + PE-PE C-multicast routing. Therefore, the impact of the PE-CE + C-multicast routing overhead on the overall system scalability is + independent of the protocol used for PE-PE signaling and is therefore + not relevant when comparing the different approaches proposed for the + PE-PE C-multicast routing. This is true even if in some operational + contexts, the PE-CE C-multicast routing overhead is a significant + factor in the overall system overhead. + +3.3.3. Scalability of P Routers + + The first and second mechanisms are restricted to use within + multicast VPNs that use an MI-PMSI, thereby necessitating: + + o the use of a P-tunnel technique that allows shared P-tunnels (for + example, PIM-SM in ASM mode or MP2MP LDP), or + + o the use of one P-tunnel per PE per VPN, even for PEs that do not + have sources in their directly attached sites for that VPN. + + By comparison, the fourth mechanism doesn't impose either of these + restrictions and, when P2MP P-tunnels are used, only necessitates the + use of one P-tunnel per VPN per PE attached to a site with a + multicast source or Rendezvous Point (RP) (or with a candidate + Bootstrap Router (BSR), if BSR is used). + + In cases where there are fewer PEs connected with sources than the + total number of PEs, the fourth mechanism improves the amount of + state maintained by P routers compared to the amount required to + build an MI-PMSI with P2MP P-tunnels. Such cases are expected to be + frequent for multicast VPN deployments (see Section 4.2.4.1 of + [RFC4834]). + +3.3.4. Impact of C-Multicast Routing on Inter-AS Deployments + + Co-existence with unicast inter-AS VPN options, and an equal level of + security for multicast and unicast including in an inter-AS context, + are specifically mentioned in Sections 5.2.6 and 5.2.8 of [RFC4834]. + + In an inter-AS option B context, an isolation of ASes is obtained as + PEs in one AS don't have (direct) exchange of routing information + with PEs of other ASes. This property is not preserved if PIM-based + + + +Morin, et al. Informational [Page 10] + +RFC 6517 Multicast VPN Mandatory Features February 2012 + + + PE-PE C-multicast routing is used. By contrast, the fourth option + (BGP-based C-multicast routing) does preserve this property. + + Additionally, the authors note that the proposed BGP-based approach + for C-multicast routing provides a good fit with both the segmented + and non-segmented inter-AS approaches. By contrast, though the PIM- + based C-multicast routing is usable with segmented inter-AS tunnels, + the inter-AS scalability advantage of the approach is lost, since PEs + in an AS will see the C-multicast routing activity of all other PEs + of all other ASes. + +3.3.5. Security and Robustness + + BGP supports MD5 authentication of its peers for additional security, + thereby possibly directly benefiting multicast VPN customer multicast + routing, whether for intra-AS or inter-AS communications. By + contrast, with a PIM-based approach, no mechanism providing a + comparable level of security to authenticate communications between + remote PEs has yet been fully described [RFC5796] and, in any case, + would require significant additional operations for the provider to + be usable in a multicast VPN context. + + The robustness of the infrastructure, especially the existing + infrastructure providing unicast VPN connectivity, is key. The + C-multicast routing function, especially under load, will compete + with the unicast routing infrastructure. With the PIM-based + approaches, the unicast and multicast VPN routing functions are + expected to only compete in the PE, for control plane processing + resources. In the case of the BGP-based approach, they will compete + on the PE for processing resources and in the route reflectors + (supposing they are used for MVPN routing). In both cases, + mechanisms will be required to arbitrate resources (e.g., processing + priorities). In the case of PIM-based procedures, this arbitration + occurs between the different control plane routing instances in the + PE. In the case of the BGP-based approach, this is likely to require + using distinct BGP sessions for multicast and unicast (e.g., through + the use of dedicated MVPN BGP route reflectors or the use of a + distinct session with an existing route reflector). + + Multicast routing is dynamic by nature, and multicast VPN routing has + to follow the VPN customers' multicast routing events. The different + approaches can be compared on how they are expected to behave in + scenarios where multicast routing in the VPNs is subject to an + intense activity. Scalability of each approach under such a load is + detailed in Appendix A.2, and the fourth approach (BGP-based) used in + conjunction with the Route Target Constraint mechanisms [RFC4684] is + the only one having a cost for join/leave operations independent of + the number of PEs in the VPN (with one exception detailed in + + + +Morin, et al. Informational [Page 11] + +RFC 6517 Multicast VPN Mandatory Features February 2012 + + + Appendix A.2) and state maintenance not concentrated on the upstream + PE. + + On the other hand, while the BGP-based approach is likely to suffer a + slowdown under a load that is greater than the available processing + resources (because of possibly congested TCP sockets), the PIM-based + approaches would react to such a load by dropping messages, with + failure-recovery obtained through message refreshes. Thus, the BGP- + based approach could result in a degradation of join/leave latency + performance typically spread evenly across all multicast streams + being joined in that period, while the PIM-based approach could + result in increased join/leave latency, for some random streams, by a + multiple of the time between refreshes (e.g., tens of seconds), and + possibly in some states, the adjacency may timeout, resulting in + disruption of multicast streams. + + The behavior of the PIM-based approach under such a load is also + harder to predict, given that the performance of the "Join + suppression" mechanism (an important mechanism for this approach to + scale) will itself be impeded by delays in Join processing. For + these reasons, the BGP-based approach would be able to provide a + smoother degradation and more predictable behavior under a highly + dynamic load. + + In fact, both an "evenly spread degradation" and an "unevenly spread + larger degradation" can be problematic, and what seems important is + the ability for the VPN backbone operator to (a) limit the amount of + multicast routing activity that can be triggered by a multicast VPN + customer and (b) provide the best possible independence between + distinct VPNs. It seems that both of these can be addressed through + local implementation improvements and that both the BGP-based and + PIM-based approaches could be engineered to provide (a) and (b). It + can be noted though that the BGP approach proposes ways to dampen + C-multicast route withdrawals and/or advertisements and thus already + describes a way to provide (a), while nothing comparable has yet been + described for the PIM-based approaches (even though it doesn't appear + difficult). The PIM-based approaches rely on a per-VPN data plane to + carry the MVPN control plane and thus may benefit from this first + level of separation to solve (b). + +3.3.6. C-Multicast VPN Join Latency + + Section 5.1.3 of [RFC4834] states that the "group join delay [...] is + also considered one important QoS parameter. It is thus RECOMMENDED + that a multicast VPN solution be designed appropriately in this + regard". In a multicast VPN context, the "group join delay" of + interest is the time between a CE sending a PIM Join to its PE and + + + + +Morin, et al. Informational [Page 12] + +RFC 6517 Multicast VPN Mandatory Features February 2012 + + + the first packet of the corresponding multicast stream being received + by the CE. + + It is to be noted that the C-multicast routing procedures will only + impact the group join latency of a said multicast stream for the + first receiver that is located across the provider backbone from the + multicast source-connected PE (or the first <n> receivers in the + specific case where a specific Upstream Multicast Hop selection + algorithm is used, which allows <n> distinct PEs to be selected as + the Upstream Multicast Hop by distinct downstream PEs). + + The different approaches proposed seem to have different + characteristics in how they are expected to impact join latency: + + o The PIM-based approaches minimize the number of control plane + processing hops between a new receiver-connected PE and the + source-connected PE and, being datagram-based, introduce minimal + delay, thereby possibly having a join latency as good as possible + depending on implementation efficiency. + + o Under degraded conditions (packet loss, congestion, or high + control plane load) the PIM-based approach may impact the latency + for a given multicast stream in an all-or-nothing manner: if a + C-multicast routing PIM Join packet is lost, latency can reach a + high time (a multiple of the periodicity of PIM Join refreshes). + + o The BGP-based approach uses TCP exchanges, which may introduce an + additional delay depending on BGP and TCP implementation but which + would typically result, under degraded conditions (such packet + loss, congestion, or high control plane load), in a comparably + lower increase of latency spread more evenly across the streams. + + o As shown in Appendix A, the BGP-based approach is particular in + that it removes load from all the PEs (without putting this load + on the upstream PE for a stream); this improvement of background + load can bring improved performance when a PE acts as the upstream + PE for a stream and thus benefits join latency. + + This qualitative comparison of approaches shows that the BGP-based + approach is designed for a smoother degradation of latency under + degraded conditions such as packet loss, congestion, or high control + plane load. On the other hand, the PIM-based approaches seem to + structurally be able to reach the shorter "best-case" group join + latency (especially compared to deployment of the BGP-based approach + where route reflectors are used). + + Doing a quantitative comparison of latencies is not possible without + referring to specific implementations and benchmarking procedures and + + + +Morin, et al. Informational [Page 13] + +RFC 6517 Multicast VPN Mandatory Features February 2012 + + + would possibly expose different conclusions, especially for best-case + group join latency for which performance is expected to vary with PIM + and BGP implementations. We can also note that improving a BGP + implementation for reduced latency of route processing would not only + benefit multicast VPN group join latency but the whole BGP-based + routing, which means that the need for good BGP/RR performance is not + specific to multicast VPN routing. + + Last, C-multicast join latency will be impacted by the overall load + put on the control plane, and the scalability of the C-multicast + routing approach is thus to be taken into account. As explained in + Section 3.3.1 and Appendix A, the BGP-based approach will provide the + best scalability with an increased number of PEs per VPN, thereby + benefiting group join latency in such higher-scale scenarios. + +3.3.7. Conclusion on C-Multicast Routing + + The first and fourth approaches are relevant contenders for + C-multicast routing. Comparisons from a theoretical standpoint lead + to identification of some advantages as well as possible drawbacks in + the fourth approach. Comparisons from a practical standpoint are + harder to make: since only reduced deployment and implementation + information is available for the fourth approach, advantages would be + seen in the first approach that has been applied through multiple + deployments and shown to be operationally viable. + + Moreover, the first mechanism (full per-MVPN PIM peering across an + MI-PMSI) is the mechanism used by [RFC6037]; therefore, it is + deployed and operating in MVPNs today. The fourth approach may or + may not end up being preferred for a said deployment, but because the + first approach has been in deployment for some time, the support for + this mechanism will in any case be helpful to facilitate an eventual + migration from a deployment using mechanism close to the first + approach. + + Consequently, at the present time, implementations are recommended to + support both the fourth (BGP-based) and first (full per-MVPN PIM + peering) mechanisms. Further experience on deployments of the fourth + approach is needed before some best practices can be defined. In the + meantime, this recommendation would enable a service provider to + choose between the first and the fourth mechanisms, without this + choice being constrained by vendor implementation choices. A service + provider can also take into account the peculiarities of its own + deployment context by pondering the weight of the different factors + into account. + + + + + + +Morin, et al. Informational [Page 14] + +RFC 6517 Multicast VPN Mandatory Features February 2012 + + +3.4. Encapsulation Techniques for P-Multicast Trees + + In this section, the authors will not make any restricting + recommendations since the appropriateness of a specific provider core + data plane technology will depend on a large number of factors, for + example, the service provider's currently deployed unicast data + plane, many of which are service provider specific. + + However, implementations should not unreasonably restrict the data + plane technology that can be used and should not force the use of the + same technology for different VPNs attached to a single PE. Initial + implementations may only support a reduced set of encapsulation + techniques and data plane technologies, but this should not be a + limiting factor that hinders future support for other encapsulation + techniques, data plane technologies, or interoperability. + + Section 5.2.4.1 of [RFC4834] states, "In a multicast VPN solution + extending a unicast layer 3 PPVPN solution, consistency in the + tunneling technology has to be favored: such a solution SHOULD allow + the use of the same tunneling technology for multicast as for + unicast. Deployment consistency, ease of operation, and potential + migrations are the main motivations behind this requirement". + + Current unicast VPN deployments use a variety of LDP, RSVP-TE, and + GRE/IP-Multicast for encapsulating customer packets for transport + across the provider core of VPN services. In order to allow the same + encapsulations to be used for unicast and multicast VPN traffic, it + is recommended that multicast VPN standards should recommend that + implementations support multicast VPNs and all the P2MP variants of + the encapsulations and signaling protocols that they support for + unicast and for which some multipoint extension is defined, such as + mLDP, P2MP RSVP-TE, and GRE/IP-multicast. + + All three of the above encapsulation techniques support the building + of P2MP multicast P-tunnels. In addition, mLDP and GRE/ + IP-ASM-Multicast implementations may also support the building of + MP2MP multicast P-tunnels. The use of MP2MP P-tunnels may provide + some scaling benefits to the service provider as only a single MP2MP + P-tunnel need be deployed per VPN, thus reducing by an order of + magnitude the amount of multicast state that needs to be maintained + by P routers. This gain in state is at the expense of bandwidth + optimization, since sites that do not have multicast receivers for + multicast streams sourced behind a said PE group will still receive + packets of such streams, leading to non-optimal bandwidth utilization + across the VPN core. One thing to consider is that the use of MP2MP + multicast P-tunnel will require additional configuration to define + the same P-tunnel identifier or multicast ASM group address in all + PEs (it has been noted that some auto-configuration could be possible + + + +Morin, et al. Informational [Page 15] + +RFC 6517 Multicast VPN Mandatory Features February 2012 + + + for MP2MP P-tunnels, but this is not currently supported by the auto- + discovery procedures). (It has been noted that C-multicast routing + schemes not covered in [RFC6513] could expose different advantages of + MP2MP multicast P-tunnels; this is out of the scope of this + document.) + + MVPN services can also be supported over a unicast VPN core through + the use of ingress PE replication whereby the ingress PE replicates + any multicast traffic over the P2P tunnels used to support unicast + traffic. While this option does not require the service provider to + modify their existing P routers (in terms of protocol support) and + does not require maintaining multicast-specific state on the P + routers in order for the service provider to be able deploy a + multicast VPN service, the use of ingress PE replication obviously + leads to non-optimal bandwidth utilization, and it is therefore + unlikely to be the long-term solution chosen by service providers. + However, ingress PE replication may be useful during some migration + scenarios or where a service provider considers the level of + multicast traffic on their network to be too low to justify deploying + multicast-specific support within their VPN core. + + All proposed approaches for control plane and data plane can be used + to provide aggregation amongst multicast groups within a VPN and + amongst different multicast VPNs, and potentially reduce the amount + of state to be maintained by P routers. However, the latter (the + aggregation amongst different multicast VPNs) will require support + for upstream-assigned labels on the PEs. Support for upstream- + assigned labels may require changes to the data plane processing of + the PEs, and this should be taken into consideration by service + providers considering the use of aggregate PMSI tunnels for the + specific platforms that the service provider has deployed. + +3.5. Inter-AS Deployments Options + + There are a number of scenarios that lead to the requirement for + inter-AS multicast VPNs, including: + + 1. A service provider may have a large network that it has segmented + into a number of ASes. + + 2. A service provider's multicast VPN may consist of a number of + ASes due to acquisitions and mergers with other service + providers. + + 3. A service provider may wish to interconnect its multicast VPN + platform with that of another service provider. + + + + + +Morin, et al. Informational [Page 16] + +RFC 6517 Multicast VPN Mandatory Features February 2012 + + + The first scenario can be considered the "simplest" because the + network is wholly managed by a single service provider under a single + strategy and is therefore likely to use a consistent set of + technologies across each AS. + + The second scenario may be more complex than the first because the + strategy and technology choices made for each AS may have been + different due to their differing histories, and the service provider + may not have unified (or may be unwilling to unify) the strategy and + technology choices for each AS. + + The third scenario is the most complex because in addition to the + complexity of the second scenario, the ASes are managed by different + service providers and therefore may be subject to a different trust + model than the other scenarios. + + Section 5.2.6 of [RFC4834] states that "a solution MUST support + inter-AS multicast VPNs, and SHOULD support inter-provider multicast + VPNs", "considerations about co-existence with unicast inter-AS VPN + Options A, B, and C (as described in Section 10 of [RFC4364]) are + strongly encouraged", and "a multicast VPN solution SHOULD provide + inter-AS mechanisms requiring the least possible coordination between + providers, and keep the need for detailed knowledge of providers' + networks to a minimum -- all this being in comparison with + corresponding unicast VPN options". + + Section 8 of [RFC6513] addresses these requirements by proposing two + approaches for MVPN inter-AS deployments: + + 1. Non-segmented inter-AS tunnels where the multicast tunnels are + end-to-end across ASes, so even though the PEs belonging to a + given MVPN may be in different ASes, the ASBRs play no special + role and function merely as P routers (described in Section 8.1). + + 2. Segmented inter-AS tunnels where each AS constructs its own + separate multicast tunnels that are then 'stitched' together by + the ASBRs (described in Section 8.2). + + (Note that an inter-AS deployment can alternatively rely on Option A + -- so-called "back-to-back" VRFs -- that option is not considered in + this section given that it can be used without any inter-AS-specific + mechanism.) + + Section 5.2.6 of [RFC4834] also states, "Within each service + provider, the service provider SHOULD be able on its own to pick the + most appropriate tunneling mechanism to carry (multicast) traffic + among PEs (just like what is done today for unicast)". The segmented + approach is the only one capable of meeting this requirement. + + + +Morin, et al. Informational [Page 17] + +RFC 6517 Multicast VPN Mandatory Features February 2012 + + + The segmented inter-AS solution would appear to offer the largest + degree of deployment flexibility to operators. However, the non- + segmented inter-AS solution can simplify deployment in a restricted + number of scenarios. [RFC6037] only supports the non-segmented + inter-AS solution; therefore, the non-segmented inter-AS solution is + likely to be useful to some operators for backward compatibility and + during migration from [RFC6037] to [RFC6513]. + + The following is a comparison matrix between the "segmented inter-AS + P-tunnels" and "non-segmented inter-AS P-tunnels" approaches: + + o Scalability for I-PMSIs: The "segmented inter-AS P-tunnels" + approach is more scalable, because of the ability of an ASBR to + aggregate multiple intra-AS P-tunnels used for I-PMSI within its + own AS into one inter-AS P-tunnel to be used by other ASes. Note + that the I-PMSI scalability improvement brought by the "segmented + inter-AS P-tunnels" approach is higher when segmented P-tunnels + have a granularity of source AS (see item below). + + o Scalability for S-PMSIs: The "segmented inter-AS P-tunnels" + approach, when used with the BGP-based C-multicast routing + approach, provides flexibility in how the bandwidth/state trade- + off is handled, to help with scalability. Indeed, in that case, + the trade-off made for a said (C-S,C-G) in a downstream AS can be + made more in favor of scalability than the trade-off made by the + neighbor upstream AS, thanks to the ability to aggregate one or + more S-PMSIs of the upstream AS in one I-PMSI tunnel in a + downstream AS. + + o Configuration at ASBRs: Depending on whether segmented P-tunnels + have a granularity of source ASBR or source AS, the "segmented + inter-AS P-tunnels" approach would require respectively the same + or additional configuration on ASBRs as the "non-segmented + inter-AS P-tunnels" approach. + + o Independence of tunneling technology from one AS to another: The + "segmented inter-AS P-tunnels" approach provides this; the "non- + segmented inter-AS P-tunnels" approach does not. + + o Facilitated coexistence with, and migration from, existing + deployments and lighter engineering in some scenarios: The "non- + segmented inter-AS P-tunnels" approach provides this; the + "segmented inter-AS P-tunnels" approach does not. + + The applicability of segmented or non-segmented inter-AS tunnels to a + given deployment or inter-provider interconnect will depend on a + number of factors specific to each service provider. However, given + the different elements reminded above, it is the recommendation of + + + +Morin, et al. Informational [Page 18] + +RFC 6517 Multicast VPN Mandatory Features February 2012 + + + the authors that all implementations should support the segmented + inter-AS model. Additionally, the authors recommend that + implementations should consider supporting the non-segmented inter-AS + model in order to facilitate coexistence with, and migration from, + existing deployments, and to provide a lighter engineering in a + restricted set of scenarios, although it is recognized that initial + implementations may only support one or the other. + +3.6. BIDIR-PIM Support + + In BIDIR-PIM, the packet-forwarding rules have been improved over + PIM-SM, allowing traffic to be passed up the shared tree toward the + RPA. To avoid multicast packet looping, BIDIR-PIM uses a mechanism + called the designated forwarder (DF) election, which establishes a + loop-free tree rooted at the RPA. Use of this method ensures that + only one copy of every packet will be sent to an RPA, even if there + are parallel equal cost paths to the RPA. To avoid loops, the DF + election process enforces a consistent view of the DF on all routers + on network segment, and during periods of ambiguity or routing + convergence, the traffic forwarding is suspended. + + In the context of a multicast VPN solution, a solution for BIDIR-PIM + support must preserve this property of similarly avoiding packet + loops, including in the case where multicast VRFs in a given MVPN + don't have a consistent view of the routing to C-RPL/C-RPA (Customer- + RPL/Customer-RPA, i.e., RPL/RPA of a Bidir customer PIM instance). + + Section 11 of the current MVPN specification [RFC6513] defines three + methods to support BIDIR-PIM, as RECOMMENDED in [RFC4834]: + + 1. Standard DF election procedure over an MI-PMSI + + 2. VPN Backbone as the RPL (Section 11.1) + + 3. Partitioned Sets of PEs (Section 11.2) + + Method (1) is naturally applied to deployments using "Full per-MVPN + PIM peering across an MI-PMSI" for C-multicast routing, but as + indicated in [RFC6513], Section 11, the DF election may not work well + in an MVPN environment, and an alternative to DF election would be + desirable. + + The advantage of methods (2) and (3) is that they do not require + running the DF election procedure among PEs. + + Method (2) leverages the fact that in BIDIR-PIM, running the DF + election procedure is not needed on the RPL. This approach thus has + the benefit of simplicity of implementation, especially in a context + + + +Morin, et al. Informational [Page 19] + +RFC 6517 Multicast VPN Mandatory Features February 2012 + + + where BGP-based C-multicast routing is used. However, it has the + drawback of putting constraints on how BIDIR-PIM is deployed, which + may not always match the requirements of MVPN customers. + + Method (3) treats an MVPN as a collection of sets of multicast VRFs, + all PEs in a set having the same reachability information towards + C-RPA but distinct from PEs in other sets. Hence, with this method, + C-Bidir packet loops in MVPN are resolved by the ability to partition + a VPN into disjoint sets of VRFs, each having a distinct view of the + converged network. The partitioning approach to BIDIR-PIM requires + either upstream-assigned MPLS labels (to denote the partition) or a + unique MP2MP LSP per partition. The former is based on PE + Distinguisher Labels that have to be distributed using auto-discovery + BGP routes, and their handling requires the support for upstream + assigned labels and context label lookups [RFC5331]. The latter, + using MP2MP LSP per partition, does not have these constraints but is + restricted to P-tunnel types supporting MP2MP connectivity (such as + mLDP [RFC6388]). + + This approach to C-Bidir can work with PIM-based or BGP-based + C-multicast routing procedures and is also generic in the sense that + it does not impose any requirements on the BIDIR-PIM service + offering. + + Given the above considerations, method (3) "Partitioned Sets of PEs" + is the RECOMMENDED approach. + + In the event where method (3) is not applicable (lack of support for + upstream assigned labels or for a P-tunnel type providing MP2MP + connectivity), then method (1) "Standard DF election procedure over + an MI-PMSI" and (2) "VPN Backbone as the RPL" are RECOMMENDED as + interim solutions, (1) having the advantage over (2) of not putting + constraints on how BIDIR-PIM is deployed and the drawbacks of only + being applicable when PIM-based C-multicast is used and of possibly + not working well in an MVPN environment. + +4. Co-Located RPs + + Section 5.1.10.1 of [RFC4834] states, "In the case of PIM-SM in ASM + mode, engineering of the RP function requires the deployment of + specific protocols and associated configurations. A service provider + may offer to manage customers' multicast protocol operation on their + behalf. This implies that it is necessary to consider cases where a + customer's RPs are outsourced (e.g., on PEs). Consequently, a VPN + solution MAY support the hosting of the RP function in a VR or VRF". + + However, customers who have already deployed multicast within their + networks and have therefore already deployed their own internal RPs + + + +Morin, et al. Informational [Page 20] + +RFC 6517 Multicast VPN Mandatory Features February 2012 + + + are often reluctant to hand over the control of their RPs to their + service provider and make use of a co-located RP model, and providing + RP-collocation on a PE will require the activation of Multicast + Source Discovery Protocol (MSDP) or the processing of PIM Registers + on the PE. Securing the PE routers for such activity requires + special care and additional work and will likely rely on specific + features to be provided by the routers themselves. + + The applicability of the co-located RP model to a given MVPN will + thus depend on a number of factors specific to each customer and + service provider. + + It is therefore the recommendation that implementations should + support a co-located RP model but that support for a co-located RP + model within an implementation should not restrict deployments to + using a co-located RP model: implementations MUST support deployments + when activation of a PIM RP function (PIM Register processing and RP- + specific PIM procedures) or a VRF MSDP instance is not required on + any PE router and where all the RPs are deployed within the + customers' networks or CEs. + +5. Avoiding Duplicates + + It is recommended that implementations support the procedures + described in Section 9.1.1 of [RFC6513] "Discarding Packets from + Wrong PE", allowing fully avoiding duplicates. + +6. Existing Deployments + + Some suggestions provided in this document can be used to + incrementally modify currently deployed implementations without + hindering these deployments and without hindering the consistency of + the standardized solution by providing optional per-VRF configuration + knobs to support modes of operation compatible with currently + deployed implementations, while at the same time using the + recommended approach on implementations supporting the standard. + + In cases where this may not be easily achieved, a recommended + approach would be to provide a per-VRF configuration knob that allows + incremental per-VPN migration of the mechanisms used by a PE device, + which would allow migration with some per-VPN interruption of service + (e.g., during a maintenance window). + + Mechanisms allowing "live" migration by providing concurrent use of + multiple alternatives for a given PE and a given VPN are not seen as + a priority considering the expected implementation complexity + + + + + +Morin, et al. Informational [Page 21] + +RFC 6517 Multicast VPN Mandatory Features February 2012 + + + associated with such mechanisms. However, if there happen to be + cases where they could be viably implemented relatively simply, such + mechanisms may help improve migration management. + +7. Summary of Recommendations + + The following list summarizes conclusions on the mechanisms that + define the set of mandatory-to-implement mechanisms in the context of + [RFC6513]. + + Note well that the implementation of the non-mandatory alternative + mechanisms is not precluded. + + Recommendations are: + + o that BGP-based auto-discovery be the mandated solution for auto- + discovery; + + o that BGP be the mandated solution for S-PMSI switching signaling; + + o that implementations support both the BGP-based and the full per- + MVPN PIM peering solutions for PE-PE exchange of customer + multicast routing until further operational experience is gained + with both solutions; + + o that implementations use the "Partitioned Sets of PEs" approach + for BIDIR-PIM support; + + o that implementations implement the P2MP variants of the P2P + protocols that they already implement, such as mLDP, P2MP RSVP-TE, + and GRE/IP-Multicast; + + o that implementations support segmented inter-AS tunnels and + consider supporting non-segmented inter-AS tunnels (in order to + maintain backward compatibility and for migration); + + o that implementations MUST support deployments when the activation + of a PIM RP function (PIM Register processing and RP-specific PIM + procedures) or VRF MSDP instance is not required on any PE router; + and + + o that implementations support the procedures described in Section + 9.1.1 of [RFC6513]. + +8. Security Considerations + + This document does not by itself raise any particular security + considerations. + + + +Morin, et al. Informational [Page 22] + +RFC 6517 Multicast VPN Mandatory Features February 2012 + + +9. Acknowledgements + + We would like to thank Adrian Farrel, Eric Rosen, Yakov Rekhter, and + Maria Napierala for their feedback that helped shape this document. + + Additional credit is due to Maria Napierala for co-authoring + Section 3.6 on BIDIR-PIM Support. + +10. References + +10.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ + BGP IP VPNs", RFC 6513, February 2012. + + [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP + Encodings and Procedures for Multicast in MPLS/BGP IP + VPNs", RFC 6514, February 2012. + +10.2. Informative References + + [MVPN] Aggarwal, R., "Base Specification for Multicast in BGP/ + MPLS VPNs", Work in Progress, June 2004. + + [PIM-PORT] Farinacci, D., Wijnands, I., Venaas, S., and M. + Napierala, "A Reliable Transport Mechanism for PIM", Work + in Progress, October 2011. + + [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private + Networks (VPNs)", RFC 4364, February 2006. + + [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, + R., Patel, K., and J. Guichard, "Constrained Route + Distribution for Border Gateway Protocol/MultiProtocol + Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual + Private Networks (VPNs)", RFC 4684, November 2006. + + [RFC4834] Morin, T., Ed., "Requirements for Multicast in Layer 3 + Provider-Provisioned Virtual Private Networks (PPVPNs)", + RFC 4834, April 2007. + + [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream + Label Assignment and Context-Specific Label Space", + RFC 5331, August 2008. + + + + +Morin, et al. Informational [Page 23] + +RFC 6517 Multicast VPN Mandatory Features February 2012 + + + [RFC5796] Atwood, W., Islam, S., and M. Siami, "Authentication and + Confidentiality in Protocol Independent Multicast Sparse + Mode (PIM-SM) Link-Local Messages", RFC 5796, March 2010. + + [RFC6037] Rosen, E., Cai, Y., and IJ. Wijnands, "Cisco Systems' + Solution for Multicast in BGP/MPLS IP VPNs", RFC 6037, + October 2010. + + [RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, + "Label Distribution Protocol Extensions for Point-to- + Multipoint and Multipoint-to-Multipoint Label Switched + Paths", RFC 6388, November 2011. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Morin, et al. Informational [Page 24] + +RFC 6517 Multicast VPN Mandatory Features February 2012 + + +Appendix A. Scalability of C-Multicast Routing Processing Load + + The main role of multicast routing is to let routers determine that + they should start or stop forwarding a said multicast stream on a + said link. In an MVPN context, this has to be done for each MVPN, + and the associated function is thus named "customer-multicast + routing" or "C-multicast routing", and its role is to let PE routers + determine that they should start or stop forwarding the traffic of a + said multicast stream toward the remote PEs, on some PMSI tunnel. + + When a Join message is received by a PE, this PE knows that it should + be sending traffic for the corresponding multicast group of the + corresponding MVPN. However, the reception of a Prune message from a + remote PE is not enough by itself for a PE to know that it should + stop forwarding the corresponding multicast traffic: it has to make + sure that there aren't any other PEs that still have receivers for + this traffic. + + There are many ways that the "C-multicast routing" building block can + be designed, and they differ, among other things, in how a PE + determines when it can stop forwarding a said multicast stream toward + other PEs: + + PIM LAN Procedures, by default + By default, when PIM LAN procedures are used when a PE on a LAN + Prunes itself from a multicast tree, all other PEs on that LAN + check their own state to known if they are on the tree, in which + case they send a PIM Join message on that LAN to override the + Prune. Thus, for each PIM Prune message, all PE routers on the + LAN work to let the upstream PE determine the answer to the "did + the last receiver leave?" question. + + BGP-based C-multicast routing + When BGP-based procedures are used for C-multicast routing, if no + BGP route reflector is used, the "did the last receiver leave?" + question is answered by having the upstream PE maintain an up-to- + date list of the PEs that are joined to the tree, thus making it + possible to instantly know the answer to the "did the last + receiver leave?" question whenever a PE leaves the said multicast + tree. + + However, when a BGP route reflector is used (which is expected to + be the recommended approach), the role of maintaining an updated + list of the PEs that are part of a said multicast tree is taken + care of by the route reflector(s). Using BGP procedures, a route + reflector that had advertised a C-multicast Source Tree Join route + for a said (C-S,C-G) to other route reflectors before will + withdraw this route when there is no of its clients PEs + + + +Morin, et al. Informational [Page 25] + +RFC 6517 Multicast VPN Mandatory Features February 2012 + + + advertising this route anymore. Similarly, a route reflector that + had advertised this route to its client PEs before will withdraw + this route when its (other) client PEs and its route reflectors + peers are no longer advertising this route. In this context, the + "did the last receiver leave?" question can be said to be answered + by the route reflector(s). + + Furthermore, the BGP route distribution can leverage more than one + route reflector: if multiple route reflectors are used with PEs + being distributed (as clients) among these route reflectors, the + "did the last receiver leave?" question is partly answered by each + of these route reflectors. + + We can see that the "last receiver leaves" question is a part of the + work that the C-multicast routing building block has to address, and + the different approaches significantly differ. The different + approaches for handling C-multicast routing can indeed result in a + different amount of processing and how this processing is spread + among the different functions. These differences can be better + estimated by quantifying the amount of message processing and state + maintenance. + + Though the type of processing, messages, and states may vary with the + different approaches, we propose here a rough estimation of the load + of PEs, in terms of number of messages processed and number of + control plane states maintained. A "message processed" is a message + being parsed, a lookup being done, and some action being taken (such + as, for instance, updating a control plane or data plane state or + discarding the information in the message). A "state maintained" is + a multicast state kept in the control plane memory of a PE, related + to an interface or a PE being subscribed to a multicast stream (note + that a state will be counted on an equipment as many times as the + number of protocols in which it is present, e.g., two times when + present both as a PIM state and a BGP route). Note that here we + don't compare the data plane states on PE routers, which wouldn't + vary between the different options chosen. + +A.1. Scalability with an Increased Number of PEs + + The following sections evaluate the processing and state maintenance + load for an increasingly high number of PEs in a VPN. + +A.1.1. SSM Scalability + + The following subsections do such an estimation for each proposed + approach for C-multicast routing, for different phases of the + following scenario: + + + + +Morin, et al. Informational [Page 26] + +RFC 6517 Multicast VPN Mandatory Features February 2012 + + + o One SSM multicast stream is considered. + + o Only the intra-AS case is concerned (with the segmented inter-AS + tunnels and BGP-based C-multicast routing, #mvpn_PE and #R_PE + should refer to the PEs of the MVPN in the AS, not to all PEs of + the MVPN). + + o The scenario is as follows: + + * One PE joins the multicast stream (because of a new receiver- + connected site has sent a Join on the PE-CE link), followed by + a number of additional PEs that also join the same multicast + stream, one after the other; we evaluate the processing + required for the addition of each PE. + + * A period of time T passes, without any PE joining or leaving + (baseline). + + * All PEs leave, one after the other, until the last one leaves; + we evaluate the processing required for the leave of each PE. + + o The parameters used are: + + * #mvpn_PE: the number of PEs in the MVPN + + * #R_PE: the number of PEs joining the multicast stream + + * #RR: the number of route reflectors + + * T_PIM_r: the time between two refreshes of a PIM Join (default + is 60s) + + The estimation unit used is the "message.equipment" (or "m.e"): one + "message.equipment" corresponds to "one equipment processing one + message" (10 m.e being "10 equipments processing each one message", + "5 messages each processed by 2 equipments", or "1 message processed + by 10 equipment", etc.). Similarly, for the amount of control plane + state, the unit used is "state.equipment" or "s.e". This accounts + for the fact that a message (or a state) can be processed (or + maintained) by more than one node. + + We distinguish three different types of equipments: the upstream PE + for the considered multicast stream, the RR (if any), and the other + PEs (which are not the upstream PE). + + + + + + + +Morin, et al. Informational [Page 27] + +RFC 6517 Multicast VPN Mandatory Features February 2012 + + + The numbers or orders of magnitude given in the tables in the + following subsections are totals across all equipments of a same + type, for each type of equipment, in the "m.e" and "s.e" units + defined above. + + Additionally: + + o For PIM, only Join and Prune messages are counted: + + * The load due to PIM Hellos can be easily computed separately + and only depends on the number of PEs in the VPN. + + * Message processing related to the PIM Assert mechanism is also + not taken into account, for the sake of simplicity. + + o For BGP, all advertisements and withdrawals of C-multicast Source + Tree Join routes are considered (Source-Active auto-discovery + routes are not used in an SSM context); following the + recommendation in Section 16 of [RFC6514], the case where the + Route Target Constraint mechanisms [RFC4684] is not used is not + covered. + + (Note that for all options provided for C-multicast routing, the + procedures to set up and maintain a shortest path tree toward the + source of an SSM group are the same as the procedures used to set up + and maintain a shortest path tree toward an RP or a non-SSM source; + the results of this section are thus re-used in Appendix A.1.2.) + + + + + + + + + + + + + + + + + + + + + + + + +Morin, et al. Informational [Page 28] + +RFC 6517 Multicast VPN Mandatory Features February 2012 + + +A.1.1.1. PIM LAN Procedures, by Default + + +------------+------------+---------------+----------+--------------+ + | | upstream | other PEs | RR | total across | + | | PE (1) | (total across | (none) | all | + | | | (#mvpn_PE-1) | | equipments | + | | | PEs) | | | + +------------+------------+---------------+----------+--------------+ + | first PE | 1 m.e | #mvpn_PE-1 | / | #mvpn_PE m.e | + | joins | | m.e | | | + +------------+------------+---------------+----------+--------------+ + | for *each* | 1 m.e | #mvpn_PE-1 | / | #mvpn_PE m.e | + | additional | | m.e | | | + | PE joining | | | | | + +------------+------------+---------------+----------+--------------+ + | baseline | T/T_PIM_r | (T/T_PIM_r) . | / | (T/T_PIM_r) | + | processing | m.e | (#mvpn_PE-1) | | x #mvpn_PE | + | over a | | m.e | | m.e | + | period T | | | | | + +------------+------------+---------------+----------+--------------+ + | for *each* | 2 m.e | 2(#mvpn_PE-1) | / | 2 x #mvpn_PE | + | PE leaving | | m.e | | m.e | + +------------+------------+---------------+----------+--------------+ + | the last | 1 m.e | #mvpn_PE-1 | / | #mvpn_PE m.e | + | PE leaves | | m.e | | | + +------------+------------+---------------+----------+--------------+ + | total for | #R_PE x 2 | (#mvpn_PE-1) | 0 | #mvpn_PE x ( | + | #R_PE PEs | + | x (#R_PE) x 2 | | 3 x #R_PE + | + | | T/T_PIM_r | + T/T_PIM_r) | | T/T_PIM_r ) | + | | m.e | . | | m.e | + | | | (#mvpn_PE-1) | | | + | | | m.e | | | + +------------+------------+---------------+----------+--------------+ + | total | 1 s.e | #R_PE s.e | 0 | #R_PE+1 s.e | + | state | | | | | + | maintained | | | | | + +------------+------------+---------------+----------+--------------+ + + Messages Processing and State Maintenance - PIM LAN Procedures, by + Default + + We suppose here that the PIM Join suppression and Prune Override + mechanisms are fully effective, i.e., that a Join or Prune message + sent by a PE is instantly seen by other PEs. Strictly speaking, this + is not true, and depending on network delays and timing, there could + be cases where more messages are exchanged, and the number given in + this table is a lower bound to the number of PIM messages exchanged. + + + + +Morin, et al. Informational [Page 29] + +RFC 6517 Multicast VPN Mandatory Features February 2012 + + +A.1.1.2. BGP-Based C-Multicast Routing + + The following analysis assumes that BGP route reflectors (RRs) are + used, and no hierarchy of RRs (note that the analysis also assumes + that Route Target Constraint mechanisms are used). + + Given these assumptions, a message carrying a C-multicast route from + a downstream PE would need to be processed by the RRs that have that + PE as their client. Due to the use of Route Target Constraint + mechanisms [RFC4684], these RRs would then send this message to only + the RRs that have the upstream PE as a client. None of the other RRs + and none of the other PEs will receive this message. Thus, for a + message associated with a given MVPN, the total number of RRs that + would need to process this message only depends on the number of RRs + that maintain C-multicast routes for that MVPN and that have either + the receiver-connected PE or the source-connected PE as their clients + and is independent of the total number of RRs or the total number of + PEs. + + In practice, for a given MVPN, a PE would be a client of just 2 RRs + (for redundancy, an RR cluster would typically have 2 RRs). + Therefore, in practice the message would need to be processed by at + most 4 RRs (2 RRs if both the downstream PE and the upstream PE are + the clients of the same RRs). Thus, the number of RRs that have to + process a given message is at most 4. Since RRs in different RR + clusters have a full Internal BGP (iBGP) mesh among themselves, each + RR in the RR cluster that contains the upstream PE would receive the + message from each of the RRs in the RR cluster that contains the + downstream PE. Given 2 RRs per cluster, the total number of messages + processed by all the RRs is 6. + + Additionally, as soon as there is a receiver-connected PE in each RR + cluster, the number of RRs processing a C-multicast route tends + quickly toward 2 (taking into account that a PE peering to RRs will + be made redundant). + + + + + + + + + + + + + + + + +Morin, et al. Informational [Page 30] + +RFC 6517 Multicast VPN Mandatory Features February 2012 + + + +------------+----------+--------------+-----------+----------------+ + | | upstream | other PEs | RRs (#RR) | total across | + | | PE (1) | (total | | all equipments | + | | | across | | | + | | | (#mvpn_PE-1) | | | + | | | PEs) | | | + +------------+----------+--------------+-----------+----------------+ + | first PE | 2 m.e | 2 m.e | 6 m.e | 10 m.e | + | joins | | | | | + +------------+----------+--------------+-----------+----------------+ + | for *each* | between | 2 m.e | (at most) | (at most) 10 | + | additional | 0 and 2 | | 6 m.e | m.e tending | + | PE joining | m.e | | tending | toward 4 m.e | + | | | | toward 2 | | + | | | | m.e | | + +------------+----------+--------------+-----------+----------------+ + | baseline | 0 | 0 | 0 | 0 | + | processing | | | | | + | over a | | | | | + | period T | | | | | + +------------+----------+--------------+-----------+----------------+ + | for *each* | between | 2 m.e | (at most) | (at most) 10 | + | PE leaving | 0 and 2 | | 6 m.e | m.e tending | + | | m.e | | tending | toward 4 m.e | + | | | | toward 2 | | + +------------+----------+--------------+-----------+----------------+ + | the last | 2 m.e | 2 m.e | 6 m.e | 10 m.e | + | PE leaves | | | | | + +------------+----------+--------------+-----------+----------------+ + | total for | at most | #R_PE x 4 | (at most) | at most 10 x | + | #R_PE PEs | 2 x #RRs | m.e | 6 x #R_PE | #R_PE + 2 x | + | | m.e (see | | m.e | #RRs m.e | + | | note | | (tending | (tending | + | | below) | | toward 2 | toward 6 x | + | | | | x #R_PE | #R_PE + #RRs | + | | | | m.e) | m.e ) | + +------------+----------+--------------+-----------+----------------+ + | total | 4 s.e | 2 x #R_PE | approx. 2 | approx. 4 | + | state | | s.e | #R_PE + | #R_PE + #RRx | + | maintained | | | #RR x | #clusters + 4 | + | | | | #clusters | m.e | + | | | | s.e | | + +------------+----------+--------------+-----------+----------------+ + + Message Processing and State Maintenance - BGP-Based Procedures + + + + + + +Morin, et al. Informational [Page 31] + +RFC 6517 Multicast VPN Mandatory Features February 2012 + + + Note on the total of m.e on the upstream PE: + + o There are as many "message.equipment"s on the upstream PE as the + number of times the RRs of the cluster of the upstream PE need to + re-advertise the C-multicast (C-S,C-G) route; such a re- + advertisement is not useful for the upstream PE, because the + behavior of the upstream PE for a said (VPN associated to the + Route Target, C-S,C-G) will not depend on the precise attributes + carried by the route (other than the Route Target, of course) but + will happen in some cases due to how BGP processes these routes. + Indeed, a BGP peer will possibly re-advertise a route when its + current best path changes for the said NLRI if the set of + attributes to advertise also changes. + + o Let's look at the different relevant attributes and when they can + influence when a re-advertisement of a C-multicast route will + happen: + + * next-hop and originator-id: A new PE joining will not + mechanically result in a need to re-advertise a C-multicast + route because as the RR aggregates C-multicast routes with the + same NLRI received from PEs in its own cluster (Section 11.4 of + [RFC6514]), the RR rewrites the values of these attributes; + however, the advertisements made by different RRs peering with + the RRs in the cluster of the upstream PE may lead to updates + of the value of these attributes. + + * cluster-list: The value of this attribute only varies between + clusters, changes of the value of this attributes does not + "follow" PE advertisements, and only advertisements made by + different RRs may possibly lead to updates of the value of this + attribute. + + * local-pref: The value of this attribute is determined locally; + this is true both for the routes advertised by each PE (which + could all be configured to use the same value) and for a route + that results from the aggregation by an RR of the route with + the same NLRI advertised by the PEs of his cluster (the RRs + could also be configured to use a local pref independent of the + local_pref of the routes advertised to him). Thus, this + attribute can be considered to result in a need to re-advertise + a C-multicast route. + + * Other BGP attributes do not have a particular reason to be set + for C-multicast routes in intra-AS, and if they were, an RR + (or, for attributes relevant for inter-AS, an ASBR) would also + overwrite these values when aggregating these routes. + + + + +Morin, et al. Informational [Page 32] + +RFC 6517 Multicast VPN Mandatory Features February 2012 + + + o Given the above, for a said C-multicast Source Tree Join (S,G) + NLRI, what may force an RR to re-advertise the route with + different attributes to the upstream PE would be the case of an RR + of another cluster advertising a route better than its current + best route, because of the values of attributes specific to that + RR (next-hop, originator-id, cluster-list) but not because of + anything specific to the PEs behind that RR. If we consider our + (#R_PE -1) joining a said (C-S,C-G), one after the other after the + first PE joining, some of these events may thus lead to a re- + advertisement to the upstream PE, but the number of times this can + happen is at worse the number of RRs in clusters having receivers + (plus one because of the possible advertisement of the same route + by a PE of the local cluster). + + o Given that we look at scalability with an increased number of PEs + in this section, we need to consider the possibility that all + clusters may have a client PE with a receiver. We also need to + consider that the two RRs of the cluster of the upstream PE may + need to re-advertise the route. With this in mind, we know that + 2x#RRs is an upper bound to the number of updates made by RRs to + the upstream PE, for the considered C-multicast route. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Morin, et al. Informational [Page 33] + +RFC 6517 Multicast VPN Mandatory Features February 2012 + + +A.1.1.3. Side-by-Side Orders of Magnitude Comparison + + This section concludes the previous section by considering the orders + of magnitude when the number of PEs in a VPN increases. + + +------------+--------------------------------+---------------------+ + | | PIM LAN Procedures | BGP-based | + +------------+--------------------------------+---------------------+ + | first PE | O(#mvpn_PE) | O(1) | + | joins (in | | | + | m.e) | | | + +------------+--------------------------------+---------------------+ + | for *each* | O(#mvpn_PE) | O(1) | + | additional | | | + | PE joining | | | + | (in m.e) | | | + +------------+--------------------------------+---------------------+ + | baseline | (T/T_PIM_r) x O(#mvpn_PE) | 0 | + | processing | | | + | over a | | | + | period T | | | + | (in m.e) | | | + +------------+--------------------------------+---------------------+ + | for *each* | O(#mvpn_PE) | O(1) | + | PE leaving | | | + | (in m.e) | | | + +------------+--------------------------------+---------------------+ + | the last | O(#mvpn_PE) | O(1) | + | PE leaves | | | + | (in m.e) | | | + +------------+--------------------------------+---------------------+ + | total for | O(#mvpn_PE x #R_PE) + | O(#R_PE) | + | #R_PE PEs | O(#mvpn_PE x T/T_PIM_r) | | + | (in m.e) | | | + +------------+--------------------------------+---------------------+ + | states (in | O(#R_PE) | O(#R_PE) | + | s.e) | | | + | notes | (processing and state | (processing and | + | | maintenance are essentially | state maintenance | + | | done by, and spread amongst, | is essentially done | + | | the PEs of the MVPN; | by, and spread | + | | non-upstream PEs have | amongst, the RRs) | + | | processing to do) | | + +------------+--------------------------------+---------------------+ + + Comparison of Orders of Magnitude for Message Processing and State + Maintenance (Totals across All Equipments) + + + + +Morin, et al. Informational [Page 34] + +RFC 6517 Multicast VPN Mandatory Features February 2012 + + + The conclusions that can be drawn from the above are as follows: + + o In the PIM-based approach, any message will be processed by all + PEs, including those that are neither upstream nor downstream for + the message; as a result, the total number of messages to process + is in O(#mvpn_PE x #R_PE), i.e., O(#mvpn_PE ^ 2) if the proportion + of receiver PEs is considered constant when the number of PEs + increases. The refreshes of Join messages introduce a linear + factor not changing the order of magnitude, but which can be + significant for long-lived streams; + + o The BGP-based approach requires an amount of message processing in + O(#R_PE) lower than the PIM-based approach. The amount is + independent of the duration of streams. + + o State maintenance is of the same order of magnitude for all + approaches: O(#R_PE), but the repartition is different: + + * The PIM-based approach fully spreads, and minimizes, the amount + of state (one state per PE). + + * The BGP-based procedures spread all the state on the set of + route reflectors. + +A.1.2. ASM Scalability + + The conclusions in Appendix A.1.1 are reused in this section, for the + parts that are common to the setup and maintenance of states related + to a source tree or a shared tree. + + When PIM-SM is used in a VPN and an ASM multicast group is joined by + some PEs (#R_PEs) with some sources sending toward this multicast + group address, we can note the following: + + PEs will generally have to maintain one shared tree, plus one source + tree for each source sending toward G; each tree resulting in an + amount of processing and state maintenance similar to what is + described in the scenario in Appendix A.1.1, with the same + differences in order of magnitudes between the different approaches + when the number of PEs is high. + + An exception to this is when, for a said group in a VPN among the PIM + instances in the customer routers and VRFs, none would switch to the + shortest path tree (SPT) (SwitchToSptDesired always false): in that + case, the processing and state maintenance load is the one required + for maintenance of the shared tree only. It has to be noted that + this scenario is dependent on customer policy. To compare the + resulting load in that case, between PIM-based approaches and the + + + +Morin, et al. Informational [Page 35] + +RFC 6517 Multicast VPN Mandatory Features February 2012 + + + BGP-based approach configured to use inter-site shared trees, the + scenario in Appendix A.1.1 can be used with #R_PEs joining a (C-*, + C-G) ASM group instead of an SSM group, and the same differences in + order of magnitude remain true. In the case of the BGP-based + approach used without inter-site shared trees, we must take into + account the load resulting from the fact that to build the C-PIM + shared tree, each PE has to join the source tree to each source; + using the notations of Appendix A.1.1, this adds an amount of load + (total load across all equipments) that is proportional to #R_PEs and + the number of sources. The order of magnitude with an increasing + number of PEs is thus unchanged, and the differences in order of + magnitude also remain the same. + + Additionally, to the maintenance of trees, PEs have to ensure some + processing and state maintenance related to individual sources + sending to a multicast group; the related procedures and behaviors + largely may differ depending on which C-multicast routing protocol is + used, how it is configured, how the multicast source discovery + mechanism is used in the customer VPN, and which SwitchToSptDesired + policy is used. However, the following can be observed: + + o When BGP-based C-multicast routing is used: + + * Each PE will possibly have to process and maintain a BGP + Source-Active auto-discovery route for (some or all) sources of + an ASM group. The number of Source-Active auto-discovery + routes will typically be one but may be related to the number + of upstream PEs in the following cases: when inter-site shared + trees are used and simultaneously more than one PE is used as + the upstream PE for SPT (C-S,C-G) trees and when inter-site + shared trees are used and there are multiple PEs that are + possible upstream for this (S,G). + + * This results in message processing and state maintenance (total + across all the equipments) linearly dependent on the number of + PEs in the VPN (#mvpn_PE) for each source, independent of the + number of PEs joined to the group. + + * Depending on whether or not inter-site shared trees are used, + on the SwitchToSptDesired policy in the PIM instances in the + customer routers and VRFs, and on the relative locations of + sources and RPs, this will happen for all (S,G) of an ASM group + or only for some of them and will be done in parallel to the + maintenance of shared and/or source trees or at the first join + of a PE on a source tree. + + + + + + +Morin, et al. Informational [Page 36] + +RFC 6517 Multicast VPN Mandatory Features February 2012 + + + o When PIM-based C-multicast routing is used, depending on the + SwitchToSptDesired policy in the PIM instances in the customer + routers and VRFs and depending on the relative locations of + sources and RPs, there are: + + * Possible control plane state transitions triggered by the + reception of (S,G) packets. Such events would induce + processing on all PEs joined to G. + + * Possible PIM Assert messages specific to (S,G). This would + induce a message processing on each PE of the VPN for each PIM + Assert message. + + Given the above, the additional processing that may happen for each + individual source sending to the group, beyond the maintenance of + source and shared trees, does not change the order of magnitude + identified above. + +A.2. Cost of PEs Leaving and Joining + + The quantification of message processing in Appendix A.1.1 is done + based on a use case where each PE with receivers has joined and left + once. Drawing scalability-related conclusions for other patterns of + changes of the set of receiver-connected PEs can be done by + considering the cost of each approach for "a new PE joining" and "a + PE leaving". + + For the "PIM LAN Procedure" approach, in the case of a single SSM or + SPT tree, the total amount of message processing across all nodes + depends linearly on the number of PEs in the VPN when a PE joins such + a tree. + + For the "BGP-based" approach: + + o In the case of a single SSM tree, the total amount of message + processing across all nodes is independent of the number of PEs, + for "a new PE" joining and "a PE leaving"; it also depends on how + route reflectors are meshed, but not on linear dependency. + + o In the case of an SPT tree for an ASM group, BGP has additional + processing due to possible Source-Active auto-discovery routes: + + * When BGP-based C-multicast routing is used with inter-site + shared trees, for the first PE joining (and the last PE + leaving) a said SPT, the processing of the corresponding + Source-Active auto-discovery routes results in a processing + cost linearly dependent on the number of PEs in the VPN. For + + + + +Morin, et al. Informational [Page 37] + +RFC 6517 Multicast VPN Mandatory Features February 2012 + + + subsequent PEs joining (and non-last PE leaving), there is no + processing due to advertisement or withdrawal of Source-Active + auto-discovery routes. + + * When BGP-based C-multicast routing is used without inter-site + shared trees, the processing of Source-Active auto-discovery + routes for an (S,G) happens independently of PEs joining and + leaving the SPT for (S,G). + + In the case of a new PE having to join a shared tree for an ASM group + G, we see the following: + + o The processing due to the PE joining the shared tree itself is the + same as the processing required to set up an SSM tree, as + described before (note that this does not happen when BGP-based + C-multicast routing is used without inter-site shared trees). + + o For each source for which the PE joins the SPT, the resulting + processing cost is the same as one SPT tree, as described before. + + * The conditions under which a PE will join the SPT for a said + (C-S,C-G) are the same between the BGP-based with inter-site + shared tree approach and the PIM-based approach, and depend + solely on the SwitchToSptDesired policy in the PIM instances in + the customer routers in the sites connected to the PE and/or in + the VRF. + + * The conditions under which a PE will join the SPT for a said + (C-S,C-G) differ between the BGP-based without inter-site + shared trees approach and the PIM-based approach. + + * The SPT for a said (S,G) can be joined by the PE in the + following cases: + + + as soon as one router, or the VPN VRF on the PE, has + SwitchToSptDesired(S,G) being true + + + when BGP-based routing is used and configured to not use + inter-site shared trees + + * Said differently, the only case where the PE will not join the + SPT for (S,G) is when all routers in the sites of the VPN + connected to the PE, or the VPN VRF itself, will never have + SwitchToSptDesired(S,G) being true, with the additional + condition that inter-site shared trees are used when BGP-based + C-multicast routing is used. + + + + + +Morin, et al. Informational [Page 38] + +RFC 6517 Multicast VPN Mandatory Features February 2012 + + + Thus, when one PE joins a group G to which n sources are sending + traffic, we note the following with regards to the dependency of the + cost (in total amount of processing across all equipments) to the + number of PEs: + + o In the general case (where any router in the site of the VPN + connected to the PE, or the VRF itself, may have + SwitchToSptDesired(S,G) being true): + + * For the "PIM LAN Procedure" approach, the cost is linearly + dependent on the number of PEs in the VPN and linearly + dependent on the number of sources. + + * For the "BGP-based" approach, the cost is linearly dependent on + the number of sources, and, in the sub-case of the BGP-based + approach used with inter-site shared trees, is also dependent + on the number of PEs in the VPN only if the PE is the first to + join the group or the SPT for some source sending to the group. + + o Else, under the assumption that routers in the sites of the VPN + connected to the PE, and the VPN VRF itself, will never have the + policy function SwitchToSptDesired(S,G) being possibly true, then: + + * In the case of the PIM-based approach, the cost is linearly + dependent on the number of PEs in the VPN, and there is no + dependency on the number of sources. + + * In the case of the BGP-based approach with inter-site shared + trees, the cost is linearly dependent on the number of RRs, and + there is no dependency on the number of sources. + + * In the case of the BGP-based approach without inter-site shared + trees, the cost is linearly dependent on the number of RRs and + on the number of sources. + + Hence, with the PIM-based approach, the overall cost across all + equipments of any PE joining an ASM group G is always dependent on + the number of PEs (same for a PE that leaves), while the BGP-based + approach has a cost independent of the number of PEs. An exception + is the first PE joining the ASM group for the BGP-based approach used + without inter-site shared trees; in that case, there is a dependency + with the number of PEs. + + On the dependency with the number of sources, without making any + assumption on the SwitchToSptDesired policy on PIM routers and VRFs + of a VPN, we see that a PE joining an ASM group may induce a + processing cost linearly dependent on the number of sources. Apart + from this general case, under the condition where the + + + +Morin, et al. Informational [Page 39] + +RFC 6517 Multicast VPN Mandatory Features February 2012 + + + SwitchToSptDesired is always false on all PIM routers and VRFs of the + VPN, then with the PIM-based approach, and with the BGP-based + approach used with inter-site shared trees, the cost in amount of + messages processed will be independent of the number of sources (it + has to be noted that this condition depends on customer policy). + +Appendix B. Switching to S-PMSI + + (The following point was fixed in a draft version of the document + that became [RFC6513] and is here for reference only.) + + In early versions of the document that became [RFC6513], two + approaches were proposed for how a source PE can decide when to start + transmitting customer multicast traffic on a S-PMSI: + + 1. The source PE sends multicast packets for the (C-S,C-G) on both + the I-PMSI P-multicast tree and the S-PMSI P-multicast tree + simultaneously for a pre-configured period of time, letting the + receiver PEs select the new tree for reception before switching + to only the S-PMSI. + + 2. The source PE waits for a pre-configured period of time after + advertising the (C-S,C-G) entry bound to the S-PMSI before fully + switching the traffic onto the S-PMSI-bound P-multicast tree. + + The first alternative had essentially two drawbacks: + + o (C-S,C-G) traffic is sent twice for some period of time, which + would appear to be at odds with the motivation for switching to an + S-PMSI in order to optimize the bandwidth used by the multicast + tree for that stream. + + o It is unlikely that the switchover can occur without packet loss + or duplication if the transit delays of the I-PMSI P-multicast + tree and the S-PMSI P-multicast tree differ. + + By contrast, the second alternative has none of these drawbacks and + satisfies the requirement in Section 5.1.3 of [RFC4834], which states + that "a multicast VPN solution SHOULD as much as possible ensure that + client multicast traffic packets are neither lost nor duplicated, + even when changes occur in the way a client multicast data stream is + carried over the provider network". The second alternative also + happens to be the one used in existing deployments. + + Consistent with this analysis, only the second alternative is + discussed in [RFC6513]. + + + + + +Morin, et al. Informational [Page 40] + +RFC 6517 Multicast VPN Mandatory Features February 2012 + + +Authors' Addresses + + Thomas Morin (editor) + France Telecom - Orange + 2 rue Pierre Marzin + Lannion 22307 + France + EMail: thomas.morin@orange.com + + Ben Niven-Jenkins (editor) + BT + 208 Callisto House, Adastral Park + Ipswich, Suffolk IP5 3RE + UK + EMail: ben@niven-jenkins.co.uk + + Yuji Kamite + NTT Communications Corporation + Granpark Tower + 3-4-1 Shibaura, Minato-ku + Tokyo 108-8118 + Japan + EMail: y.kamite@ntt.com + + Raymond Zhang + Alcatel-Lucent + 777 Middlefield Rd. + Mountain View, CA 94043 + USA + EMail: raymond.zhang@alcatel-lucent.com + + Nicolai Leymann + Deutsche Telekom + Winterfeldtstrasse 21-27 + 10781 Berlin + Germany + EMail: n.leymann@telekom.de + + Nabil Bitar + Verizon + 60 Sylvan Road + Waltham, MA 02451 + USA + EMail: nabil.n.bitar@verizon.com + + + + + + + +Morin, et al. Informational [Page 41] + |