Subject: PIM Snooping

From: Shane Amante <[email-masked]>
Date: Mon, 28 Nov 2005 13:26:37 -0700

Folks,

At IETF 64, in Vancouver, there was substantial concerns[1] raised wrt 
Join Suppression in latest PIM snooping draft[2].  Specfically, the 
current draft has defined that CE PIM routers MUST disable Join 
Suppression, in order that receivers will not suppress their own Joins 
so they can receive multicast traffic through a VPLS instance.  The 
[sole?] advantage of disabling Join Suppression at the CE's is:
1) PE's would remain relatively simple PIM snooping/forwarding devices, 
allowing a VPLS instance to [continue to] transparently forward all traffic.

The disadvantages are:
2) Not all CE's support disabling Join Suppression;
3) It requires on-going coordination between SP's and their customers to 
disable Join Suppression on CE's, (CE's which may/will not be under the 
SP's control); and, finally,
4) It inhibits scalability of PIM in a VPLS instance.

Since there was little, if any, consensus in Vancouver as to the best 
direction forward with the PIM snooping work, we would like to hear from 
the WG:
A) Should we require disabling Join Suppression on CE's?
B) Should we NOT require disabling Join Suppression on CE's, thereby 
making the PE a more active element in PIM procedures in a VPLS?
C) Other, more palatable, suggestions?

Please answer the above questions and feel free to add color commentary 
as to other issues or concerns not identified above.

Thanks,

-shane & Vach

[1] http://www3.ietf.org/proceedings/05nov/minutes/l2vpn.txt
[2] draft-hemige-serbest-l2vpn-vpls-pim-snooping-00.txt

---

From: Ray Qiu <[email-masked]>
Date: Mon, 28 Nov 2005 13:03:24 -0800

Hi folks,

Thanks to Shane and Vach for initiating a discussion on PIM snooping. I
would like to initiate a discussion on the LDP multicast state distribution
draft as well, since it is directly related to this topic.

Dino pointed out in the meeting that this proposal would require explicit
tracking in LDP. As we clarified earlier, LDP is only used as a vehicle to
carry the multicast state information. LDP doesn't need to understand any
multicast related states, because the PIM snooping component is responsible
for handling multicast states.

Multicast state distribution between L2VPN PE routers is an important issue
to solve. We would like to hear your comments and ideas.

Thanks.

--Ray

---

From: Eric Rosen <[email-masked]>
Date: Tue, 29 Nov 2005 13:00:20 -0500

> 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: Yakov Rekhter <[email-masked]>
Date: Wed, 30 Nov 2005 06:51:45 -0800

Shane,

> as to other issues or concerns not identified above.

Wrt (B) what are the implications of making the PE a "more active
element" on the externally visible behavior (where by "externall
visible" I mean visible to a VPLS customer) ?

Specifically would a VPLS customer be able to distinguish between
the cases where a PE operates as specified today, and making the
PE "a more active element in PIM procedures in a VPLS" ?  And if
yes, then what are the differences ?

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 30 Nov 2005 07:06:48 -0800

Eric,

> protocols are transparent ;-)

It is just that some L3 protocols are more transparent than others :-)

On a more serious note the interaction with PIM refresh reduction
and/or running PIM over TCP applies not just to VPLS, but to any
ethernet switch that does PIM snooping. Therefore, while this is a
valid issue, it goes well beyond VPLS.

With this in mind I added PIM to the cc: list, as  I think that the
PIM WG would be more appropriate place to discuss the impact of PIM
refresh reduction and/or running PIM over TCP on ethernet switches
that do PIM snooping.

Yakov.