Subject: Re: Subsecond hello and dead rtr timer support in v2/v3

From: Tom Petch <[email-masked]>
Date: Wed, 26 Feb 2003 09:36:07 -0000

I am with Tony on this one, that layer 2 problems should be solved at
layer 2; layer 3 may now be faster than when OSPF first appeared but
it is still orders of magnitude slower than layer 2 (and in Enterprise
networks, the 68000 chipset of a major router manufacturere remains
slow:-).  Historically, a similar problem appeared when moving from
analog to digital circuits so that network operators could and did
report outages of O(mS) duration which previously had gone unnoticed
or caused a checksum failure and retransmission.  Attempts to solve
that in layer 3 were a cure worse than disease and the correct
solution was to change layer 2 so that 'incidents' were counted but
not always acted upon by layer three.

We need a better layer 2 algorithm to tell us whether this outage is
worth reconfiguring for or not, and yes that has impacts on flow
control and buffering (eg my 2G4bit/s link is down for 100uS, do I
buffer the data, flag congestion, teminated the sessions etc?).

And conversely, because this mailing list contains the world's
greatest expertise in OSPF, we should take care not to assume that
OSPF
is the right answer, what's that question?

Tom Petch

-----Original Message-----
From: Yasuhiro Ohara <[email-masked]>
To: [email-masked] <[email-masked]>
Date: 26 February 2003 08:48
Subject: Re: Subsecond hello and dead rtr timer support in v2/v3

>Hi.
>
>> Discussion has been had many times, almost everybody having built
>> those protocols and deployed them in on a larger scale shares the
>> opinion that this is best solved by a link-layer mechanism. Of
course
>
>I don't think that this is best solved by a link-layer. Who do you
mean
>by "everybody" ? At least in the OSPF ML there were some objections
>to that, IIRC.
>
>> it may work on a 3-boxes-in-a-triangle-all-properly-hacked-up
>> scenario but then, OSPF is not your ideal tool to solve the problem
>> and something more light-weight may be needed.
>
>Why do you think L3 scheme is heavy ? L3's flap detection will be
>done at various point independently. I don't think it's heavy.
>
>I believe that there certainly exist the cases where L2 up and L3
down.
>L3 reachability should be detected in L3, similar way of thinking
>which is employed in ships-in-the-night.
>
>regards,
>yasu

---

From: Erblichs <[email-masked]>
Date: Thu, 27 Feb 2003 02:14:31 -0800

Come on people,

Are you guys telling me that your systems can't handle 300 pings
per second while your routers are operating? It shouldn't even
increase CPU load by most a few percent.

This was Tony's number with 30 nbrs and 100ms intervals.

Just because it is subsecond it nature doesn't mean it needs
to carry the normal nbr list, etc that is normally encountered
with a hello packet.

Simplify the amount of work that needs to be done, add a sequence
number, a timestamp, as optional processing items. The sequence
number tells us that we haven't lost a packet. The timestamp
can be read and compared with past / future timestamps to determine
the amount of variance that is occuring.

Why not decrease multiple second convergence timeframes when you
can detect failure or congestion within 1 second?

What I am not saying is that we need microsec detection at
layer 3, but having a protocol that allows the detection time
to decrease to "us" timeframes is intreiging.. (spelling)

Mitchell Erblich
Sr Software Engineer
============================

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 27 Feb 2003 11:54:50 +0100

>increase CPU load by most a few percent.
talking about pings vs. OSPF helloes you're in a parallel universe ...

>to carry the normal nbr list, etc that is normally encountered
So why do you exactly want this thing in OSPF if it is not an OSPF hello
beside
trying to make it a kitchen-sink ?

>the amount of variance that is occuring.
translates to me into 'build some lower layer keepalive', look at
Kireetis draft.

    --- tony