Subject: RE: [Isis-wg] comment on draft-parker-short-isis-hold-times-00.t xt

From: Jeff Parker <[email-masked]>
Date: Wed, 28 Feb 2001 13:28:35 -0500

> Following up on this thread, on BGP the recommended behavior is to 
> not use a timer for withdrawals when adjacencies fail, can one 
> utilize a similar behavior and immediately generate and distribute 
> updated LSPs when L2 link is lost?
> 
> Bora
 
Bora -

Section 7.3.6 of 10589 describes the minimumLSPGenerationInterval, a
hold-down
timer on the regeneration of an particular LSP with a default value of 30
seconds.  
I assume this means that we could generate the first LSP after an Adjacency
change 
at once,  though regeneration due to later events would be damped by this
value.  

That is, I read this to say that regeneration could happen right
after the first adjacency was lost, recording the time until the 
next regeneration would be valid.  
It may be more common to see implementations simply start a timer 
to schedule regeneration in the future, which may be a bit simpler,
and has the nice tendency to group more events into one generation,
suffering the problem of increasing the convergence time.  

Is there any reason why we should not encourage Bora's interpretation
for Adjacency Loss?  I could defend a distinction between adjacency
loss and things like metric change or a change in the DIS, as those
do not prevent a packet from reaching its destination.  

- jparker
- axiowave networks
- If you want truly to understand something, try to change it. - Kurt Lewin
_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: Jeff Parker <[email-masked]>
Date: Wed, 28 Feb 2001 15:00:40 -0500

Les -
	I agree that getting the LSP out quickly is important.  
I guess I haven't seen where it is written in stone that
"hold-down timer" means "don't do something until X seconds elapse"
rather than "don't do this more often than once every X seconds."
The first is an easy way to implement the second, but not the only way.
	Given the second interpretation, we could still get rapid
convergence while keeping a large minLSPGen time, which is desirable.  

- jdp

> If faster convergence is to be achieved and be useful, then 
> clearly all
> aspects must be addressed - adjacency state change detection, 
> propagation,
> SPF performance, and forwarding database update. It does no 
> good to detect
> an adjacency failure in milliseconds if you can't tell anyone 
> about it until
> 30 seconds later. So clearly minimumLSPGenerationInterval needs to be
> adjusted as well as the hold down timer on the SPF. All of 
> these issues are
> mentioned in Cengiz et al draft.
> 
> I also think that treating adjacency state change as a 
> "special" kind of
> update is unnecessary. So long as we are not talking about leaking BGP
> routes into IS-IS, adjacency flapping has to be the primary 
> cause of LSP
> updates in a network.
> 
>    Les
>

---

From: Les Ginsberg <[email-masked]>
Date: Wed, 28 Feb 2001 12:15:13 -0800

So long as you have a large minLSPgen timer, no matter which implementation
method you use, the best you can do is get fast convergence on one adjacency
change. If two events occur over a short time span then even the second
interpretation would have to wait 30 seconds to propagate the second change.

So if you think that minLSPgen needs to be large, then its pretty much a
waste of time to do sub-second adjacency timeout. 
Note that I am not in opposition to the faster convergence concept - just
want to be sure all aspects are addressed.

   Les

> -----Original Message-----
> From: Jeff Parker [mailto:[email-masked]]
> Sent: Wednesday, February 28, 2001 12:01 PM
> To: 'Les Ginsberg'; Jeff Parker; Bora Akyol; Danny McPherson (E-mail);
> Cengiz Alaettinoglu (E-mail)
> Cc: [email-masked]
> Subject: RE: [Isis-wg] comment on
> draft-parker-short-isis-hold-times-00.t xt
> 
> 
> Les -