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

From: "Kandula, Ramesh" <[email-masked]>
Date: Fri, 24 Mar 2006 21:07:00 -1000

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg

---

From: "Les Ginsberg \(ginsberg\)" <[email-masked]>
Date: Sun, 26 Mar 2006 15:36:34 -0800

Jeff -

I think Sandip's point is of significance. In order for the scenario you
raise to be relevant here you have to have some routers in which the
forwarding plane is protected by UPS but the control plane is not -
while other routers are fully protected (or otherwise isolated from the
power failure).

Nevertheless, I agree that the scenario raised by Ramesh needs to be
considered - and to the extent your example suggests ways in which it
might occur - however unlikely - that is helpful.

   Les

> -----Original Message-----
> From: Parker, Jeff [mailto:[email-masked]]
> Sent: Sunday, March 26, 2006 11:28 AM
> To: Sandip Devnath (sadevnat); Les Ginsberg (ginsberg); Kandula,
Ramesh;
> [email-masked]
> Subject: RE: [Isis-wg] Question about IS-IS Restart Signaling
> 
> I don't think this is a case we should alter the design for.
> I can imagine a scenario where some routers are on a UPS, and others
are
> not.
> 
> Again, this is an existence proof that the problem can happen, not
> something we need to engineer for.
> 
> - jdp
> 
> ________________________________
> 
> From: Sandip Devnath (sadevnat) [mailto:[email-masked]]
> Sent: Sun 3/26/2006 12:46 PM
> To: Parker, Jeff; Les Ginsberg (ginsberg); Kandula, Ramesh; isis-
> [email-masked]
> Subject: RE: [Isis-wg] Question about IS-IS Restart Signaling
> 
> 
> 
> Wouldn't it cause whole forwarding to go away? Graceful restart's
> requirement is to have the forwarding intact, while routing protocol
> restarts (across different cards or same card).
> 
> Regards
> Sandip
> 
> -----Original Message-----
> From: Parker, Jeff [mailto:[email-masked]]
> Sent: Saturday, March 25, 2006 4:40 AM
> To: Les Ginsberg (ginsberg); Kandula, Ramesh; [email-masked]
> Subject: RE: [Isis-wg] Question about IS-IS Restart Signaling
> 
> I would think that losing power in a building and recovering might
well
> give you several routers rebooting at once.
> 
> - jeff parker
> 
> ________________________________
> 
> From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
> Sent: Sat 3/25/2006 3:02 AM
> To: Kandula, Ramesh; [email-masked]
> Subject: RE: [Isis-wg] Question about IS-IS Restart Signaling
> 
> 
> 
> 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"
> 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.
> 
> 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.
> 
>    Les
> 
> 
> > -----Original Message-----
> > From: Kandula, Ramesh [mailto:[email-masked]]
> > Sent: Friday, March 24, 2006 11:07 PM
> > To: [email-masked]'
> > Subject: [Isis-wg] Question about IS-IS Restart Signaling
> >
> > Hi all,
> >

---

From: "Les Ginsberg \(ginsberg\)" <[email-masked]>
Date: Sun, 26 Mar 2006 15:59:03 -0800

Hannes -

> From: Hannes Gredler [mailto:[email-masked]]
> Sent: Sunday, March 26, 2006 12:51 PM
> To: Les Ginsberg (ginsberg)
> Cc: Kandula, Ramesh; [email-masked]
> Subject: Re: [Isis-wg] Question about IS-IS Restart Signaling
> 
> hi les,
> 
> some disagreement from my side - see comments inline;
> 
> Les Ginsberg (ginsberg) wrote:
its
sent
> 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.

two
> 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
> 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
> >>According to RFC 3847, if multiple routers on a broadcast network
> >
> > restart
> >
> >>around the same time, is the helper (receiving) router supposed to
> >
> > include
> >