Re: [Roll] need clarification: DIS processing

[JP Vasseur <jvasseur at cisco.com>]

On Nov 17, 2009, at 6:14 PM, Jonathan Hui wrote:

> On Nov 17, 2009, at 9:05 AM, Jerald.P.Martocci at jci.com wrote:
>
> > Not sure I buy that.  If I'm not satisfied with my routes, why  
> > wouldn't I take the lead and issue a DIS as needed?
>
> In most cases, picking routes is based on relative terms (e.g. I  
> chose route A because it is better than B, not because B is  
> unsatisfactory).  While I may have a working route, how would I  
> discover a much better route if one exists?
>
> > It seems to me we should have either a time based algorithm or an  
> > event based algorithm, but not both.  I could see having both if  
> > the time based algorithm was used mainly as a heartbeat to assure  
> > that the links are still in place.  However, if this was the  
> > reason, the periodicity of the periodic DIOs would be in minutes no  
> > milliseconds.
>
> Well, "minutes" in some cases is not good enough.  If routes are  
> inconsistent or you need to discover a new one, waiting "minutes" to  
> discover a new route may not be acceptable.  But sending DIOs on the  
> order of "seconds" is also not acceptable in those situations.   
> Hence the need for an adaptive timer.  Note that, for the most part,  
> the timer is periodic - but that you can speed it up in certain  
> situations.
>
> This tradeoff between fast and slow periods is nothing new.  Many IP- 
> based protocols operate by having a short period when reacting to  
> some event and a long period to maintain the network.

Indeed, note that this is why (on a different subject) global repair  
is also a reoptimization mechanism. In many IP protocols you do use  
indeed fast mechanism for immediate actions combined with longer term  
strategies for reoptimization. Repair is one of the notorious examples.

> --
> Jonathan Hui
>
> _______________________________________________
> Roll mailing list
> Roll at ietf.org
> https://www.ietf.org/mailman/listinfo/roll