Subject: RE: Restart Signaling for IS-IS (draft-ietf-isis-restart-05.tx t)

From: Jeff Parker <[email-masked]>
Date: Mon, 17 Nov 2003 14:49:59 -0500

Comments on second half.  

3.4.1.1.          Restarting 

   ....such that the same information occurs in the same place in the 
   same LSP (and hence the LSPs are identical to their previous 
   versions). If this can be achieved, the new versions will not even 
   cause SPF to be run in other systems. 

"will" assumes something about the implementation of the receiving
router (it does not re-run SPF if the LSP has not changed).  Suggest
you use "may" rather than "will".  

		....this would be highly undesirable, because it could 
   cause premature removal of an own LSP

When you use the term "own LSP" later, you put 'own' in quotes.  
Suggest you do the same here, or say something lile

		....this would be highly undesirable, because it could 
   cause premature removal of an LSP originated by the rebooting
   router before reboot, causing churn in remote routers. 

  4.1     Running Router 

  Event       | Running              | ADJ suppressed  
  ============================================================== 
  RX RR       | Maintain ADJ State   | 
              | Send RA              | 
              | Set SRM,send CSNP    | 
              |  (Note 1)            | 
              | Update Hold Time,    | 
              |  set Restart Mode    | 
              |  (Note 2)            | 
  ============================================================== 
  
    Note 1: If ADJ is UP 
 
Not every Running router will send a CSNP set.  Do you want to 
add this to Note 1?

  4.2     Restarting Router 

  Event      | Restarting         | ADJ Seen  | ADJ Seen  | SPF Wait 
             |                    |    RA     |   CSNP    | 
  =================================================================== 
  Router     | Send IIH/RR        |           |           | 
   restarts  | ADJ Init           |           |           | 
             | Start T1,T2,T3     |           |           | 
 ------------+--------------------+-----------+-----------+------------ 
  RX RR      | Send RA            |           |           | 
 ------------+--------------------+-----------+-----------+------------ 
  RX RA      | Adjust T3          |           | Cancel T1 | 
             | Goto ADJ Seen RA   |           | Adjust T3 | 
 ----------- +--------------------+-----------+-----------+------------ 
  RX CSNP set| Goto ADJ Seen CSNP | Cancel T1 |           | 
 ------------+--------------------+-----------+-----------+------------ 

1) Is a restarting router in position to send an RA?  Is it a good idea?
Could this fool a running router on a LAN with lower DIS priority into 
deferring to the restarting router?

2) Should there be state transitions out of "seen RA" and "seen CSNP"
when the other event (RA or CSNP set) arrives?  If not, should there 
be transitions from those columns when LSP DB Sync arrives?
 
- jeff parker

---

From: Les Ginsberg <[email-masked]>
Date: Mon, 17 Nov 2003 13:25:21 -0800

>you use "may" rather than "will".

OK.

>Suggest you do the same here, or say something lile

I have searched the document and cannot find any instance of quotes around 
"own LSP". ????

>   Event       | Running              | ADJ suppressed

You are referring here to the LAN case I assume. How about:

Note 1: CSNPs are sent by routers as described in Section 3.2.1c.

??

>   Event      | Restarting         | ADJ Seen  | ADJ Seen  | SPF Wait

The case of a router which does not have an adjacency in the UP state to 
the restarting router (as would be the case for a neighbor of a restarting 
router who is also restarting) is covered by the last paragraph of 3.2.1:

   "Otherwise (i.e. if there was no adjacency in the "UP" state to the
    system ID in question), process the IIH as normal by reinitializing
    the adjacency, and setting the RA bit in the returned IIH. "

When the restarting router receives an RA it takes note of that fact and 
also notes whether the adjacency state in the IIH indicates that the sender 
of the RA has an adjacency in the UP state. If so, then T3 is adjusted. 
(See 3.3.1 - top of Page 8).

Running routers which are neighbors of the restarting routers on a LAN 
should not consider the restarting routers when performing the "helper DIS 
election" because both routers will be marked as being in "restart mode" 
until an IIH with RR clear is received. See 3.2.1a and 3.2.1c.

>when the other event (RA or CSNP set) arrives?

I don't think so. The significance of the per adjacency states "seen RA" 
and "seen CSNP" relates to when to cancel T1 for that interface. Once T1 is 
cancelled, there is no significance to subsequent occurrences of either of 
the two events.

>If not, should there

Well, the state table is a hybrid of adjacency specific states (see above) 
and global states. The event "LSP DB sync" is a global state, not a per 
adjacency state. We wrestled with the presentation of the state tables 
several months ago. An alternative presentation would be to have more state 
tables, separating the adjacency specific state logic from the global. That 
was discussed somewhat when the state tables were added but no one pressed 
the point. (BTW - who was it that asked for the addition of the state 
tables?? :-) ).

Thanx Jeff.

    Les

---

From: Jeff Parker <[email-masked]>
Date: Mon, 17 Nov 2003 17:09:00 -0500

> >Suggest you do the same here, or say something like....
> 
> I have searched the document and cannot find any instance of 
> quotes around "own LSP". ????

There are a number of early uses without quotes, but here is a usage
on page 14.  It is an idiom that you are comfortable with, but 
sounds odd to the uninitiated.  A definition early on of "own LSP"
could address this.  

   Shand, Ginsberg            Expires May 2004                  [Page 13] 
 
   INTERNET DRAFT              IS-IS restart                    Nov 2003 

   Once the other level's SPF has run and any inter-level propagation 
   has been resolved, the 'own' LSPs can be generated and flooded...
 
> >   Event       | Running              | ADJ suppressed
...
> Note 1: CSNPs are sent by routers as described in Section 3.2.1c.

Works for me.  
 
> >  ----------- 
> +--------------------+-----------+-----------+------------

Les -
	Guilty as charged.  I do think it makes things clearer for me.  
 
	And I think I brought up the last issue (transition to LSP DB Sync)
in the past as well.  I will take an action to review this and make
a proposal that you can use or ignore.

- jeff

---

From: Les Ginsberg <[email-masked]>
Date: Mon, 17 Nov 2003 14:24:19 -0800

>    has been resolved, the 'own' LSPs can be generated and flooded...

Oh - single quotes! I missed that.
My proposal is to remove the single quotes throughout. The term "own LSPs" 
is used in a number of places in 10589 - I see no need to define it here.

    Les

---

From: Jeff Parker <[email-masked]>
Date: Mon, 17 Nov 2003 17:34:17 -0500

> The term "own LSPs" is used in a number of places in 10589 - I see no need
to 
> define it here.

I think it would improve the exposition, and it wouldn't cost you much

- jeff