Subject: RE: Restart Signaling for IS-IS - 05

From: Les Ginsberg <[email-masked]>
Date: Sat, 15 Nov 2003 20:20:18 -0800

Professor Parker -

Welcome to the party!

At 03:44 PM 11/15/2003 -0500, Jeff Parker wrote:
>A few nits on the first half of the document.  YMMV.
>I've put my suggestions in quotes.
>
>The original text is from a draft dated Nov 2003.

That's the latest.

>I will try to review the rest of the doc next week.
>
>- jeff parker
>
>    3.2     Restart TLV
>
>    ...All IIHs transmitted by a
>    router that supports this capability MUST include this TLV.
>
>This doesn't deal with the case that the router supports the capability, but
>the capability isn't enabled.  I'm not happy with the proposal below, but
>don't want to carp without offering an alternative.
>
>    "...All IIHs transmitted by a
>    router -that is supporting- this capability MUST include this TLV"
>

The point of the text is to make clear that a router which supports the 
capability sends the Restart TLV always, not just when it is 
restarting/starting (but you knew that). Frankly I am not concerned with 
whether the box has a knob to enable/disable the feature. If it is turned 
off, from an operational point of view the router doesn't support the 
feature. And I find your suggestion leads me to ask the questions:

"Is there something an implementation is supposed to do if it WAS 
supporting the feature? Or if it COULD support the feature but isn't? "

And I don't like where that leads us...

>         ID Length
>
>ID Length appears in a couple of spots.  Haven't we agreed that it is 6?
>

We've agreed that nobody uses anything other than 6. But the spec still 
allows different values, though they are not useful/interoperable. Are you 
flogging us because we choose to be strict in our presentation? Certainly 
the use of "ID length" here in no way is meant to imply that something 
other than 6 should be used. It just uses the terminology which is 
appropriate. Please see RFC 3373.

>          Type   211
>          Length # of octets in the value field (1 to (3 + ID Length))
>          Value
>
>I take this to mean that the TLV has variable length, though the figure
>seems to suggest that it always has 10 bytes.

We clearly state:

"(Note: Remaining fields are required when RA bit is set) "

Is this not clear enough?
I do not like "optional". If RA is set, the remaining fields are 
"required", not optional.

>   The suggestion below is
>clumsy, but I didn't find a precedent to steal from.
>                                            No. of octets
>              +-----------------------+
>              |   Flags               |     1
>              +-----------------------+
>              | Remaining Time        |     2 (optional)
>              +-----------------------+
>              | Restarting Neighbor ID|     ID Length (optional, and only
>present
>              +-----------------------+     if Remaining Time is present)
>
>And do we need to explain what to do if an RA has a zero Remaining Time?
>
>
>            Restarting Neighbor System ID (ID Length octets)
>
>              The system ID of the neighbor to which the RA refers.
>
>Nit - "to which -an- RA refers."  This TLV might be an RR, not an RA.

OK.

>
>    When a router receives an IIH with the restart TLV having the SA bit
>    set, if there exists on this interface an adjacency in state "Up"
>    with the same System ID, and in the case of a LAN circuit, with the
>    same source LAN address, then advertisement of the adjacency to the
>    neighbor in LSPs MUST be suppressed.
>
>Why do we care if there is already an adjacency?  Perhaps we had one once,
>but it timed out.

We care because we are trying to describe how behavior differs from what a 
router would do in the absence of this extension. If there is no adjacency 
in the UP state, then this extension does not apply as regards 
advertisement i.e. current rules are sufficient.

>There will still be aged LSPs lurking in the network,
>with the same chance of black holes.  I suggest
>
>    "When a router receives an IIH with the restart TLV having the SA bit
>    set, then the router must suppress advertisement of the adjacency to the
>    neighbor in his LSPs."
>
>I've also moved from the passive to active voice, which makes it clearer who
>is suppressing what to whom.

I note the improvement in clarity with active voice. Be happy to change that.

>
>
>
>    Note that a router which suppresses advertisement of an adjacency
>    MUST NOT use this adjacency when performing its SPF calculation.
>
>That is, we must use information consistent with the LSP we are sending, or
>
>    "A router which is suppressing advertisement of an adjacency
>    MUST use only the information advertised in its LSPs in its own SPF
>calculations.
>    Thus it MUST NOT use this adjacency in computing routes."
>

You are treading on implementation here. There is no requirement to use own 
LSPs in an SPF implementation. And I am aware of interoperable/correct 
implementations that do not utilize own LSPs. The point here is that if an 
implementation has followed the suggested algorithm in Annex C, it should 
take care to not use the adjacency which has been suppressed. It could be 
argued that we have no need to make this statement at all. It is not a 
normative statement - and both Mike and I try to keep non-normative 
statements to a minimum. However, given the subtlety of this point, it 
seemed worth including.

>    On a Point-to-Point circuit the "Adjacency Three-Way State" SHOULD
>    be set to "Init", because the receipt of the acknowledging IIH (with
>    RA set) MUST cause the adjacency to enter "Up" state immediately.
>
>It is not clear to me whose three way state this is, and if it is the state
>in the adjacency table or the state in the 3Way TLV.

Ummm...it's both. That is the restarting router sets the local adjacency 
three-way state to "Init" and then reports same in the IIH 3way TLV. I 
think the use of the term "Adjacency Three-Way State" is consistent with 
RFC 3373. As for clarifying ownership, how about:

    "On a Point-to-Point circuit the restarting router SHOULD set the
    "Adjacency Three-Way State" to "Init", because the receipt of the 
acknowledging IIH (with
    RA set) MUST cause the adjacency to enter "Up" state immediately. "

??

>    If an interface is active, but does not have any neighboring router
>    reachable over that interface the timer T1 would never be cancelled,
>    and according to clause 3.4.1.1 the SPF would never be run.
>    Therefore timer T1 is cancelled after some pre-determined number of
>    expirations (which MAY be 1). (By this time any existing adjacency
>    on a remote system would probably have expired anyway.)
>
>I think the comment
>                                 (By this time any existing adjacency
>    on a remote system would probably have expired anyway.)
>
>was left over from a time when you were suggesting 3 expirations.  It
>doesn't seem probably with 1 expiration.
>

If Mike has no objection, I am OK with removing the parenthetical comment.

>
>
>    For each interface (and in the case of a LAN circuit, for each
>    level), when an adjacency reaches the UP state, the starting router
>    starts a timer T1 and transmits an IIH containing the restart TLV
>    with the RR bit clear and SA bit set.
>
>    ...
>
>    On receipt of an IIH with RR bit set (regardless of whether SA is
>    set or not) the behavior described in 3.2.1 is followed.
>
>This allows the starting router to signal the helper that he thinks the
>adjacency is up.  I believe the reference in the second paragraph above is
>asking for the neighbors set of LSPs and CSNPs, not the first clause in
>3.2.1.  I'd suggest something like
>
>    "On receipt of an IIH with RR bit set (regardless of whether SA is
>    set or not) the behavior described in 3.2.1 b) and c) is followed:
>    the helping router sends a complete set of LSPs, and a complete set
>    of CSNPs is sent if the helping router meets the conditions described
>    in 3.2.1 c)."

Well, what you say is strictly true, but it creates a problem for the 
helper router in that it must discriminate between receiving IIH-RR from a 
starting router vs receiving one from a restarting router. It's true this 
could be derived from the setting of the SA bit, but I am not sure the 
extra complication is worth the trouble. The "danger" is that the helper 
router will not refresh the hold time until receiving an IIH w RR clear. If 
it takes longer than holdtime to exchange CSNPs, this could happen - but it 
could be argued that the adjacency should go down in such a case.

On the other hand, if we allow the helper router to skip 3.2.1a, then a 
misbehaving restarting router could keep an adjacency up indefinitely by 
sending IIH-RR-SA (which of course it should not do). This seems like a 
bigger danger than losing an adjacency due to poor CSNP delivery.

But, I'll think on this some more.

All of this "crept in" because we decided in later versions to allow the 
restarting router to buy more time during restart because there were some 
easily demonstrable cases where the remaining hold time after restart was 
insufficient (e.g. if restarting router was/is DIS on a LAN). So we allowed 
the helper router to update the holdtime after receiving an IIH-RR but 
tried to contain it so as to protect the helper router from a restarting 
router gone mad.

>This runs the risk of weakening the description of conditions for sending
>CSPNs, but some indication of what the section describes would help the
>reader.
>
>In any case, isn't this standard behavior?  Since the starter is forcing the
>adjacency to restart, isn't this behavior automatic?

What the starting router is trying to do here by sending RR is to make CSNP 
transmission reliable. Absent this draft, a router would send a set of 
CSNPs once after adjacency reaches UP state. In the rare event one of the 
CSNPs is lost, it will not be retransmitted. Use of the RR bit to trigger 
sending of CSNPs gives us a second (or third or...) chance if needed. Note 
that in the starting case we do not send RR until after the first 
expiration of T1. This gives the initial set of CSNPs (triggered by 
adjacency UP) a chance to arrive before requesting a second set.

Thanx Jeff.

    Les

---

From: Tony Przygienda <[email-masked]>
Date: Sun, 16 Nov 2003 09:38:09 +0100

> You are treading on implementation here. There is no requirement to 
> use own LSPs in an SPF implementation. And I am aware of 
> interoperable/correct implementations that do not utilize own LSPs. 
> The point here is that if an implementation has followed the suggested 
> algorithm in Annex C, it should take care to not use the adjacency 
> which has been suppressed. It could be argued that we have no need to 
> make this statement at all. It is not a normative statement - and both 
> Mike and I try to keep non-normative statements to a minimum. However, 
> given the subtlety of this point, it seemed worth including. 

I think the text is well worth it, there are tons of first-timers 
implementing one-way link-connectivity SPF only and wondering why
thinggns go wrong. This kind of drives the point home that you must use 
both sides of the adjacency

> helper router in that it must discriminate between receiving IIH-RR 
> from a starting router vs receiving one from a restarting router. It's 
> true this could be derived from the setting of the SA bit, but I am 
> not sure the extra complication is worth the trouble. The "danger" is 
> that the helper router will not refresh the hold time until receiving 
> an IIH w RR clear. If it takes longer than holdtime to exchange CSNPs, 
> this could happen - but it could be argued that the adjacency should 
> go down in such a case. 

I would warn against coupling the SA-bit to have some semantics in terms 
of 'it's a restarting router'. SA-bit is best considered as a bit
in its own merit and could be used by people for different purposes, 
even during restart.

>
>
> On the other hand, if we allow the helper router to skip 3.2.1a, then 
> a misbehaving restarting router could keep an adjacency up 
> indefinitely by sending IIH-RR-SA (which of course it should not do). 
> This seems like a bigger danger than losing an adjacency due to poor 
> CSNP delivery. 

Well, if he sets SA all the time, nobody's hurt in the network. 
Actually, I think even sending just SA should be allowed, keep adjancey up
but invisible to other people.

    thanks

    -- tony

---

From: mike shand <[email-masked]>
Date: Mon, 17 Nov 2003 11:09:38 +0000

>And I don't like where that leads us...

I agree. Supporting the feature MAY be operationally enabled and disabled, 
but we are talking about the case when it is enabled.

>appropriate. Please see RFC 3373.

I think it should be ID length since that is what it is in the base spec. 
The fact that we have an agreement to only use a particular value for ID 
length is irrelevant.

>I note the improvement in clarity with active voice. Be happy to change that.

Agreed.

>You are treading on implementation here. There is no requirement to use 
>own LSPs in an SPF implementation. And I am aware of interoperable/correct 

Yup. That looks good.

>If Mike has no objection, I am OK with removing the parenthetical comment.

Yes that's fine. It was gratuitous anyway.

>router will not refresh the hold time until receiving an IIH w RR clear. 
>If it takes longer than holdtime to exchange CSNPs, this could happen - 
>but it could be argued that the adjacency should go down in such a case.
>
>insufficient (e.g. if restarting router was/is DIS on a LAN). So we 
>allowed the helper router to update the holdtime after receiving an IIH-RR 
>but tried to contain it so as to protect the helper router from a 
>restarting router gone mad.
>
>
>What the starting router is trying to do here by sending RR is to make 
>CSNP transmission reliable. Absent this draft, a router would send a set 
>of CSNPs once after adjacency reaches UP state. In the rare event one of 
>the CSNPs is lost, it will not be retransmitted. Use of the RR bit to 
>trigger sending of CSNPs gives us a second (or third or...) chance if 
>needed. Note that in the starting case we do not send RR until after the 
>first expiration of T1. This gives the initial set of CSNPs (triggered by

---

From: mike shand <[email-masked]>
Date: Mon, 17 Nov 2003 11:15:03 +0000

At 09:38 16/11/2003 +0100, Tony Przygienda wrote:

>>own LSPs in an SPF implementation. And I am aware of 
>>interoperable/correct implementations that do not utilize own LSPs. The 
>>point here is that if an implementation has followed the suggested 
>>algorithm in Annex C, it should take care to not use the adjacency which 
>>has been suppressed. It could be argued that we have no need to make this 
>>statement at all. It is not a normative statement - and both Mike and I 
>>try to keep non-normative statements to a minimum. However, given the 
>>subtlety of this point, it seemed worth including.
>
>

Yes, I agree.

>>helper router in that it must discriminate between receiving IIH-RR from 
>>a starting router vs receiving one from a restarting router. It's true 
>>this could be derived from the setting of the SA bit, but I am not sure 
>>the extra complication is worth the trouble. The "danger" is that the 
>>helper router will not refresh the hold time until receiving an IIH w RR 
>>clear. If it takes longer than holdtime to exchange CSNPs, this could 
>>happen - but it could be argued that the adjacency should go down in such 
>>a case.
>
>in its own merit and could be used by people for different purposes, even 
>during restart.

I agree. The SA bit means "suppress the adjacency", that is all.

>Well, if he sets SA all the time, nobody's hurt in the network. Actually, 
>I think even sending just SA should be allowed, keep adjancey up