Subject: Reset SPTbit(S,G) on topology change events

From: [email-masked]
Date: Tue, 6 Mar 2001 18:30:23 -0800

Hi all,
     When topology change occurs and causes RPF_interface(S) to be changed,
should the upstream (S,G) state-machine reset SPTbit(S,G) to 0?
Draft-ietf-pim-sm-v2-new-01.txt doesn't do it, but Sec 2.10 of rfc2362 did
mention about resetting SPTbit(S,G) on topology change under certain conditions.
Which one is correct?

Thanks for your input.

James Huang

---

From: Mark Handley <[email-masked]>
Date: Tue, 06 Mar 2001 20:22:00 -0800

>mention about resetting SPTbit(S,G) on topology change under certain condition

SPTbit determines whether or not (S,G) Join state is used to calculate
the outgoing interface list, and which incoming interface the packet
can be accepted on.

If RPF_interface(S) changes from I1 to I2, (S,G) packets still
arriving on I1 will be rejected if SPTbit is still set.  If SPTbit is
cleared, then they'll be accepted in the case where RPF_interface(*,G)
is I1, although they'll only be forwarded on interfaces with (*,G)
join state.

In either case, once an (S,G) packet arrives on I2, the SPTbit will be
set again.

So, the plus side of clearing the SPTbit is that in some cases traffic
isn't interrupted while the new (S,G) state is built.  The downside is
that you're now accepting packets on (*,G) state, and in the case
where you have (*,G) and (S,G) join state on the same OIF, the routers
downstream of you will accept traffic from you on (S,G) state.
Normally traffic cannot go from being forwarded on (*,G) state to
being forwarded on (S,G) state, only the other way around.  In some
convoluted cases, this can cause a routing loop.  I can't think of any
case where the loop accepts traffic that isn't already in transit in
the links involved in the loop, but this just generally gives me a bad
feeling - it reduces one of the forms of safeness in the basic PIM-SM
design.

Thus I don't think you should clear the SPTbit when RPF_interface(S)
changes.  

 - Mark

---

From: Mark Handley <[email-masked]>
Date: Tue, 06 Mar 2001 21:45:38 -0800

>>mention about resetting SPTbit(S,G) on topology change under certain conditio
>n
>>s.
>>Which one is correct?
>

Actually I should have read the relevant section in RFC 2362 before
responding.  What I said about loops is correct, but RFC 2362
anticipated this and says:

   If the router has a (S,G) entry with the SPT-bit
   set, and the updated iif(S,G) does not differ from iif(*,G) or
   iif(*,*,RP), then the router resets the SPT-bit.

Thus the SPTbit is only reset when
  new RPF_interface(S) == RPF_interface(RP(G)).  
So the loop I described couldn't happen anyway.

So what other effects would clearing SPTbit have?  

1. CouldAssert(S,G,I) would become false.  So we'd lose asserts on our
  downstream interfaces that have (S,G) Join state.

2. If the new RPF_interface(S) is a LAN, and RPF'(S,G) != RPF'(*,G),
  then if SPTbit is set, we'd send an (S,G,rpt) prune to RPF'(*,G).
 
These would both appear to be good.  Although PIM-SM doesn't
gracefully allow a receiver to choose to switch back to the RPT from
the SPT, in the case where a routing change causes the SPT to change,
and the new SPT fails to be set up for any reason, then these would
appear to allow the fallback to the RPT to be a little faster.

But note that this is a special case: 

 - new RPF_interface(S) == RPF_interface(RP(G))
 - new RPF_interface(S) is a LAN
 - RPF'(S,G) != RPF'(*,G)
 - the new SPT fails to be set up.

Under these circumstanes, you get faster switchback to the RPT if you
clear SPTbit when new RPF_interface(S) == RPF_interface(RP(G)).

Is it worth adding a special rule to deal with this special failure
case?  Our policy has been that we try to avoid adding unnecessary
complication to the spec, especially when it's only a special case
optimization like this one.

I think you can implement either, but I don't think it makes much
difference in reality.  But definitely don't clear SPTbit when
new RPF_interface(S) != RPF_interface(RP(G)).

Cheers,
	Mark