Subject: RE: More comments on - I-D ACTION:draft-parker-isis-wg-mib-00.txt

From: Peter Higginson <[email-masked]>
Date: Wed, 02 Dec 1998 01:24:40 +0000

Jeff,

The problem with taking the default on circuit creation is that if
you later change the default it does not change the default values on the
circuits already created.

A better way is to make the circuit value default to zero and define zero
to mean take the system wide default.

Peter

At 19:23 01/12/98 -0500, you wrote:
>Peter -
>	You are right about the overlap.  Cisco allows you
>to modify several system wide parameters on an interface basis
>as well.  I'm using the following model
>
>	upon circuit creation take the system wide variant
>	use that, until configured otherwise
>
>This would be hard to capture without duplicate fields.
>
>On your second point, I want to see much clearer
>descriptions of all of these timers.  Reasonable folks
>could disagree about what today's text means.
>
>- jparker
>- nexabit.com
>
>> -----Original Message-----
>> From:	Peter Higginson [SMTP:[email-masked]]
>> Sent:	Tuesday, December 01, 1998 7:03 PM
>> To:	[email-masked]
>> Subject:	More comments on - I-D
>> ACTION:draft-parker-isis-wg-mib-00.txt
>> 
>> 
>> Having tried to convert our implementation from the old draft to the
>> new one, I had some problems with the new variables in Circuit Table.
>> 
>> I think as a minimum we need better explainations for the new
>> variables
>> since the variables do not exist in the OSI or DEC documentation.
>> 
>> I think I have 2 basic difficulties:
>> 
>> 1) Overlap between the System and Circuit Tables
>> ================================================
>> 
>> The best example of this is seen by comparing isisSysCompSNPInt with
>> isisCircL1CSNPInterval and isisCircL2CSNPInterval. The definitions are
>> the same and something must be redundant.
>> 
>> Similarly isisSysMinLSPTransInt and isisCircLSPInterval.
>> 
>> Some customer requests I have seen ask for as much as possible to be
>> "per-circuit" manageable. We are in danger of generating more
>> duplicates
>> and I'd therefore like to make the (somewhat radical) suggestion that
>> the following move from the System table to the Circuit table:
>> 
>> 	MinLSPTransInt		(ie delete as duplicate)
>> 	MinBroadLSPTransInt
>> 	CompSNPInt			(ie delete as a duplicate)
>> 	PartSNPInt
>> 
>> I would also like to rename isisCircLSPInterval to
>> isisCircLSPRetranInt and
>> set its default to 5 seconds (the current 1200 seconds must be a
>> mistake).
>> 
>> 
>> 2) Separation of LAN and Point-to-Point cases
>> =============================================
>> 
>> Some variables apply only to broadcast or to point-to-point circuits
>> but
>> others (mainly the variables controlling Hello Timers) can have
>> different
>> values for broadcast L1, broadcast L2, Designated Router (at both
>> levels)
>> and point-to-point. One simplification is to use the broadcast L2
>> values
>> for point-to-point circuits but we should say so.
>> 
>> 
>> Regards,
>> Peter
>
>

---

From: Antoni Przygienda <[email-masked]>
Date: Tue, 01 Dec 1998 21:18:13 -0500

> >> 2) Separation of LAN and Point-to-Point cases

yes, plenty timers can be split L1 and L2 and it's unclear which one
hold 
for the p2p case. I saw different treatements. I always thought that
using 
L1 values is fine but then if the router is L2 only, it doesn't make
much 
sense ?

		thank you

		--- tony

---

From: Mike Shand <[email-masked]>
Date: Wed, 02 Dec 1998 09:45:34 +0000

Let's not repeat the mistakes I made with the original DEC management. The
overloading of the various timer variables has caused untold confusion.
Let's bite the bullet and have explicit variables for each one. If we want
to sugar the pill by having some interesting defaulting relationships along
the lines Peter suggests, that's fine, but don't let it obscure what is
going on.

So that means for the hellos we need per circuit
L1 Broadcast
L2 Broadcast
L1 DR
L2 DR
Pt-pt

and similarly for the multipliers

If we did Peter's thing of duplicating these for the system, and defaulting
all the circuit ones to 0 (meaning take the system default), then the
actual amount of config required for simple cases would be minimal. The
downside of Peter's scheme would be that a manager or management
application wanting to find the value for a particular circuit would have
to look at the circuit, and if that was zero go look at the system. I don't
see that as much of a problem. Maybe we should name the system one
defaultfoobar or some such in order to reduce the possibility of confusion.

I guess the main issue is that doing this would force implementations to
allow all these things to be tweaked independently, while the underlieing
protocol standards make no such requirement. Do we want to force the change
into the protocol standards on the grounds that this level of flexibility
is actually required in the real world? Or do we want to have some cop out
mechanism for existing implementations?

For the LSP timers I guess we need

for the system ONLY

MaxLSPGenInt
MinLSPGen Int
MaxAge
ZeroAgeLifetime (does anybody EVER change this from 1 minute? I guess a
VERY big/slow network might want it higher.)
WaitingTime

each of them duplicated for L1 and L2

Then for each circuit, with a master on the system as before

MinLSPTransInt
MinBroadcastLSPTransInt*
CompleteSNPInt
PartialSNPInt

* i.e. throttle. There's no need to limit it to broadcast circuits, but
possibly different default values are appropriate. BTW, the value of 33
milliseconds was chosen to prevent overrun reception in some very old DEC
hardware (microserver for the cognoscenti). It is probably very
inapropriate for current hardware. Does anyone actually implement all the
complex holdback based on reception queues? (clause 7.3.15.6) Its all
designed to try to minimise the retransmission storm when a large number of
routers on a LAN all have a burst of LSPs to send.

Again the above attributes should be duplicated for L1 and L2

Would that be overkill?

I guess the other nasty question is do we want any of the existing second
based hello timers to be sub-second?

Oh and a final unrelated question. What is mean exactly by disabling
checking of maximum area addresses as described for isissysmaxareacheck?
Which of the following does that include?

1. checking the value of the maxareaaddresses field in an incoming LSP, SNP
or IIH.
2. checking that the combined number of area addresses in ALL L1 LSPs
doesn't exceed maxareaaddress.

I assume it means both, but it probably needs to be made explicit.

	Mike

---

From: Peter Higginson <[email-masked]>
Date: Thu, 03 Dec 1998 10:45:23 +0000

I agree with Mike that having explicit variables for each timer, multiplier,
etc. is the best way. We were going to add these to our enterprise MIB to
fill in the gaps in the previous draft MIB.

You then have the problem of duplication, to which I can see three solutions:

1) Choose good defaults and just have the variables in the Circuit Table.

2) The System Table has defaults that are copied when the circuit is created.

3) 0 is the default in the Circuit Table and means use the System Table value.

The current draft has fixed defaults in the Circuit Table making the System
table entries redundant so it has to be changed in some way.

My personal preference would be 1) since it is simplest and most
straightforward
followed by 3) if people really feel that global defaults are important.

While thinking about this, I realised that, for the Hello timers, the
"ResettingTimer behaviour" does not cover the case where you increase the
timer to more than the previous holding time, because the adjacency will
then time out before you send the next hello.

(IMHO - The ResettingTimer behaviour is not necessary for short timers and
 would not be needed for hello timers if the maximum permitted value were
 to be limited to a minute or two rather than the 1000 minutes it is
 currently.)

Peter

============================================================================
====

---

From: Mike Shand <[email-masked]>
Date: Thu, 03 Dec 1998 11:37:48 +0000

> to be limited to a minute or two rather than the 1000 minutes it is

Yes, as I'm sure your well aware, Peter (but others may not be), the
resetting timers behaviour is designed to avoid the problem of accidentally
setting the timer to a very long value, realizing your mistake and setting
it back to the shorter interval, but having to wait for the erroneous
longer time interval to expire before anything happens. i.e. you couldn't
correct your mistake.

As you rightly point out it doesn't allow you to change a timer upwards (to
a value greater than holdingMultiplier*originalhellottimer) without loosing
the adjacency. 

I can't for the life of me think why we didn't just say. "Whenever you
reset the timer, expire it and do the associated action immediately (with
the new timer value for any derived information in the PDU, such as holding
time), and then set the timer to the new interval." Maybe that would have
been too easy :-(

As you say, if the upper limit was reasonably short, there would be no need
for it.

Hmmmm. looks like I attempted to fix it in ISO 10733, where the behaviour
reads

"..... the next expiration of that interval takes place no later than the
expiration of the interval in progress or the specified interval whichever
is SOONER...."

but that's still wrong, or at least open to misinterpretation. Damn, this
is worse than describing the representation of MAC addresses, computation
of incremental checksums and MTU size determination all rolled into one :-)
What's wrong with "just do it NOW"?

	Mike