Subject: [Isis-wg] IS-IS restart (more comments)

From: Bruno Mongazon <[email-masked]>
Date: Wed, 25 Apr 2001 11:21:22 +0200

Hi Mike,

Here are some more comments about your IS-IS restart draft.

1. Simultaneous restart of peers

The draft does not explicitely indicate if simultaneous restart of peers
is possible/supported. My current understanding is that it is not
possible for peers to restart simultaneously mainly because the restart
mechanism implies a peer to help the restarting router.

If my understanding is correct, it could be fine to indicate explicitely
in the draft that simultaneous restart is not possible. If my
understanding is not correct, can you give a few explanation of what
happens in the case of simultaneous restart of peers.

2. State table

Could be fine to split the state table in two state tables:

-state table of the restarting IS-IS
-state table of a peer IS-IS which helps a peer to restart

My motivations are the followings:

-make the state table more readable and understandable as it is
currently
-distinguish two behaviors: engine restart and engine restart assistance

3.  Forwarding activity during restart

I understand the draft as useful _only_ if the forwarding activity is
not discontinued when ISIS is restarting. This might be stated
explicitely in the draft because it implies a control/forwarding
separation in the router.

If forwarding is not discontinued during restart, it might however be
temporarily out-of-date until restart completes (engine is back to
Running state) if routing has changed in the meantime. Since being
out-of-date during restart might have impacts on network users, i guess
this should be stated explicitely in the draft. In particular excessive
restart times definitely have impacts on routing. 

4. Typo's

Page 8:
<= ...(which is has generated, but not yet transmitted)...
=> ...(which it has generated, but not yet transmitted)...

Thanks in advance for your reply.
Bruno.
_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: mike shand <[email-masked]>
Date: Wed, 25 Apr 2001 11:15:34 +0100

>happens in the case of simultaneous restart of peers.

It depends what you mean by supported. I think it has to be supported in 
the sense that if neighbors do restart simultaneously nothing bad happens. 
Although the draft doesn't state this explicitly, both neighbors can 
operate the restart algorithms with each other (as well as their 
non-restarted neighbors). So both would set RR and both would expect RA and 
note the LSP IDs from the received CSNPs. In the case where both neighbors 
were restarting the initial CSNPs over those interfaces would not reference 
very much and so those two neighbors would not add very much to the set of 
LSPs which must be acquired before synchronization is declared complete. 
But presumably other interfaces would contribute the full set of LSP IDs so 
the synchronization would not terminate prematurely.

Obviously if one of the routers in question were ONLY connected to the 
other restarting router, then it may be fooled into thinking that it was 
synchronized prematurely. This would negate the "restart" capability but 
would be equivalent to what would have happened with a standard 
implementation. So nothing "bad" happens.

>-distinguish two behaviors: engine restart and engine restart assistance

I'll look into that.

>separation in the router.

OK

>restart times definitely have impacts on routing.

Sure. I would only expect it to be used where restart times were of the 
order of a few seconds. One possibility is to abort the restart when the 
neighbor detects a topology change. Ideally this would only be a topology 
change which affects routes passing through the restarting router. i.e. if 
the neighbor thinks that the restarting router's forwarding table may be 
wrong, it treats the adjacency as down and routes around it (if possible). 
But if we wanted to do that we would need an indication from the neighbor 
that it had now re-run its SPF, and hence the adjacency is trustworthy. 
This could either be explicitly signalled by another bit in the hello 
restart TLV, or perhaps we could notice that the neighbor had re-issued its 
own LSP.

>=> ...(which it has generated, but not yet transmitted)...

Noted.

>Thanks in advance for your reply.

Thanks for your comments.

BTW, in case people hadn't noticed, the draft is now available from the 
usual places

e.g. ftp://ftp.ietf.org/internet-drafts/draft-shand-isis-restart-00.txt

         Mike

---

From: Bruno Mongazon <[email-masked]>
Date: Wed, 25 Apr 2001 15:15:21 +0200

> implementation. So nothing "bad" happens.

Fine, you designed the mechanism in a way that nothing bad should happen
in case of simultaneous restarts. Then you might or not state it
explicitely in the draft.

Note that this question came to my mind while checking the state table
for such a case.
In particular could you please clarify my following wonders:

When the state table specifies an Action such as the one depicted
hereafter,

State:	Running
Event:	Router Restarted
Action: Set SRM
	Send RR
	Send CSNP
	Start T1
Next state: Restarting

Do you assume that all PDUs transmission performed as part of an action
are done before a PDU reception (more generally an event) can be handled
by the state machine ? More clearly, given the previous action, do you
assume it is not possible for a RA PDU to enter the state machine after
RR has been sent and while CSNP is not yet sent ? 

> restart TLV, or perhaps we could notice that the neighbor had re-issued its

Interesting proposal?

If there is an additional bit in the restart TLV indicating that the
neighbor has or not re-run its SPF, then the restarting router might use
the bit to re-run or not its SPF.
If there is no additional bit, i guess the restarting router will have
to always re-run its SPF after restart.

Is the additional bit interesting?

Bruno.