Subject: RE: [[email-masked]: I-D ACTION:draft-ietf-pim-v2-dm-02 .txt]

From: Ravi Shekhar <[email-masked]>
Date: Fri, 21 May 1999 10:54:44 -0400

I have two more comments to add:

  1. When there are multiple downstream routers on a LAN which want to send 
     prune up, shouldnt they use a random delay timer before sending it on
the 
     LAN (and suppress their prune if some other router has sent it with
same 
     prune-expiration time). Otherwise every time first data is flooded,
there
     will be a prune generated by each downstream router on the LAN. 
       This mechanism is already being used for prune-override joins in
section
     5.2.1. I think it would be good to extend it to prunes too.

  2. In section 5.6
>  The prune message sent upstream contains a holdtime. Its default value
>  is  [Data-Timeout],  ....

     Shouldnt the prune sent up have a holdtime value of "minimum of 
     prune-expiration time of each pruned oif" - "current-time". If its 
     value is 210 seconds, then network might get into vicious cycle of
     sending a prune up for 210 seconds, followed by a graft up to cancel it
     (as the preceeding paragraph in the draft seems to suggest).
     This could end up happening every 210 seconds (and will at least
tripple the
     control traffic on pruned branches). It would be better to send a prune
up
     with appropriate holdtime instead. 

     - Ravi Shekhar. 

> 
> This draft doesn't seem to have answered any of the outstanding PIM-DM
> issues that have been brought up over the past several months.
> 
> None of the black holes that I pointed out appear to have been
> addressed.
> 
> There are some open questions about packet processing - 2 
> that I remember:
> - where do you send a graft if you sent your prune
> with an upstream neighbour of 0.0.0.0?
> - what do you do with a Join that does not appear to
> be acting as a prune-override (e.g. your prune-override
> timer is not running for the source and group described
> in the Join)?
> 
> Sections 5.3 and 7.8 still disagree about when to send Graft-ACKs.
> 
> Section 5.2.1 is still very vague about what it means by "must not be
> sent...in response to each ... packet"; it could be interpreted to
> mean "must never be sent".  I continue to think that this should be
> reworded.
> 
> Several references to "deleting" an interface were changed to say
> "prune", however several references remain to "deleting" the interface
> so now it's even more confusing than it used to be.
> 
> "negative cache entry" is defined in section 5 as an entry with no
> outgoing interfaces, and section 5.6 as an entry whose outgoing
> interfaces are all pruned.  These definitions should be unified
> (and perhaps put in the glossary).
> 
> The reference to the PIM-SM spec in section 7 is normative; thus this
> document can't progress to a state (e.g. Proposed) before the SM
> spec is in that state.  This probably isn't desirable.
> 
>   Bill
>