Subject: [Isis-wg] Incorrect\Different LSP checksum in SNP

From: Aravind Ravikumar <[email-masked]>
Date: Mon, 6 May 2002 07:40:57 -0700 (PDT)

Hi,All In the section 7.3.16.2 of the 2001 edition of ISO 10589, Checksums in LSP entries in SNP packets are also considered while dealing with 
LSP confusion. I have some doubts on that  
If a system has send a LSP on point to point link and is waiting for an acknowledgement 
and gets a PSNP,in which the LSPs sequence number is same,but checksum is different,
Why should it try to purge or regenerate as we can be sure that its not a valid differentchecksum,but an incorrect checksum? The other system has send an acknowledgement, either because it has installed 
the received LSP,or is already having the same LSP
(seqnum,checksum same remaining life time both zero or both non zero).
if we have a different checksum for an LSP with same sequence number
in a PSNP packet received on a point to point circuit,it can be because 1.The SNP packet itself is corrupted,
2.The LSP got corrupted in the other systems memory,before the PSNP was 
constructed.
3.Local systems memory got corrupted Here there is no LSP confusion as this is not describing copy of the same LSP
with different data(with valid different checksums) .Can't we be sure that the checksum isincorrect. The last of the 3 cases can be verified and action should be taken in the same way
an implementation handles memory corruption.For the first two cases,how will 
the purging of LSP(if the LSP is not in the set of LSP generated by the system)
or regeneration(if its in the setof LSPs generated by the local system)
help? or what does it achieve? I assume that in case of broadcast,while processing CSNPs,if we come across
similar situation where sequence numbers are same and checksums are different,
we cannot make out whether the LSP being described is a corrupted LSP,or its
same LSP with different data or SNP itself is corrupted.In order to work in 
any case and get the database synchronized we are purging or regenerating
according to the condition Am I right?? Aravind

---------------------------------
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness

---

From: Les Ginsberg <[email-masked]>
Date: Tue, 7 May 2002 10:50:48 -0700

The notion that a system which detects internal DB corruption should recover
by purging an LSP is, of course, wrong, and I apologize for unintentionally
suggesting that. The point I was trying to make was that if you receive an
SNP and have no reason to know that its contents are corrupt (i.e. no
checksum/authentication failure) then you must treat its contents as valid.
If you are truly worried about SNP corruption (and certainly that has been a
real world problem) then use the optional checksum TLV or HMAC
authentication. Don't just ignore information in the hope that the SNP might
have been corrupted. 
 
   Les

-----Original Message-----
From: Aravind Ravikumar [mailto:[email-masked]]
Sent: Monday, May 06, 2002 11:46 PM
To: Les Ginsberg; [email-masked]
Subject: RE: [Isis-wg] Incorrect\Different LSP checksum in SNP

 Hi,

Does this mean that if a system detects that its memory is corrupted
(corrupted LSP in memory)it should purge the LSP ,causing a purge
(area wide if its level1 LSP or domain wide in case of L2 LSP)and 
the regeneration by the originating system in case of non local LSP
and regeneration in caser of local LSP?

But the section 7.3.18 on database validation says that if a system detects
failure
the network entity should be disabled until the failure is corrected and
also suggests
that in the absence of implementation specific methods to deal with the
situation, as a 
minimum we should take action to delete the databasea and reacquire the
entire database 

Your answer seems to suggest that as an implementation specific way we can
try to
re-acquire the corrupted LSP by purging it.Are we justified in doing this
.Won't it
be better if we consider the memory corruption as an indication
of more serious problems in our system(Atleast trying to find out whether
the problem 
is transient or persistent)
if its persistent problem we will keep on corrupting and purging,if we do
like that 

I think dealing with memory corruption is an implemetation specific
issue,but shouldn't it be fail stop-manner as suggested 
in the ISO 10589? 

Aravind 

  Les Ginsberg <[email-masked]> wrote: 

As you say, there are three possibilities:

1.The SNP packet itself is corrupted,
 
Without the optional SNP checksum and/or HMAC authentication, you will not
know this is the case. If you do have optional checksum/HMAC and the
validation fails, you will never process the SNP.

NOT purging might help you if the checksum reported in the SNP is a
transient error i.e. the neighbor really has the correct checksum but simply
reported it incorrectly. The most likely reason for this is SNP corruption.
The best way to address this is to use optional SNP checksums or HMAC
authentication. Once you have decided to process the SNP you must assume its
contents accurately reflect the neighbors DB.
 
So we are left with 2 and 3:

2.The LSP got corrupted in the other systems memory,before the PSNP was 
constructed.
or
3.Local systems memory got corrupted
 
(or perhaps both...)
 
If you were certain that neighbor's memory was corrupted you could simply
keep the SRM flag set and try again. I suppose an implementation could
recheck the checksum on the local copy of the LSP. If it failed, then we
know local memory is corrupt and we need to make sure we get a new copy of
the LSP. Purging it (if non-local) or regenerating it (if local)
accomplishes that.
 
If the recheck of the checksum succeeds then you could try resending the LSP
(keep SRM flag set). However, when the neighbor receives this LSP for a
second time and compares it to the local copy (sequence #'s match, lifetime
both non-zero, but checksums don't match) then the neighbor must initiate
the purge. So we have merely delayed the purge briefly.

   Les

-----Original Message-----
From: Aravind Ravikumar [mailto:[email-masked]]
Sent: Monday, May 06, 2002 7:41 AM
To: [email-masked]
Subject: [Isis-wg] Incorrect\Different LSP checksum in SNP

Hi,All
 
In the section 7.3.16.2 of the 2001 edition of ISO 10589, 
Checksums in LSP entries in SNP packets are also considered while dealing
with 
LSP confusion. I have some doubts on that 

If a system has send a LSP on point to point link and is waiting for an
acknowledgement 
and gets a PSNP,in which the LSPs sequence number is same,but checksum is
different,
Why should it try to purge or regenerate as we can be sure that its not a
valid different
checksum,but an incorrect checksum?
 
The other system has send an acknowledgement, either because it has
installed 
the received LSP,or is already having the same LSP
(seqnum,checksum same remaining life time both zero or both non zero).
if we have a different checksum for an LSP with same sequence number
in a PSNP packet received on a point to point circuit,it can be because
 
1.The SNP packet itself is corrupted,
2.The LSP got corrupted in the other systems memory,before the PSNP was 
constructed.
3.Local systems memory got corrupted
 
Here there is no LSP confusion as this is not describing copy of the same
LSP
with different data(with valid different checksums) .Can't we be sure that
the checksum is
incorrect. The last of the 3 cases can be verified and action should be
taken in the same way
an implementation handles memory corruption.For the first two cases,how will

the purging of LSP(if the LSP is not in the set of LSP generated by the
system)
or regeneration(if its in the setof LSPs generated by the local system)
help? or what does it achieve?
 
I assume that in case of broadcast,while processing CSNPs,if we come across
similar situation where sequence numbers are same and checksums are
different,
we cannot make out whether the LSP being described is a corrupted LSP,or its
same LSP with different data or SNP itself is corrupted.In order to work in 
any case and get the database synchronized we are purging or regenerating
according to the condition
 
Am I right??
 
Aravind

  _____  

Do You Yahoo!?
Yahoo!  <http://rd.yahoo.com/welcome/*http://health.yahoo.com> Health - your
guide to health and wellness

  _____  

Do You Yahoo!?
Yahoo! Health <http://rd.yahoo.com/welcome/*http://health.yahoo.com>  - your
guide to health and wellness