Subject: Prune timers in PIM-DM

From: Bill Fenner <[email-masked]>
Date: Tue, 17 Nov 1998 15:28:33 PST

When a router sends a prune upstream, by default it uses a timeout of
[Data-Timeout].  However, if this router has downstream prunes that
expire in less time than [Data-Timeout], then it sends a graft upstream
when said downstream prune expires.

2 messages could be saved (Graft and Graft-Ack) if the prune sent
upstream is simply sent with the minimum of [Data-Timeout] and the
remaining timer of all downstream prunes.  That way, the downstream
router can be sure that the prune that it sent upstream will expire at
the same time as the downstream prune, so no need for the Graft.

Grafts will still be necessary on multi-access LANs where the router
with the smallest downstream prune timer is not the one that sent the
Prune that was acted upon by the upstream router.  This requires that
routers keep track of whether or not they were the last one to send a
prune, so that they can skip sending the Graft if so.  Alternately,
downstream routers on multi-access LANs could keep track of the prune
timer that it or its neighbors send, so that all routers on the LAN can
be aware of whether or not the upstream prune is pending.  (In fact, I
think that the latter is a requirement anyway, to avoid transient black
holes in certain situations.  More on this later.)

Any comments?

Thanks,
  Bill

---

From: [email-masked] (Ravi Shekhar)
Date: Tue, 17 Nov 1998 21:19:03 -0500 (EST)

Hi Bill,

>holes in certain situations.  More on this later.)

    I hit a somewhat similar problem, but in a different scenario.

    Lets say if assert between two upstream routers happens 30 seconds 
    after prune has been sent by a downstream router. The assert-winner 
    will schedule to prune the interface and prune it for 210 seconds 
    (30 seconds more than what the downstream desired it to be on the 
     absolute clock).
        
        The way I was planning to handle it was by making downstream routers 
    update their prune timeouts to be the holddown time from the "schedule 
    to prune" message from the assert-winner.

        This scenario will happen rarely and will last only for a transient
    period - the chances of two upstream routers asserting after prune has 
    been sent is less. It will only happen if there is a routing topology 
    change and suddenly new upstream routers appear. Hence it was not 
    worth any attention.

        But what you have pointed out is much more generalised and probably
    could happen more frequently.
        
        If downstream routers listen to the "schedule to prune" messages
    from the upstream router and update their prune times accordingly, it 
    should fix this scenario too. And as you pointed out in another mail,
    <S, G> state in the upstream router should be maintained as long 
    as either entry-timer or prune-timer is active on the upstream router.

    Will this fix it?

    - Ravi Shekhar.