Subject: [Isis-wg] ISIS std question.

From: [email-masked] (Christian E. Hopps)
Date: 19 Nov 1999 15:42:27 -0500

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  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: Dave Katz <[email-masked]>
Date: Fri, 19 Nov 1999 12:58:38 -0800 (PST)

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: [email-masked] (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: [email-masked]
   Errors-To: [email-masked]
   X-Mailman-Version: 1.0rc3
   Precedence: bulk
   List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
   X-BeenThere: [email-masked]

   Chris.

---

From: "Lester Ginsberg" <[email-masked]>
Date: Sat, 20 Nov 1999 11:14:50 -0800

Two matters of clarification:

1)The problem related to purging the LSP in this situation rather than
dropping it as Dave recommends (and I heartily concur) was actually 
addressed as a defect by ISO in April of 1993. It is listed in a summary
of defects (ISO/IEC JTC1/SC6/WG2 N523). However, I do not believe it
was ever published in any of the Technical Corrigenda.

2)The second edition draft of ISO 10589 which I posted some time ago
has many problems - most of which have been documented in a contribution
I also posted. The draft in its current form should NEVER be used by ANYONE
as a means of clarifying or resolving protocol issues. It was provided
as a means of getting reviewed by the community.

Although further work on this draft has been stalled for some time, there is
hope that this work may soon be resumed and a revised second edition may
soon be available. 

   Les