[Isis-wg] ISIS std question.

[Dave Katz]

The dominant implementations drop the LSP rather than purging it.

The reasoning behind purging was that an LSP with a bad checksum
probably was due to the LSP being corrupted in memory in some other
system (since the link data checksum should protect the LSP while
in flight).

A few years ago, a certain large ISP was using some L2 equipment that
did checksum regeneration had some problems.  As a result, one link
was reliably corrupting the data while delivering it with good datalink
checksums.  The net result of this was a continuous purge/reflood cycle
for every LSP in the domain (since by definition every LSP must cross
every link, mesh groups notwithstanding).  It was very exciting, and
brought my vacation to an untimely halt.  Thus the addition of the
"ignore-lsp-errors" configuration in the cisco box.  The Juniper box
always ignores errored LSPs without configuration.

   From: chopps@merit.edu (Christian E. Hopps)
   Date: 19 Nov 1999 15:42:27 -0500
   Lines: 27
   User-Agent: Gnus/5.070097 (Pterodactyl Gnus v0.97) XEmacs/20.4 (Emerald)
   MIME-Version: 1.0
   Content-Type: text/plain; charset=us-ascii
   Sender: isis-wg-admin@external.juniper.net
   Errors-To: isis-wg-admin@external.juniper.net
   X-Mailman-Version: 1.0rc3
   Precedence: bulk
   List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
   X-BeenThere: isis-wg@external.juniper.net


   I'm trying to figure out checksum failures in the isis std..

   When I receive an LSP with a bad checksum the std in 7.3.14.2 says I
   should generate an event, overwrite the cksum and lifetime fields with
   zero and

	   c) treat the link state pdu as though its remaining lifetime had
	   expired (see 7.3.16.4).

   It seems to me that there are some problems with this.  Since 7.3.16.4
   has two cases: lifetime on a LSP _in_memory_ becoming zero (i.e., what I 
   would consider `expiring') and receipt of an LSP with a zero lifetime.

   If it means the former should I just treat my in DB copy of the LSP as
   if it has expired?

   If it means the latter it could cause problems.  What if the bogus LSP
   I just received had a really large sequence number (close to `wrapping').
   This would seem to allow corrupted pdus to effect the operation of the
   protocol too greatly.

   I looked at the proposed new text for the standard and it says to just
   drop the LSP.  Is this what other vendors currently do?  It makes a lot
   of sense to me :)

   Chris.

   _______________________________________________
   Isis-wg mailing list  -  Isis-wg@external.juniper.net
   http://external.juniper.net/mailman/listinfo/isis-wg