Subject: RE: The Assert Mechanism

From: "Mohit Talwar (Exchange)" <[email-masked]>
Date: Thu, 21 Oct 1999 00:27:47 -0700

> -----Original Message-----
> From: Isidor Kouvelas [mailto:[email-masked]]
> Sent: Wednesday, October 20, 1999 5:48 PM
> To: Mohit Talwar (Exchange)
> Cc: Bill Fenner; [email-masked]; [email-masked]
> Subject: Re: The Assert Mechanism 
> 
> 
> "Mohit Talwar (Exchange)" writes:
> > > >In PIM Dense Mode, the outgoing interface is "pruned" 
> > > >and a timer is associated with it, so that Asserts reoccur 
> > > >periodically to handle failures like this.  Perhaps PIM-SM 
> > > >could use a similar mechanism.
> > > >
> > > >to avoid the periodic reflood upstream of the
> > > >assert loser, the assert winner can periodically 
> > > >re-assert as long as there is traffic for the source.
> > > 
> > >You mean the winner would retransmit its Assert before the loser's
> > >timer goes off to refresh the timer?  (If the loser doesn't have a
> > >timer then this doesn't help any when the winner dies).
> >
> >correct me if i am wrong...
> >but this solution requires another timer per oif per tree entry
> >and periodic generation of control (assert and joinprune) messages.
> >
> >what do u think about the alternative in which the DR on an 
> >interface keeps track of tree entries for which it has lost 
> >the interface and the neighbor to whom it lost it. so the 
> >interface can be added to those entries if the assert winner 
> >dies.  
> 
> This would only work if you can also detect that state has 
> been cleared by configuration on the assert winner. To achieve 
> this the GenID in Hello messages should change when state 
> is cleared as well as on restarts.

well, i don't understand this argument.  the state could just 
as easily have been deleted on the DR (by configuration) when 
it has NOT lost the interface to an assert election.  how is 
that any different from the state having been deleted from the 
assert winner?

> In either case, as Bill pointed out, on the loser you have to maintain
> information on the interface after you have stoped forwarding (keeping
> it in the list in pruned state).

my arguments in favor of the alternative proposal

1. the state has to be maintained (per interface, per neighbor)
   only at the DR and 
   only for tree entries for which...
   - there are local receivers on the interface
   - the assert election was won by that neighbor

   but i agree, it's the same amount of state either way.

2. it does not need periodic asserts or join-prunes messages,
   basically lower control overhead.

mohit.

---

From: Isidor Kouvelas <[email-masked]>
Date: Thu, 21 Oct 1999 10:38:39 -0700

>that any different from the state having been deleted from the 

It is different as in the case that the state is cleared on the DR, on the
next IGMP report the router will again create (*,G) and add the interface to
the olist (since it is the DR) hence there is no problem. If the state is
cleared on an assert winner that is not the DR, then it will lose its
forwarding state and the DR will have no way of finding out.
The only way to work around this is to change the GenID in the Hello message.

>   but i agree, it's the same amount of state either way.

Right.

Isidor