Subject: [Isis-wg] draft-ietf-isis-restart-01.txt [continued]

From: "Kent Wong" <[email-masked]>
Date: Mon, 17 Jun 2002 22:47:55 +0000

Hi,

Some more questions and comments:

4. I don't understand why there is a need for two different timers
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

_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com

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