Subject: [Isis-wg] last call on draft-ietf-isis-restart-02

From: Tony Przygienda <[email-masked]>
Date: Fri, 10 Jan 2003 11:37:56 +0100

We are starting last call on draft-ietf-isis-restart-02. The last call will end 1/24/03

    thanks

    -- tony

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

---

From: Les Ginsberg <[email-masked]>
Date: Wed, 22 Jan 2003 11:49:00 -0800

>We are starting last call on draft-ietf-isis-restart-02. The last call 

Some issues with the draft in its current form:

1)In regard to LANs, if the restarting router was DIS (at either level) 
then it is necessary that it continue to be DIS at that level following 
restart in order to avoid unnecessary disruption in the network. This 
requires that the circuit ID associated with the LAN circuits on which the 
restarting router was/is DIS does not change across restarts. The only 
place the circuit ID used pre-restart can be found is in the LAN IIHs 
received from neighboring routers i.e. the neighbors had copied this 
information from IIHs sent by the re-starting router prior to the re-start 
event according to the rules in ISO 10589 8.4.5 (penultimate paragraph). In 
order to prevent this information from being overwritten with whatever 
circuit ID might be initially assigned by the restarting router, it is 
necessary for the neighbors of a restarting router to ignore the LANID in 
IIHs with the RR bit set. This requirement is not explicit in the draft.

2)When T3 expires the current draft says(4.3.1.2):
  If the timer T3 expires before all the T2 timers have expired, this
    indicates that the synchronization process is taking longer than
    minimum holding time of the neighbors. The router's own LSP(s) for
    levels which have not yet completed their first SPF computation are
    then flooded with the overload bit set to indicate that the router's
    LSPDB is not yet synchronized ...
Once the restarting router begins issuing newly generated LSPs it should 
begin updating its own FIB so that it is consistent with what is being 
advertised. It would be better to say that the restarting router should 
begin normal operation of the update process, begin SPF calculations, and 
begin updating its own FIB. Basically we should exit restart mode with the 
exception that we allow T2 to continue to run (as it would in the case of a 
starting router) so we know how long to continue to set the OL bit.

3)When a router "starts" (NOT restarts) there may be stale LSPs in the 
network from its previous incarnation. This can cause temporary blackholes 
until the normal operation of the update process removes the stale LSPs 
from the network. The fundamental cause of the problem lies in the fact 
that IS-IS does not require LSP-DB synchronization prior to advertising a 
new adjacency. While modifying the protocol rules for adjacency formation 
would undoubtedly be an unpopular/unwise solution, the restart TLV in IIHs 
provides us with an opportunity to solve this problem in a less intrusive 
and backwards compatible way. Here's the idea:

a)Use one of the unused bits in the restart TLV to request suppressing 
advertisement of the adjacency (SA bit)
b)A restart capable router which is rebooting in a non-restart environment 
(e.g. unexpected reboot or other case in which it is unable to maintain 
forwarding plane across reboots) would set this bit in IIHs that it sends 
until it had achieved LSP database synchronization (or T2 expires)
c)A restart capable neighbor of the restarting router which sees the "SA" 
bit in the IIH would delay advertising the neighbor in its own LSPs until 
the SA bit is cleared. It would also send a set of CSNPs each time it saw 
an IIH with the "SA" bit set - thus making CSNP delivery reliable in the 
case of a starting router (just as it now is for restart using the RR bit).

    Les