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

From: Erblichs <[email-masked]>
Date: Tue, 25 Feb 2003 02:48:18 -0800

Hey guys,

        I got a request for subsecond timer support in OSPFv2 and V3, that
        hopefully follows the reasoning that was suggested in the ISIS
        subsecond timer draft.

        Thus, I was interested to know whether I have missed an existing
        experimental or information draft suggesting a possible impliemtation
        of subsecond timer support within OSPF.

        Mitchell Erblich
        Network / OS Software Engineer

---

From: Rohit Gupta <[email-masked]>
Date: Tue, 25 Feb 2003 04:12:05 -0800

Erblichs,
The reason that the existing timers have been kept in
O(secs) is to avoid any instability which may be
introduced due to transient perturbations inside the
network. If you go and change these timers rightaway
then obviously there will be a lot of problems
introduced. How we can deal with them is an issue by
itself though!

BTW has there been any work done on changing these
timers to milli-secs and studying OSPF's behaviour?

I guess its time the OSPF WG charter did something
about it !!!

Rohit
>         hopefully follows the reasoning that was

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/

---

From: mukul goyal <[email-masked]>
Date: Tue, 25 Feb 2003 07:38:17 -0500

We have studied the impact on OSPF (fast failure detection versus
number of false alarms) of reducing the Hello Interval to lower values.
This is a simulation based analysis performed on a number of IP
backbone topologies. The paper will be published in ICC 2003. Here is a
link to one draft of the paper:

http://www.cis.ohio-state.edu/~mukul/icc.pdf

Thanks,
Mukul

---

From: Yasuhiro Ohara <[email-masked]>
Date: Wed, 26 Feb 2003 05:05:28 +0900

> introduced. How we can deal with them is an issue by

Hi, my take is that the concepts 'millisecond convergence' and
'stability and robustness' are somewhat opposite things in terms
of implementation. We have to receive all the up/down events
irrelevant of its interval, and then have to calculate
how it affects the stability of network.

But I believe we have to achieve both concepts at the same time,
at least some day. To achieve this, fixed-timer is not enough
I guess, and I'm wondering if the fixed-timer exists now is
adequate... Do we allow the flaps if it's interval is more than
(say) 5 sec ?

Wondering if this's informational, and sorry for duplication ;p)
but

We have studied the relationship between fixed-timer protocol feature
(MinLSInterval, MinLSArrival) and the route flaps.

The copy of our paper can be retrieved at:
http://www.sfc.wide.ad.jp/~yasu/saint2003.pdf
Manav and I submitted the paper to the workshop of Saint2003.

The paper is efficient in that the new correlation between OSPF protocol
and convergence property was found. I agree that we all knew the fact
that fixed-timer can affect adversely to convergence, but I guess
we did not know how bad the effect is, at least in the way that
we described in our paper.

The paper is short in that the situation is rare in reality.
The configuration of experiment is not like the real network.
And the assumption that our paper implicitly has, which is
"There should be multiple paths to the identical destination",
may be wrong.

regards,
yasu

From: Rohit Gupta <[email-masked]>
Subject: Re: Subsecond hello and dead rtr timer support in v2/v3
Date: Tue, 25 Feb 2003 04:12:05 -0800

---

From: Erblichs <[email-masked]>
Date: Tue, 25 Feb 2003 18:20:12 -0800

Rohit,

        I am extremely familair with the tradeoffs.

        Simply said, I would like to remove even
        a few seconds loss of convergence dealing
        with 1Gb or faster links, if I am able to
        minimize the negative consequences.

        On systems with 5 or 6 '9s reliability
        requirements, even a 1 second hello and
        a 3 sec dead rtr interval doesn't cut it..

        The only way I can understand to really
        do this is to create a new sub-sec heartbeat
        packet type while keeping the standard
        hello packet. This newer packet could be
        effectively empty to minimze size and
        processing requirements.

        Legacy systems could just ignore this
        newer packet type.

        Then the systems that support this packet
        type could set an internal bit and track
        that they are repeatedly seen and use
        this as a true heart-beat.

        Mitchell Erblich
        Sr. Software Engineer

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 26 Feb 2003 08:39:35 +0100

>        I am extremely familair with the tradeoffs.
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
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.

    thanks

    - tony

---

From: Yasuhiro Ohara <[email-masked]>
Date: Wed, 26 Feb 2003 17:48:11 +0900

Hi.

> 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.

> 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: Tony Przygienda <[email-masked]>
Date: Wed, 26 Feb 2003 10:33:42 +0100

Yasuhiro Ohara wrote:

>I don't think that this is best solved by a link-layer.
>
of course you're entitled to your opinios as I am to mine. I don't
insist link-layer as in
MAC is necessary the absolute solution but e.g. the new Kireeti draft or
LMP or things
that Russ was showing for ethernet recently could be a possibility. I'm
saying OSPF
hellos are not the way to achieve what you all seem to desperately seek.

> Who do you mean
read the archives of OSPF/IS-IS groups and meeting minutes of
presentations, e.g.
by Cengiz. And the 'objections' raised on OSPF ML were raised not by
people that have
significant experience in large scale deployments of OSPF (at least to
my knowledge).

>Why do you think L3 scheme is heavy ?
>
Because I did it couple times on different processors/different
operating systems with different
link-speeds and amounts of memory (probably going 10-1000x speedup and
size factor during the
years) and despite having done it smarter every time (of course,
there may be people who did it way better than me but those to step
forward then), millisecond
link-state timers with reasoanble numbers of adjacencies (dozens) with
reasonable load on
the control-plane don't work very well in real deployments. Let me give
you one example: if you generate every 100msecs a
hello for let's say 30 adjacencies, this is 300 hellos per second in
each direction and couple of
hundreds context switches (if running OSPF process). If you have an SPF
going, it means that
you either have to implement SPF in a way that does run concurrently to
the rest of OSPF,
doable but not trivial (pretty soon the locking overhead starts to slow
things down considerable
and code complexity goes up tremendously) or otherwise make sure that
your SPF gives up
every 30 msecs or so (to do the timering/helloeing well). Now, 30msecs
in control plane starts
to smell like trashing. So, you start to 'batch up' the hello processing
so you do many helloes in/out
every 300msecs for example. But then you defeat the purpose and have to
deal with interesting
quantization effects. Of course, you can put helloes 'exploded' on the
input/output blades but then
you need a synchronization mechanims to make sure OSPF on main
controller is not letting
'loose i/o blades' live in case it hick-ups. Which just shifts the
problem into another synchronization
domain (if you do it in OSPF< same problems, otherwise you just invented
a 'link-layer-box-internal-protocol'
which is what I argue for in first case ;-).
And so on ...  Now, what's the gain vs. e.g. using the light-out on the
fiber or some low-layer
keep-alive mechanism (e.g. LCP) to detect the link-down ? See what
interesting corner the RSVP
people painted themselves into by doing the fast-refreshes (before
recent hacks that basically grain up the
timer resolution for things to work) and RSVP guts are way simpler than
a working OSPF.

Arguably, if you consider just OSPF in separation on a discrete-event
simulator, probably with time-dilution,
things don't look that way but it is unfortunately not the real-product
world. So if you find someone to
pay for this research, you arguably 'won' and things arguably 'work' and
we can agree that we disagree on
what 'works' means.

    I rest my case

        -- tony

---

From: Erblichs <[email-masked]>
Date: Wed, 26 Feb 2003 01:50:17 -0800

Mukal,

        THANKS, got it and did a quick read of the paper..

        I disagree with the set-up, implimentation, and conclusion
        of the paper for the following reasons:

        1) A proper way to impliment a "sub-second hello interval"
           is really to suppliment the current second hello protocol
           with a "heartbeat packet".

           Why?
                A) It limits the size of the packet to basicly a
                   echo request / reply (ping) with a OSPF header.
                   Note: failure detection time includes the overhead
                        to process failure detection pkts.
                        (aka hello pkts).

                B) This removes the requirement to process the nbr
                   list within the hello pkt.

                B 1-n) Various chksums, authentications, could be
                       optional to reduce overhead processing and
                        prevent the heartbeat from possibly causing
                        congestion due to a hello that could be up
                        to a 9k size jumbo Ethernet frame.

                C) Legacy systems can ignore the new packet type code.

                D) Under extended congestion, the hello interval can
                   still be used.

                E) We are able to specify a rtr dead interval of 4* that
                   would not be a multiple of second units. The suggested
                   values could be anywhere from 1 to 999 millisecs. This
                   in effect is the transmit interval of the heartbeat pkt.

                F) If our router clocks are synchronized (have the same
                   times), then we are able to identify the latency of
                   the media or whether collisions are occuring within
                   the media and rexmit backoff algorithms need finer
                   granularity, by including a timestamp within the pkt
                   ; ala ping..

        2) Related work. The heartbeat packet can be queued and processed
           independently.

           Why? At "dead interval time frames", the quantity of incoming
           heartbeat packets can be noted and this number of packets
           processed. Any normally speaking heartbeat rtr that hasn't
           sent a heartbeat pkt, could minimally be noted as undergoing
           some form of congestion and longer RxmitIntervals involving
           this rtr could be employed. If we share information with other
           protocols (BGP) we may have an alternative route to temporarily
           decrease the number of pkts transiting this congested rtr.

        3) If our time to process a SPF calcualtion for a LSA quantity
           is a fraction of a second, there is no need to support
           multiple sec spfDelays and spfHoldTimes.

        4) Assuming the the #3 above spf times are kept with their
           secs default values, if a false alarm occurs within
           the spfHoldTime, and then clears, resulting in a non-
           delta change. Then  no additional spf calculation will occur.
           Actually, during the spfHoldTime, nbrs could be marked
           as questionable and processed as dead nbrs, only if
           a heartbeat isn't seen.

        5) The hello interval and heartbeat is on a per link / circuit
           and should
           only be set to sub-second values with known trusted,
           normally highly reliable systems.
           These systems by default are less likely to be overcome by
           congestion. I am assming here that heartbeats control adj
           teardowns.

        6) Lastly for this short email..
           The existance of sub-second heartbeat informs destination systems
           that it is still up and it is not congested... Thus, loss of one
           or more heartbeats is an indication of some issue within the system
           that can be tracked and responded to, possibly even before
congestion
           occurs..

        7) Depending on the repetive nature of lossed heartbeats, adj's could
           still be marked up (we are still recieving at least 1 hello per
           rtrdeadinterval) but in a degraded state...

        Mitchell Erblich
        Sr Network Software Engineer

=============
=============

---

From: Manav Bhatia <[email-masked]>
Date: Wed, 26 Feb 2003 16:09:47 +0530

I believe this thread was initiated in an effort to realize sub-second
convergence or milli-secs convergence for OSPF (this could apply easily to
IS-IS also!). Current standards call for implementations to support these
timers in O(secs). With the ISPs requirements for SLAs increasing
aggressively and the current paranoia people have for faster convergence a
lot of people think that there should be something done at the IGP level.

MinLSUpdate/MinLSArrival/etc timers restrict your convergence timings and
people are basically looking for different ways to over come these
problems. One is of reducing these to O(ms). Everybody is aware of the
problems this could bring in (i will not rehash them here in the list!) and
people are trying to look for solutions. Obviously when you bring down
these timers to O(ms) we cant just leave the Hello interval hanging in mid
air with granularity in secs. This too comes down to O(ms).

Now we need to look into how we can mitigate the ill effects of doing this.

Nobody is saying that you just bring down your HELLO to O(ms). What we need
to remember is that we are trying to bring down all the timers to this fine
granularity! How we need to schedule SPF is a different issue though!

Am open to flames! :-)

Regards,
Manav

P.S.
I personally feel that there is a lot more that can be done in hardware to
bring down our convergence timings before we start tinkering around with
the IGPs. But that shouldn't put somebody on hold if he/she wants to do
something at L3!!

----- Original Message -----
From: "Tom Petch" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, February 26, 2003 3:06 PM
Subject: Re: Subsecond hello and dead rtr timer support in v2/v3

> 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

---

From: mukul goyal <[email-masked]>
Date: Wed, 26 Feb 2003 06:56:10 -0500

Mitchell,

The paper in question basically says that reducing the HelloInterval
arbitrarily to very small values can have significant destabilizing impact
on the OSPF operation in the network. Missed Hellos will translate into
false breakdowns of adjancencies which along with
subsequent reestablishment of the adjacencies increases the OSPF
processing loads, possibly cause unnecessary SPFs and even lead to
catastrophic situations in some cases. The conclusion of the paper is
that the HelloInterval can usually be reduced to a much smaller value
than 10s, however, an appropriate value for a particular network depends
on a number of factors including the size of the network (i.e. area) and
the expected congestion levels on the links.

>         of the paper for the following reasons:

Please be more specific regarding exactly what are the things you disagree with.

>            with a "heartbeat packet".

Could you send me a reference for the "second hello protocol" you are
talking about?

>                 C) Legacy systems can ignore the new packet type code.

OK. The "heartbeat" may have a lower processing time than that of a
typical LSA. However, my impression (based on the OSPF black box
measurement work of Aman Shaikh) is that the per-packet handling times
constitute the major portion of the total processing times. I am not sure
if not doing the authentications etc. will cause any security concerns. In
any case, the heartbeat/Hello processing time is not the real issue.

The issue is : As we reduce the hello/heartbeat interval, there is an
increased probability that several consecutive heartbeats will be lost due
to a congestion on the link or the router will not be able to process a
heartbeat before the expiry of the routerdeadinterval (which will also
decrease alongwith the HelloInterval).

> >                 D) Under extended congestion, the hello interval can

?? Please clarify.

>                    in effect is the transmit interval of the heartbeat pkt.

If I understand it correctly, you are saying that the router dead interval
can be assigned values in the millisecond range based on the heartbeat
interval (4 times heartbeat interval). I am not clear how does it
influence the problem I mentioned earlier.

>            decrease the number of pkts transiting this congested rtr.

How will the heartbeats avoid getting queued behind a whole lot of other
packets or getting dropped because of buffer overflows before the router
has a chance to know that these are heartbeats?

Adjusting the timer values according to the congestion level will
definitely make subsecond hellos more acceptable provided that we can
achieve a very mature understanding of how this adjustment should be done.
I think there are several concerns in this regard.

>            multiple sec spfDelays and spfHoldTimes.

My understanding is that a major stability related concern is to keep the
OSPF processing load within limits. Even if SPF does not take as much
time as it used to take earlier, SPF will be a concern especially for large
areas. I think spfDelay and spfHoldTime are important for stability. They
may be significantly reduced but perhaps should not be eliminated
altogether. However, this is a complete problem in itself which needs to
be treated separately for now.

The bottomline is that there will be one situation or the
other where the router will be busy doing other things and won't be able
to attend to millisecond Hellos or heartbeats in time to avoid false
alarms.

>            as questionable and processed as dead nbrs, only if

One of the potentially several reasons why we need large
enough spfHoldTime. I do talk about this in the paper.

>            congestion. I am assming here that heartbeats control adj

Here, you seem to be agreeing with me that congestion should be a factor
in deciding the HelloInterval to be used on the link.

>            that can be tracked and responded to, possibly even before

Fine. No arguments here. Loss of occasional heartbeat/Hello is not a
problem. The problem is, I repeat, that as you increase the
heartbeat/Hello frequency and (hence) reduce the routerdeadinterval,
there is an increasing likelihood that multiple hearbeats will be dropped
or won't get timely processing thus causing frequent false alarms.

>            rtrdeadinterval) but in a degraded state...

OK.

My overall impression is that you are simply calling a subsecond Hello as
a heartbeat. This does not change the basic concerns about the
possibilities of false alarms.

Mukul Goyal

---

From: Yasuhiro Ohara <[email-masked]>
Date: Wed, 26 Feb 2003 21:28:07 +0900

Hi.

First thank you for your valuable message. I feel I saw a lot of
things from this and I guess I understand your opinion more or less.
I admit I'm less experienced, but I'm not convinced yet.

First of my consideration is that if we made L2 detection available,
the failure detected by L2 only will be sufficient at millisecond
level ? I don't know how many percent of failure occuring
in the real world can be detected by L2 only. If some failures which
can be detected only by L3 exist (sure I believe those exist), then
L3 detection at millisecond level will be necessary anyway, isn't it ?
It is obvious that if we detect failure by L3 at millisecond level,
we'll be able to find all the failure in subsecond. If we fails
to detect some of the failure, we get not so robust network.

Second is about the control traffic load of Hello. In your example of
100ms hello interval on 30 adjacencies, the load will be 403.2Kbps,
even with calculating standard OSPF hello format (which may be somewhat
redundant). I guess this cost is worthy to pay, in order to get
robust and fast convergence network.

I agree the context switching and scheduling of OSPF tasks will be
a consideration. But is it already achieved by vendor hardware routers ?
I think it more easy way such as "install CPUs as many as necessary",
because I'm not hardware engineer ;p) sorry.

I don't understand the synchronization problem you're saying.
I understand that the control-plane only won't be able to handle
huge number of Hellos by itself. I will want "Hello-dedicated Blade"
or something. But what is the problem with notifying from
hello-dedicated-blade to control-plane, apart from the similar one
happens when notifying from L2-detection-box/blade
to OSPF router/process ? Is there any particular problem that L3 detection
will have but L2 detection will not have, without restricting
how they implemented ? Am I totally missing the point ?

I will learn about how RSVP and other L2 detection works.
I agree L2 detection will be more light and faster than L3.
But what we need is L3 failure detection, and it can only be acheived
completely by L3 detection. I guess we should take millisecond level
L3 detection rather than nanosecond level L2 detection.

regards,
yasu

From: Tony Przygienda <[email-masked]>
Subject: Re: Subsecond hello and dead rtr timer support in v2/v3
Date: Wed, 26 Feb 2003 10:33:42 +0100

---

From: alok <[email-masked]>
Date: Wed, 26 Feb 2003 18:13:24 +0530

pardon my interrupting,

from a lay man's perspective my 1 cent's worth...

> to detect some of the failure, we get not so robust network.

for L2 detection....
i have some questions...
how long is it that when an interface goes down, does the kernel report it?
is it instantaneous? i mean i lost clock for a microsec and i came back up..
does it filter up immediately?or is there "a delay" to see if its really
down there too?
if it is instantaneous, could the routing daemon "lag" this by as many
seconds rather than send out packets to test it?

> robust and fast convergence network.

?????????? err no, ISPs are usually not that accomodating in the developer's
favour :-)
> how they implemented ? Am I totally missing the point ?

choking up the bandwidth is a good point (are u saying those hellos are out
of band)?
> L3 detection rather than nanosecond level L2 detection.

fine i need faster hellos on BMA networks.
why? coz there is multicast happening, the only way i know that a router is
out is either if "the arp is out and doesnt come back in" or i miss hellos
and there we have "sufficent bandwidth" coz i assume BMA is primarily
ethernet...and no one runs ospf on "extended lans" via media convertors...i
hope (hell if u have a router put in a serial link)
but on P2P, line protocol/PPP down is a good enuf bet to imply the other end
is down. why do we need L3 there?

---

From: Yasuhiro Ohara <[email-masked]>
Date: Wed, 26 Feb 2003 22:36:02 +0900

> seconds rather than send out packets to test it?

I don't know how they intend to do but some kind of flap damping
technology as in BGP route flap damping will be necessary, at L2 level.

> ?????????? err no, ISPs are usually not that accomodating in the developer's

agreed ;p)

> choking up the bandwidth is a good point

do you mean the router's backplane by "bandwidth" ?

> (are u saying those hellos are out of band)?

I mean Hello calculation must not necessarily be done
on control-plane. Hello packet will be on the band, as far as I said.
and yes, 400K may be too much.

But, the size 400K is not caused by the fact that it's on L3,
it's caused by the fact that I calculated without changing
standard Hello packet.

If we make sufficient L2 detection, we need some kind of packet format,
which includes some kind of identifier, etc. Obviously detecting the
electricity is not enough, because we cascades many LAN switches.

> and there we have "sufficent bandwidth" coz i assume BMA is primarily ethernet...

you mean most of your failures are L2, isn't it ? that's OK.
but how much you have sufficient bandwidth ?
don't you have extra 400K bandwidth ? ;p)

> and no one runs ospf on "extended lans" via media convertors...i

- L2 detection is not so better than L3 detection,
  if both made by hardware
- L3 detection is (thought you're saying none) a little bit better
  than L2 deteciton
- you must develop a detection method for each of L2 technology
  (again I don't believe electricity checking is not enough)

regards,
yasu

---

From: alok <[email-masked]>
Date: Wed, 26 Feb 2003 19:45:11 +0530

> > and there we have "sufficent bandwidth" coz i assume BMA is primarily
ethernet...
> don't you have extra 400K bandwidth ? ;p)

i meant ethernet doesnt cost me money but wan links do.
i can do L3 on ethernet..... for that matter that 400k is fine there (with
the old hellos and reduced timers)

u can reduce the size of those hellos on L3 for WAN stuff...my only doubt is
if it is required on WAN links.
-rgds
Alok
serial is up line protocol is down.

---

From: Erblichs <[email-masked]>
Date: Thu, 27 Feb 2003 03:53:12 -0800

Mukul,

        I'll try to keep this short because a test of mine just finished at
        3:30am.

        I have yet to see a low end system that I work on that is not designed
        to accept a slow path ping packet at the rate that would be in excess
        of 300 per sec.

        I think the amount of overhead need to process a hello with a nbr list
        of say 100+ nbrs could be overwhelming. However, since I consider this
        type of information less likely to change we don't need to tell someone
        about our view of our neighbors more than the current hello default
        interval. Decreasing the size of the packet reduces bandwidth
requirements
        and only adds a bit to the packet per second processing overhead
needed.
        I saw a 2+yr old doc that stated high end rtrs with pps speeds in the
        the millions dealing with 40byte short packets. This is a Spirent doc.

        A 1 to 4 ratio or hello to rtr dead interval isn't needed when you
        run with a subsecond heartbeat. Think of the heartbeat like a ping.
        I would think that 100ms heartbeat interval with a 1 sec dead rtr
        interval should be a conserative starting value. I am investigating
        100x ratios (10ms for the deadbeat, and 1sec for the congestion timer)
        with my at home network setup starting today.

        Thus a loss of one or two should not result in the loss of an adj/nbr
        state.

        Since we could use a monotonically increasing sequence (see Juniper's
paper),
        and a local time field, then we could see if a heartbeat is delayed,
        lost, whatever.

        Now, since we still have a hello packet occuring, if we see that
someones
         heartbeat is eratic, we can slow down our exhange process with him,
flood
        him with fewer updates at a time, etc.

        And then mark him as CONGESTED or transient down until our 40 sec dead
interval
         has occurred. While we are waiting for the default dead interval to
occur
        we could then follow one or more of the suggested
        operations in a earlier RFC draft that concentrated on congestion.

        And could you send me a pointer to the Aman Shaikh black box rtr paper
for
        me to understand his slow path pps issues.

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

---

From: Erblichs <[email-masked]>
Date: Thu, 27 Feb 2003 04:13:53 -0800

What 400k...

What is 64byte size packet times 300 packets per sec.
I think its 19.2KB. Thats 19,200 bytes per second.<------
Does anybody have a problem with this extra consumption
bandwidth??? If you have just 1 sec from determining
that a rtr is down with a 1Gb link, you save yourself
100+ million bytes...

and there is a chance that you can save 10 secs worth
of data . Thats 1 billion bytes..

Why do you want the full hello packet in the sub-second
interval? Make it simple and small that their is
minimal overhead to process the packet and doesn't
use bandwidth..

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

---

From: alok <[email-masked]>
Date: Thu, 27 Feb 2003 18:14:07 +0530

read my next mail on the list...
i said yes, you can make is smaller...
and u do need it on ethernet
my question was if it is needed on P2P.......
192000*8 bites per sec == 1536000 bps (bandwidth is measured in bits i
presume)
19.2kbytesps every one second is quite a bit
its 1536,000bitsper sec :-)

---

From: alok <[email-masked]>
Date: Thu, 27 Feb 2003 18:27:12 +0530

okie knock off one zero >:o)

----- Original Message -----
From: alok <[email-masked]>
To: <[email-masked]>
Sent: Thursday, February 27, 2003 6:14 PM
Subject: Re: Subsecond hello and dead rtr timer support in v2/v3

> > > how long is it that when an interface goes down, does the kernel
report
> it?
> > > is it instantaneous? i mean i lost clock for a microsec and i came
back
> up..
> > > > a consideration. But is it already achieved by vendor hardware
routers
> ?
> > > choking up the bandwidth is a good point (are u saying those hellos
are
> out
> > > why? coz there is multicast happening, the only way i know that a
router
> is
> > > but on P2P, line protocol/PPP down is a good enuf bet to imply the
other
> end

---

From: Yasuhiro Ohara <[email-masked]>
Date: Thu, 27 Feb 2003 23:32:39 +0900

I did something shameful !! (@_@)
I missed my calculation, but not that way you're saying.

> bandwidth??? If you have just 1 sec from determining

I was talking about the case of standard Hello packets.

44 (byte) + 29 (nbr) * 4 (byte) = 160 (byte) # OSPF Hello size
160 (byte) * 30 (nbr) * 10 (times/sec) = 48000 (byte/sec)
48000 * 8 = 384000 (bit/sec)

 384K bps

Precisely, not 403.2Kbps, 384K bit/sec is correct.
384K bps = 48K Bps (byte/sec).

Not so that big mistake to affect that we've discussed.

> of data . Thats 1 billion bytes..

I agree here.

> minimal overhead to process the packet and doesn't

The fact that you can receive from router Ra does not mean
that you can talk to Ra. This is why OSPF lists its neighbors.

(not to Erblich)
One says "L2 detection is enough for me" that's fine but
it's not applicable to whole internet users. There surely exist
cases where L2 reachable but L3 unreachable.

regards,
yasu

---

From: alok <[email-masked]>
Date: Thu, 27 Feb 2003 20:07:27 +0530

> cases where L2 reachable but L3 unreachable.

where on P2P???

ospfd going down?

---

From: Yasuhiro Ohara <[email-masked]>
Date: Thu, 27 Feb 2003 23:49:16 +0900

> ospfd going down?

YES ! ;p)

regards,
yasu

---

From: alok <[email-masked]>
Date: Thu, 27 Feb 2003 20:27:28 +0530

----- Original Message -----
From: Yasuhiro Ohara <[email-masked]>
To: <[email-masked]>
Sent: Thursday, February 27, 2003 8:19 PM
Subject: Re: Subsecond hello and dead rtr timer support in v2/v3

> YES ! ;p)

but the router is still up :-o so routing will be fine and mebbe ospfd will
come in routerdeadinterval....like "switching REs/RSMs"...........

we just did a lot of stuff on this list to reduce LSAs and hellos and get in
triggered updates and now u want to add more hellos?

what are we trying here?

look fine, u wanna do it, go ahead..the point is that if someone doesnt
support it, he is justified and these will be his arguments..

153Kbps is the overhead i get from Mitchell Erblich's example

sounds bad on 2Mb links

fine his figures were off (so were my zeros :-D)..but why are u undoing the
whole thing?

what is wrong with L2 detection..? L3 is fine on BMA...thats all i can
see....

---

From: Yasuhiro Ohara <[email-masked]>
Date: Fri, 28 Feb 2003 00:22:21 +0900

> come in routerdeadinterval....like "switching REs/RSMs"...........

This is what we call blackhole. The routing will not be fine.
Don't forward packets to the router suppose to run OSPF but does not.
"maybe" may be "may not be" ...

regards,
yasu

---

From: alok <[email-masked]>
Date: Thu, 27 Feb 2003 21:32:48 +0530

> "maybe" may be "may not be" ...

then lets not support "graceful restart" . coz its equally "grey"

as long as the node is up and the FT is switching packets...whats the
problem?

---

From: Manav Bhatia <[email-masked]>
Date: Fri, 28 Feb 2003 08:46:15 +0530

> then lets not support "graceful restart" . coz its equally "grey"

I believe there is a subtle difference there. When you support graceful
restart you ensure that your FIB stays up even if your control plane is
down and hence you keeping forwarding your packets to that router even
though you know that his OSPF is down.

But we cannot always assume that the FIB will remain updated when OSPF goes
down and hence you need to check at the L3 too!

> as long as the node is up and the FT is switching packets...whats the

No problem .. but you need to ensure that!

---

From: vishal <[email-masked]>
Date: Thu, 27 Feb 2003 21:24:13 -0800

Guys,

    How about experimenting with a MilliOSPF implementation first ( like
S-BGP.) Modify some
existing OSPF implementation, run some tests on it and then publish the
results.
If the results are impressive, I am sure other people will follow you
footsteps.

-Vishal  

-------Original Message-------

From: Mailing List
Date: Thursday, February 27, 2003 07:17:30 PM
To: [email-masked]
Subject: Re: Subsecond hello and dead rtr timer support in v2/v3