Subject: [Isis-wg] 4.2 c) draft-ietf-isis-restart-02.txt

From: Noguchi Kay <[email-masked]>
Date: Wed, 26 Feb 2003 13:07:33 -0800

Hi Mike,

I have a question regarding 4.2 c) Adjacency re-acquisition.

In 4.2 c),

>   c) if the corresponding interface is a Point-to-Point interface, or 
>     if the receiving router has the highest LnRouterPriority (with 
>     highest source MAC address breaking ties) among those routers 
>     whose IIHs contain the restart TLV, excluding the transmitting 
>     router (note the actual DIS is NOT changed by this process.), 
>     initiate the transmission over the corresponding interface of a 
>     complete set of CSNPs, and set SRMflags on the corresponding 
>     interface for all LSPs in the local LSP database. 

	Could you tell me the reason why helper router should send CSNPs
	and set SRMflags for each LSPs?

	As noted below, standard process can acheive the database
	synchronization without any special treatment.

	What do you think?

1) On Point-to-Point interface

   Restarting router sends CSNP with own LSP only. Then neighbor router
   just sets SRMflags for missing LSPs and synchronization will be done
   as normal.

2.1) DIS restarting on Broadcast interface

   Restartng router sends CSNP with own LSP only. Then neighbor routers
   just sets SRMflags for missing LSPs and synchronization will be done
   as normal.

2.2) nonDIS restarting on Broadcast interface

   Restarting router receives CSNPs from DIS after some period, but less
   than CSNP interval, and restarting router sets SSNflags for missing
   LSPs and synchronization will be done as normal.

Thank you,

								kay

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

---

From: Les Ginsberg <[email-masked]>
Date: Wed, 26 Feb 2003 14:24:05 -0800

>         synchronization without any special treatment.

Kay -

You are correct is stating that the normal operation of the update process 
will eventually result in database synchronization. But one of the 
requirements of restart is for the restarting router to be able to 
deterministically know WHEN it has achieved database synchronization. In 
order to do that the restarting router must know the set of LSPs that it 
should expect in order to reach "synchronization". This requires receiving 
a full set of CSNPs from your neighbor(s). When the restarting router has 
received all of the LSPs mentioned in the CSNPs, it can then declare itself 
synchronized (cancel T2 timers and T3 timer) and begin to update FIB, clear 
OL bit and regenerate its own LSPs, etc.

On Point-to-point interface CSNPs would not normally be sent unless 
adjacency transitioned to UP. In the restart case we are trying to prevent 
an unnecessary down-up transition, so we must get the neighbor to send 
CSNPs even though adjacency state has not transitioned to UP.

On Broadcast interface, if restarting router was DIS, CSNPs would not 
normally be sent by other routers, so we must get the router which would be 
elected DIS in the absence of the restarting router to send the CSNPs. If 
the restarting router was NOT DIS, we would like the current DIS to send 
CSNPs immediately (rather than waiting for expiration of the next SNP 
interval) so as to make database synchronization faster.

In all cases the router sending CSNPs must set SRMflags to initiate the 
sending of the LSPs to the restarting router.

    Les

---

From: Noguchi Kay <[email-masked]>
Date: Wed, 26 Feb 2003 16:02:53 -0800

Hi Les,

Thank you for your quick reply.

I understand the deterministic synchronization then why don't we put
one line after the clause that tells us the reason to send the CSNPs
and LSPs by helper router like below.

>     complete set of CSNPs, and set SRMflags on the corresponding
      interface for all LSPs in the local LSP database to achive the
      deterministic synchronization for resterting router as stated
      in section 4.3.

Thank you,

								kay

---

From: Les Ginsberg <[email-masked]>
Date: Wed, 26 Feb 2003 16:16:08 -0800

>and LSPs by helper router like below.

Given the statement in Section 3

   "Secondly, whether or not the router is being re-started, it is
    desirable to be able to determine when the LSP databases of the
    neighboring routers have been synchronized (so that the overload bit
    can be cleared in the router's own LSP, for example). This document
    describes modifications to achieve this. "

your proposal seems unnecessary.

    Les