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

From: "Kent Wong" <[email-masked]>
Date: Tue, 18 Jun 2002 18:39:42 +0000

Hi Mike and Russ,

Thanks for your reply. I have a couple more comments on the draft:

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 would be
cancelled anyway. The only case T3 is supposed to be useful is
when T3 expires before T2. The draft states that if T3 expires
before T2, router's own LSP for level which have not completed
their first SPF should be flooded with the OL bit set.

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 the helper 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 nbrs. 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

>From: mike shand <[email-masked]>
>To: "Kent Wong" <[email-masked]>
>CC: [email-masked]
>Subject: Re: [Isis-wg] draft-ietf-isis-restart-01.txt
>Date: Tue, 18 Jun 2002 10:29:48 +0100
>
>At 22:25 17/06/2002 +0000, Kent Wong wrote:
>>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.
>
>Yes. That was the assumption. Sorry that wasn't made clear.
>
>
>>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.
>
>Yes that is possible too. My take on this is that the protocol mechanisms
>described in the spec can be used in a variety of creative ways which do
>not necessarily need to be spelled out in the draft because they do not
>require explicit co-operation. This is an example of such a mechanism.
>
>
>>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.
>
>Yes.
>
>>Thanks.
>>
>>Kent Wong
>>
>>_________________________________________________________________
>>MSN Photos is the easiest way to share and print your photos:
>>http://photos.msn.com/support/worldwide.aspx
>>
>>_______________________________________________
>>Isis-wg mailing list  -  [email-masked]
>>http://spider.juniper.net/mailman/listinfo/isis-wg
>

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

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

---

From: mike shand <[email-masked]>
Date: Fri, 21 Jun 2002 09:43:09 +0100

At 18:39 18/06/2002 +0000, Kent Wong wrote:
>cancelled anyway.

When BOTH T2s have expired

>The only case T3 is supposed to be useful is

No it won't, the neighbor will send back the latest version, and the 
restarting router will override it with the next highest value.

>and everything reverts back to normal. Isn't this much more simpler

Yes you could have a single timer for each level, which you set to the 
value of T3. If it goes off for either level, then you abort the whole 
thing (as if T3 had gone off). But I think that is rather harder to describe.

>change the normal ISIS behavior even though it is not a restart?

Yes, optionally. The idea is to get the equivalent of the OSPF adjacency 
start behaviour so that you avoid the black hole on startup problem.

>network admin on individual cases whether to set the OL bit or not.

No you need T1 as well. The whole point is that you have a RELIABLE CSNP 
exchange, and so you can correctly determine when you are synchronized and 
hence clear the overload bit at the right time, rather than (as we do now) 
simply waiting for some time pulled out of the air.

>pseudonode LSP if it doesn't specify otherwise?

Yes (hopefully).

         Mike