Subject: [Isis-wg] Operation of P-toP links

From: Talmon_Reiss <[email-masked]>
Date: Wed, 2 May 2001 14:57:06 +0300

Hi

I have some questions regarding the operation of P-to-P links in IS-IS:
After the establishment of a P-to-P adjacency what exactly happens wrt to
LSP transmission ?
Why is a CSNP also transmitted at initialisation (10589 7.3.15.3)?
What is the purpose of the partialSNPInterval timer? When is it used? 
What is the general procedure wrt PSNPs between 2 ISs on a P-to-P link?

Also did ISO ever update 10589 to fix the errors/omissions in the 1st
edition dated 30/4/92 (eg to incl the stuff in the Defect Report 10589/001
from July 92 and / or other errors)?

TIA
Talmon

_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: mike shand <[email-masked]>
Date: Wed, 02 May 2001 13:25:12 +0100

>Why is a CSNP also transmitted at initialisation (10589 7.3.15.3)?

Its an optimization (only). Receipt of a CSNP from the neighbor specifying 
which LSPs the neighbor has allows you to clear SRMflags for those LSPs and 
hence avoid transmitting them. Clearly if the link is to a neighbor which 
has just come up (as opposed to a link just coming up to a neighbor which 
has a full LSP database), then there will be no optimization.

But I stress, it is ONLY an optimization. i.e. loss of the CSNP will still 
result in correct synchronization. Its just that it may require the 
unnecessary transmission of some or all the LSPs.

>What is the purpose of the partialSNPInterval timer? When is it used?

The idea is to batch up the acknowledgements. The only requirement is that 
the ack is received before the re-transmit happens. SO by delaying the 
sending of the PSNP it is likely that multiple LSPs can be acknowledged in 
the same PSNP.

>What is the general procedure wrt PSNPs between 2 ISs on a P-to-P link?

You always send them to acknowledge every LSPs. i.e. SRMflags for an LSP is 
NOT cleared until either a PSNP has been received or an LSP with equal or 
newer sequence number.

>from July 92 and / or other errors)?

There is a version 2 currently being progressed by ISO. Note DO NOT confuse 
this with an earlier V2 draft which was circulating a couple of years ago 
which contained MANY errors.

---

From: Talmon_Reiss <[email-masked]>
Date: Wed, 2 May 2001 16:19:11 +0300

Hi again - thanks for replying

So if I understand you correctly:
On a P-to-P link, FIRST, a CSNP is sent, thus maybe saving the transmission
of some LSPs from the neighbour. Then each sends his LSPs, which you
acknowledge when the partialSNPInterval timer fires. Then basically this
previous sentence is repeated when an IS receives new LSPs to propagate. Is
my understanding correct?

Another question:
Say hypothetically, that a IS with a P-to-P adjacency "lost" an LSP from its
database. Apart from waiting for a retransmission of this LSP from its
neighbour (after maximumLSPGenerationInterval seconds), is there any other
way to get this LSP sooner?

Thanks
Talmon

---

From: mike shand <[email-masked]>
Date: Wed, 02 May 2001 14:33:09 +0100

>my understanding correct?

Yes, if I understand you correctly.

>way to get this LSP sooner?

Well, it better hadn't arbitrarily loose LSPs!!!

If it detects that an LSP it holds is corrupt (bad checksum in memory), 
then it can treat it as expired and hence get a new one.

Alternatively if it KNOWS that it has "lost" the LSP it could adopt various 
strategies to try to get it back, but none of this is covered by the normal 
protocol.

As I said, once a router has acknowledged an LSP it is its responsibility 
to preserve it in its memory. If it doesn't it should probably crash!

         Mike

---

From: mike shand <[email-masked]>
Date: Thu, 03 May 2001 08:20:21 +0100

At 14:50 02/05/2001 -0700, Neal Castagnoli wrote:

> > any decent implementation does only flush its own LSPs these
> > days. Flushing
> > other people LSPs has proven to be a bad idea.

Absolutely. I wasn't really advocating purging the bad checksum in memory 
case. My main concern was to emphasis that you shouldn't arbitrarily loose 
LSPs!

>Right.  In NLSP we eliminated the "bad checksum purge" when receiving
>corrupted LSPs, because a corrupting link (or misbehaving router on the
>other end of the link) could bring down a network.  We discarded the bad
>ones, and alerted the administrator.

This is exactly what IS-IS does now. (There's a TC on ISO/IEC 10589 which 
says this).

>The other instance of a network wide purge is receipt of an LSP that has the
>same "newness" (same sequence number, same lspid, both non-zero lifetime),
>but different checksums.  In this case, we included checksum as a part of
>the "newer" calculation.  LSPs with higher checksums were "newer."  This
>prevented routers from purging others LSPs, and in the case of two routers
>battling over a system ID, it allowed the LSPs to flow back and forth
>between the battling routers (both routers complain).
>
>Is this being done with ISIS implementations?  If so, it seems all routers
>need to have the same algorithm (what is it?).

I know of implementations which do this, but there is nothing which says 
which is the "right" way to do it (higher or lower checksum). As you say it 
is critical that all implementations choose the same algorithm. (Well, in 
fact it is safe for this to co-exist with the "standard" purging).

But I'm not sure that this issue is particularly important (as opposed to 
the bad checksum in a received LSP, which is important, as we have real 
world evidence to show )

>  If not, what is being done
>to prevent the purge?
>
> >> <way to recover from corrupt LSPs in the database deleted>
> > even simpler solutions to the problem exist given some
> > cooperation from your
> > neighbor
> >
>
>Do you know what the simpler solutions are?  Care to describe them?

Well, something along the lines of draft-shand-isis-restart-00.txt springs 
to mind!

But as Tony says, you can do interesting things with SNPs.

>(which begs the question of whether it is even right to try to recover!).
>
> >             -- tony
> >
>
>   --Neal