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

From: Les Ginsberg <[email-masked]>
Date: Wed, 28 Feb 2001 11:51:59 -0800

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

> -----Original Message-----
> From: Jeff Parker [mailto:[email-masked]]
> Sent: Wednesday, February 28, 2001 10:29 AM
> To: '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
> 
> 
> > 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
> 
_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: Bora Akyol <[email-masked]>
Date: Wed, 28 Feb 2001 11:55:06 -0800

As long as you generate LSP updates when the adjacency is dropped 
quickly and you apply some sort of backoff interval when the 
adjacency comes back, is there any reason that you can not generate 
an LSP update immediately when adjacencies are lost (via L2 
notification)?

Bora

At 11:51 AM -0800 2/28/01, Les  Ginsberg wrote:
>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.
>