Subject: Re: Selection of router id. And behaviour with IPv4 address removal.

From: Erblichs <[email-masked]>
Date: Mon, 13 Feb 2006 12:55:46 -0800

Group,

	I just wanted to add something to this 1/2 old month
	thread.

	There are a few implementations that take into account
	the number of LSAs in a database against a configurable
	limit. Even though flushing old LSAs is not architectually
	specified, here is one case where it is prudent.

	Old LSAs, aka stale LSAs consume memory and CPU cycles
	to at least age them (exception of the DNA 0x8000 bit).

	Due to downward memory scalability, stale LSAs may
	consume memory for up to 1 hr. However, to prevent a
	LSDB from consuming all of a router's memory, some
	implementations support a "max-lsa" type CLI command
	that limits this amount of memory and depending on the
	freq of hitting this limit, a router may be suspended
	until another CLI command is manually entered.

	Thus, if router is aware of his environment and stale
	LSAs may be a issue, it is prudent IMO, to re-originate
	LSAs one's own LSAs that they are to be flushed.

	In addition,, one needs to be able to actively flush
	nbrs LSAs for stale LSAs if this limit is set
	and reached (or close to being reached).

	Or accept that this limit has prevented from synchronizing
	the LSDB, and suspend oneself.

	Mitchell Erblich
	--------------------

Dave Katz wrote:
> 
> My point was only that flushing the LSAs is not necessary for
> correctness, as the protocol must be robust against this sort of
> thing.  Whether or not it is a good idea, or easy, or hard, is an
> issue for the implementer.  There are certainly some cases where it
> is not possible or at least not reasonable (the router ID changing
> during a reboot, which can happen for secondary reasons.)
> 
> On Jan 29, 2006, at 11:30 PM, Erblichs wrote:
> 
> >
> >
> >       So the bottom line, IMO, if we broke the suggested 30 min
> >       re-originate interval and do it every 50 mins, and 48 mins
> >       have passed, I would elect to allow "independent flushing"
> >       to occur in 12 mins.
> 
> I "broke" this in 1997;  the 30 minute refresh interval is stupid.  I
> did turn up really egregious bugs in a couple of other
> implementations this way, so whether I was also stupid is open for
> debate.
> 
> >
> >       And if we are close to a group determined LSDB Overload,
> >       and 55 mins is due to the LSA being aged out, I would elect
> >       to do "demand MAXAGE flushing". Yes, DNA LSAs also fit here.
> >
> >       Anywhere in between is dependent on whether we are in
> >       a stub area and memory is IMPORTANT or..
> >
> >       In between, I tend to lean towards "demand MAXAGE flushing"
> >       to remove unnecessary periodic work.
> >
> 
> We're free to implement this as we wish, as it is not and cannot be
> subject to standardization.  There is also a cost to complexity
> (bloat and bugs) and being squeaky clean about these things need to
> be weighed against the obvious and more subtle costs of doing so.
> 
> Let's put it this way--if your implementation can withstand the
> occasional (and seemingly inevitable, based on history)
> misconfiguration when full routing gets dumped into OSPF, the
> negligible loads of aging extra LSAs will not make you break a sweat.

---

From: Dave Katz <[email-masked]>
Date: Mon, 13 Feb 2006 13:12:53 -0800

> 	specified, here is one case where it is prudent.

This is reasonable if you're trying to protect against the all- 
Internet-routes-dumped-into-OSPF misconfiguration case, but if your  
limit is not significantly larger (some multiple) than the steady- 
state LSA load, you've already lost.  If your network can break  
because you've changed a router ID and the LSAs weren't flushed, you  
probably shouldn't be running a network.

> 	to at least age them (exception of the DNA 0x8000 bit).

It is unnecessary to use any CPU at all to age LSAs (except when they  
finally expire), but that's an implementation nit.

> 	LSAs one's own LSAs that they are to be flushed.

Like I said, you can't rely on this.  It may be helpful and friendly,  
but you can't rely on it.

> 	and reached (or close to being reached).

This is wildly dangerous and is a seriously bad idea.  It requires a  
definition of "stale" that cannot be satisfied in a distributed  
system, particularly one that is unstable (which is probably why  
you're trying to do this in the first place.)

--Dave

---

From: Erblichs <[email-masked]>
Date: Mon, 13 Feb 2006 14:23:13 -0800

One item,

	First, some routers have memory limitations!

	wow. Are you telling me that you can't identify link/local
	or area scope routers that have dropped out AND their
	associated LSAs? It is deduceable.

	Yes, we need to be aware of XYZ.. Sorry, group I am not
	going to give you all the nity grity details of how to
	do this.

	Yes, this doesn't keep the router up and functioning if
	the dump was a massive external LSA dump and the router
	is still active.

	My hope is that the router that did the LSA dump becomes
	aware of this issue first and solves this problem. It
	should see huge rexmit lists, etc.

	However, it does solve the problem if the cause is based
	on stale LSAs. Active flushing is only suggested WHEN
	passive/age flushing has either not kept track or..

	Either way, we either reduce our current number of LSAs in
	our LSDB or suspend. I would rather reduce if possible.

	since these are stale LSAs they have no effect on our
	routing and if nbr returns, it will re-originate its
	LSAs.

	As to an unstable .. that should be a different thread.

	Mitchell Erblich
	-----------------

---

From: Dave Katz <[email-masked]>
Date: Fri, 17 Feb 2006 09:43:21 -0800

I'll bloviate one more time and then let this drop.

> 	First, some routers have memory limitations!

Certainly.  But as I said, if they don't have a significant margin  
for LSA storage (well beyond what would be needed for the odd extra  
LSA) then they have already failed.  If nothing else, there are far  
more memory-intensive dynamic things in a router (a single installed  
route typically has much more overhead than an LSA.)  They are going  
to be hosed when you add a few more routers or a few more subnets.   
Routers that are *that* limited have no place in a production network.

If you accept this, then by definition the only time the memory  
situation should become critical is when something goes badly wrong  
(like dumping BGP into OSPF), which makes this optimization pointless.

> 	associated LSAs? It is deduceable.

Wow.  They cannot be positively identified.  The safety of a guess  
goes up with the time constant over which the absence is integrated,  
but then the purported value of doing so goes down.  You certainly  
can't just purge LSAs for router IDs to which nobody happens to be  
advertising adjacency at a particular instant (imagine the fun if the  
adjacency is flapping as you get into flooding wars with the real  
owner of the LSA.)

You can create heuristics to decide how long enough a router has to  
be missing (or on the other side of a partition) in order to clean up  
after it, but this is not for the faint of heart, and will have very  
ugly consequences if not done well.  It's not for nothing that the  
OSPF spec specifically bars premature aging of LSAs other than one's  
own.

Further, the complexity and risk is simply not worth it for the  
purported benefits, which I claim are essentially nonexistent in the  
real world.

Way too many years of scars have taught me that the failure modes in  
these protocols are endlessly fascinating and often surprising.  The  
early Cisco OSPF implementation had a bug (among many, and for the  
record, not written by me) in which it sent acknowledgements for  
received LSAs that were older than what was in the database rather  
than just dropping them.  The side effects are quite spectacular, but  
are not obvious (and certainly surprised me at the time.)

> 	should see huge rexmit lists, etc.

Hoping doesn't help.  There is an existence proof (roughly annually,  
starting with "AOL down for 19 hours" back in 1995) that this *does*  
happen and that the originating router *doesn't* care.  Most  
implementations have fail-safe code that will cause something  
reasonable to happen if too many LSAs are in the process of being  
originated, but this is difficult to have enabled by default, and is  
not always set by the operators.

Any implementation that expects to survive *must* expect that it will  
share the network with implementations that may not be well-mannered  
in many random ways.

> 	passive/age flushing has either not kept track or..

See above.  A few stale LSAs are *not* a "problem."  They may be a  
"nuisance" but are probably just "distasteful."  If they are a  
"problem" then the network has much larger Problems.

> 	our LSDB or suspend. I would rather reduce if possible.

I would rather be stable if possible.  Imagine the fun when each of  
2000 routers in the area decides simultaneously that the LSAs are  
stale and simultaneously flood MaxAge LSAs, and then the originating  
router reappears from its partition because of a flapping link, ad  
nauseum.  In the case where the database uses up all available memory  
(which one way or another is a human-induced disaster) suspending  
(and shutting up rather than adding to the disaster) is the only  
reasonable course.

Purging other routers' LSAs is just a bad idea.

This was learned early in the deployment of IS-IS.  The original IS- 
IS spec said to purge an LSP if it was received with a broken  
Fletcher checksum (in the theory that this could only occur if said  
LSP was corrupted in memory, since the links were error protected.)   
A very nice correctness mechanism, as it gets rid of the corrupted  
LSP.  Unfortunately, in about 1996, a link in UUnet started  
delivering corrupted packets with valid datalink checksums.  This led  
to another fascinating, spectacular, and mildly surprising at the  
time (though not so in hindsight) event.

> 	As to an unstable .. that should be a different thread.

No, it should not.  If you are not thinking "unstable" in *every*  
suggested change to the protocol, then you're making a large  
mistake.  Everything is easy in a stable network.  To quote Mike  
O'Dell (albeit out of context), "If you're not scared, you're just  
not paying attention."

Stability is the Prime Directive.  Making essentially useless changes  
that are demonstrably destabilizing (not to mention in conflict with  
the spec, which was written that way for a good reason) is not good  
engineering.  It's tinkering for tinkering's sake.

Pointless optimization is a bad addiction (aptly demonstrated by  
other parts of the OSPF spec) that inevitably leads to tears and  
recrimination.

--Dave

---

From: Erblichs <[email-masked]>
Date: Fri, 17 Feb 2006 14:41:03 -0800

Group,

	summary;
	This discussion has been offlined and
	I agree that routers must behave correctly,
	without assuming that its nbrs will also
	do so.

	Some questions from the edu folks will be
	reviewed if clarifications are wanted.

	The .com folks can research and resolve
	the issues themselves.

	Lastly, I don't believe one should purge other's LSAS
	by MAX-AGING them and flooding. I never said that.

	Mitchell Erblich
	------------------