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

RE: Multicast in BGP/MPLS IP VPNs

Yetik,

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)
- encapsulation of customer data (either GRE or IP)
- one MDT per VPN versus one MDT per customer multicast domain per VPN

- 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 - e.g., maybe mVPN draft can be expanded to talk about PIM/IGMP snooping if needed.

-Ali


If IGMP and/or PIM snooping is a viable solution, I see well-known benefits
of layer-2 solution: no PIM adjacency with the customer, P routers are still
dumb etc...

Thanks,
yetik

-----Original Message-----
From: Ali Sajassi [mailto:sajassi at cisco.com]
Sent: Monday, August 16, 2004 4:36 PM
To: Yakov Rekhter; Ali Sajassi
Cc: Serbest, Yetik; Yakov Rekhter; erosen at cisco.com; l3vpn at ietf.org;
l2vpn at ietf.org
Subject: Re: Multicast in BGP/MPLS IP VPNs

At 02:00 PM 8/16/2004 -0700, Yakov Rekhter wrote:
>Ali,
>
> > >I think we should optimize VPLS for support of IP multicast. For
instance,
> > >what am I going to do for the regional networks where I don't sell
> 2547? Do
> > >I have to backhaul everybody to National backbone to provide multicast
> > >support?
> >
> >
> > I was implying in my previous message that the multicast service can be
> > considered as an independent service and it doesn't need to be tied up
to
> > other services such as VPLS or L3VPN (unicast). So a customer can order
it
> > in conjunction with its VPLS or L3VPN service or separately. Now if the
> > question is: what the best way is to implement it, then that depends on
> the
> > requirements and if the requirements is for IP multicast applications
with
> > optimum routing & replication through the core, then the rosen-vpn-mcast
> > discusses several options and pros/cons for these different options
which
> > addresses adjacency between CEs & PEs (c-address/group) as well as among
> > PEs (p-address/group). And a VPLS capable PE (or at least an n-PE) that
> > needs to support multicast service in conjunction with VPLS, can do it
> > using vpn-mcast (and that doesn't mean it has to provide l3vpn-unicast
> > service to the customer).
> >
> > However, if there are different set of requirements that are not met by
> > vpn-mcast, then we can go over them and see what to do to meet them.
>
>Why would requirements to support IP multicast with 2547 be any different
>than the requirements to support IP multicast with VPLS ?

 From IP multicast user/application perspective, I cannot see why there
should be any difference and that is why I am suggesting vpn-mcast
mechanism to be leveraged here. However, I was raising a more general
question that if some providers have special requirements that are not
already addressed by vpn-mcast and are specific to VPLS applications, then
they can bring them up and we can collectively evaluate them.

-Ali


>Yakov.