Subject: Sending new LSA

From: Attila Nohl <[email-masked]>
Date: Tue, 4 Jun 2002 17:06:09 +0200

Hello!

I have question about originating new LSAs. Let's say that the status of
a router's interface changes. In this case, the router creates a new
Router LSA, replaces its own Router LSA in its LSA database and sends the
new LSA to its neighbours. My questions are:

- When the LSA is replaced in the LSA database, does the router run an SPF
  calculation (because the LSA database has changed)? I think, if the
  interface is towards a transit network, then the router must run the
  SPF calculation, but what happens in case of interfaces towards stub
  networks?

- If the router runs an SPF calculation, which happens sooner? The sending
  of the LSA to the neighbours or the SPF calculation?

                                Bye,NAR

---

From: Anton Smirnov <[email-masked]>
Date: Tue, 4 Jun 2002 21:15:38 +0200

Attila,
   you can schedule full SPF whenever your own router LSA changes to be on
the safe side. But apparently implementation may try to optimize SPF
algorithm - including complete elimination of SPF run - if this doesn't
produce discrepancy with standardized behavior.
   It makes very good sense to schedule SPF based on interface+neighbor
state change rather than on only interface up or down change. If router
doesn't have any neighbors on local interface then full SPF likely to bring
no changes in the routing table (though some implementation may require it
for some reason)
   If you strictly follow standard timers then router always sends LSA
before running SPF (at least if SPF was triggered by change in this LSA, not
by another LSA some seconds earlier). In theory, I could imagine that
well-designed implementation sends LSA "at the very same time" as SPF is
running.
   But, generally speaking, if you run SPF first then flood then changes in
routing tables throughout OSPF domain will look more like in distance-vector
protocols. Remember that SPF run is relatively slow process. Not a nice
thing you could expect from link state protocol, right? Such timers
configuration better be avoided.

Anton

---

From: Erblichs <[email-masked]>
Date: Sat, 15 Jun 2002 01:17:29 -0700

Just a few late remarks..

First, it would be nice for the router to identify the
time it takes to run a FULL SPF  and not schedule more than
1 in that time frame.. This should be dynamic as the size
of the LSDB and time it takes for the SPF changes.

In my experience, once you recieve a LSA that should cause a
SPF calculation, there is a high chance that another LSA
isn't far behind... (buyer beware) It may make sense to support
a short duration wait timer before the next SPF is done...

If a OSPF router is over-loaded with LSAs, it may make sense
to pospone SPF.

Disjoint router groups may allow sub-SPF type calculations.

When a OSPF interface is enabled, it may make sense to have
a larger than normal delay before the SPF is run..

All LSAs are not considered equal and some may not require
a SPF..

The loss of neighbors and or down interfaces does not necessarily
need a new SPF. This assumes that your SPF code has extra smarts..

....

Inter-area OSPF routes are distance-vector calculations.... and
are not SPF calculations like it's link-state cousin, IS-IS.

Mitchell Erblich

---

From: Amit Srivastava <[email-masked]>
Date: Tue, 18 Jun 2002 04:55:54 -0700

Hi All,
   I have the doubt which is described below:-
Suppose a router is there whose database is full.Now
it can send and receive hello packets but discards any
new LSA coming to it(as database is full) and hence it
will not ack that LSA.Now my doubt is that RFC 2328
says the the retransmission will continue till the
adjacency is broken.
    Does that mean if the database does not have space
for accomodating the new LSA infinite number of
retransmission would result???
Regards
Amit

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com