Subject: Re: [Isis-wg] draft-ietf-isis-restart-02: Update process question

From: mike shand <[email-masked]>
Date: Wed, 15 Jan 2003 09:07:25 +0000

At 16:40 14/01/2003 -0800, Ravindra Sunkad wrote:
>Section "4.3.1.2 Restarting" states two things:
>     1. Do not flood 'own' LSPs before they are completely rebuilt
>     2. Ignore LSP/SNP updates of 'own' LSPs before they are completely
>        rebuilt
>
>I have the following questions regarding the update process operation on the
>restarting router before it has completely rebuilt it's 'own' LSPs:
>
>1. Should a restarting router send out CSNPs on a circuit 'C' that it would
>    normally send out? If yes, must it include SNP entries for it's 'own' LSPs
>    in these?

Yes it should send CSNPs.

It doesn't really matter whether or not the own LSPs are mentioned.
If they are not mentioned, the neighbors will send copies of the ones which 
they have.
If they ARE mentioned, but have a lower sequence number than the copies the 
neighbors hold, the neighbors will still send them.
If they are mentioned and have the SAME sequence number as those the 
neighbors hold, nothing will happen.
If they are mentioned and have a greater sequence number (shouldn't happen) 
than those the neighbors hold or if some neighbor doesn't have them, then 
the neighbor will ask for them.

In all cases the arrival of the "newer" version or the request is ignored 
until the LSPs are really there.

I would say for preference don't mention them, since you don't "really" 
have them (yet).

>
>2. Do ACKs have to be sent on receipt of 'own' LSPs from a helper router on a
>    point-to-point circuit?

Again, it doesn't really matter. If you acknowledge it, you will shut the 
neighbor up. If you don't, it will keep asking. But we should probably have 
it all sorted out by the next time it would ask anyway and will have 
already sent out our real LSP (with a sequence number of 1) which will 
provoke the neighbor to send the old copy again, so we can trump it with a 
higher sequence number.

It all amounts to the same thing really.

Or you could even remember the sequence number of the copy the neighbor 
sent you the first time (before you were ready) and use that to determine 
the sequence number to use for the first LSP.

I would say for preference ACK them. What you must NOT do is purge them.

The real guiding principle here is to do whatever comes naturally. i.e. we 
are NOT defining a NEW update process, but simply using the existing one in 
a creative way. There are always (even with the "normal" update process) 
lots of "optimizations" you COULD do with impunity, but the safest approach 
is not to attempt any special casing and just follow the normal very simple 
rules.

         Mike

>Thanks,
>Ravi

_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg

---

From: Les Ginsberg <[email-masked]>
Date: Wed, 15 Jan 2003 14:19:25 -0800

>It doesn't really matter whether or not the own LSPs are mentioned.

This statement MUST be amended to say that if your own LSPs are mentioned 
in CSNPs sent during restart, the info MUST be based on copies you have 
received from neighbors during the restart process. If own LSPs are never 
mentioned, this is OK as well. I say "MUST be amended" because there is one 
possible case where your old incarnation LSP will get purged unless the 
amended statement is followed. Please see below.

>If they are not mentioned, the neighbors will send copies of the ones 
>which they have.
>
>If they ARE mentioned, but have a lower sequence number than the copies 
>the neighbors hold, the neighbors will still send them.
>

Not always true. If you did NOT base your SNP entry on a copy of the old 
incarnation LSP you received during the restart period, the checksums are 
likely to differ. This will result in a purge - which is VERY BAD. The 
likelihood of this case occurring is low, but non-zero.

>If they are mentioned and have a greater sequence number (shouldn't 
>happen) than those the neighbors hold or if some neighbor doesn't have 
>them, then the neighbor will ask for them.

Yes. And the neighbor will clear the SRMflag for the old copy it holds. So 
you may never receive your old copy. This may not be a problem - unless you 
are trying to match the new copies you generate after T3 by using the old 
incarnation copies. Unlikely I suppose.

>until the LSPs are really there.

This seems to suggest that an implementation has no interest in the old 
copies of its own LSPs. While an implementation can certainly choose that 
path, there is value in storing these LSPs. You can reduce the number of 
copies/retransmissions of these LSPs that are received by storing them and 
including them in CSNPs sent subsequently. You can also use the sequence # 
as a starting point for regenerating these LSPs after T3 has stopped. Both 
of these things are optimizations, not requirements.

>I would say for preference don't mention them, since you don't "really" 

I think the optimal thing is to mention them if you have a copy you have 
received from a neighbor.
Second best is not to mention them at all.
Dangerous to mention a locally generated copy.

>neighbor up. If you don't, it will keep asking. But we should probably 
>have it all sorted out by the next time it would ask anyway and will have 
>are NOT defining a NEW update process, but simply using the existing one 
>in a creative way. There are always (even with the "normal" update 
>process) lots of "optimizations" you COULD do with impunity, but the 
>safest approach is not to attempt any special casing and just follow the 
>normal very simple rules.

I agree - but an implementation has to do "something" a bit differently 
from normal. It could:

    o discard local LSPs received during restart
    o store local LSPs received during restart but suppress 
purging/regeneration

Either way it must be sure that it does NOT send SNP entries based on local 
LSPs which it generated post restart until T3 has stopped. There are a 
variety of ways to do this as well, but regardless of what goes on behind 
the "implementation curtain" what appears on the wire in CSNPs must be 
constrained.

---

From: mike shand <[email-masked]>
Date: Thu, 16 Jan 2003 08:42:28 +0000

At 14:19 15/01/2003 -0800, Les Ginsberg wrote:
>mentioned, this is OK as well. I say "MUST be amended" because there is 
>one possible case where your old incarnation LSP will get purged unless 
>the amended statement is followed. Please see below.
>

Yes. You are absolutely right of course.

>you may never receive your old copy. This may not be a problem - unless 
>you are trying to match the new copies you generate after T3 by using the 
>old incarnation copies. Unlikely I suppose.
>

I agree. Perhaps we should actually state that. i.e. do not mention a 
locally generated copy.

>>provoke the neighbor to send the old copy again, so we can trump it with 
>>a higher sequence number.
>>
>>The real guiding principle here is to do whatever comes naturally. i.e. 
>>we are NOT defining a NEW update process, but simply using the existing 
>>one in a creative way. There are always (even with the "normal" update 
>Either way it must be sure that it does NOT send SNP entries based on 
>local LSPs which it generated post restart until T3 has stopped. There are 
>a variety of ways to do this as well, but regardless of what goes on 
>behind the "implementation curtain" what appears on the wire in CSNPs must 
>be constrained.
>
>>         Mike
>>
>>
>>>
>>>Thanks,
>>>Ravi
>>

---

From: Naiming Shen <[email-masked]>
Date: Thu, 16 Jan 2003 02:13:17 -0800

I don't see any reason to change the restarting router CSNP
behaviour during the restart. i.e. to hide the local lsps as
suggested in this thread.

During restart, the restarting router starts its own lsps from 1
and it probably has a previous life higher seq# lsps out there, for
example seq X. if the restarting router is a DIS on the lan, it's
perfectly fine to announce the local lsps with seq less than X,
equal to X, or higher than X.

a) if it sends csnp with local lsp with seq less than X, then the
   neighbors will send its previous lsp with seq# X over. for the
   normal lsp operation, the router should increase its lsp
   to seq# X+1.

b) if it sends out with seq X, and chksum does not match with the
   old copy. notice that, the restarting router can NOT send out this
   lsp with seq# X during the restart, it can only send CSNP to
   indicate that. the spec certainly does not say the neighbor should
   purge the existing lsp just because it sees the same seq# with diff
   chksum in a csnp and purge the lsp. when the restarting router
   receives its old lsp, even it want to purge, but it can't, since
   it's not allowed to send lsp out(including purged lsps). it should
   just up the seq# as in case (a).

c) if it sends csnp with local lsp with seq larger than X, the neighbors
   should just send psnp to request this lsp(but can't get it). the
   neighbors should still keep the old lsp around until they get the
   higher seq# lsps from the restarting router.

when the restarting router is allowed to send out the lsps, it will
have the seq# lager than X. the neighbors will update their database.
thus in all a, b, and c cases, sending out csnp with its local lsps
do not in any way affect the restarting router or the neighbor
non-stop forwarding status. then we should keep the normal DIS csnp
behaviour to minimize the changes to the graceful restart.

thanks.

 ] At 14:19 15/01/2003 -0800, Les Ginsberg wrote:
 ] >At 09:07 AM 1/15/2003 +0000, mike shand wrote:
 ] >>At 16:40 14/01/2003 -0800, Ravindra Sunkad wrote:
 ] >>>Section "4.3.1.2 Restarting" states two things:
 ] >>>     1. Do not flood 'own' LSPs before they are completely rebuilt
 ] >>>     2. Ignore LSP/SNP updates of 'own' LSPs before they are completely
 ] >>>        rebuilt
 ] >>>
 ] >>>I have the following questions regarding the update process operation on 
the
 ] >>>restarting router before it has completely rebuilt it's 'own' LSPs:
 ] >>>
 ] >>>1. Should a restarting router send out CSNPs on a circuit 'C' that it wou
ld
 ] >>>    normally send out? If yes, must it include SNP entries for it's 
 ] >>> 'own' LSPs
 ] >>>    in these?
 ] >>
 ] >>Yes it should send CSNPs.
 ] >>
 ] >>It doesn't really matter whether or not the own LSPs are mentioned.
 ] >
 ] >
 ] >This statement MUST be amended to say that if your own LSPs are mentioned 
 ] >in CSNPs sent during restart, the info MUST be based on copies you have 
 ] >received from neighbors during the restart process. If own LSPs are never 
 ] >mentioned, this is OK as well. I say "MUST be amended" because there is 
 ] >one possible case where your old incarnation LSP will get purged unless 
 ] >the amended statement is followed. Please see below.
 ] >
 ] >>If they are not mentioned, the neighbors will send copies of the ones 
 ] >>which they have.
 ] >>
 ] >>If they ARE mentioned, but have a lower sequence number than the copies 
 ] >>the neighbors hold, the neighbors will still send them.
 ] >>
 ] >>If they are mentioned and have the SAME sequence number as those the 
 ] >>neighbors hold, nothing will happen.
 ] >
 ] >Not always true. If you did NOT base your SNP entry on a copy of the old 
 ] >incarnation LSP you received during the restart period, the checksums are 
 ] >likely to differ. This will result in a purge - which is VERY BAD. The 
 ] >likelihood of this case occurring is low, but non-zero.
 ] 
 ] Yes. You are absolutely right of course.
 ] 
 ] 
 ] 
 ] >>If they are mentioned and have a greater sequence number (shouldn't 
 ] >>happen) than those the neighbors hold or if some neighbor doesn't have 
 ] >>them, then the neighbor will ask for them.
 ] >
 ] >Yes. And the neighbor will clear the SRMflag for the old copy it holds. So 
 ] >you may never receive your old copy. This may not be a problem - unless 
 ] >you are trying to match the new copies you generate after T3 by using the 
 ] >old incarnation copies. Unlikely I suppose.
 ] >
 ] >>In all cases the arrival of the "newer" version or the request is ignored 
 ] >>until the LSPs are really there.
 ] >
 ] >This seems to suggest that an implementation has no interest in the old 
 ] >copies of its own LSPs. While an implementation can certainly choose that 
 ] >path, there is value in storing these LSPs. You can reduce the number of 
 ] >copies/retransmissions of these LSPs that are received by storing them and 
 ] >including them in CSNPs sent subsequently. You can also use the sequence # 
 ] >as a starting point for regenerating these LSPs after T3 has stopped. Both 
 ] >of these things are optimizations, not requirements.
 ] >
 ] >>I would say for preference don't mention them, since you don't "really" 
 ] >>have them (yet).
 ] >
 ] >I think the optimal thing is to mention them if you have a copy you have 
 ] >received from a neighbor.
 ] >Second best is not to mention them at all.
 ] >Dangerous to mention a locally generated copy.
 ] 
 ] I agree. Perhaps we should actually state that. i.e. do not mention a 
 ] locally generated copy.
 ] 
 ] 
 ] 
 ] >>>2. Do ACKs have to be sent on receipt of 'own' LSPs from a helper router 
 ] >>>on a
 ] >>>    point-to-point circuit?
 ] >>
 ] >>Again, it doesn't really matter. If you acknowledge it, you will shut the 
 ] >>neighbor up. If you don't, it will keep asking. But we should probably 
 ] >>have it all sorted out by the next time it would ask anyway and will have 
 ] >>already sent out our real LSP (with a sequence number of 1) which will 
 ] >>provoke the neighbor to send the old copy again, so we can trump it with 
 ] >>a higher sequence number.
 ] >>
 ] >>It all amounts to the same thing really.
 ] >>
 ] >>Or you could even remember the sequence number of the copy the neighbor 
 ] >>sent you the first time (before you were ready) and use that to determine 
 ] >>the sequence number to use for the first LSP.
 ] >>
 ] >>I would say for preference ACK them. What you must NOT do is purge them.
 ] >>
 ] >>The real guiding principle here is to do whatever comes naturally. i.e. 
 ] >>we are NOT defining a NEW update process, but simply using the existing 
 ] >>one in a creative way. There are always (even with the "normal" update 
 ] >>process) lots of "optimizations" you COULD do with impunity, but the 
 ] >>safest approach is not to attempt any special casing and just follow the 
 ] >>normal very simple rules.
 ] >
 ] >I agree - but an implementation has to do "something" a bit differently 
 ] >from normal. It could:
 ] >
 ] >    o discard local LSPs received during restart
 ] >    o store local LSPs received during restart but suppress 
 ] > purging/regeneration
 ] >
 ] >Either way it must be sure that it does NOT send SNP entries based on 
 ] >local LSPs which it generated post restart until T3 has stopped. There are 
 ] >a variety of ways to do this as well, but regardless of what goes on 
 ] >behind the "implementation curtain" what appears on the wire in CSNPs must 
 ] >be constrained.
 ] >
 ] >>         Mike
 ] >>
 ] >>
 ] >>>
 ] >>>Thanks,
 ] >>>Ravi
 ] >>
 ] >>_______________________________________________
 ] >>Isis-wg mailing list
 ] >>[email-masked]
 ] >>https://www1.ietf.org/mailman/listinfo/isis-wg
 ] >
 ] >_______________________________________________
 ] >Isis-wg mailing list
 ] >[email-masked]
 ] >https://www1.ietf.org/mailman/listinfo/isis-wg
 ] 
 ] _______________________________________________
 ] Isis-wg mailing list
 ] [email-masked]
 ] https://www1.ietf.org/mailman/listinfo/isis-wg

- Naiming

---

From: mike shand <[email-masked]>
Date: Thu, 16 Jan 2003 10:44:25 +0000

>    just up the seq# as in case (a).

Hmm interesting question. In general I think you DO have to invoke whatever 
"LSP confusion" mechanism you are using (i.e. either purging, or treating 
the higher checksum as newer), when you see a CSNP entry which has the same 
sequence number but different checksum to your LSP. If you don't do this, 
you could join two isolated portions of the network which have different 
epochs of LSPs and you wouldn't detect anything was amiss.

Or am I once again speaking without thinking hard enough?

         Mike

---

From: Naiming Shen <[email-masked]>
Date: Thu, 16 Jan 2003 03:33:13 -0800

you can either send your copy over, or you can ask for a copy.
either one will trigger a purge in the normal case as defined
in "LSP confusion".

but in this graceful restarting case, neither action will trigger
a purge, this is actually what we want.

usually during the restart, the restarting router either have
a lower seq# lsp, or higher(due to received its own old lsp),
it should be very rare to see an equal seq# case.

thanks.

 ] At 02:13 16/01/2003 -0800, Naiming Shen wrote:
 ] >b) if it sends out with seq X, and chksum does not match with the
 ] >    old copy. notice that, the restarting router can NOT send out this
 ] >    lsp with seq# X during the restart, it can only send CSNP to
 ] >    indicate that. the spec certainly does not say the neighbor should
 ] >    purge the existing lsp just because it sees the same seq# with diff
 ] >    chksum in a csnp and purge the lsp. when the restarting router
 ] >    receives its old lsp, even it want to purge, but it can't, since
 ] >    it's not allowed to send lsp out(including purged lsps). it should
 ] >    just up the seq# as in case (a).
 ] 
 ] Hmm interesting question. In general I think you DO have to invoke whatever 
 ] "LSP confusion" mechanism you are using (i.e. either purging, or treating 
 ] the higher checksum as newer), when you see a CSNP entry which has the same 
 ] sequence number but different checksum to your LSP. If you don't do this, 
 ] you could join two isolated portions of the network which have different 
 ] epochs of LSPs and you wouldn't detect anything was amiss.
 ] 
 ] Or am I once again speaking without thinking hard enough?
 ] 
 ]          Mike
 ] 
 ] 
 ] 
 ] 

- Naiming

---

From: Les Ginsberg <[email-masked]>
Date: Thu, 16 Jan 2003 11:00:26 -0800

At 10:44 AM 1/16/2003 +0000, mike shand wrote:
>Hmm interesting question. In general I think you DO have to invoke 
>whatever "LSP confusion" mechanism you are using (i.e. either purging, or 
>treating the higher checksum as newer), when you see a CSNP entry which 
>has the same sequence number but different checksum to your LSP. If you 
>don't do this, you could join two isolated portions of the network which 
>have different epochs of LSPs and you wouldn't detect anything was amiss.
>

This is an old defect in the spec. DR 1 against ISO 10589 (circa 1992) 
mentioned that the rules in determining which LSP was newer should be 
applied the same for SNP entries as for received LSPs, but this was not 
explicit in the spec. Appropriate changes to the spec were specified, but 
due to some long ago confusion were never published in any of the TCs. 
These changes have been incorporated into the 2001 draft of ISO 10589 (to 
be published someday I hope).

The relevant portion here is that the rules associated with LSP confusion 
(7.3.16.2) are to be applied to received SNP entries just as they would for 
a received LSP. So in this case if the neighbor of a restarting router 
received an SNP entry from the restarting router which matched its database 
entry in sequence # but checksums differed, then the neighbor is duty bound 
to purge the LSP. This, of course, is undesirable in this case.

Although this is an unlikely case to occur, it is possible.

     Les