Subject: [Isis-wg] few doubts on LSP purging

From: Aravind Ravikumar <[email-masked]>
Date: Sun, 24 Mar 2002 23:13:25 -0800 (PST)

Hi All,

ISO 10589 section 7.3.16.4 says when we purge an LSP with zero remaining 
life time we should retain the header in  the database for ZeroAgeLifetime
and  if we are purging because of any other reson we have to retain the 
header in the database for MaxAge.

Am I correct in assuming that the purging of old Designated IS's pseudoNode
LSP by the new Designated system and the purging of local pseudonode LSP 
when the system is resigning as designated system are two such situations,
where we are purging eventhough the remaining life time has not become zero?

My doubts are as follows:

1. What exactly is the purpose of retaining the header for MaxAge ?

2. What are the things for which we should'nt use such an aged out LSP retained
   in our database and what are the things for which the LSP  can be used?

3. Can we include it in CSNPs?

4. Can we consider them while doing look up in the database (for eg: while
   trying to add entry into database) . If we do consider and if the IS 
   becomes Designated IS again, before the pseudoNode LSPs from the earlier
   stint as Designated IS are removed from the LS database 

   A. What should be done, with the header of the aged out pseudonode LSPs
       retained in the database?

   B.Should we take the sequence number of the aged out LSP into consideration
      while generating the new pseudonode LSP?

Thanks in advance.

Aravind

---------------------------------
Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards®

---

From: mike shand <[email-masked]>
Date: Mon, 25 Mar 2002 09:08:59 +0000

>where we are purging eventhough the remaining life time has not become zero?

Yes

>1. What exactly is the purpose of retaining the header for MaxAge ?

Because if the network partitions such that some copies of the old LSP are 
left unpurged, and then the partition is healed, there must be a purge 
header still alive to cause those LSPs to be properly purged.

Note that the strict requirement in all cases is that the purge header is 
retained for the maximum possible lifetime of any copy of the LSP in the 
network. So you COULD use just the actual remaining lifetime (plus a bit). 
This becomes interesting when we consider having variable max lifetimes.

>    in our database and what are the things for which the LSP  can be used?

Nothing and everything. You use it exactly as a normal LSP. Of course it 
won't have any data, so you wouldn't use it in an SPF, but you wouldn't do 
that anyway since npobody else's LSP would point to it.

>Yes you MUST.

>    stint as Designated IS are removed from the LS database

I'm not quite sure what you mean by this. Can you re-phrase the question?

>        retained in the database?

It will get overwritten by the NEW version

>       while generating the new pseudonode LSP?

Yes if you have it, but you don't have to, since if you start at 1 and 
there are any old copies of the purge header out there, they will cause 
their sequence number to be propagated back to you, and you will then 
automatically issue your new LSP with the next highest number. i.e. it all 
just works.

Mike

>Yahoo! Movies - coverage of the 74th Academy Awards®

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

---

From: Tony Li <[email-masked]>
Date: Mon, 25 Mar 2002 01:21:42 -0800

| >3. Can we include it in CSNPs?
 | 
 | Yes you MUST.

Interesting.  Why?

Omitting the LSP from the CSNP is an indication of not having valid
information for the LSP, which should be identical to including it with
zero lifetime.

Tony

p.s. Dave, warm up a PR for me... ;-)
_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://spider.juniper.net/mailman/listinfo/isis-wg

---

From: Tony Li <[email-masked]>
Date: Mon, 25 Mar 2002 01:18:11 -0800

| Am I correct in assuming that the purging of old Designated IS's pseudoNode
 | LSP by the new Designated system and the purging of local pseudonode LSP 
 | when the system is resigning as designated system are two such situations,
 | where we are purging eventhough the remaining life time has not become zero?

A fine example.

 | My doubts are as follows:
 | 
 | 1. What exactly is the purpose of retaining the header for MaxAge ?

It's been demonstrated quite conclusively with extensive field experience
that if a node does not retain the header and simply flush it, then the
node will somehow relearn the LSP through some peer and reinstate it.  It
then purges it and the cycle continues.

 | 2. What are the things for which we should'nt use such an aged out LSP
 |    retained 
 |    in our database and what are the things for which the LSP  can be used?

There is no point in using it for anything other than a fine indication
that you don't want to relearn it.

 | 3. Can we include it in CSNPs?

Not adviseable.  I'd bet that it's against the letter of the law and in any
case it would not help anything to advertise it.

 | 4. Can we consider them while doing look up in the database (for eg: while
 |    trying to add entry into database) . If we do consider and if the IS 
 |    becomes Designated IS again, before the pseudoNode LSPs from the earlier
 |    stint as Designated IS are removed from the LS database 
 | 
 |    B.Should we take the sequence number of the aged out LSP into
 |    consideration while generating the new pseudonode LSP?

Absolutely.  Despite the purge, there will be some system out there
somewhere that has hung onto the old LSP.

 |    A. What should be done, with the header of the aged out pseudonode LSPs
 |        retained in the database?

I would compare the newly received LSP against the aged out header and
perform standard sequence number checks.  This should discard duplicate
echos of what was just purged.

Tony

---

From: mike shand <[email-masked]>
Date: Mon, 25 Mar 2002 09:58:34 +0000

>information for the LSP, which should be identical to including it with

Its not quite the same as having no information. It says "I have no 
information and YOU shouldn't have any either". SO suppose the DR has a 
purge header for an LSP. Some other router on the LAN has the full copy. It 
sends that out on the LAN and the DR realizes that it has a newer version 
(i.e. the purge has half a bit more sequence number), so it floods it on 
the LAN. But the packet gets lost.

Oh OK, maybe you are right. The CSNP claims nothing, so the other router 
re-sends its full copy, which causes the DR to resend the purge. I guess it 
all gets sorted out in the end. But its slightly "unnatural".

But my immediate reaction was that you should always do the normal thing 
and not special case the purge header. As far as the update process is 
concerned, the only interesting thing about a purge header is that it 
appears to be newer than a non-purged LSP with the same sequence number.

The only special casing that I know about is that you must not set SRMflags 
for a zero sequence number "LSP".

         Mike

---

From: Aravind Ravikumar <[email-masked]>
Date: Mon, 25 Mar 2002 02:30:20 -0800 (PST)

Hi Mike,
Thanks for the reply and now I have understood the issues, but for a small clarifcation.
If an IS finds out, while processing the CSNP (which includes the aged out entry in it) from a DIS, that
it is not having the aged out LSP in its database or is having an older copy, then it will make a request for the LSP
in its next PSNP. But since only the header of the aged out LSP is sent in response to the PSNP, won't
it be rejected because of authentication faliure, in case authentication is configured and this sequence will keep on
repeating. Am I right or wrong, please clarify? 

>I'm not quite sure what you mean by this. Can you re-phrase the question?

Sorry for putting the above question in a wrong way in my earlier mail. Any way its more to the implementation
side and is clear now from your answers to the two questions that followed it. I was trying to describe
a situation followed by the doubts on that.
I'll put the situation in a proper way as follows
System A is Designated IS for a LAN 
System B comes up and becomes the designated IS
Now the pseudonode LSPs generated by A will be purged and the headers will be retained.
System B goes down and system A again becomes the designated IS.
A is still having the headers of the old pseudonode LSPs,which it comes across while 
trying to add the new pseudonode LSPs to the database
It was in this context I asked the other two questions
Aravind

---

From: mike shand <[email-masked]>
Date: Mon, 25 Mar 2002 10:33:34 +0000

At 02:30 25/03/2002 -0800, Aravind Ravikumar wrote:

>it is not having the aged out LSP in its database or is having an older 
>copy, then it will make a request for the LSP
>
>it be rejected because of authentication faliure, in case authentication 
>is configured and this sequence will keep on
>

No. you have to include authentication even for purge headers.

         Mike

---

From: Dave Katz <[email-masked]>
Date: Mon, 25 Mar 2002 10:37:24 -0800 (PST)

Tony

I agree with you here; in the partition case, if there's no
information on one side of the network and the spent LSP is on the
other, everybody's on the same foot; if there is a live LSP on one
side and the spent LSP on the other, the live one will be flooded into
the other side when the partition heals and the originator (who is
presumably on the spent side) will do the right thing.

Moreover, this is an optimization, as there's no harm in the stale LSP
hanging around (which will only happen if the originator is
disconnected from the rest of the network) as it will just take up
space in the database until it times out of its own accord.

Having said that, many years ago Tony and I got a first-hand education
on why holding negative (purged) state is necessary.  A certain west
coast regional network running OSPF on equipment made by a certain
common former employer of ours was having regular network meltdowns of
MAXAGE LSAs.  Turns out there was a simple and subtle bug in the
flooding mechanism (something was being acked when it should have just
been dropped, I believe) and the net result was that old MAXAGE LSAs
would repeatedly come falling in from the network Oort Cloud and
ricochet around inside the network, with several different sequence
numbers.

The lesson learned from this is that you have to hold onto negative
state long enough to make sure that it will never come back to you, so
that its flooding damps out (since there is no lifetime limit to this
information.)  OSPF takes an agressive, but fragile approach to
this--if all of your neighbors have acknowledged the purged LSA, then
you can toss the state (since those neighbors will not flood it to you
again, and by extrapolation their neighbors will not flood it to them,
etc.)  Works perfectly as long as there's no bug, but it gets really
ugly when things aren't quite right.

ISIS, because it doesn't use a positive acknowledgement scheme on LANs
(a feature) must hold the negative state until it is guaranteed that
it has reached all corners of the network; otherwise it could slosh
back and forth through the network repeatedly.  (I *think* it is
guaranteed to stabilize eventually as the LSP wavefronts will cancel
one another out, but if you put a flapping link or two into the
picture I think you can come up with a somewhat plausible scenario
in which it might not ever stop.)

Link state protocols are not as simple as they appear, as has been
discovered repeatedly by those who have attempted to roll their own.

---

From: Aravind Ravikumar <[email-masked]>
Date: Tue, 26 Mar 2002 01:45:47 -0800 (PST)

Hi,

1.While purging if we retain only the header and the authentication CLV,
the existing checksum will be inconsistent as we are removing rest of the 
data portion So Do we need to 

A.Recompute checksum? or

B.Leave it as it is? or

C.Make it 0

In second case mentioned above,the receiving IS
will generate corruptedLSPReceived circuit event, according to section
section 7.3.14.2.e.1 and will treat it as an aged out LSP.

In the third case the receiving IS will treat the LSP as an aged outLSP
without generating a corruptedLSPReceived circuit event according to 
section 7.3.14.2.i 

I personally feel, the third option is the better one. Am I right? 

2.What does the following note in the section 7.3.16.4 of ISO 10589 imply

NOTE 32 A check of the checksum of a zero Remaining
Lifetime LSP succeeds even though the data portion is not
present

Does it mean that since LSP received with corrupted checksum
are treated as if the remaining life time is zero,we can afford
to have a wrong checksum for the LSP we are trying to purge so that any IS 
which receives it considers it as an aged out LSP 

3.What are we supposed to do in response to corruptedLSPReceived 
circuit event,I think we don't have any management variable
corresponding to this event.What is the pupose of generating
this event

Aravind

 

Mike

---

From: mike shand <[email-masked]>
Date: Tue, 26 Mar 2002 10:47:04 +0000

>data portion So Do we need to

The original design assumed that you would make it zero. However you can in 
fact do any of the above because the checksum is not checked for a zero 
lifetime PDU.

>section 7.3.14.2.e.1 and will treat it as an aged out LSP.

Note that this is in fact wrong, and has been corrected by a defect report 
which is incorporated in 10589 version2. The correct thing to do with a 
corrupt LSP is to ignore it,  NOT to purge it. The latter action can create 
storms (and indeed has been observed to do so) in the presence of a flakey 
link which causes excessive LSP corruption.

However, your assumption that the second case will lead to this action is 
incorrect because of the note you refer to below. The checksum will be 
ignored if the lifetime is zero.

>without generating a corruptedLSPReceived circuit event according to

Yes. that (as I said) was the original intention - that the checksum should 
be zero. Note that a Fletcher Checksum can never genuinely be zero, so 
there is no confusion with unpurged LSPs.

>I personally feel, the third option is the better one. Am I right?

Yes.

>which receives it considers it as an aged out LSP

No. It means that since there is no data portion (or strictly needn't be, 
because I believe some strange implementation persist in retaining the data 
portion of a zero age LSP - it doesn't matter - it's just a waste of 
space), there is no need to check the checksum.

As I said above, it is no longer thought desirable to purge a corrupt LSP.

>corresponding to this event.What is the pupose of generating

As far as the protocol is concerned, just ignore it. The idea of the event 
is to draw some manager's attention to the fact that weird things are 
happening.

Mike

>Aravind
>
>
>
>
>
>
>
>
>
>
>   mike shand <[email-masked]> wrote:
>> > >>4. Can w! e consider them while doing look up in the database (for 
>> eg: while
>> >Now the pseudonode LSPs generated by A will be purged and the hea! ders 
>> will
>> >be retained.
>> >
>> >System B goes d! own and system A again becomes the designated IS.
>> >

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 26 Mar 2002 07:09:11 -0800

> data portion So Do we need to

I would recommend to read the hmac draft and ponder over it some.
Basically it is undesirable for anyone _but_ the originator to purge the
originated LSP (and modern implementations adhere to this rule AFAIK)
and in doing so, it should remove the content of the LSP
except for the authentication TLV. This has denial-of-service protection
implications that are spelled out.

Coming back to the Dave-Tony reciprocal shoulder-patting on the
'maintain aged-out LSP' instead of dropping it after all neighbors acked ;-)
IMHO I liked OSPF better when memory was at a premium and always
went along the line 'if you can't write robust software, do something else
in your life' since the OSPF spec was correct. Given the dramatic increase in
memory & CPU availability in modern embedded systems
and the constant or rather dropping amount of engineer brain cycles
facing an onslaught of features and protocols, I tend to concur with them. Robust,
over-engineered designs are better, except when they keep excessive
amounts of redundant state.

    thqanks

    -- tony

---

From: Dave Katz <[email-masked]>
Date: Tue, 26 Mar 2002 14:50:32 -0800 (PST)

Obviously it was a formative moment for both of us.  ;-)

There is an existence proof that writing a robust routing protocol
implementation is difficult, and becoming moreso by the day as the
demands of features, scalability, and dynamism all increase.  A
brittle system has an unfortunate but quite spectacular way of failing
catastrophically.  Designs that are more forgiving are more practical
to implement.  On the other hand, brittle designs help reduce
competition.

It's all tradeoffs, of course, but if keeping the purged LSPs around
for awhile cramps the memory footprint, you're probably already dead
given the dynamic memory usage profiles of most implementations.

(I think this equine corpse has been sufficiently beaten.)

---

From: Tony Li <[email-masked]>
Date: Wed, 27 Mar 2002 00:49:11 -0800

| >1.While purging if we retain only the header and the authentication CLV,
 | >the existing checksum will be inconsistent as we are removing rest of the
 | >data portion So Do we need to
 | >
 | >A.Recompute checksum? or
 | >
 | >B.Leave it as it is? or
 | >
 | >C.Make it 0
 | 
 | The original design assumed that you would make it zero. However you can in 
 | fact do any of the above because the checksum is not checked for a zero 
 | lifetime PDU.

IMHO, you should do A, in keeping with the general idea that checksums are
good.  Even if an implementation doesn't check them, you can be strict in
what you send to insure interoperability.

Tony