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

From: Jeff Parker <[email-masked]>
Date: Sat, 15 Nov 2003 15:44:33 -0500

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. 
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"

	ID Length

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

         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.  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.  

   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.  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. 

   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."

   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.

   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.  

   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)."

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?

---

From: Jeff Parker <[email-masked]>
Date: Mon, 17 Nov 2003 10:23:56 -0500

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

I don't want to belabour this, so this is my last suggestion...

	...All IIHs transmitted by a
	router with this capability enabled MUST ....

2) SA Bit

	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.
 
I'm just looking for the simplest description of behavior.
If the SA bit is set, and we understand it, we surpress 
the adjacency.  We may surpress it other times as well.
I find this easier to understand and implement. 

> >You are treading on implementation here.  There is no 
> >requirement to use own LSPs

Again, I'm trying to discover the simplest rule possible
that covers this case.  The more complex it is, the more
implementation errors I would anticipate.  

> >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. "
> 
> Yup. That looks good.

Works for me.  You could add

	"....SHOULD set the "Ajacency Three-Way State in the Hello
	and in the adjacency to 'Init'.... 

> >>This allows the starting router to signal the helper...
> >>I'd suggest something like
> >>
> >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  

Let me rephrase my suggestion, which is to let the user know
what is buried in section 3.2.1, without forcing them to turn
back and lose context.  Perhaps

	"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, with the following results:
	the helping router sends a complete set of LSPs (3.2.1 b)
	and a complete set of CSNPs may be sent (3.2.1 c)."

- jeff parker

---

From: Les Ginsberg <[email-masked]>
Date: Mon, 17 Nov 2003 10:15:06 -0800

>         router with this capability enabled MUST ....

This seems to lose what you were trying to achieve in the first place i.e. 
make a distinction between a router which is capable of supporting restart 
but has the feature disabled vs having it enabled. Can we agree to disagree 
on this and leave the text unchanged?

>I find this easier to understand and implement.

I find it confusing to suggest that an implementation has to suppress 
advertising an adjacency which it would not normally advertise (i.e. one 
that is NOT in the UP state) because it receives SA. SA has no impact 
unless the adjacency in question is UP.

>implementation errors I would anticipate.

If an implementation follows Annex C and does not look at own LSPs when 
performing SPF, then I think your presentation would be very confusing. It 
suggests that if advertisement of an adjacency is suppressed that the 
algorithm defined in Annex C is no longer applicable, which is not at all true.

>         and in the adjacency to 'Init'....

Jeff, I hate to keep disagreeing with you - but... can you find any case in 
RFC 3373 where the adjacency three-way state that is reported in the TLV 
differs from that which the reporting system has in its local adjacency 
table? If so, then your addition makes sense. But I don't think that is the 
case. They are always consistent.

> > whether SA is

But that is exactly what we want to avoid i.e. we want the behavior 
specified in 3.2.1(a,b, and c) to be performed whenever an IIH-RR is 
received, independent of whether SA is also set in the same IIH or not. 
Although one can see cases where not doing 3.2.1a might be appropriate we 
have decided to avoid extra complexity and just say "always do all of 
3.2.1". And, it always seems better to me to refer to a single definition 
rather than try to paraphrase it. Then there is no possibility that the 
reader could think we are specifying a variation on the 3.2.1 behavior.

    Les

---

From: Jeff Parker <[email-masked]>
Date: Mon, 17 Nov 2003 13:36:08 -0500

> Can we agree to disagree 

Of course 

> >back and lose context.   

Les -
	To restate, the goal is not to redefine, but to remind 
the reader what that section describes.  
	I will drop this as well.  

- jeff