Subject: RE: [Isis-wg] ISIS graceful restart...

From: "Jeelani Syed" <[email-masked]>
Date: Wed, 21 Apr 2004 11:33:58 -0400

Hi Les,

That is what i thought, restart router could use the pre-start seq #
from ignored local
lsp received from neighbours if the gracefull restart is successfull(T3
cancelled). Do 
you think it is worth mentioning it in draft or it is implicit?

Thanx,

-jeelani.sm

-----Original Message-----
From: Les Ginsberg [mailto:[email-masked]]
Sent: Wednesday, April 21, 2004 11:23 AM
To: Jeelani Syed
Cc: mike shand; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Isis-wg] ISIS graceful restart...

At 10:27 AM 4/21/2004 -0400, Jeelani Syed wrote:
>Mike & Les,
>
>Thanks for your response...i have one more question...
>Are the local LSPs of the restart router going to use the sequence no.
>they left off before restarting or they start from zero?

As the restarting router has no memory of what sequence numbers were in
use 
prior to restart, it begins by reinitializing the sequence #s of its own

LSPs. However, as explained in Section 3.4.1.1

"In the case of a restarting router, none of the router's own LSPs
    are transmitted, nor are the router's own forwarding tables updated
    while the timer T3 is running."

During this time LSPDB synchronization is occurring. The restarting
router 
will acquire copies of its own LSPs (pre-restart) from its neighbors. 
Normal operation of the update process will cause the restarting router
to 
update the sequence numbers in its own LSPs based on the copies
received. 
Once flooding of own LSPs is resumed (T3 expired or cancelled) this
ensures 
that the own LSPs will use either the same sequence # as pre-restart or
a 
newer sequence #.

    Les

>Thanx,
>
>-jeelani.sm
>
>-----Original Message-----
>From: mike shand [mailto:[email-masked]]
>Sent: Wednesday, April 21, 2004 2:41 AM
>To: Jeelani Syed; [email-masked]
>Cc: [email-masked]; [email-masked]; [email-masked]
>Subject: Re: [Isis-wg] ISIS graceful restart...
>
>
>My apologies Jeelandi, I thought you were simply questioning whether
you
>
>had to wait for timer expiry, as opposed to cancelling. But you are
>right,
>this should be when T1 is cancelled. This is actually a remnant of the
>original design where we didn't want to refresh the adjacency until we
>were
>sure that the restart recovery was complete. But that changed a while
>ago,
>and somehow this piece of text was not changed accordingly, but, as Les
>pointed out, the state table was.
>
>We should fix this.
>
>          Mike
>
>
>At 19:58 20/04/2004 +0100, mike shand wrote:
> >At 14:14 20/04/2004 -0400, Jeelani Syed wrote:
> >>Hi,
> >From  draft-ietf-isis-restart-05.txt, section 3.3.1( Adjacency
> >>reacquisition during restart )
> >>it says.
> >>
> >>    "Once the timer T3 has expired or been cancelled, subsequent
IIHs
>are
> >>     transmitted according to the normal algorithms, but including
the
> >>     restart TLV with both RR and RA clear."
> >>
> >>I am wondering why restart router needs to wait untill T3 expires to
>send
> >>IIH with RA and RA cleared.
> >>Can it be done once T1 expires? If not why?
> >
> >
> >T3 has expired OR BEEN CANCELLED
> >
> >You don't need to wait until T3 expires.
> >
> >         Mike
> >
> >
> >
> >>Thanx,
> >>
> >>-jeelani.sm
> >>
> >>_______________________________________________
> >>Isis-wg mailing list
> >>[email-masked]
> >>https://www1.ietf.org/mailman/listinfo/isis-wg
> >
> >
> >_______________________________________________
> >Isis-wg mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/isis-wg

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

---

From: mike shand <[email-masked]>
Date: Wed, 21 Apr 2004 16:46:08 +0100

>you think it is worth mentioning it in draft or it is implicit?

I think it is implicit, since (as Les has said) it is normal operation of 
the update process, which is not changed by this draft.

         Mike