[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Multicast in BGP/MPLS IP VPNs

Yakov,


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

Yes it is, although it is inefficient in terms of packet replication and BW consumption over the MPLS/IP network. So, it would be good to get service providers input on this with respect to their applications.


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

Why not just have one MDT for the entire network and all the VPNs. As you know there is a trade off between # of states in the core versus # of the receiving endpoints and corresponding replications in the core.


> - 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 ?

Be my guest in doing that and while you are at it you may want to apply VPWS approach as well (to replicate at the very edge).


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

For VPLS, the issue is not as much what flavor of PIM to use but whether to use PIM at all (to build MDT) or whether replication at the edge is sufficient.

-Ali


Yakov.