Re: Multicast in BGP/MPLS IP VPNs

[Yakov Rekhter <yakov at juniper.net>]

Ali,

> At 07:44 AM 8/17/2004 -0500, Serbest, Yetik wrote:
> >Ali,
> >
> >I think rosen-mVPN and VPLS have their places in the solution spectrum (....
> >Layer-2, Layer-3 ...). I am interested in why we can not use IGMP and/or PIM
> >snooping for VPLS to increase the bw and replication efficiency. Is it
> >because they result in state explosion? Is it because they degrade
> >performance? Do they make operations and maintenance troublesome?
> 
> If we look at different components needed in the provider network to 
> support customer IP multicast efficiently, we can list them as follow:
> 
> - auto-discovery for provider multicast tunnel (either PIM or BGP depending 
> on PIM mode)
> - signaling to setup provider multicast tunnel (PIM)

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.

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

> - forwarding table per VPN (MAC table v.s. routing table)
> - signaling OR snooping of customer's PIM/IGMP
> 
> It seems besides the last two items, the rest are in common between L2 and 
> L3 implementation. Furthermore, it seems the only major differentiation 
> between L2 and L3 is whether PE peers with customer's PIM/IGMP or whether 
> it snoops it. So there is lot of commonality for providing multicast 
> service in L2 and L3 domain and I was pointing out in my previous email, 
> instead of starting from scratch for VPLS, we can leverage the existing 
> mVPN and try to see how we can adopt it for VPLS with minimum changes - 

Or may be we can leverage the existing VPLS approach to multicast to see
how can we adopt it for 2547 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, the
overhead of PIM state on PEs associated with VRF-VRF PIM peering,
etc...

Yakov.