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

From: Paul Jak <[email-masked]>
Date: Wed, 26 Feb 2003 03:20:38 GMT

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

very true ..

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

Infact now that you have brought this out let me also sound
in my concerns. I have always been wondering as to how we
arrived at this sacrosanct figure of 5 secs (MinLSUpdate
Interval) for damping any up/down events. The reason i
belive it was decided upon this was coz the CPUs in those
times were not fast enough and if you had an entity changing
@ < 5secs .. you could crash your system with the heavy
processing load you would incur by running the SPF each
time.

I believe things have changed now and if we truly want
millisecs convergence then we need to do away with these
timers. I found your logic (in your paper) quite good and i
think it looks like the only feasible solution wherein if
there is an entity which changes too rapidly (wherein the
value of "too rapidly" could mean differently to different
people) then you somehow suppress that !

But why do you only look for AS-External-LSAs being
suppresses. Could this logic not be extended to Router LSAs
and other LSAs too? Or has this been kept for future work?

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

you do have a lot of redundant links in a network so it isnt
sooo rare!

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

Again .. if you have redundant links then you would have
multiple paths to an identical destination with one having a
better cost than the other one so that its always the
preffered one.

I think its time that the OSPF ADs look up and draw
something in the charter which says something about doing
something in OSPF for millisecs convergence! I see a lot of
papers coming up on the same but they somehow get lost and
nobody seems to know of what happens to them!

Just my two cents.

Paul

_____________________________________________________________________
// free anonymous email || forums \\ subZINE || anonymous browsing
            subDIMENSION -- http://www.subdimension.com

---

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

> and other LSAs too? Or has this been kept for future work?

It has just been kept for the future work ;p)

About the origination and acceptance of LSA, Router-LSAs are not
an exception. But the flapping of LSA existense for the same
Router-LSA/Network-LSA will be done by the granularity of HelloInterval
(typically 10 sec), because those includes establishing of adjacencies.
I thought that the case Router-LSA or Network-LSA flaps by the rate of
subsecond, is more rare case than that case of AS-External-LSA
(because origination/flushing of AS-External-LSA can be triggered by
L2 link up/down, which is likely to be subsecond).

Obviously if we make HelloInterval milliseconds,
it is possible that Router-LSA flaps in a second.

> better cost than the other one so that its always the

Agreed, but I meant that it is rare where multiple routers originate
LSAs for the same routes. Changing path to a certain link
     -------------------
is another scenario, similar to the Router-LSA case described above.

regards,
yasu

---

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

Adding a little more to what Yasu has already said.

> It has just been kept for the future work ;p)

This paper in its current state is very generic and takes only an example
of an AS-External-LSA which is flapping, but the same techniques can
definitely be applied on a Router LSAs/etc. One could also apply damping in
cases where there are lost HELLOs because of say, congestion in the
link/Overloaded Router. If a router finds that it is periodically timing
out HELLOs from one particular router then it can choose to damp that
adjaceny. It can start accepting the HELLOs once it finds that the
link/Router has now somewhat stablized.

These extensions really come into play once when we start envisaging a
network will timers of milli-secs granularities/etc.

Regards,
Manav

---

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

Bhatia,

        I need to think about this, but do you
        only hold back originated LSAs or
        transit LSAs into an area that only
        has a single edge rtr?

        If the route specified is the only
        route to a specified set of network
        segments, then what is the negative
        effect of advertising this flapping
        route?

        If the route isn't advertised, then
        the network segments are blackholed?

        If the route is advertised and the route
        is really unreachable, then the
        transit network segments are consuming
        wasted bandwidth. The packets will
        eventually be dropped anyway.

        If the route is advertised and the route
        flaps back positive, it will take some
        time longer than 1/2 of a hello interval
        once a SPF algorithm removed the route,
        plus your penalty, plus a new SPF run,
        plus flooding time..

        Thus, if there isn't an alternative route
        THEN maybe just ignore the lost of the
        route... Stub areas and stub routes may
        not want to use the penalty.

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

---

From: Manav Bhatia <[email-masked]>
Date: Thu, 27 Feb 2003 17:18:03 +0530

Erblichs,
Thanks for the comments.

If you understand the basic philosophy behind the whole thing then most of
these questions are answered by themselves!

The understanding is that if an entity is flapping then
- you waste cycles running SPF with each flap which can in turn can result
in more adjacencies breaking and which may (in the worst case) lead to a
total network meltdown.
- you waste your bandwidth (no need to explain!)
- it (the flapping entity) must pay a price for this! It pays in a sense
because we don't use it as long as we gain enough confidence in it that it
is now going to function properly!

Now i will get on to your specific questions ..

>         transit LSAs into an area that only

Currently we are only looking into the self originated ones and i *think*
we should only be doing this for the self originated ones or we can have
some scenarios of inconsistent database.

>         effect of advertising this flapping

you mean what happens currently .. right? we advertise a flapping entity.

well to begin with you waste your bandwidth, clog your processors/etc.
Things begin to get a little complicated when these IGP derived routes are
being used by BGP to recursively resolve the next-hops. Things can really
get very nasty if you are running BGP with thousands of routes and if it is
using those OSPF resolved next-hops. Moreover it can get worse if an ISP is
using its IGP costs to advertise as its MED!

>         the network segments are blackholed?

This is one price which a flapping entity *has* to pay! It is given enough
opportunities to correct itself (depends upon how the damping parameters
are configured!) and if it still doesnt do anything about it then yes ..
routes will not be advertised even though its up!

>         flaps back positive, it will take some

what is "flaps back positive"? you mean it "flaps" ?

>         plus your penalty, plus a new SPF run,

i couldnt get what you mean by this.

>         not want to use the penalty.

we need to explore on this.

Regards,
Manav