Subject: mVPN and customer multicast routing information distribution

From: Thomas Morin <[email-masked]>
Date: Mon, 04 Dec 2006 16:17:51 +0100

Hi folks,

Stuff I recently heard and read make me feel the need to try clarify one
specific point about Multicast VPN and customer multicast routing
information distribution.  The idea seems to be widespread that PIM LAN
procedures involve "unidirectional" and "targeted" join/prune messages,
and that supporting the equivalent in BGP-based procedures for multicast
VPNs, would be hard and complex.

This is a _myth_ and let me try to explain why.

-----------------------------------------------------------------------
A. In proposed PIM LAN procedures for mVPN, Joins and Prunes are _not_
"unicast" nor "targeted"
-----------------------------------------------------------------------

    By default, PIM LAN procedures use join-suppression and prune
override mechanisms, which in the mVPN case requires all PEs
participating in an mVPN, to process every Join/Prune sent by another
PEs, even if they are not the upstream PE for the multicast
channel (checking if the VRF has membership for the mcast channel, and
eventually resetting a timer to do join-suppression, or sending a join
to override a prune made by another PE). This processing requires
checking the VRF MRIB.

    The alternative mode is the use of explicit tracking (optional in
the PIM specifications). In this mode PIM is closer to using only
"targeted" Join/Prune messages, but even in that mode, a router need to
process the PIM packet to determine if it is the intended upstream PE
for that Join (PIM protocols packets are sent in multicast to all PIM
routers present on an interface). In the mVPN context, PIM state
refreshes make explicit tracking quite processing heavy.

    --> A1: PIM LAN procedures require a PE for an mVPN to see and
process all Join/Prunes sent by all PEs in the mVPN
    --> A2: Only with explicit tracking could this processing be made
lighter  (but PIM being refreshes-based, PIM explicit tracking is not
considered as very scalable in the mVPN context)

----------------------------------------------------------------------
B - BGP-based procedures can provide incremental reduction of C-mcast
routes processing done by PEs
----------------------------------------------------------------------

    First, if BGP route reflectors are not used, a processing similar to
"explicit tracking" is done on the PE, using standard BGP behavior : BGP
receives multiple equivalent C-mcast routes for a same (VPN,S,G) tuple
(meaning "there is a receiver for S,G in this MVPN") and reduces this
information to knowing if there are or not receiver for the S,G across
the provider core in this mVPN.  BGP being hard state, the absence of
"refreshes" make this "explicit tracking" cheaper than in PIM (for which
explicit tracking would hardly be a viable option).
    
    --> A3: with proposed BGP-based procedures, a PE applies dumb/basic
BGP procedures to do the equivalent of "explicit tracking"
    --> A4: this equivalent of "explicit tracking" is cheaper in BGP
than in PIM
        
    Now, deployment of BGP/MPLS VPNs is mostly always done using Route
Reflectors, and what will happen is that the Route Reflectors (using the
usual BGP procedures) will only keep/select one S,G route for a said
VPN. Thus, a PE will only receive and process one such route. In other
words, the workload related to reducing multiple "joins" informations
into just knowing if there are or not receivers for a multicast channel
across the VPN, is done by route reflectors, without requiring them to
be aware of any multicast related semantics. 
       
    --> A5: when used, the BGP route reflectors (not the PEs) will carry
the "explicit tracking" workload
    --> A6: this doesn't require the RRs to have any multicast-related
awareness
    --> A7: this workload can be spread out nicely on multiple RRs (e.g.
using a RR clusters), without requiring any mVPN-specific mechanism
       
    With the above, a PE will still receive C-mcast routes for multicast
channels for which it is not the upstream (remember: this also the case
by default with PIM LAN procedures!). They will be easily discarded by
the BGP process, based only on the route target (no need to consult the
VRF multicast routing tables like PIM has to do).
          
    --> A8: BGP-based procedures allow a PE to easily discard C-mcast
routes not relevant for him
              
    Current proposals for BGP-based procedures include an optional
mechanism to further improve this: using the RT-constraint mechanism
[RFC4684], they basically allow PEs to tell the route reflectors how to
only send them C-mcast routes for which they are the upstream.
       
    --> A9: BGP-based procedures, by reusing the RT-constraint
mechanism, allow a PE to only see the relevant C-mcast routes, without
inducing specific load on the PEs, since all filtering is made on route
reflectors
    --> A10: this also is done without any multicast-specific
implementation on the route reflectors 

-------------
Conclusion...
-------------

With PIM LAN procedures the only choice is between the default mode
(with join-suppression and prune override mechanisms, requiring all PEs
in an mVPN to process all joins/prune sent by other PEs in the mVPN,
based on VRF MRIB information) and the optional alternative "explicit
tracking" mode (not much implemented, and which would impose a
significant workload on PEs at a high deployment scale).  Both of these
modes may impose a burden on the PE devices.

With BGP-based procedures [draft-ietf-l3vpn-2547bis-mcast-bgp], same
functionality is implemented using only generic BGP mechanisms (BGP
basic route handling behavior, route reflectors, RT-constraint), but
these mechanisms allow to control where the processing is made, and on
which devices the corresponding load is put. Ultimately, they allow to
free the PEs from most of the processing : using all proposed
mechanisms, without any multicast-specific mechanisms on
route-reflectors, the PEs will have minimal processing and will only
receive relevant BGP route updates/withdraws and for only one route per
MVPN,S,G tuple. In that case, all the load is put on route reflectors,
which can be dedicated to mVPN processing, and for which mechanisms
exists to spread/control the load.

So while the structural amount of information that need to be processed
is more or less the same, in typical deployments, BGP-based procedures
can be expected to in fact result in quite less processing on the PEs
than PIM LAN procedures. And contrary to PIM LAN procedures, using
already defined generic BGP mechanisms, the processing load can be
spread on route reflectors, and have very low impact on the PE devices.

... Now... this doesn't mean there aren't other differences/points of
comparison between the two approaches, but I hope the above can help
clarify ideas on at least this particular point.  

Thanks for reading,

-Thomas