[Isis-wg] ISIS std question.

[Lester Ginsberg]

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


> 
> 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
> 
> 
> 
> _______________________________________________
> Isis-wg mailing list  -  Isis-wg@external.juniper.net
> http://external.juniper.net/mailman/listinfo/isis-wg
>