Subject: RE: PIM Snooping

From: "Suresh Boddapati" <[email-masked]>
Date: Thu, 1 Dec 2005 19:04:58 -0800

> > 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.
> 
> 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) ?
> 
The implications are that a customer router connected to a PE will not
necessarily see the same packet that its counterpart at another PE
generated. The packets may be modified, consumed and/or generated by PEs
on behalf of customer routers. 

> 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" ?  
> 
Not necessarily. The whole idea of making the PE an active element would
be to ensure that nothing has to change in C routers, the multicast
states will be built as before. The only difference is that the C
routers may end up seeing different packets than what they used to
before. 

Let us consider what a "more active element" in this context means.
Consider an example where there are three PEs: PE1, PE2, PE3. 
PE1 has the upstream router U  and a downstream router D1 connected to
it on the same AC.
PE2 has a downstream router D2.
PE3 has a downstream router D3.

In order for snooping to build states correctly:
1)If D2 sends a Join to U, we don't want D3 to see the Join because if
it did, then it would suppress its Join and the pseudowire PE1-PE3 will
not receive the traffic (since PE1 never saw a Join on PE1-PE3). This
would not be a problem if all C routers disabled Join suppression and
did explicit tracking.

2)If D2 sends a Prune to U, we want D3 to see the Prune so that it can
override it. Same would apply if D1 sent a Prune to U; you want D2 and
D3 to see it so that they can override the Prune. Again, this would not
be a problem if Join suppression was disabled.

It would be easy to solve the problem without requiring disabling of
Join suppression if Joins and Prunes were separate messages - just
unicast Joins (by modifying the dest mac to the upstream router's mac)
and multicast Prunes. But Joins and Prunes can be in the SAME JP message
and that's where it becomes more complicated.

If we want to preserve the transparency to the C routers (i.e. not
requiring them to disable Join suppression), then the PEs will have to
do something like:

1) Consume the Join/Prune messages seen on the AC. This means we might
have to consume other PIM packets (Hello, Assert, BSM) and then send
them so that the ordering between the messages is preserved. (An Assert
sent to an upstream router that does not have a downstream state will be
dropped, for example, since the Join came after the Assert when actually
it was sent before the Assert).
2) Separate the Joins from the Prunes: This means the PE is generating
packets on behalf of the C routers.
3) Unicast joins to the upstream router and multicast the Prunes to all
routers.

There may be other ways of doing this, but essentially, we are trying to
make the PEs make up for Join Suppression not being disabled in the VPLS
by simulating it. The downside is we are no longer plain "snooping", we
are also an active participant. Of course, there are also some benefits
to doing this. Since the PE is assuming a Proxy role, if it has already
signaled a Join for an (S,G) on a PW (due to having received one on an
AC), it need not signal Joins for the same state if they arrive on other
ACs, as long as it keeps track of how many ACs sent the Joins. This way,
the number of Join states sent on the PWs is also reduced.  

So the question boils down to: Is this the direction we want to go in
i.e. have the PEs assume a Proxy role so that the C routers do not have
to change OR should we require C routers to disable Join suppression and
do explicit tracking. There is a tradeoff here:
1) If we want to preserve the transparency to the C routers (a
reasonable goal indeed), the proxy procedures might be perceived by some
as "hacks". It was said so in the previous IETF at Paris. But that is
the cost of preserving the transparency.
2) If we want to keep the snooping procedures straightforward without
any modifications to the C packets, then the C routers have to disable
Join suppression. It was suggested at the Vancover IETF that this is an
unreasonable requirement since most routers do not support Explicit
tracking today. This is a good point too. 

Both the approaches have merits and demerits. We would like opinions on
what the WGs think is the best approach. Thanks.

Suresh

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 14 Dec 2005 06:56:36 -0800

Suresh,

[clipped...]

> 3) Unicast joins to the upstream router and multicast the Prunes to all

How the above would work (especially the part where the PE is
generating packets on behalf of the C routers) if one uses IPSec
authentication header to provide data integrity protection and data
origin authentication of PIM protocol messages ?

Yakov.

---

From: "Suresh Boddapati" <[email-masked]>
Date: Thu, 15 Dec 2005 11:05:40 -0800

.
> origin authentication of PIM protocol messages ?
Yakov, you make a good point. I am not an IPSEC expert, but it seems
like if authentication header is used, then we will still be able to
snoop, but will not be able to do proxy, since we won't have the
security associations. I guess we need to make some hard calls here. If
the requirement is not to require CE routers to disable Join
Suppression, then proxy as a solution does not still give you pure plug
and play in at least one case that you pointed out. Plus, the solution
has more complexity than just snooping. This seems like one more
argument to not go the proxy way and stick with pure snooping.

Another thing to consider is how many routers actually support
authentication of PIM packets using IPSEC and how many deployments of
this are out there. If they plan to move to an authentication scheme in
the future, they anyway have to upgrade (assuming all routers do not
support this), in which case requiring disabling Join suppression may
still be ok.

What do you think?

Thanks,

Suresh