Subject: [Isis-wg] Questions and comments on draft-ietf-isis-restart-01.txt

From: "Kent Wong" <[email-masked]>
Date: Thu, 13 Jun 2002 20:06:39 +0000

Resent of e-mail because pervious e-mails were lost:
----------------------------------------------------
Hi,

I have some questions and comments on the isis restart draft:

1. On Page 6
"....a router MAY transmit one or more normal IIHs
(containing a restart option, but with RR and RA clear) after the
initial RR/RA exchange, but before synchronization has been
achieved, in order to extend the holding time of the neighbors
adjacencies, beyond that indicated in the remaining time field of
the neighbors IIH with the RA bit set."

When a router does this, should it also extend T3 to be the new
holding time? Otherwise, even though we extend nbr's holding time
for the adjacency, T3 will still expire in a short time and LSP
with OL bit set will be generated and the graceful restart will
fail anyway.

2. Instead of sending normal IIH after initial RR/RA exchange,
would it make more sense that if this is a planned restart,
a normal IIH with a large holding time is sent before the router
going down so that nbr will hold the adjacency until restarting
router finishes the complete restart procedure. In that way, there
is no need to send extra normal IIH after initial RR/RA exchange.

3. If T2 on both levels expires/cancelled, it means end of
database resync and if T3 is still running, we should cancel
T3 at this time. Is that correct? The draft did not say this explicitly.

4. Along the same line of thought, there is no need for a separate
T2 and T3. Because when T2 expires/cancels before T3, T3 should be
cancelled anyway. The only case T3 is supposed to be useful is
when T3 expires before T2. The draft states that

"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 (and other routers should therefore
not compute routes through this router)."

However this assumes that the restarting router has acquired its
own pre-start LSP before T3 expires. What if T3 expires even before
it acquires its pre-start LSP? In that case, it doesn't know what
sequence number it should use in its zero LSP to set the OL bit.
If the seq num it uses is smaller than the seq num in its nbr's DB,
then the zero LSP will be ignored by nbr anyway.

So why not just combine T2 and T3 into a single timer and set the
timer to be the min. remaining holding time of its nbr. If the timer
expires before it DB re-sync, then graceful restart fails
and everything reverts back to normal. Isn't this much more simpler
and effective?

5. On section 4.3.1.1, the draft mentions the behavior of a router
when it starts for the first time. Does it mean this draft intends to
change the normal ISIS behavior even though it is not a restart?
That means we need to start T2 (but no T1, T3) for each level even
we start for the first time. However, it may not be desirable to set
the OL bit every time ISIS comes up. This should be decided by the
network admin on individual cases whether to set the OL bit or not.

6. Just for clarification, in the draft, it mentions "own" LSP
many times, sometimes it mention own non-pseudonode LSP, sometimes
it mention own LSP including pseudonode. Sometimes, it simply
mention "own" LSP. Should we interpret the "own" LSP as including
pseudonode LSP if it doesn't specify otherwise?

Thanks!

---Kent Wong

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://spider.juniper.net/mailman/listinfo/isis-wg