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

From: [email-masked]
Date: Wed, 7 Mar 2001 14:57:22 -0800

From:  James Huang@MITEL on 03/07/2001 02:57 PM PST
>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.

Mark:
     Can you tell me more about this routing loop scenario?  If routing loop
does occur in your scenario, don't we have the same problem during some initial
SPT setup where both (*,G) and (S,G) join state exists in the same downstream
interface, RPF_intf(RP) != RPF_intf(S), and SPTbit(S,G) == 0. Under this
condition, the router will try to join the SPT by sending join(S,G) to
RPF'(S,G).  But before (S,G) traffic starts arriving from the SPT, the router
will accept (S,G) traffic from the RPT and foward it down to the interface where
both (S,G) and (*,G) join state exists. In this situation, traffic DOES go from
being forwarded on (*,G) state (by this router) to being forwarded on (S,G)
state (by downstream routers with upstream (S,G) join state on the interface
where both (S,G) and (*,G) join state exists)

-- James Huang

Mark Handley <[email-masked]> on 03/06/2001 09:45:38 PM

To:
cc:   James Huang/USA/Mitel@Mitel, [email-masked]

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

>
>>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 conditio
>n
>>s.
>>Which one is correct?
>
>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.

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

---

From: Mark Handley <[email-masked]>
Date: Wed, 07 Mar 2001 16:19:18 -0800

>Mark:
>     Can you tell me more about this routing loop scenario?  

Ok, this is hard in ASCII art.  

         J(S)->   J(S)->
     RP ------- A ----------------B
         <-J(*) |                 |J(S)
                |                 ||
             ^  |                 |V
           J(*) |           <-J(*)|
               LAN----------------D------>
                |                 |  I1  to
             ^  |               ^ |I2    S
           J(*) R2            J(*)o------>
                                  |
                                  R1

The starting situation is that R1 and R2 have done (*,G) Joins, and
the RP has joined to S (through B, for whatever reason).  D has sent
an (S,G,rpt) prune on the LAN to A, but R2 overrode the prune, so
traffic from S is still arriving on the LAN from A.  D doesn't have
any downstream join state on the LAN interface, so it doesn't
assert. D's iif towards S is I2.

Now the RPF_interface to S changes to I1.  

D sends a Join(S,G) on I1, but for some reason the join fails to
complete (say the join packet is lost).

Now if D clears SPTbit, then traffic from the LAN will immediately be
accepted by D, and forwarded around the loop.  Whatever traffic was
already in the D->B->A->LAN loop will circulate until its TTL
decrements to zero.  

Fortunately no new traffic can enter the loop, so this is a transient
event.  Not a disaster, but undesirable.

>If routing loop
>does occur in your scenario, don't we have the same problem during some initia
>will accept (S,G) traffic from the RPT and foward it down to the interface whe
>both (S,G) and (*,G) join state exists. In this situation, traffic DOES go fro

Yes, that is indeed the case:

              <-J(S)
         S----------------RP
         |                |
         |                |^
         |                |J(*)
         |                |
         |      J(*)->    |
         A----------------B---------R2
         |                |
         |                |
       ^ |                |
     J(*)|                |
         |                |
         C----------------+
       ^ |
     J(*)|
         |
        R1

In this situation, R1 has done a Join(*,G), and RP has joined to S
directly.

Now R2 does a Join(S,G), which is routed via C:

              <-J(S)
         S----------------RP
         |                |
         X                |^
      ^  |                |J(*)
     J(S)|                |
         |      J(*)->    |
         A----------------B---------R2
         |                |   <-J(S)
         |                |
       ^ | ^              |J(S)
     J(*)|J(S)            |V
         |                |
         C----------------+
       ^ |     <J(S)
     J(*)|
         |
        R1

But between A and S, the Join fails for whatever reason (say the Join
packet is lost).

Now SPTbit at C and B is set by arriving traffic, but SPTbit at
A is not set.

Traffic loops from B->A->C->B.  However as the SPTbit at B is set, it
doesn't accept any more traffic from the RP, so no new traffic is
accepted into the loop.  Thus, although it's undesirable, it's not a
disaster either.

I think this has always been an issue with PIM-SM.  We cured quite a
few problems when writing the new spec, but this wasn't one we could
solve and stay completely compatible.  C simply cannot tell that an
upstream router is accepting packets from the RPT when they're
arriving on its RPF_interface towards S.  

To solve the problem you'd need either:

 - a downstream message that says "SPT incomplete" when this scenario
   is detected, or

 - a downstream message in the normal case that says "SPT complete"
   and that triggers the SPTbit being set.  

The former could be added as a negotiated extension if we believe this
is a significant issue; the latter would probably have been the better
solution, but isn't backwards compatible with existing deployed code.

However the first case (when RPF_interface(S) changes) is easily
preventable by not clearing the SPTbit when it's unsafe to do so.

Cheers,
	Mark

---

From: Liming Wei <[email-masked]>
Date: Wed, 7 Mar 2001 18:04:24 -0800 (PST)

Mark,

There is no loop in the first scenario you described. When D uses the
(*,G) for forwarding the link D->B, that is in the (S,G) oif list, is
NOT in the (*,G)'s oif list, so no packets will go from the (*,G) tree
down D->B back toward the RP that way.

But in general, I agree with the statement about the downside of such
uses of the SPTbit. In reality, it should be used to signify
whether one wants to use SPT or RPT for an application ("static decision")
at configuration/control time. As opposed to a clever forwarding path
mechanism to cut down the small window where packet loss may
occur.

The behavior of packet-driven SPT-bit having things working along the
RPT when the SPT is broken can be viewed both as a feature and as
a bug.

-Liming
----------
> From: Mark Handley <[email-masked]>
> Cc: [email-masked]
> 
> >Mark: