Network Working Group                                      T. Morin, Ed.
Internet-Draft                                        France Telecom R&D
Intended status: Informational                     B. Niven-Jenkins, Ed.
Expires: August 28, 2008                                              BT
                                                               Y. Kamite
                                                      NTT Communications
                                                                R. Zhang
                                                                      BT
                                                              N. Leymann
                                                        Deutsche Telekom
                                                       February 25, 2008


    Considerations about Multicast for BGP/MPLS VPN Standardization
                draft-morin-l3vpn-mvpn-considerations-02

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 28, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   The current proposal for multicast in BGP/MPLS includes multiple



Morin, et al.            Expires August 28, 2008                [Page 1]


Internet-Draft        Multicast VPN Considerations         February 2008


   alternative mechanisms for some of the required building blocks of
   the solution.  The aim of this document is to leverage previously
   documented requirements to identify the key elements and help move
   forward solution design, toward the definition of a standard having a
   well defined set of mandatory procedures.  The different proposed
   alternative mechanisms are examined in the light of requirements
   identified for multicast in L3VPNs, and suggestions are made about
   which of these mechanisms standardization should favor.  Issues
   related to existing deployments of early implementations are also
   addressed.

Requirements Language

   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].



































Morin, et al.            Expires August 28, 2008                [Page 2]


Internet-Draft        Multicast VPN Considerations         February 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Examining alternatives mechanisms for MVPN functions . . . . .  4
     3.1.  MVPN auto-discovery  . . . . . . . . . . . . . . . . . . .  4
     3.2.  S-PMSI Signaling . . . . . . . . . . . . . . . . . . . . .  6
     3.3.  PE-PE Transmission of C-Multicast Routing  . . . . . . . .  8
       3.3.1.  PE-PE signalling scalability . . . . . . . . . . . . .  8
       3.3.2.  P-routers scalability  . . . . . . . . . . . . . . . . 10
       3.3.3.  Impact of C-multicast routing on Inter-AS
               deployments  . . . . . . . . . . . . . . . . . . . . . 10
       3.3.4.  Security and robustness  . . . . . . . . . . . . . . . 11
       3.3.5.  C-multicast VPN join latency . . . . . . . . . . . . . 12
       3.3.6.  Architectural considerations . . . . . . . . . . . . . 13
       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
   4.  Co-located RPs . . . . . . . . . . . . . . . . . . . . . . . . 18
   5.  Existing deployments . . . . . . . . . . . . . . . . . . . . . 19
   6.  Summary of recommendations . . . . . . . . . . . . . . . . . . 20
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
   10. Informative References . . . . . . . . . . . . . . . . . . . . 21
   Appendix A.  Handling the PIM routing processing load load . . . . 22
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
   Intellectual Property and Copyright Statements . . . . . . . . . . 25























Morin, et al.            Expires August 28, 2008                [Page 3]


Internet-Draft        Multicast VPN Considerations         February 2008


1.  Introduction

   The current proposal for multicast in BGP/MPLS
   [I-D.ietf-l3vpn-2547bis-mcast] includes multiple alternative
   mechanisms for some of the required building blocks of the solution.
   However, it does not identify the core set of mechanisms which must
   be implemented in order to ensure interoperability.  This may lead to
   a situation where implementations may support different subsets of
   the available optional mechanisms leading to implementations that do
   not interoperate.

   The aim of this document is to leverage the already expressed
   requirements [RFC4834] to identify the mechanisms that the authors
   believe are good candidates for being part of a core set of mandatory
   mechanisms which can be used to provide a base for interoperable
   solutions.

   This document will go through the different building blocks of the
   solution and provide the authors' recommendations as to which
   mechanisms the authors' favor for each building block, while
   considering the requirements already defined and the goal of a fully-
   interoperable standard.

   Considering the history of the multicast VPN proposals and
   implementations, the authors also consider it useful to discuss how
   existing deployments of early implementations
   [I-D.rosen-vpn-mcast][I-D.raggarwa-l3vpn-2547-mvpn] can fit in the
   picture, and provide suggestions in this respect.


2.  Terminology

   Please refer to [I-D.ietf-l3vpn-2547bis-mcast] and [RFC4834].


3.  Examining alternatives mechanisms for MVPN functions

3.1.  MVPN auto-discovery

   Section 5.2.10 of [RFC4834] states "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 current solution document [I-D.ietf-l3vpn-2547bis-mcast]
   addresses this requirement by proposing two different mechanisms for



Morin, et al.            Expires August 28, 2008                [Page 4]


Internet-Draft        Multicast VPN Considerations         February 2008


   MVPN auto-discovery:

   1.  BGP-based auto-discovery (described in section 4).

   2.  Discovery using PIM running on a MI-PMSI implemented with a
       shared tree using multicast ASM, or MP2MP LDP with the same
       common tree identifier configured in all VRFs of an MVPN.

   It is the recommendation of the authors that BGP-based auto-discovery
   is the preferred solution for auto-discovery and should be supported
   by all implementations while PIM/shared-tree based auto-discovery
   should be optionally considered for migration purpose only.

   Part of the rationale for this recommendation is also based on
   section 5.2.10 of [RFC4834] which states "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".

   BGP is the auto-discovery protocol used in unicast (RFC4364) VPNs and
   therefore the use of BGP-based auto-discovery within multicast VPNs
   avoids the introduction of an additional auto-discovery protocol that
   would require additional OAM processes and tools.  Service providers
   with deployed unicast (RFC4364) VPNs already have extensive
   deployment and operations experience of using BGP as an auto-
   discovery protocol including OAM processes and tools.  Such processes
   and tools will require modifications in order to support multicast
   auto-discovery but those modifications are anticipated to be less
   than those required to develop new processes and tools for a specific
   auto-discovery protocol.  Additionally, BGP supports MD5
   authentication of its peers for additional security.  In contrast,
   there are no obvious authentication mechanisms to secure PIM
   communications in any known implementation.

   Furthermore, PIM based discovery is only applicable to deployments
   using a shared tree on an MI-PMSI, whereas BGP-based auto-discovery
   does not place any restrictions on the type of multicast trees that
   can be used.  BGP-based auto-discovery is independent of the type of
   P-multicast tree 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 trees for the default
   MDTs within their current deployments, therefore relying already on
   BGP-based auto-discovery.




Morin, et al.            Expires August 28, 2008                [Page 5]


Internet-Draft        Multicast VPN Considerations         February 2008


   When shared trees are used, the use of BGP auto-discovery would allow
   inconsistencies in the addresses/identifiers used for the shared
   trees to be detected (e.g. the same shared tree 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 ASs.  Note that this
   technique to detect some misconfiguration may not be usable during a
   transition period from a shared-tree autodiscovery to a BGP-based
   autodiscovery.

   Last, the use of the BGP-based autodiscovery is expected to be less
   prone to spoofing attacks (being based on a connection established
   with a three-way handshake), to which the PIM Hello over MI-PMSI
   procedures may be subject to (being datagram-based).

   ( the authors note that, in order to support the coexistence of both
   protocols (for example during migration scenarios), implementations
   could support both alternatives by providing a per-VRF configuration
   knob that would allow recognizing new PIM neighbors based on the
   reception of PIM hellos on a shared P-multicast tree, even for
   neighbors that did not advertise a BGP auto-discovery route )

3.2.  S-PMSI Signaling

   The current solution document [I-D.ietf-l3vpn-2547bis-mcast] proposes
   two mechanisms for S-PMSI Signaling:

   1.  A new UDP-based TLV protocol specifically for S-PMSI signaling
       (described in section 7.2.1).

   2.  A BGP-based mechanism for S-PMSI signaling (described in section
       7.2.2).

   It is the recommendation of the authors that BGP is the preferred
   solution for S-PMSI signaling and should be supported by all
   implementations while the UDP-based S-PMSI signaling protocol should
   be considered optional.

   Part of the rationale for this recommendation is similar to that for
   BGP-based auto-discovery and is based on section 5.2.10 of [RFC4834]
   and the desire to avoid introducing and deploying additional
   protocols unless strictly necessary.

   Furthermore:

   o  The BGP-based S-PMSI signaling mechanism can be used within MVPNs
      using either a UI-PMSI or a MI-PMSI while the UDP-based protocol



Morin, et al.            Expires August 28, 2008                [Page 6]


Internet-Draft        Multicast VPN Considerations         February 2008


      is restricted to use within MVPNs using an MI-PMSI.

   o  The BGP-based S-PMSI signaling mechanism can be efficiently used
      in an inter-AS option B deployment context while the use of the
      UDP-based protocol does not preserve AS routing independence when
      used in an inter-AS option B context (i.e. the decision by a PE in
      an AS to use an S-PMSI for a given customer flow will impact
      routing state in other ASes).  Co-existence with unicast inter-AS
      VPN options is strongly encouraged by section 5.2.6 of [RFC4834].

   o  The BGP-based S-PMSI signaling supports all the functionality and
      all the operational contexts that are supported by UDP-based
      protocol (and more).

   o  BGP supports MD5 authentication of its peers for additional
      security.  In contrast, there are no obvious authentication
      mechanisms to secure PIM communications in any known
      implementation.

   Therefore, it is the opinion of the authors that BGP is the preferred
   solution for performing S-PMSI signaling.

   However, the authors recognize that the UDP-based protocol has been
   in deployment for some time and would recommend that implementations
   supporting both protocols optionally provide a per-VRF configuration
   knob to allow an implementation to use the UDP-based TLV protocol for
   S-PMSI signaling for specific VRFs in order to support the
   coexistence 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-multicast trees.

   Section 7.2.2.3 of [I-D.ietf-l3vpn-2547bis-mcast] proposes two
   approaches 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.




Morin, et al.            Expires August 28, 2008                [Page 7]


Internet-Draft        Multicast VPN Considerations         February 2008


   The first alternative has 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
   satisfy 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 happen to be the one used in existing deployments.

   For these reasons, it is the authors' recommendation to mandate the
   implementation of the second alternative for switching to S-PMSI.

3.3.  PE-PE Transmission of C-Multicast Routing

   The current solution document [I-D.ietf-l3vpn-2547bis-mcast] proposes
   multiple mechanisms for PE-PE transmission of customer multicast
   routing information:

   1.  Full per-MVPN PIM peering across an MI-PMSI (described in section
       5.2.1).

   2.  Lightweight PIM peering across an MI-PMSI (described in section
       5.2.2)

   3.  The unicasting of PIM C-Join/Prune messages (described in section
       5.2.3)

   4.  The use of BGP for carrying C-Multicast routing (described in
       section 5.3).

3.3.1.  PE-PE signalling 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



Morin, et al.            Expires August 28, 2008                [Page 8]


Internet-Draft        Multicast VPN Considerations         February 2008


   having multicast service enabled".

   At such 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 PIM Hellos with each other) and to refresh
   C-Join/Prune states, thus limiting the scalability of these
   approaches.

   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, and would
   require refresh-reduction mechanisms to be used to mitigate the fact
   that PIM "Join suppression" cannot be used (what such a refresh-
   reduction mechanism would be has not been described yet).  For these
   reasons, it seems that this approach is not suitable for higher scale
   scenarios.

   The second mechanism would operate in a similar manner to full per-
   MVPN PIM peering except that PIM hellos are not transmitted and PIM
   C-Join/Prune refresh-reduction would be used, thereby improving
   scalability, but this approach has been further developed and it is
   unclear if it is applicable.

   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 one Join message for each remote PE joined
   to a multicast stream, but this improvement comes at the price of
   requiring all PEs of a multicast VPN to process all PIM Joins sent by
   any 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 the C-multicast routing approach leverages the
   Route-Target constraint mechanisms, which specifically allows only
   the interested upstream PE to receive a BGP C-multicast route.  When
   RT constraints are used the fourth mechanism reduces the processing
   load put on the provider infrastructure for customer multicast
   routing to the minimum (by avoiding any processing by "unrelated"
   PEs, that are nor the joining PE nor the upstream PE), and inherits
   BGP features that are expected to improve scalability (through, for
   instance, providing a means to offload some of the processing burden
   associated with client multicast routing onto BGP route-reflectors),
   and being based on TCP has no refresh-related scalability limit.
   (Please refer to Handling the PIM routing processing load load, for a



Morin, et al.            Expires August 28, 2008                [Page 9]


Internet-Draft        Multicast VPN Considerations         February 2008


   detailed explanation of the differences in ways of handling the
   C-multicast routing load, between the PIM-based approaches and the
   BGP-based approach)

   However, it is to be noted that offloading customer multicast routing
   processing onto BGP route-reflectors will increase the processing
   load placed on the route-reflector infrastructure, which, in the
   higher scale scenarios, is expected to call for adaptations such as:

   o  a separation of resources for unicast and multicast VPN routing :
      using mvpn-dedicated BGP sessions and/or mvpn-dedicated BGP
      instances on route-reflectors, and/or mvpn-dedicated route-
      reflectors ;

   o  the deployment of additional route-reflectors resources :
      increased processing resources on existing route reflectors or
      additional route-reflectors.

3.3.2.  P-routers scalability

   Mechanisms (1) and (2) are restricted to use within multicast VPNs
   that use an MI-PMSI, thereby necessitating:

      the use of a P-multicast tree technique that allows shared trees
      (for example PIM-SM in ASM mode or MP2MP LDP)

   or   the use of one P-multicast tree 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 trees are used only necessitates the use
   of one tree per VPN per PE attached to a site with a multicast source
   or RP (or with a candidate BSR, if BSR is used), thereby improving
   the amount of state maintained by P-routers compared to the amount
   required to build an MI-PMSI with P2MP trees.

3.3.3.  Impact of C-multicast routing on Inter-AS deployments

   Furthermore, 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, 5.2.8
   and 5.2.12 of [RFC4834].

   The first three mechanisms impose direct PE to PE communications :
   this does not apply well to an inter-AS option B context, because of
   security and robustness issues that are involved by such a level of
   reachability and interaction between PEs in different ASes.



Morin, et al.            Expires August 28, 2008               [Page 10]


Internet-Draft        Multicast VPN Considerations         February 2008


   Their use in an inter-AS context is possible, but not without
   limitations or additional engineering design trade-offs depending
   upon the interconnect types.

   By comparison, the fourth option (the use of BGP for carrying
   C-Multicast routing) does not have any of the above limitations
   related to inter-AS deployments, and also provides an additional
   alternative to facilitate such deployments through the possibility of
   using segmented inter-AS trees.

3.3.4.  Security and robustness

   BGP supports MD5 authentication of its peers for additional security,
   thereby possibly benefit directly to 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 been yet fully described yet
   [I-D.ietf-pim-sm-linklocal][], 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, unicast and multicast VPN routing are expected to only
   compete in the PE, for routing plane processing resources.  In the
   case of the BGP-based approach, they will compete on the PE for
   processing resources, and in the route-reflector if they are used.
   It is identified that in both cases, mechanisms will be required to
   arbitrate resources (e.g. processing priorities).  In the case of
   PIM-based procedures, between the different control plane routing
   instances in the PE.  And in the case of the BGP-based approach, this
   is likely to require using distinct BGP sessions for multicast and
   unicast, possibly toward distinct route-reflectors.

   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.  Such a load would be comparable to the higher
   scale scenarios described in xx (Section 3.3.1) and the fourth (BGP-
   based) approach - when deployed to handle a significant multicast VPN
   routing load - is expected to be the most efficient approach in a
   such case.  On the other hand, while the BGP-based approach is likely
   to suffer a slowdown under a load raising beyond processing resources
   (because of possibly congested TCP sockets), the PIM-based approaches



Morin, et al.            Expires August 28, 2008               [Page 11]


Internet-Draft        Multicast VPN Considerations         February 2008


   would react to such a load by dropping messages, with later failure
   recovery through message refreshes, this being at the expense of some
   predictability.

   In fact both situations are 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 to (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 approach 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 hasn't been yet
   described for the PIM-based approach, though these type of approaches
   rely on a per VPN dataplane to carry the mvpn control plane, and thus
   might naturally benefit from this first level of separation to solve
   (b).

3.3.5.  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
   the first packet of the corresponding multicast stream being received
   by the CE.

   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 the PE of a new receiver and the PE of the
      multicast source, and being datagram based introduce minimal
      delay, thereby possibly having a best-case join latency as good as
      possible depending on implementation efficiency

   o  the BGP-based approach uses TCP exchanges, that may introduce an
      additional delay depending on BGP implementation performances, but
      are expected to control the worst-case join latency under load

   o  the BGP-based approaches is designed to allow the introduction of
      route-reflectors which will introduce an additional processing
      delay between the receiver-PE and the source-PE

   o  in higher scale scenarios, the BGP-based approach is expected to
      provide some control of the worst-case join latency whereas the



Morin, et al.            Expires August 28, 2008               [Page 12]


Internet-Draft        Multicast VPN Considerations         February 2008


      PIM-based approaches may behave less efficiently if PIM messages
      are lost

   o  in higher scale scenarios, the introduction of route-reflectors in
      the BGP architecture are expected to provide processing efficiency
      which is expected to improve latency compared to the PIM-based
      approaches

   This qualitative comparison of approaches tend to highlight that the
   BGP based approach is designed for controlling the "worst-case" join
   latency whereas for 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 is not
   possible without referring to specific implementations and
   benchmarking procedures, and would possibly expose different
   conclusions, especially for best-case group join latency for which
   performance is expected vary with 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.

   Last, 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.

3.3.6.  Architectural considerations

   The fourth mechanism (the use of BGP for carrying C-Multicast
   routing) would appear to fit well with the current unicast
   architecture as BGP is the customer routing distribution protocol
   used in unicast VPNs and therefore using BGP for customer routing
   distribution within multicast VPNs avoids the introduction of an
   additional protocol that would require additional OAM processes and
   tools.  Service provider's with deployed unicast (RFC4364) VPNs
   already have extensive deployment and operations experience of using
   BGP as a customer routing distribution protocol including OAM
   processes and tools.  Such processes and tools will require
   modification in order to support customer multicast routing but those
   modifications are anticipated to be less than those required to
   develop new processes and tools for a distinct customer routing
   protocol.

   It should be noted that because PIM will be used as the CE-PE
   customer routing distribution protocol, service providers will still
   need OAM processes and tools in order to manage the PIM protocol, so
   this rationale only applies to a subset of the tools and processes



Morin, et al.            Expires August 28, 2008               [Page 13]


Internet-Draft        Multicast VPN Considerations         February 2008


   already in place.

   An illustrative example of the benefit brought by consistency with
   unicast design is how the "extranet" feature can be implemented :
   when BGP-based mechanisms are used, the already defined and well
   understood BGP route target import/export semantics are just reused
   and applied to BGP mVPN routes.  By contrast, it is not specified how
   implementing the same feature would be done in the context of other
   alternative mechanisms, and unclear if this is possible without
   significant engineering trade-offs given that their control plane is
   tied to a specific MI-PMSI tunnel.  Note that the support for the
   Extranet feature is stated as a MUST in sections 5.1.6 of [RFC4834].

   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".  Considering that the recommendation of the authors
   would be BGP for auto-discovery and S-PMSI signaling, the choice of
   BGP for customer multicast routing would be consistent with the
   protocol choice for unicast VPNs and would adequately address this
   requirement.

3.3.7.  Conclusion on C-multicast routing

   The fourth approach (BGP-based) for customer multicast routing
   clearly presents some advantages over the PIM-based alternatives.
   However it has yet to be deployed within an operational MVPN, and
   only limited experience exists with its implementations.  By
   contrast, PIM-based mechanisms lack many of these benefits and have
   identified limitations in how they can handle customer multicast
   routing load in higher-scale scenarios.  Despite these, experience
   showed that the "Full PIM peering" approach is operationally viable.

   Consequently, at the present time and until there is experience with
   all of the proposed mechanisms it is not clear which of the above
   mechanisms should be recommended as the preferred solution to
   implementers.  However, it would appear prudent for implementations
   to consider supporting both the fourth (BGP-based) and first (full
   per-MPVN PIM peering) mechanisms.  Further experience on both
   implementations is likely to be required before some best practice
   can be defined.

   The first mechanism (full per-MVPN PIM peering across an MI-PMSI) is
   the mechanism used by [I-D.rosen-vpn-mcast] and therefore it is
   deployed and operating in MVPNs today.  The authors recognize that
   because full per-MVPN PIM peering has been in deployment for some



Morin, et al.            Expires August 28, 2008               [Page 14]


Internet-Draft        Multicast VPN Considerations         February 2008


   time, the support for this mechanism may be helpful for backwards
   compatibility and in order to facilitate migration towards the BGP-
   based approach.

   Moreover to improve the clarity of the proposed specifications,
   considering that neither hello suppression nor refresh-reduction
   procedures are currently specified or documented and that it is not
   clear what the impact to the PIM state machine of these additional
   procedures may be, the authors recommend that the proposals for
   lightweight PIM peering across an MI-PMSI (the second mechanism) and
   for the unicasting of PIM C-Join/Prune messages (the third mechanism)
   be removed from the current solution document
   [I-D.ietf-l3vpn-2547bis-mcast] (at least until they have been further
   specified and both their impact and benefit on a multicast VPN
   deployment is spelled out).

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 L3 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.  It is recommended that
   implementations support the three corresponding multicast tree
   encapsulations techniques, namely: mLDP, P2MP RSVP-TE and GRE/
   IP-multicast in order to allow the same encapsulations to be used for
   unicast and multicast traffic as well as facilitating migration from
   [I-D.rosen-vpn-mcast] to an MPLS label based encapsulation.



Morin, et al.            Expires August 28, 2008               [Page 15]


Internet-Draft        Multicast VPN Considerations         February 2008


   All three of the above encapsulation techniques support the building
   of P2MP multicast trees.  In addition mLDP and GRE/IP-ASM-Multicast
   implementations may also support the building of MP2MP multicast
   trees.  The use of MP2MP trees may provide some scaling benefits to
   the service provider as only a single MP2MP tree need be deployed per
   VPN, thus reducing the amount of multicast state that needs to be
   maintained by P routers.  This gain in state is at the expect 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 tree will require configuring the
   same tree identifier or multicast ASM group address in all PEs, and
   will not provide the kind of autoconfiguration possible with P2MP
   trees.

   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 dataplane 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 S-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:





Morin, et al.            Expires August 28, 2008               [Page 16]


Internet-Draft        Multicast VPN Considerations         February 2008


   1.  A service provider may have a large network that they have
       segmented into a number of ASs.

   2.  A service provider's multicast VPN may consist of a number of ASs
       due to acquisitions and mergers with other service providers.

   3.  A service provider may wish to interconnect their multicast VPN
       platform with that of another service provider.

   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 history and the service provider may
   not have (or may be unwilling to) unified 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 ASs 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 "A solution MUST support inter-AS
   multicast VPNs, and SHOULD support inter-provider multicast VPNs.
   Considerations about coexistence 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 [I-D.ietf-l3vpn-2547bis-mcast] addresses these
   requirements by proposing two approaches for mVPN inter-AS
   deployments:

   1.  Segmented inter-AS tunnels where each AS constructs its own
       separate multicast tunnels which are then 'stitched' together by
       the ASBRs (described in section 8.2).

   2.  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 ASs the ASBRs play no special role
       and function merely as P routers (described in section 8.1).




Morin, et al.            Expires August 28, 2008               [Page 17]


Internet-Draft        Multicast VPN Considerations         February 2008


   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)".  Segmented inter-AS
   tunnels is the only solution that is capable of meeting this
   requirement.

   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 and [I-D.rosen-vpn-mcast] only supports the non-
   segmented inter-AS solution and therefore the non-segmented inter-AS
   solution is likely to be required by some operators for backward
   compatibility and during migration from [I-D.rosen-vpn-mcast] to
   [I-D.ietf-l3vpn-2547bis-mcast].

   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, due to
   the additional deployment flexibility offered by segmented inter-AS
   tunnels, it is the recommendation of 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 co-existence with existing deployments, and as a feature
   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.

   Additionally, the authors note that the proposed BGP-based approaches
   for S-PMSI signaling and C-multicast routing information distribution
   provide a good fit with both segmented and non-segmented inter-AS
   tunnels.  In contrast the UDP-TLV based approach for S-PMSI signaling
   appears to be incompatible with segmented inter-AS tunnels, and it is
   unclear if the proposed PIM-based approaches for C-multicast routing
   information distribution would be fully applicable to segmented
   inter-AS tunnels.


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."



Morin, et al.            Expires August 28, 2008               [Page 18]


Internet-Draft        Multicast VPN Considerations         February 2008


   Co-locating a customer's RP on a PE can provide some benefits to the
   customer as outlined in section 5.1.10.3 of [RFC4834] which states
   "In the case of PIM-SM, when a source starts to emit traffic toward a
   group (in ASM mode), if sources and receivers are located in VPN
   sites that are different than that of the RP, then traffic may
   transiently flow twice through the SP network and the CE-PE link of
   the RP (from source to RP, and then from RP to receivers).  This
   traffic peak, even short, may not be convenient depending on the
   traffic and link bandwidth.

   However, customers who have already deployed multicast within their
   networks and have therefore already deployed their own internal RPs
   are often reluctant to hand over the control of their RPs to their
   service provider and make use of a co-located RP model.

   Also, providing collocating the RP on PE will require the activation
   of MSDP or the processing of PIM Registers on the PE.  Securing the
   PE routers for such activity requires special care, 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 of the authors
   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 VRF MSDP
   instance is not required on any PE router and where all the RPs are
   deployed within the customers' networks or CEs.


5.  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).



Morin, et al.            Expires August 28, 2008               [Page 19]


Internet-Draft        Multicast VPN Considerations         February 2008


   Mechanisms allowing "live" migration by providing concurrent use of
   multiple alternatives for a given PE and a given VPN, is not seen as
   a priority considering the expected implementation complexity
   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.


6.  Summary of recommendations

   The following list summarizes the authors' recommendations.  These
   recommendations are not intended to prevent the implementation of
   alternative solutions, rather they are the authors' recommendations
   for the mechanisms that should be made mandatory in
   [I-D.ietf-l3vpn-2547bis-mcast] and therefore be supported by all
   implementations.

   It is the authors' recommendation:

   o  that BGP-based auto-discovery be the mandated solution for auto-
      discovery ;

   o  that BGP be the mandated solution for S-PMSI signaling ;

   o  that the mandated solution for S-PMSI switch-over be the mechanism
      based on the source-connected PE switching traffic from the I-PMSI
      tunnel to the S-PMSI tunnel, without transmitting traffic on both
      at the time ;

   o  that implementations support both the BGP-based and the full per-
      MPVN PIM peering solutions for PE-PE transmission of customer
      multicast routing until further operational experience is gained
      with both solutions ;

   o  that implementations support the following multicast tree
      encapsulations: 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 backwards compatibility and for migration) ;

   o  implementations MUST support deployments when 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.







Morin, et al.            Expires August 28, 2008               [Page 20]


Internet-Draft        Multicast VPN Considerations         February 2008


7.  IANA Considerations

   This document makes no request to IANA.

   [ Note to RFC Editor: this section may be removed on publication as
   an RFC. ]


8.  Security Considerations

   This document does not by itself raise any particular security
   considerations.


9.  Acknowledgements

   We would like to thank Adrian Farrel, Eric Rosen, Yakov Rekhter, and
   Maria Napierala for their feedback that helped shape this document.


10.  Informative References

   [RFC4834]  Morin, T., "Requirements for Multicast in L3 Provider-
              Provisioned Virtual Private Networks (PPVPNs)", RFC 4834,
              April 2007.

   [I-D.ietf-l3vpn-2547bis-mcast]
              Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP
              VPNs", draft-ietf-l3vpn-2547bis-mcast-06 (work in
              progress), October 2006.

   [I-D.rosen-vpn-mcast]
              Rosen, E., "Multicast in MPLS/BGP VPNs",
              draft-rosen-vpn-mcast-08 (work in progress),
              December 2004.

   [I-D.raggarwa-l3vpn-2547-mvpn]
              Aggarwal, R., "Base Specification for Multicast in BGP/
              MPLS VPNs", draft-raggarwa-l3vpn-2547-mvpn-00 (work in
              progress), June 2004.

   [I-D.ietf-pim-sm-linklocal]
              Atwood, J., "Authentication and Confidentiality in PIM-SM
              Link-local Messages", draft-ietf-pim-sm-linklocal-02 (work
              in progress), November 2007.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.



Morin, et al.            Expires August 28, 2008               [Page 21]


Internet-Draft        Multicast VPN Considerations         February 2008


Appendix A.  Handling the PIM routing processing load 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 the multicast VPN context, this has to be made for
   each VPN, 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 of stop forwarding the
   traffic of a said multicast stream toward the remote PEs, on some
   S-PMSI tunnel.

   When some "join" message is received by a PE, this PE knows that it
   should be sending traffic for the corresponding multicast group of
   the corresponding VPN.  But 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 they 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 so that a PE can determine 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 Prunes
      itself from a multicast tree, all other PEs check their own state
      to known if they are on the tree, in which case they send a PIM
      Join message to override the Prune.  The "did the last receiver
      leave?" question is thus implicitly replied to by all PE routers,
      for each PIM Prune message.

   PIM LAN Procedures, with explicit tracking :
      PIM LAN procedures can use an "explicit tracking" approach, where
      a PE which is the upstream router for a multicast stream maintains
      an updated list of all neighbors who are joined to the tree.
      Thus, when it receives a Leave message from a PIM neighbor, it
      instantly knows the answer to the "did the last receiver leave?"
      question.
      In this case, the question is replied to by the upstream router
      alone.  The side effect of this "explicit tracking" is that "Join
      suppression" is not used : the downstream PEs will always send
      Joins toward the upstream PE, which will have to process them all.

   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 like in the PIM "explicit tracking" approach.
      But, when a BGP route-reflector is used (which is expected to be



Morin, et al.            Expires August 28, 2008               [Page 22]


Internet-Draft        Multicast VPN Considerations         February 2008


      the recommended approach), the role of maintaining an updated list
      of the PE part of a said multicast tree is taken care of by the
      route-reflector(s).  Using plain BGP route selection procedures,
      the route-reflector will withdraw a C-multicast Source Tree Join
      for a said (C-S,C-G) when there is no PE advertising one anymore.
      In this context, the "did the last receiver leave?" question can
      be said to be answered by the route-reflector alone.
      Furthermore, the BGP route distribution can leverage more than one
      route-reflector : if a hierarchy of Route Reflectors is used, the
      "did the last receiver leave?" question is partly answered by each
      route-reflector in the hierarchy.

   We can see that answering the "last receiver leaves" questions is a
   significant proportion of the work that the C-multicast routing
   building block has to make, and that there are many ways that the
   related load can be spread among the different functions.


Authors' Addresses

   Thomas Morin (editor)
   France Telecom R&D
   2 rue Pierre Marzin
   Lannion  22307
   France

   Email: thomas.morin@orange-ftgroup.com


   Ben Niven-Jenkins (editor)
   BT
   208 Callisto House, Adastral Park
   Ipswich, Suffolk  IP5 3RE
   UK

   Email: benjamin.niven-jenkins@bt.com


   Yuji Kamite
   NTT Communications Corporation
   Tokyo Opera City Tower
   3-20-2 Nishi Shinjuku, Shinjuku-ku
   Tokyo  163-1421
   Japan

   Email: y.kamite@ntt.com





Morin, et al.            Expires August 28, 2008               [Page 23]


Internet-Draft        Multicast VPN Considerations         February 2008


   Raymond Zhang
   BT
   2160 E. Grand Ave.
   El Segundo  CA 90025
   USA

   Email: raymond.zhang@bt.com


   Nicolai Leymann
   Deutsche Telekom
   Goslarer Ufer 35
   10589 Berlin
   Germany

   Email: nicolai.leymann@t-systems.com



































Morin, et al.            Expires August 28, 2008               [Page 24]


Internet-Draft        Multicast VPN Considerations         February 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Morin, et al.            Expires August 28, 2008               [Page 25]