Subject: RE: PIM Snooping

From: "Serbest, Yetik" <[email-masked]>
Date: Tue, 6 Dec 2005 10:07:02 -0600

Eric,

What is your solution/proposal to support multicast over VPLS? Flooding?

Thanks,
yetik

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Eric Rosen
Sent: Tuesday, November 29, 2005 12:00 PM
To: Shane Amante
Cc: [email-masked]
Subject: Re: PIM Snooping 

> Should we require disabling Join Suppression on CE's? 

Oh,  it's  worse than  that.   We'd  also have  to  prohibit  CEs from
ever
implementing PIM refresh reduction (if such  a thing ever comes to be),
from
ever running PIM  over TCP (if such  a thing ever comes to  be), etc.
Well,
it's a good thing the customer has bought an L2 service, to which all
the L3
protocols are transparent ;-)

And remember, it's  not just CEs that are "directly"  connected to PEs,
it's
all routers on a LAN which is bridged to a PE.  

> Should we NOT  require disabling Join Suppression on  CE's, thereby
making
> the PE a more active element in PIM procedures in a VPLS? 

At  least the  PE would  only have  to understand  the  customer's
multicast
routing, it  wouldn't have to  understand anything really  complicated,
like
the customer's unicast routing ;-)

Maybe we should step back and look at what we're doing here.

---

From: "Venu Hemige" <[email-masked]>
Date: Thu, 8 Dec 2005 19:37:16 -0800

Hi Eric,

Please see comments inline

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Eric Rosen
> Sent: Tuesday, November 29, 2005 10:00 AM
> To: Shane Amante
> Cc: [email-masked]
the
> L3

There are already solutions deployed today by many vendors that make the
L2 service not so transparent ;-). Obviously, these are done because
they provide a better solution to the customer.

As Yakov points out, PIM-Snooping is already employed in Ethernet
switches. We should work towards requiring the PIM refresh reduction
solution to be friendly to PIM-Snooping. The requirement for refresh
reduction may very well come from l3vpn multicast. But PIM WG is
building a generic refresh reduction solution and as such it should be
friendly to other technologies like PIM Snooping as well.

> all routers on a LAN which is bridged to a PE.

True. But what is the problem you see here?

> the customer's unicast routing ;-) 

Whether we adopt a solution that requires CEs to disable Join
suppression or not, PEs will not have to understand the customer's
unicast routing. We are not suggesting to make the PE a router.

> Maybe we should step back and look at what we're doing here.

We would be interested in hearing alternate solutions if they are
better. As is evident from the requirements draft, VPLS Multicast is
becoming an important requirement to Providers. We have not seen any
solutions other than PIM Snooping on the table. Suggestions to make the
PIM Snooping solution better are always welcome.

Regards,
-Venu

---

From: Thomas Morin <[email-masked]>
Date: Fri, 16 Dec 2005 14:58:06 +0100

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.

Just to mitigate this one statement : there actually is some text about
snooping/transparency related considerations (4.1.2 §4), asking for
careful design choices, etc.  Though you might consider the wording not
strong enough depending on how hard you feel about snooping.

> 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
> type of approach in the IETF. For example, we also have two drafts
> on IGMP out: one for IGMP snooping, the oher one for IGMP proxy
> routing. The proxy-routing is tageted for standards track, the snoping
> one just informational. That's i think as far as any other technology
> that depends on or describes snooping should go in the IETF.

I agree : it has to be kept in mind that snooping is a design trade-off.

Cheers,

-Thomas