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

From: Peter Higginson <[email-masked]>
Date: Wed, 02 Dec 1998 00:03:02 +0000

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: Mike Shand <[email-masked]>
Date: Wed, 02 Dec 1998 09:53:46 +0000

>since the variables do not exist in the OSI or DEC documentation.

Yes. One of the features of the DEC management specification (and the ISO
stuff derived from it) was that whenever a variable used by the algorithms
themselves was exposed to management it was given the same name. So it was
obvious exactly what the relationship was. I think we need to continue this
(IMHO) excellent tradition. Either we need to be careful to have the
original names in the MIB (as has been done mostly via the REFERENCE), or
when we invent new 'thingies' we need to propose updates to the spec to
describe exactly how the thingie is used by the algorithms.

Or am I an old fuddy duddy?

	Mike