Subject: [Isis-wg] Questions on IS-IS Restart Signalling

From: Saravana Kumar <[email-masked]>
Date: Thu, 22 Aug 2002 20:18:46 +0530

Hello There,

I have a few questions on the IS-IS Restart Signaling draft
 draft-ietf-isis-restart-01.txt ), My understanding of IS-IS and this draft
is still a bit patchy and i hope to clear them up before i start
implementing it. Here goes...

- Is it necessary that the 3-way handshake be implemented on the system for
the restart signaling work ? I guess this draft is written keeping in mind
the extra processing we have to do incase the 3-way handshake is implemented
on the system. Otherwise it is not really mandatory is it ?

 - In section "4.2 Adjacent re-acquisition" : The following clause is not
very clear to me.

   "DO NOT refresh the timer on the adjacency, but leave the
     adjacency in state "Up","

  I assume the timer being referred to here is the Adjacency Hold Timer for
the particular adjacency. What does "DO NOT refresh the timer on the
adjacency" mean here ? If we don't reset it ( im assuming refresh = reset )
the timer is gonna sooner rather than later, which is not what we wanted in
the first place.

- In section "4.3.1.2 Restarting" :
    Do we have to store the sequence numbers of the routers 'own' LSP's in
some non-volatile memory before the router restarts and use the stored
sequence numbers to generate the LSP's ? or do have to first purge all our
'own' LSP's by setting its remaining lifetime to zero and flooding it and
then after the zero-age timer expires, re-originate the LSPs again freshly.

This is it for now.. Thanks,
Sarav

PS : I would also appreciate it if someone answered my question on MTU
changes in the IS-IS router, which i posted to this list yesterday.

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

---

From: mike shand <[email-masked]>
Date: Fri, 06 Sep 2002 10:08:30 +0100

>on the system. Otherwise it is not really mandatory is it ?

No I'd say it was mandatory. You really need the assurance the 3WH gives you.

>the timer is gonna sooner rather than later, which is not what we wanted in

Yes it is. The idea is that the restart stuff doesn't delay the expiration 
of the adjacency holding timer, so that if something goes wrong it will 
fail (and correct routes around the problem will be calculated) no later 
than it would have done had we not done the re-start stuff. I.e. it doesn't 
make things worse.

There are those (Naiming?) who believe this is a bad idea, and I have some 
sympathy with that viewpoint. This says that since we have committed to 
doing restart, we ought to be able to extend the adjacency holding timer to 
give ourselves a bit more time to get it all done. So the spec now permits 
you to do this if you want to.

So to summarise, the text your referred to says don't refresh, but you MAY 
refresh if you want to.

>sequence numbers to generate the LSP's ?

No. There is no need to do that.

>or do have to first purge all our

No. Don't have to do that either.

         Mike

---

From: Saravana Kumar <[email-masked]>
Date: Fri, 06 Sep 2002 15:31:30 +0530

Hi Mike,

Thanks for your clarifications, i have some more questions/comments on the
draft.

> So to summarise, the text your referred to says don't refresh, but you MAY

Just to make sure that i got this right. I'am assuming that it is the
restarting routers responsibility to refresh the neighbors adjacency timer,
if it wants to, by sending out a "normal" IIH to the neighbor. Is this right
?

There are conflicting statements regarding running SPF in section 4.3.1.2.
First it says that the SPF should not be run to update the forwarding tables
when timer T3 is running. And then a couple of paragraphs later it says that
When timer T2 expires or is cancelled the SPF is run to update the RIB and
FIB. Which is true then ?

Since currently. almost everyone supports both L1->L2 & L2->L1 route
distribution, we can never really run SPF for one level and generate LSPs
for that level, before the other levels database is synchronized. So I guess
it will be better to put off SPF computation till all the levels databases
are synchronized. Now when T3 expires prematurely here, we should first run
SPF for all the levels which have completed their database synchronization
and then transmit LSPs for those levels. For the other levels whose database
is not yet synchronized we generate the LSPs with the overloadbit set.

Finally... before timer T3 is cancelled, should the re-starting router (in
the case of a warm restart) run the DR election whenever it re-acquires
adjacencies with its neighbors ?  If it is allowed to do so, can it generate
its 'own' pseudonode LSPs for the LAN ?  It is not mentioned anywhere in the
draft.

Thanks,
Sarav

---

From: mike shand <[email-masked]>
Date: Fri, 06 Sep 2002 12:48:57 +0100

>if it wants to, by sending out a "normal" IIH to the neighbor. Is this right

Yes.

>FIB. Which is true then ?

As I recall, the intention is that you don't update the FIB or regenerate 
LSPs until you are completely re-synchronized on both levels, but when each 
level completes synchronization you can run the SPF for that level in order 
to get the information you need to propagate into the other level.

>is not yet synchronized we generate the LSPs with the overloadbit set.

Perhaps, but it might be safer just to set the bit for both levels.

>adjacencies with its neighbors ?

Yes.

>  If it is allowed to do so, can it generate

You mean if it becomes the DR as a result of the election, when previously 
it wasn't? That means that it LOST an adjacency during this period (or 
someone fiddled with the priorities), which is a bit odd.

If something has REALLY changed, then there is little point in trying to 
hide it from the rest of the network. It will find out soon enough. It is 
only transient "changes" which we would eventually put back to how they 
were, that we want to suppress.

The whole assumption of the draft is that nothing else changed. If it does 
change then you might as well give up on the re-start mechanism.

We certainly don't want to have to describe all the nuances of what might 
happen, its just too complicated.

---

From: Saravana Kumar <[email-masked]>
Date: Fri, 06 Sep 2002 18:38:50 +0530

> to get the information you need to propagate into the other level.

Again, what you are saying is different from the statement in the draft. The
meaning of forwarding table and RIB (& FIB) seems to be interchanged there.
IMHO the statements in the draft can be changed as follows...

  "When the timer T2 expires, or is cancelled, the SPF is run to update
   the RIB and FIB."

   be changed to..

   "When the timer T2 expires, or is cancelled, the SPF is run to update
   the forwarding table of the corresponding level."

  And the statement..

   "In the case of a re-starting router, none of the router's own non-
    pseudonode LSPs are transmitted, nor is the SPF run to update the
    forwarding tables while the timer T3 is running."

  be changed to..

  "In the case of a re-starting router, none of the router's own non-
   pseudonode LSPs are transmitted, nor is the SPF run to update the
   RIB and FIB while the timer T3 is running. "

> someone fiddled with the priorities), which is a bit odd.

No, i was referring to the simple case :). What if the restarting router
determines that it is the DR for the LAN (it has been the DR previously).
Then should it generate pseudonode LSPs for the LAN ?  I guess there is no
harm in generating a pseudonode LSP in this case ( then again there is no
harm in not generating the pseudonode LSP also )

Thanks,
Sarav

---

From: Naiming Shen <[email-masked]>
Date: Wed, 18 Sep 2002 09:55:41 -0700

] 
 ] There are those (Naiming?) who believe this is a bad idea, and I have some 
 ] sympathy with that viewpoint. This says that since we have committed to 
 ] doing restart, we ought to be able to extend the adjacency holding timer to 
 ] give ourselves a bit more time to get it all done. So the spec now permits 
 ] you to do this if you want to.
 ] 
 ] So to summarise, the text your referred to says don't refresh, but you MAY 
 ] refresh if you want to.

I don't see the version 01.txt says that. Could you change the draft
text to make this more clear? I basically see no reason we need to
"don't refresh". The closest thing I can related to this is to offer
a control by operators to limit the total number of graceful restart
a neighbor can have in a short period of time.

thanks.
- Naiming

---

From: Vijay Amrit Agrawal <[email-masked]>
Date: Thu, 19 Sep 2002 12:08:05 +0530

Hi All,
I had some simple questions regarding the restart option TLV in the IIH.

i) When the router starts for first time it can include the "restart" TLV in
the IIH, but it has no need to set the RR bit (as the remaining time in RA
will not have any meaning for it anyway and the only other purpose RR serves
is to speed up the sending of CSNP). Is this correct?
ii)The draft talks about what the neighbor should do when it receives a
"re-start" TLV with RR bit set and the adjacency is UP. What if the
adjacency is not UP? (Agreed the probability for this happening is low, but
possible).
The neighbor can do the following:
  a)Send an IIH with "re-start" TLV in which neither RA nor RR bit is set.
The restarting router can't use this as ack (at least for the first time) as
this hello might have been sent by the neighbor before recieving the IIH
with RR bit set. Restarting router will try for sometime and then give up.
  b)Send an IIH with "re-start" TLV with the RA bit set, and the remaining
time as zero. Restarting router can treat that as indication to follow the
normal process on this interface.

Regards,
Vijay

---

From: Naiming Shen <[email-masked]>
Date: Thu, 19 Sep 2002 00:09:34 -0700

] Hi All,
 ] I had some simple questions regarding the restart option TLV in the IIH.
 ] 
 ] i) When the router starts for first time it can include the "restart" TLV in
 ] the IIH,

the "restart" TLV is ALWAYS included in IIH, regardless of a router
restart or not.

 ] but it has no need to set the RR bit (as the remaining time in RA
 ] will not have any meaning for it anyway

this statement may NOT be true, this is the difference between mike
and i were discussing.

 ] and the only other purpose RR serves
 ] is to speed up the sending of CSNP). Is this correct?

the most important thing the RR bit set, is to ask the neighbor not
to reset the adjacency if its already up, this is done by ignoring
the content of "Intermediate System Neighbors" option TLV in IIH
after receiving the IIH with this RR bit set. the side benefit is
also ask the neighbor to send csnp and lsps if it can.

 ] ii)The draft talks about what the neighbor should do when it receives a
 ] "re-start" TLV with RR bit set and the adjacency is UP. What if the
 ] adjacency is not UP? (Agreed the probability for this happening is low, but
 ] possible).

this probability is not low. there is also prossibility that when a
router restart, it never had any neighbor before. but those things
have little to do with graceful restart. the graceful restart is to
keep the adjacency states the same before and after restart. if it
was not "UP" before, then this draft does not apply at all, the
neighbor should just do what ever it does for normal ISIS adjacency
setup regardless of this "restart" TLV.

 ] The neighbor can do the following:
 ]   a)Send an IIH with "re-start" TLV in which neither RA nor RR bit is set.
 ] The restarting router can't use this as ack (at least for the first time) as
 ] this hello might have been sent by the neighbor before recieving the IIH
 ] with RR bit set. Restarting router will try for sometime and then give up.
 ]   b)Send an IIH with "re-start" TLV with the RA bit set, and the remaining
 ] time as zero. Restarting router can treat that as indication to follow the
 ] normal process on this interface.
 ] 
 ] Regards,
 ] Vijay
 ] 
 ] 
 ] _______________________________________________
 ] Isis-wg mailing list
 ] [email-masked]
 ] https://www1.ietf.org/mailman/listinfo/isis-wg

- Naiming

---

From: Vijay Amrit Agrawal <[email-masked]>
Date: Thu, 19 Sep 2002 14:20:32 +0530

Please see my comments inline
----- Original Message -----
From: "Naiming Shen" <[email-masked]>
To: "Vijay Amrit Agrawal" <[email-masked]>
Cc: "isis" <[email-masked]>
Sent: Thursday, September 19, 2002 12:39 PM
Subject: Re: [Isis-wg] Questions on IS-IS Restart Signalling

> to reset the adjacency if its already up, this is done by ignoring

If the router is starting for the FIRST time the adjacency won't be up. Am I
missing something?  (one can say, as you are indicating that the draft
doesn't apply for this case so RR bit will be ignored)

> setup regardless of this "restart" TLV.

My point was, yes the normal ISIS adjacency setup will be done, but the
neighboring router can "help" the restarting router in knowing "quickly"
that there is no point waiting for RA and cancel your T1 timer.

---

From: mike shand <[email-masked]>
Date: Thu, 19 Sep 2002 10:14:02 +0100

At 14:20 19/09/2002 +0530, Vijay Amrit Agrawal wrote:

>missing something?

Yes. See clause 3,  para 4 at bottom of page starting
"Secondly, ...."

and clause 4.3.1.1

         Mike

---

From: Naiming Shen <[email-masked]>
Date: Thu, 19 Sep 2002 02:20:13 -0700

] Please see my comments inline
 ] ----- Original Message -----
 ] From: "Naiming Shen" <[email-masked]>
 ] To: "Vijay Amrit Agrawal" <[email-masked]>
 ] Cc: "isis" <[email-masked]>
 ] Sent: Thursday, September 19, 2002 12:39 PM
 ] Subject: Re: [Isis-wg] Questions on IS-IS Restart Signalling
 ] 
 ] 
 ] > ] Hi All,
 ] >  ] I had some simple questions regarding the restart option TLV in the
 ] IIH.
 ] >  ]
 ] >  ] i) When the router starts for first time it can include the "restart"
 ] TLV in
 ] >  ] the IIH,
 ] >
 ] > the "restart" TLV is ALWAYS included in IIH, regardless of a router
 ] > restart or not.
 ] >
 ] >  ] but it has no need to set the RR bit (as the remaining time in RA
 ] >  ] will not have any meaning for it anyway
 ] >
 ] > this statement may NOT be true, this is the difference between mike
 ] > and i were discussing.
 ] >
 ] >  ] and the only other purpose RR serves
 ] >  ] is to speed up the sending of CSNP). Is this correct?
 ] >
 ] > the most important thing the RR bit set, is to ask the neighbor not
 ] > to reset the adjacency if its already up, this is done by ignoring
 ] 
 ] If the router is starting for the FIRST time the adjacency won't be up. Am I
 ] missing something?  (one can say, as you are indicating that the draft
 ] doesn't apply for this case so RR bit will be ignored)
 ] 
 ] > the content of "Intermediate System Neighbors" option TLV in IIH
 ] > after receiving the IIH with this RR bit set. the side benefit is
 ] > also ask the neighbor to send csnp and lsps if it can.
 ] >
 ] >  ] ii)The draft talks about what the neighbor should do when it receives a
 ] >  ] "re-start" TLV with RR bit set and the adjacency is UP. What if the
 ] >  ] adjacency is not UP? (Agreed the probability for this happening is low,
 ] but
 ] >  ] possible).
 ] >
 ] > this probability is not low. there is also prossibility that when a
 ] > router restart, it never had any neighbor before. but those things
 ] > have little to do with graceful restart. the graceful restart is to
 ] > keep the adjacency states the same before and after restart. if it
 ] > was not "UP" before, then this draft does not apply at all, the
 ] > neighbor should just do what ever it does for normal ISIS adjacency
 ] > setup regardless of this "restart" TLV.
 ] 
 ] My point was, yes the normal ISIS adjacency setup will be done, but the
 ] neighboring router can "help" the restarting router in knowing "quickly"
 ] that there is no point waiting for RA and cancel your T1 timer.

if the neighbor didn't have an "Up" adjacency state with the restarting
router, it should not set the RA bit in it's "restart" TLV when it sends
back the IIH. this IS the information to timeout whatever the timer
the restarting router has on this interface. In p2p case the neighbor
will not set "Up" state in the 3way handshanking IIH back to the
restarting router.

besides, since the restarting router never had a working
adjacency with that neighbor, upon restarting, what's the hurry
to speed up this adjacency process? usually one needs to do things
quickly when an adjacency is changing from "Up" to "Down", but there is
no reason to do the same while changing from "Down" to "Up". keep
using a sub-optimal path is always OK.

 ] 
 ] >
 ] >  ] The neighbor can do the following:
 ] >  ]   a)Send an IIH with "re-start" TLV in which neither RA nor RR bit is
 ] set.
 ] >  ] The restarting router can't use this as ack (at least for the first
 ] time) as
 ] >  ] this hello might have been sent by the neighbor before recieving the
 ] IIH
 ] >  ] with RR bit set. Restarting router will try for sometime and then give
 ] up.
 ] >  ]   b)Send an IIH with "re-start" TLV with the RA bit set, and the
 ] remaining
 ] >  ] time as zero. Restarting router can treat that as indication to follow
 ] the
 ] >  ] normal process on this interface.
 ] >  ]
 ] >  ] Regards,
 ] >  ] Vijay
 ] >  ]
 ] >  ]
 ] >  ] _______________________________________________
 ] >  ] Isis-wg mailing list
 ] >  ] [email-masked]
 ] >  ] https://www1.ietf.org/mailman/listinfo/isis-wg
 ] >
 ] > - Naiming
 ] > _______________________________________________
 ] > Isis-wg mailing list
 ] > [email-masked]
 ] > https://www1.ietf.org/mailman/listinfo/isis-wg
 ] 

- Naiming

---

From: mike shand <[email-masked]>
Date: Thu, 19 Sep 2002 10:28:36 +0100

At 09:55 18/09/2002 -0700, Naiming Shen wrote:
>I don't see the version 01.txt says that.

You are right. I thought I put that in, but in fact all I did was add the 
last para at the end of 4.2 (just before 4.2.1)
which says that you can send an RR clear IIH to refresh it if you want to.

How about replacing 4.2 a) "DO NOT refresh...." with

a) Do not change the state of the adjacency. It is an implementation choice 
whether or not the holding time of the adjacency is refreshed. Not 
refreshing the holding time preserves the intention of the original holding 
time. Refreshing it may allow a longer grace period for the completion of 
the restart process. Whichever option is chosen, the "remaining time" 
transmitted according to (b) below MUST reflect the actual time after which 
the adjacency will now expire.

>Could you change the draft

---

From: Vijay Amrit Agrawal <[email-masked]>
Date: Thu, 19 Sep 2002 16:08:29 +0530

Let me try to summarize to make sure I understand it:

i) On starting for FIRST time, the starting router sends IIH with RR bit
set. This will cause the neighbor to send CSNP (for broadcast one would have
got the CSNP anyway but for p2p CSNP is ensured because of timer T1.) This
CSNP will help the starting router to realize when it has synchronized with
the neighbor. The starting router should stop sending packet with RR bit set
on receiving CSNP and not wait for RA.

ii)Neighbor should send CSNP packet on receiving packet with RR bit set
(even if the adjacency is not up). Neighbor should not send IIH with RA bit
set if the adjacency is not up.

---

From: Naiming Shen <[email-masked]>
Date: Thu, 19 Sep 2002 08:11:13 -0700

Mike,
	sounds good to me. thanks.

 ] At 09:55 18/09/2002 -0700, Naiming Shen wrote:
 ] >  ]
 ] >  ] There are those (Naiming?) who believe this is a bad idea, and I have 
 ] > some
 ] >  ] sympathy with that viewpoint. This says that since we have committed to
 ] >  ] doing restart, we ought to be able to extend the adjacency holding 
 ] > timer to
 ] >  ] give ourselves a bit more time to get it all done. So the spec now 
 ] > permits
 ] >  ] you to do this if you want to.
 ] >  ]
 ] >  ] So to summarise, the text your referred to says don't refresh, but you 
 ] > MAY
 ] >  ] refresh if you want to.
 ] >
 ] >I don't see the version 01.txt says that.
 ] 
 ] You are right. I thought I put that in, but in fact all I did was add the 
 ] last para at the end of 4.2 (just before 4.2.1)
 ] which says that you can send an RR clear IIH to refresh it if you want to.
 ] 
 ] How about replacing 4.2 a) "DO NOT refresh...." with
 ] 
 ] a) Do not change the state of the adjacency. It is an implementation choice 
 ] whether or not the holding time of the adjacency is refreshed. Not 
 ] refreshing the holding time preserves the intention of the original holding 
 ] time. Refreshing it may allow a longer grace period for the completion of 
 ] the restart process. Whichever option is chosen, the "remaining time" 
 ] transmitted according to (b) below MUST reflect the actual time after which 
 ] the adjacency will now expire.
 ] 
 ] 
 ] 
 ] 
 ] 
 ] >Could you change the draft
 ] >text to make this more clear? I basically see no reason we need to
 ] >"don't refresh". The closest thing I can related to this is to offer
 ] >a control by operators to limit the total number of graceful restart
 ] >a neighbor can have in a short period of time.
 ] >
 ] >thanks.
 ] >- Naiming
 ] 

- Naiming

---

From: Vijay Amrit Agrawal <[email-masked]>
Date: Sat, 21 Sep 2002 18:57:46 +0530

Hi All,

Since I did not receive any more comments on this I am assuming the
summarization captures the intention of the draft.
Will it better if we include these two statements explicitly in the draft.
i)Neighbor SHOULD respond with complete CSNP on receiving a hello with RR
bit set, even when adjacency is not up.
ii)Router may send IIH with RR bit set even when starting for first time, to
request neighbor to send complete CSNP.

According to the draft RA bit should be set even when adjacency is not up
(see page 4, first paragraph after point "c".) If this is the case what
should the remaining time set to? My take is set the remaining time to zero,
so restarting router uses zero value to understand adjacency is not up.

Thanks everyone for their responses.
Regards,
Vijay Amrit Agrawal