Subject: RE: [Isis-wg] IS-IS restart

From: Jeff Parker <[email-masked]>
Date: Fri, 9 Mar 2001 10:30:21 -0500

> -Modify the proposed restart TLV to include a restart time. ...
>  
>  When the holding timer adjacency expires and the adjacency is
>  restartable and the restart timer is non-zero, then wait for 
>  restart time seconds/milliseconds before the adjacency is 
>  declared down and recycled.

Doesn't this make it take longer to detect a bad link via
hellos?   I think Mike's proposal allows the padding you
need by making the Hello Hold Time longer than the time
required to reboot and restart sending hellos on configured
circuits.  

- jeff parker
- axiowave networks
_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: Bruno Mongazon <[email-masked]>
Date: Fri, 09 Mar 2001 17:56:41 +0100

> required to reboot and restart sending hellos on configured

Yes, i've got it:
The faster (lower) you detect bad links, the faster (lower) you restart!

Anyway the restart time will be hidden. It is a part of the holding
time.
If you want to make this part visible to the peer, my suggestion should
be ok?

Bruno.

---

From: Alex Zinin <[email-masked]>
Date: Fri, 9 Mar 2001 09:10:11 -0800

Bruno,

> If you want to make this part visible to the peer, my suggestion should

What value would it add to the mechanism?

Alex.

---

From: Bruno Mongazon <[email-masked]>
Date: Fri, 09 Mar 2001 18:25:25 +0100

> What value would it add to the mechanism?

Not a big value to the mechanism itself but a choice criterion from the
peer perspective:

The peer can choose to support or not restart for the adjacency
depending on the two values (holding time, restart time). If a router
says it can detect bad links fast but restarts slowly, then the peer
might choose high-speed detection without restart.

If everything is hidden in the hold timer, then the peer just ack/nack
according to its restart capability.

Bruno.

---

From: Alex Zinin <[email-masked]>
Date: Fri, 9 Mar 2001 09:45:38 -0800

Bruno,

 I see your point.

 However, I think such a choice would make it harder
 to predict that a graceful restart will actually happen
 when different implementations make difference choices.
 I would suggest we make it simple and go with the hold timer.

-- 
Alex Zinin

---

From: Bruno Mongazon <[email-masked]>
Date: Thu, 15 Mar 2001 10:25:42 +0100

>  I would suggest we make it simple and go with the hold timer.

Alex, Mike,

Agree, let's make it simple and go with the hold timer.

I would just suggest to add a note in the draft indicating that, in
order for graceful restart to actually happen, the hold timer of a
restarting-capable IS shall be set to the max time the IS is expected to
be out (including restart time).

Best regards.
Bruno.

---

From: mike shand <[email-masked]>
Date: Thu, 15 Mar 2001 09:51:06 +0000

OK. I'll add something to that effect.

         Mike