Subject: RE: AD-review for draft-ietf-isis-*-interoperable

From: Radia Perlman - Boston Center for Networking <[email-masked]>
Date: Tue, 1 Apr 2003 14:49:31 -0500 (EST)

From: "Tony Li" <[email-masked]>

	Purging invalid LSPs are a trivial way to turn your own network into
	its own distributed DoS self-attack system.  
	
	On the flip, not purging them and just ignoring them just wastes a bit
	of memory.
	
	Tony

From my distant memory...I believe I introduced the concept of purging other
routers' LSPs. My reason was worry about a router R1 having a very
fast clock relative to the other routers. In that case, R1 might purge
R2's LSP long before anyone else does. And then R1 would be
calculating paths on a different LSP database than the other
routers. So it seemed like a good idea to have all routers purge
LSPs at the clock of the fastest router, so their LSP databases would
be the same.

I have to admit I don't have a copy of 10589, so I'll ask a stupid
question here...I'm assuming even if you don't synchronize the
purge, that if R1's age on R2's LSP gets to 0 that R1 would
throw away R2's LSP? Or has it changed to be that only R2 gets
to purge its own LSP?

Perhaps LSPs should never be purged, (memory's free these
days, right?) or perhaps the rule should be "never purge R2's
LSP if R2 is actually reachable" (seems a little dangerous...R2
or actually a whole portion of the net might be temporarily
unreachable to some other portion of the net, and so only some
nodes might purge R2's LSP). On LANs (because of periodic CSNPs)
LSP databases would get resynchronized. But maybe there might
be some scenarios in which things could remain unsynchronized.

If the rule is that only R2 can cause a purge of R2's LSP, then
we have the router-with-the-fast-clock issue (assuming you
throw away an LSP when the age expires).

And a really really stupid question. What do you mean by
"the IP document" in the following:

>>Section 6.2 of the IP document essentially deprecates TLV 133 and
>>tells to use TLV 10 for authentication. This should be mentioned in
>>this section.

I assumed you meant RFC 1195, but there is no section 6.2 there.

Radia

---

From: Alex Zinin <[email-masked]>
Date: Tue, 1 Apr 2003 12:45:33 -0800

Radia,

> throw away an LSP when the age expires).

Oh, purging expired LSPs is definitely fine and does ensure LSDB
synchronization.

The part of the document in question talks about purging _invalid_
received LSPs.

> I assumed you meant RFC 1195, but there is no section 6.2 there.

this was regarding draft-ietf-isis-ip-interoperable-00.txt

Regards
Alex

---

From: mike shand <[email-masked]>
Date: Wed, 02 Apr 2003 11:10:15 +0100

Radia,
         This isn't about purging LSP per se. Its about doing it when you 
detect a "bad" LSP (checksum failure, corrupt format etc. etc.) The 
original spec said that if you receive a bad LSP you had to purge it all 
the way back to the source. That's fine in theory, but operationally it 
caused problems when there was a flakey link which was corrupting LSPs. 
Every time it caused the LSP in question to be purged from the network and 
then replaced by the source (until it got to the flakey link, which then 
caused it to be purged again).

         The simple resolution is to say that you simply ignore such an 
LSP. In which case the transmitter simply keeps trying to send it every few 
seconds across the link (or in the case of a LAN as a result of CSNP action 
etc. etc.).

         But the upshot is that the problem is simply confined to the 
flakey link and doesn't upset the entire network.

         Mike