Toerless Eckert | 15 Dec 2005 22:58
Picon
Favicon

Re: RE: PIM Snooping

What i still don't understand is how IGMP Snoping or PIM Snooping
are considered to be acceptable within the scope of L2VPNs. I
quite frankly think that it is important to point out that
using these two mechanisms very much breaks the transparency
expectation that traditionally has been the primary reason of
a customer to buy into an L2VPN service instead of let's say
an L3VPN service. 

In my opinion, L2VPN is perfectly fine as long as the service
required for multicast works well without snooping on PE nodes
(aka: broadcast type multicast traffic), but once you need to
have traffic constrainment only achievale with snooping, you should
seriously consider an L3VPN service, because effectively you are
running exactly the same tree building mechanisms now, just that
in L3VPN you are making it based on explicit, standardized
protocol interactions, and in L2VPN you would need to trust and pray
for vendor specific PIM Snooping functionality to be compatible
with the particular set of functions in PIM / IGMP that you as
the customer are relying on - like Bidir, DR/DF priorities, any
extensions like Proxies for InterAS, or for Dino's membership counting,
different address families (IPv4, IPv6),...

I don't understand why the base requirements of L2VPN services don't
have a very strong statement about this basic principle - transparency
of the service, and independence of protocol properties used on CE
from what the SP is using.

Surely each of the vendors will implement as much PIM, IGMP and foobar
snooping as they can make money with, and that certainly includes
Cisco, but that doesn't make it really a good thing to pursue that
(Continue reading)

Thomas Morin | 16 Dec 2005 14:58

Re: RE: PIM Snooping

Hi folks,

Toerless Eckert:
> What i still don't understand is how IGMP Snoping or PIM Snooping
> are considered to be acceptable within the scope of L2VPNs. I
> quite frankly think that it is important to point out that
> using these two mechanisms very much breaks the transparency
> expectation that traditionally has been the primary reason of
> a customer to buy into an L2VPN service instead of let's say
> an L3VPN service. 
> 
> In my opinion, L2VPN is perfectly fine as long as the service
> required for multicast works well without snooping on PE nodes
> (aka: broadcast type multicast traffic), but once you need to
> have traffic constrainment only achievale with snooping, you should
> seriously consider an L3VPN service, because effectively you are
> running exactly the same tree building mechanisms now, just that
> in L3VPN you are making it based on explicit, standardized
> protocol interactions, and in L2VPN you would need to trust and pray
> for vendor specific PIM Snooping functionality to be compatible
> with the particular set of functions in PIM / IGMP that you as
> the customer are relying on - like Bidir, DR/DF priorities, any
> extensions like Proxies for InterAS, or for Dino's membership counting,
> different address families (IPv4, IPv6),...
> 
> I don't understand why the base requirements of L2VPN services don't
> have a very strong statement about this basic principle - transparency
> of the service, and independence of protocol properties used on CE
> from what the SP is using.

(Continue reading)


Gmane