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

From: [email-masked]
Date: Thu, 04 Mar 1999 20:40:49 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IS-IS for IP Internets Working Group of the IETF.

	Title		: Management Information Base for IS-IS
	Author(s)	: J. Parker
	Filename	: draft-ietf-isis-wg-mib-00.txt
	Pages		: 71
	Date		: 03-Mar-99
	
     This document describes a management information base for the
     IS-IS Routing protocol,  as described in RFC 1142 [2], when it
     is used to construct routing tables for IP networks, as
     described in RFC 1195 [3].
 
     This memo defines an experimental portion of the Management
     Information Base (MIB) for use with network management
     protocols in the Internet community.
 
     This memo is based on a    draft revision of an IETF MIB dated
     March of 1994 and titled 'Integrated IS-IS Management
     Information Base'.  This version has been modified to include
     MIB-II syntax, to exclude portions of the protocol that    are
     not relevant to    IP, such as the ES-IS protocol, and to add
     management support for current practice.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-mib-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-isis-wg-mib-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-isis-wg-mib-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Peter Higginson <[email-masked]>
Date: Sat, 13 Mar 1999 20:45:16 +0000

Some comments on the revised MIB. Unfortunately I will not be in
Minneapolis (but Jitu Patel from my group will be there).

First, thanks for adopting most of my suggestions. There are the
following further comments. (My original have >> and  Jeff's
responses >).

>> page 21 - I can see a use for the "Protocol Supported" table 
> and Fred Baker sees even more uses... Fixed

It would be useful to put back the ISAdjProtSupport table as well - so
you can see what protocols the neighbors support.

>> page 26 - I don't see the logic for omitting
> isisCircL1HelloMultiplier,
> Changed to one, called ....CircHelloMult... We can discuss this later

I still think that as we have two Hello Timers, it would be worth having
two Multipliers, one for L1 and PtP and another for L2.

>> 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. 
> I believe I've fixed these.  

They are still shown as "read-only" in all the cases I found. 
(I have #ifdef's round my code for all these cases, so I can
cope with either answer - I'd just like to get the MIB right.)

>> 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
> These look like the same variable to me.  
> I've used 300: I'm sure you had something else in mind

This typo of mine has resulted in Jeff giving isisSysMaxLSPGenInt
a default of 60 and a max of 120 seconds. What I intended was:

        isisSysMaxLSPGenInt	OBJECT-TYPE
     	SYNTAX Integer32 (1..65535)
     	MAX-ACCESS read-write
     	STATUS current
     	DESCRIPTION
     	    "Maximum interval, in seconds, between generated LSPs by
     	    this instance. This	object follows the resettingTimer
     	    behaviour."
     	REFERENCE "{ISIS.aoi maximumLSPGenerationInterval (6)}"
     	DEFVAL { 900 }
         ::=	{ isisSysEntry 7 }

         isisSysMinBroadLSPTransInt OBJECT-TYPE
     	SYNTAX Integer32 (1..1000)

Whether the group agrees with my limit on isisSysMinBroadLSPTransInt
or not, isisSysMaxLSPGenInt must go back to having a 15 minutes
default (900 seconds).

A comment I missed last time:

We have also implemented the isisIPDestTable so I would like to
see that go back in (as optional). It is not easy in SNMP terms
because it uses OID's as indexes, however it does show you
where routes come from and so is useful.

Peter Higginson

---

From: Rajesh Balay <[email-masked]>
Date: Mon, 15 Mar 1999 13:13:34 -0500

I am touching a topic which we had discussed before...

There are references in the draft to objects which are not part of the spec.;
the issue is: should the MIB be the place where folks are going to discover
these items, or should the scope of the MIB be limited to what is described
in the spec.,  wg drafts, etc.

I have come across the following:

1. isisSysLSPIgnoreErrors

Isn't this a proposed fix .... or is there any reason to operate routers which
do not ignore lsp checksum errors i.e., given the choice.

2. isisCircLspInterval, isisCircLSPTrottle

If they refer parameters specified in the spec, it would be better
to use the parameter name instead. If these are something new, shouldn't
we have a document explaining these.

3. isisCircMeshGroupEnabled, isisCircMeshGroup

Again, a draft explaining this would help before we add this in to the MIB.

Leaving items as these in the MIB without having an agreed upon interpretation
may lead to compatibility problems. From the discussion in december (notes from
Tony P., Mike Shand, Jeff Parker), there seems to be a consensus on having
more words of wisdom on such parameters which are outside of the spec.; 
drafts on each of these or a "current practices" document detailing these items
is someting which is required.....looks like nobody has stepped-up yet.

I could "compile/edit" such a document assuming the authors/vendors/users 
of these features, etc., are willing to contribute.

regards,
-rajesh