RE: [Isis-wg] Question about IS-IS Restart Signaling

["Les Ginsberg \(ginsberg\)" <ginsberg at cisco.com>]

Hannes -

> -----Original Message-----
> From: Hannes Gredler [mailto:hannes at juniper.net]
> Sent: Sunday, March 26, 2006 12:51 PM
> To: Les Ginsberg (ginsberg)
> Cc: Kandula, Ramesh; isis-wg at ietf.org
> Subject: Re: [Isis-wg] Question about IS-IS Restart Signaling
> 
> hi les,
> 
> some disagreement from my side - see comments inline;
> 
> Les Ginsberg (ginsberg) wrote:
> > Hmmm...an interesting question.
> >
> > I would have to say that the RFC is not explicit on this point.
> >
> >>From an interoperability standpoint, I would be concerned that
> > implementations might not parse past the initial restart TLV and
> > therefore might not process a second restart TLV. This would not be
> > fatal as the restarting router would eventually retransmit an IIH-RR
> > (presumably by this time the other restarting router would have seen
its
> > RA) - but would be suboptimal as it would delay the reestablishment
of
> > the adjacency on the part of the restarting router. On the other
hand,
> > it would provide a means of decreasing the total number of IIH-RAs
sent
> > in response to the IIH-RRs in such a case.
> >
> > This is, of course, a very unlikely case for two reasons:
> >
> > 1)It is unlikely that two routers would restart "at the same time"
> 
> what about a buffer overrun during LSP parsing and a subsequent crash
> in the isis module ? - since GR is engineered for control-plane
failure
> this *is* the case we are trying to address.
> 

The primary application of GR is in the case of controlled restarts
(e.g. software upgrade). To the extent that the technology is also
useful in unexpected control plane failure cases I would argue that it
is most useful in cases of hardware component failure (assuming a
redundant component is available).

The case you cite is a very problematic use of GR. Knowledgeable
customers are going to ask why they should have confidence that the same
software which just failed is likely to survive when faced with the same
link state database which caused the failure. While it is possible that
a reboot might clear whatever set of conditions caused the original
failure, it is hardly assured - and this is NOT the primary case GR is
designed to address.

BTW, this is EXACTLY why RFC 3847 specifies rules to prevent the helper
router from supporting multiple restarts from the same router within a
short period of time.

> > 2)As the requirement on sending the IIH-RA is to send it
"immediately"
> > (with jitter on the LAN) the interval between receipt of IIH-RR from
two
> > different routers would need to be quite small.
> 
> the IIHs with the restart request could have been batched up,
> until the adjacency mgmt module drains the IO queue making
> them appear to have arrived simultaneous.
> 
> > In the conservative spirit of being "strict in what you send" I
would be
> > inclined to NOT include multiple restart TLVs in the same IIH. I
would
> > recommend sending two IIHs one immediately after the other. Note
that
> > such short bursts are already allowed in the case of LSP/CSNP
> > transmissions.
> 
> i fail to see a violation of the "strict in what you send" by packing
> multiple restart TLVs in a single IIH. what you are proposing actually
> is a violation of "be liberal what you receive" principle by ruling
> out a ligitimate way of encoding information in a single IIH.

As the RFC does NOT specifically state that multiple restart TLVs can be
included in an IIH I can imagine that implementations might be written
to only parse for the first occurrence. If I want to have the highest
confidence that what I send will be correctly interpreted by all
conforming implementations, then sending two IIHs with a single restart
TLV in each is clearly the way to go. Any implementation which cannot
correctly process such an IIH is flawed.

If however, I send a single IIH with multiple restart TLVs, I leave open
the possibility that some implementations might not look at the second
restart TLV. At that point there is a legitimate discussion (as
demonstrated by this thread) as to whether the sender or the receiver is
non-conformant. Such an argument is not one that any customer would
appreciate. So, as the sender I choose the more conservative path.

> 
> an implementation note:
>    most implementations have an internal representation of the data
>    found in TLVs. it is highly recommended to store any data found
>    in tree / list representation i.e. you may append information at
any
>    time. so ruling out "data may be spread over multiple TLVs" is like
>    encouraging bad coding habits ;-)
> 

If you are saying that you know of one implementation of RFC 3847 that
would correctly process multiple restart TLVs in a single IIH, that is a
worthwhile data point. In fact, I invite all implementers of RFC 3847 to
let me know how their implementations handle this case in both roles
(i.e. sender and receiver). It would be useful to the community to
publish the results of that survey.

   Les

> /hannes
> 
> >>-----Original Message-----
> >>From: Kandula, Ramesh [mailto:Ramesh.Kandula at SpirentCom.COM]
> >>Sent: Friday, March 24, 2006 11:07 PM
> >>To: 'isis-wg at ietf.org'
> >>Subject: [Isis-wg] Question about IS-IS Restart Signaling
> >>
> >>Hi all,
> >>
> >>According to RFC 3847, if multiple routers on a broadcast network
> >
> > restart
> >
> >>around the same time, is the helper (receiving) router supposed to
> >
> > include
> >
> >>multiple instances of Restart TLVs with RA bit set (one for each
> >>restarting
> >>router) in it's hellos?
> >>
> >>thanks
> >>ramesh
> >>
> >>_______________________________________________
> >>Isis-wg mailing list
> >>Isis-wg at ietf.org
> >>https://www1.ietf.org/mailman/listinfo/isis-wg
> >
> >
> > _______________________________________________
> > Isis-wg mailing list
> > Isis-wg at ietf.org
> > https://www1.ietf.org/mailman/listinfo/isis-wg

_______________________________________________
Isis-wg mailing list
Isis-wg at ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg