Re: Multicast in BGP/MPLS IP VPNs

[Yiqun Cai <ycai at cisco.com>]

> 
> Using multicast tree within the service provider(s) is one option
> to carry VPN/VPLS customers' multicast traffic. But not the only
> one feasible. Ingress replication is another feasible option.

Yakov,

(Please forgive me if I'm stating the obvious)

I think the point here is the balance between states and efficiency
when delivering IP multicast packets to its intended receivers.

We all know that the best way to deliver IP multicast packets is to
build multicast distribution trees.  PIM is the protocol that IETF has
been standardizing to build such trees (inter- and intra- domain).
One key advantage of PIM is it utilizes the network of routers to do
the replication.  And different PIM variants (-SM, -SSM and bidir)
offer different balance between state and efficient delivery.

I personally believe these choices should all be provided so that a
service provider can decide which option to deploy depending on his
specific requirement.

> 
> > - encapsulation of customer data (either GRE or IP)
> > - one MDT per VPN versus one MDT per customer multicast domain per VPN
> 
> Why not one MDT per multiple VPNs ? After all, with unicast we
> do not require a dedicated PE-PE LSP per each VPN (or VPLS).

I don't think there is anything wrong with one MDT per multiple VPNs.
One can certainly build one if the traffic being carried in that MDT
spans multiple VPNs.

> 
> > e.g., maybe mVPN draft can be expanded to talk about PIM/IGMP snooping if 
> > needed.
> 
> May be before expanding mVPN draft to cover VPLS we should first
> fix few fairly fundamental problems of the mVPN draft, like the
> amount of state within the service provider with PIM-SSM, 

This comes back to the thread again.  (which reminds me one thing, I'm
still waiting to see the meeting minutes or Rahul's presentation so
that we can discuss more on the scalability issue which we didn't get
a chance to discuss at the IETF)

When all three PIM variants are available, a service provider can
certainly choose the one(s) that best suits the requirement.  If state
maintainence is a concern, PIM-bidir is the answer; if RP placement is
a concern, PIM-SSM is a good candidate.  

I don't consider this as a fundamental flaw, unless one sticks to only
one PIM variant, which will for sure lead to scaling issues one way or
the other.  Otherwise, we wouldn't not produce three PIM variants.

> the overhead of PIM state on PEs associated with VRF-VRF PIM peering,
> etc...
> 

I'm not sure which PIM states you are refering to.  The only PIM
states required in the peering is the identity and uptime of the PIM
neighbours.  And since PIM adjancency is fairly lightweight (compared
to that of link state protocols), I don't consider this as an issue in
practice.

Besides, there is also possibility that we can leverage MDT SAFI to do
the neighbour discovery and eliminate periodic PIM Hellos altogether.
We just need to expand the idea.  What do you think?

Thanks.


-- 
Yiqun