Subject: RE: [Isis-wg] IS-IS Restart Capability: receiving/processing "old " IIH packets?

From: "Miyagishima, Corwyn (Corwyn)" <[email-masked]>
Date: Mon, 8 Apr 2002 12:41:38 -0400

Ok, I think I was confusing "not containing the 're-start' option" with not
responding with the RA bit, and you just confirmed for me that we should
ignore the IIH(s) received without the RA bit set, so that takes care of my
question.

Thank you very much!

Corwyn Y. Miyagishima
Senior Software Engineer
Lucent Technologies
978-952-7632 

> -----Original Message-----
> From: mike shand [mailto:[email-masked]]
> Sent: Monday, April 08, 2002 12:37 PM
> To: Miyagishima, Corwyn (Corwyn)
> Cc: [email-masked]'; Sciandra, Francesco (Francesco)
> Subject: Re: [Isis-wg] IS-IS Restart Capability: receiving/processing
> "old" IIH packets?
> 
> 
> At 11:56 08/04/2002 -0400, Miyagishima, Corwyn (Corwyn) wrote:
> 
> >I guess it's time for me to delurk...
> >
> >It seems as though there's a decently high (or at least non-zero)
> >probability that Restart Capability can fail under normal operating
> >circumstances, if I'm reading the draft properly.  Please 
> forgive me if this
> >has been discussed before (I didn't see it in the archives) or if I'm
> >misunderstanding something...
> >
> >Given that a restarting router ("A") is probably in an 
> unstable state for
> >some length of time, it might not be immediately able to 
> process the packets
> >it receives, so a periodic IIH might be sent by a neighbor 
> ("B") before A
> >has signalled a restart, but not processed until after A has 
> sent an IIH
> >with the RR bit set.  As such, A will then assume that B has failed a
> >restart and revert back to a start, rather than a restart.  Is this a
> >correct analysis?
> 
> No. The text below from the draft describes the case where 
> the IIH contains 
> NO restart option.
> 
> Receipt of an IIH not containing the "re-start" option is 
> also treated as 
> an acknowledgement, since it indicates that the neighbor is 
> not re-start 
> capable. In this case the neighbor will have re-initialized 
> the adjacency 
> as normal, which in the case of a Point-to-Point link will 
> guarantee that 
> SRMflags have been set on its database, thus ensuring eventual LSPDB 
> synchronization. In the case of a LAN interface, the usual 
> operation of the 
> update process will also ensure that synchronization is eventually 
> achieved. However, since no CSNP is guaranteed to be received 
> over this 
> interface, T1 is cancelled immediately without waiting for a CSNP. 
> Synchronization may therefore be deemed complete even though 
> there are some 
> LSPs which are held (only) by this neighbor (see section 4.3).
> 
> However, in the case you describe, the IIH will still contain 
> the restart 
> option (because the neighbor is re-start capable,) but it 
> will NOT have the 
> RA bit set. In this case it will simply be ignored and 
> eventually the IIH 
> with the RA bit set will be received (or if not, the RR will 
> be retransmitted).
> 
>          Mike
> 
> 
> >If, indeed, this is a side-effect of the current design, 
> would it be prudent
> >to allow A to "ignore" a certain number (1?  3?  42?) of 
> IIHs without the RA
> >bit set immediately following a restart, or is there a 
> better solution to
> >this?
> 
> 
> 
> 
> 
> >Thanks!
> >
> >Corwyn Y. Miyagishima
> >Senior Software Engineer
> >Lucent Technologies
> >978-952-7632
> >
> >_______________________________________________
> >Isis-wg mailing list  -  [email-masked]
> >http://spider.juniper.net/mailman/listinfo/isis-wg
> 
_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://spider.juniper.net/mailman/listinfo/isis-wg