Re: Multicast in BGP/MPLS IP VPNs

[Eric Rosen <erosen at cisco.com>]

(I'm trying  to cut down on  the l2vpn/l3vpn cross-posting,  because I think
that is leading to some confusion about the problem being discussed.)

Yakov> ... and all the current variants of PIM build shortest path trees, which
Yakov> are known to be less efficient wrt bandwidth usage than minimum cost
Yakov> trees. And, if efficient bandwidth use is an important issue, then
Yakov> why should we be limited to shortest path trees ?

I can't find  where anyone said we should be limited  to any particular kind
of tree.  The  mvpn spec allows for a number  of different tree construction
techniques, and that  really isn't meant to be an  exhaustive list.  From an
architectural perspective,  it is  straightfoward to incorporate  any future
improvements to multicast technology. 

Sure, some  folks have  been saying that  the mvpn  doc requires the  use of
PIM-SSM, but anyone who's looked at that doc knows that this isn't the case.

However, being that this is the L3VPN WG and not one of the multicast WGs, I
think it's understandable for us to  focus most of our attention on on those
tree construction procedures which have already been invented. 

Having  said  that,  I'm  not  at  all sure  that  minimum  cost  trees  are
worthwhile.   A  shortest  path  tree  which contains  the  source  and  the
receivers already ensures  that no packet will travel more  than once on any
given link.   A least cost tree  ensures further that the  packet travels on
the smallest  possible number of links needed  to get it from  the source to
all its destinations.  The importance of this additional bit of optimization
is not nearly  as clear.  The purpose of  using multicast distribution trees
is not  to MINIMIZE  the bandwidth used,  but to  ensure that the  amount of
traffic  the  core  needs to  carry  is  not  multiplied  by the  number  of
receivers. 

Sure, I understand  the trade-offs re state and  operational complexity.  My
opinion is that when  you have a variety of scaling factors,  it is best not
to make a fetish out of any single factor.

Yakov> May be before expanding mVPN draft to cover VPLS we should first
Yakov> fix few fairly fundamental problems of the mVPN draft, like the
Yakov> amount of state within the service provider with PIM-SSM, the
Yakov> overhead of PIM state on PEs associated with VRF-VRF PIM peering,
Yakov> etc...

I find that the rhetorical effect of  "etc." is enhanced if you double it to
"etc., etc."  You should try it ;-)

I do have a couple of comments on these "fundamental problems". 

- I would agree that in the  long term the VRF-VRF PIM peering is a problem,
  but  I  do  think it's  one  we  could  work  on,  e.g., Yiqun's  idea  of
  eliminating the Hello's in favor of BGP-advertised MDT SAFIs. 

- The "amount of state within the SP with PIM-SSM" is a bit overdone: 

  * Nowhere is the use of PIM-SSM required

  * PIM-Bidir is recommended (though  not required) for intra-SP VPNs, which
    seem to be more the rule than the exception

  * It  is  true  that  if  we  have thousands  of  PEs  with  thousands  of
    inter-provider multicast-enabled VPNs each, then we are going to have a
    problem unless  we follow your  suggestion of aggregating  multiple VPNs
    onto a single  multicast distribution tree.  (It might  not be that good
    an idea to call a problem "fundamental" after you've already suggested a
    solution to it -:)) However, we're  okay if there are merely hundreds or
    PEs with  hundreds of  multicast-enabled inter-provider VPNs  each.  And
    the alternative of using inter-provider PIM-SM shared trees falls on its
    face  way before  that  point,  for reasons  I've  outlined in  previous
    messages and in San Diego.