Subject: [Isis-wg] [IS-IS WG] Subsecond Timers

From: Jeff Parker <[email-masked]>
Date: Mon, 18 Dec 2000 20:38:17 -0500

The "Sub Second convergence" draft

	draft-alaettinoglu-ISIS-convergence-00.ps

has a number of useful suggestions about
implementation.  While most of these ideas
can be implemented today, the one change that
would be needed to include all recommendations
would be a new way to encode the hold timer in 
hello messages.  Do the authors plan to put that 
forward in a later version of the document?  

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

---

From: "Shah, Himanshu" <[email-masked]>
Date: Tue, 19 Dec 2000 13:50:50 -0500

OSPF restart (which I guess can be extended for ISIS) and 
fast convergence seems to have conflicting goal (by way of
affecting routerDeadInterval, one desiring longer other
desiring shorter), don't you think?

This needs to be tackled in one or the other RFC too.

-----Original Message-----
From: Jeff Parker [mailto:[email-masked]]
Sent: Monday, December 18, 2000 8:38 PM
To: [email-masked]
Subject: [Isis-wg] [IS-IS WG] Subsecond Timers

- jeff parker

---

From: "Shah, Himanshu" <[email-masked]>
Date: Tue, 19 Dec 2000 14:51:08 -0500

I understand your point and am not contradicting that point.

My point is that, If I understand correctly, router restart's
proposed goal is to restart before neighbor declares him dead
and proceed to clean up. If routerDeadInterval is in sub-seconds,
restart may not complete. If this is a point to worry about
then it should be addressed or mentioned. If not, no sweat..

If ISIS allows changing hold times on per packet basis then
your described method would work for managed restarts for
ISIS. However, if that hello packet got lost after changed
configuration in congestion (which can happen in busy 
network :-) then you may have to hope for the best...

-----Original Message-----
From: Jeff Parker [mailto:[email-masked]]
Sent: Tuesday, December 19, 2000 2:16 PM
To: 'Shah, Himanshu'; Jeff Parker; [email-masked]
Subject: RE: [Isis-wg] [IS-IS WG] Subsecond Timers

My understanding of the two proposals has them
in strict opposition: the convergence draft 
tries to minimize the impact of a crash by 
reducing the time needed to route around any 
problem, and the Restart proposal tries to 
work fast enough to avoid getting caught.

Of course there are other uses for this
functionality, but if you know you want to
bring one side down for an upgrade, you can 
simply configure the box to start sending 
hellos with a longer Holding Timer.  
In IS-IS each side gets to dictate their own 
criteria.  I think that if you try this with 
OSPF, the other side will break the association.  

My point on the converge draft was simply this:
there is only one aspect of the draft that
describes on-the-wire behavior, and that would
have to do with the meaning of the Holding Time.
One side could send "1" if we trusted both sides to
be able to respond to hellos in a timely fashion,
but we cannot go below that with today's draft.
If the authors think 1 second is fast enough, we
could simply change the granularity of the resend
in the MIB, and keep the protocol behavior unchanged.  

- jeff parker

---

From: Danny McPherson <[email-masked]>
Date: Fri, 22 Dec 2000 18:31:16 -0700

>   Most of this "empirical experience" is based on very old networks
>  built out of routers with 20 MHz processors (cisco 7000s come to mind).
>  And in those days the queuing strategies on linecards, and between
>  linecards and control planes was all less elaborate.
> 
>   FYI, when I worked at cisco, I have worked with customers that used
>  holdtimes of only several seconds, but those were not ISPs.

Actually, at a previous job [] in a very large [but newer, not legacy] 
network I did a lot of fumbling with really low hello intervals (1s),
and multipliers of 4 & 5s.  

The primary driver for this at the time was to provide a mechanism 
for detection of a "new neighbor" on a point-to-point links when 
using inter-router SONET APS schemes.  The problem was that APS 
switches on the remote end occur without the local router knowing,
and as such, the fastest detection mechanism to trigger an adjacency 
tear-down and re-initialization was reception of a Hello message from 
an "unknown neighbor" on a point-to-point network.  Other 'hacks'
were experimented with as well, though their impact on network 
stability was even more questionable (right Henk :-).

So, obviously, increasing the frequency @ which Hellos are transmitted 
(by an order of magnitude) had a significant impact on convergence.
This had an even further reaching impact when considering that many
implementations throttle initial or SPF reruns and if I could get
the new adjacency established and LSPs flooded before the first SPF
was executed, then the network was a lot happier in the long run (as 
were attentive customers :-). 

Fortunately, we didn't have tons of pseudo-nodes or large NBMA clouds
with lots of neighbors, the network was composed mostly of point-to-point
POS connections.  As well, removing Hello padding [after adjacency
establishment] enabled us to not use quite as much bandwidth [though it's
never been the size of the packets as much as the volume], and it wasn't
really negligible anyways.  

Then again, I recall working on another very large, very complex network 
that was configured with things such as Hellos (and every LSP/SNP 
[re]transmit interval and SPF throttle know possible) WAY throttled, 
and 200+ neighbors on a single NBMA (w/point-to-point VCs) interface 
consumed a steady 1.5% of the usable bandwidth on the connection.  Of 
course, this was the network that encouraged Dave to add all those IOS 
knobs in order to increase stability, not improve convergence times :-)

I think the work has merit here, though I agree that manipulation of 
such parameters is extremely sensitive.  Fortunately, as Henk allluded to,
a significant portion of this work can remain spec-independent.  That 
is, anything with a Hello Multiplier >= 1s is doable without changes to
the protocol, it's just a matter of the implementation supporting it.  

As such, perhaps something informational along these lines, or at best, 
experimental, is in order?  As Vijay suggest, more experience is probably 
in order before messing with the new TLVs and the like.

-danny

---

From: Danny McPherson <[email-masked]>
Date: Wed, 27 Dec 2000 01:11:59 -0700

> i'll settle for 30 second, see abha's, abhijit's, and craig's most excellent
> 
>    http://www.acm.org/sigcomm2000/conf/paper/sigcomm2000-5-2.ps.gz
>    and http://www.nanog.org/mtg-0010/labovitz.html
> 
> but more germane to is-is, cengiz's, haobo's, and van's
> 
>    http://www.nanog.org/mtg-0010/ppt/cengiz.pdf
> 
> which does suggest finer timers, but only after more modern spf calculation.

Seen both the above documents (a few times), though the pointers should 
certainly be of benefit to others on the list.

> and it neglects to consider such silly operational concers as addressed by
> your draft.

Hence the timing :-)

-danny