Subject: Re: I-D ACTION:draft-parker-isis-wg-mib-00.txt

From: Peter Higginson <[email-masked]>
Date: Thu, 26 Nov 1998 00:02:33 +0000

Some comments on the draft.

First thanks for the hard work that went into preparing this, please take
the following as constructive. Most of the comments are based on our
implementation of IS-IS that is currently being tested.

page 9 - I don't see the logic for leaving "isisSysExistState" out,
although I think a comment to the effect that some implementations may not
allow you to alter it would be fine.

This also raises a general point as to whether we should try to maintain as
much compatibility with the previous version as possible. (Which assumes
you have the same previous version as I do of course.) If there is a
general feeling that we should, then there are a few more changes that
would make sense.

page 10 - I'd like to understand the rationale for leaving the AuthXxxPwd
entries out. I thought that there were implementations that used simple
passwords - or are these only on circuits.

page 11 - isisSysID should be read-write, the comment implies this and I
certainly see a use for it in overriding a default ID.

page 21 - I can see a use for the "Protocol Supported" table for allowing a
management station to distinguish between IP only and dual implementations.
If you only implement IP, it is a constant reply and not the most difficult
part of the SNMP to do.

page 26 - I don't see the logic for omitting isisCircL1HelloMultiplier,
given that all the rest are there. In our implementation, we have also
added isisCircRetranInterval and isisCircRetranThrottleInt to this set.

While we are on Circuits, we have a need for an adjunct to isisCircIfIndex,
where a circuit is on some part of a object with an IFIndex. This would
hold something like a DLCI for FR or a VPI/VCI for an ATM PVC. I'm not sure
what the right way to do this is, while 32 bits would be enough for now, we
might need a variable string.

page 44 - We have not implemented (yet anyway) the isisISAdjAreaAddrTable
because it seemed of little relevance to IP. So I'd like to see this as
optional.

On the other hand, we have implemented the isisISAdjIPAddrTable, the
isisISAdjProtSuppTable and the IPRATable because these did seem to have
direct relevance to IP. I'm happy to have these as optional, but I would
like to see them back in.

page 57 - All the previous versions that I have seen have had Chris Gunner
quoted as author.

A few more general comments:

In other MIBs (but not consistently) I have seen the Indexes marked as
"not-accessible". Not doing this means that if you walk the MIB you get
quite a number of entries like:
	1.3.6.1.3.37.3.3.1.4.1.2.1.2.2.2.2 = 2.2.2.2
	1.3.6.1.3.37.3.3.1.4.1.3.1.4.4.4.2 = 4.4.4.2
where you are just returning part of the index. These don't serve any
purpose and usually there are non-index variables in the same table so that
you do not lose information by omitting the indexes. (In the exception
cases you would have to have at least one index readable.) I'm not an SNMP
expert, is there a preferred way, can we change??

It has always concerned me that some timers could be set to silly values
(eg isisSysMinLSPTransInt which is a retransmission time of 18 hours). I
have implemented the following limits:
	isisSysMinLSPTransInt	1..300
	isisSysMinLSPTransInt	1..1000
	isisSysMinLSPGenInt	1..120
	isisSysPartSNPInt		1..120
	isisSysDRISISHelloTimer	1..120
Most of these would not be good to set at the max, but at least a line
monitor might see the occasional packet. (isisSysWaitTime and the ES timers
would also need limits but I did not allow changes to these in my code.)

Looking at things that we have put into our enterprise MIB for IS-IS, there
are various implementation control values (eg expected LSP's, circuits etc.
to control initial table sizes), control of forcing the database overload
bit, ignoring LSP errors, processing rate control and a few others. I'm not
sure if any of these would be general enough to go into the main MIB but
I'm willing to provide the complete list if anyone wants it.

Regards,
Peter