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

From: Antoni Przygienda <[email-masked]>
Date: Tue, 08 Dec 1998 00:09:51 -0500

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

I personally do not think that maintaining the compatibility should be a
limit.
Since this
effort is happening, a good MIB would be a desirable outcome instead of
a bad, 
compatible to "something-not-published" one ...

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

I hope I follow here, there should be 2 types of passwords, one which is 
specific to the domain/area, the other to the circuit. Different things
are 
getting validated using different passwords as described in the ISO
spec. And as far I remember last MIB did not have it ...

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

agreed ...

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

IMHO as well ...

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

yes, and taking the danger of being a bore
I would say however that we need a kind of "best-current practices"
document
that would contain the things deployed today & deemed usefull (e.g. the
timer per 
level is one of those) first & the MIB should align with that [which is
specifically
in our charter]  (as I mentioned earlier today). Using the MIB itself as 
the vehicle of such an undertaking seems to me to be the wrong tool for
this 
specific kind of task ...

		thank you

		--- tony

---

From: Peter Higginson <[email-masked]>
Date: Tue, 08 Dec 1998 13:22:38 +0000

>compatible to "something-not-published" one ...

I agree with that, I just wanted to have it clear that table entries will
not be compatible (even though currently, table numbers are).

>spec. And as far I remember last MIB did not have it ...

Unless my memory is defective, the previous MIB had the passwords but the
current draft only has one password per circuit. Given Tony Li's HMAC
presentation yesterday I think we need to put multiple passwords per
L1 and L2 area back in. 

>......
>Using the MIB itself as the vehicle of such an undertaking seems to me
>to be the wrong tool for this specific kind of task ...

I only partly agree. The MIB limits what you can manage, is exact and we
have to do it anyway. I'd prefer to get a good working MIB as soon as we
can. (Now the BCP has many non-MIB issues to cover.)

From your later message:
>Including sub-second timers in the spec is a pain IMHO and given the
>system constraints in a really loaded-box not very accurate anyway ;-)

Some of these are jittered and therefore have to be resolved at lower
granularity so you are operating sub-second anyway. For that reason in
our implementation we keep them internally in ms anyway.

What I would suggest is that we change the units to ms with a comment that
implementations may not implement granularity beyond seconds. That gives
scope for implementations to allow finer (and sub-second) control if they
wish.

Peter

---

From: Antoni Przygienda <[email-masked]>
Date: Tue, 08 Dec 1998 23:36:46 -0500

> not be compatible (even though currently, table numbers are).

more opinions ? 

> can. (Now the BCP has many non-MIB issues to cover.)

I didn't imply we don't need a good MIB, I implied that it will be funny 
to _just_ have a MIB documenting the issues without another
"human-readable" document 
 ? 

			thank you

		--- tony

---

From: Cleveland Mickles <[email-masked]>
Date: Wed, 09 Dec 1998 10:43:14 -0500

I should have mentioned this during the first ISIS WG
session but has anyone been looking into increasing 
this limit?  I'm aware that this is easier said than 
done.

Cleve...
Cable & Wireless, USA

---

From: Tony Li <[email-masked]>
Date: Wed, 9 Dec 1998 10:53:01 -0800 (PST)

Cleve,

This issue is addressed in a forthcoming document on traffic engineering
extensions.  The change is not difficult.

Regards,
Tony

|  From: Cleveland Mickles <[email-masked]>
|  
|  
|  I should have mentioned this during the first ISIS WG
|  session but has anyone been looking into increasing 
|  this limit?  I'm aware that this is easier said than 
|  done.
|  
|  Cleve...
|  Cable & Wireless, USA
|  
|

---

From: Cleveland Mickles <[email-masked]>
Date: Thu, 10 Dec 1998 08:58:59 -0500

Can I assume the extensions are *not* coupled to implementing
MPLS?

Cleve...

> -----Original Message-----
> From: Tony Li [mailto:[email-masked]]
> Sent: Wednesday, December 09, 1998 1:53 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: ISIS Metric Limitation of 63
> 
> 
> 
> Cleve,
>

---

From: Henk Smit <[email-masked]>
Date: Thu, 10 Dec 1998 09:36:17 -0800 (PST)

> Can I assume the extensions are *not* coupled to implementing

  You can definitely use the wider metrics without using MPLS.

        Henk.

---

From: AK Shyu <[email-masked]>
Date: Fri, 11 Dec 1998 10:17:35 -0500

Is there a proposed RFC or the latest ISIS spec for changing the "metric"
byte available ???

---------
A.K. Shyu
CCIE# 3898
Internet Engineering, Cable & Wireless USA
2100 Reston Pkwy, Reston, VA 22091
Phone: (703) 568-5094 Email:[email-masked]

> From: Cleveland Mickles [mailto:[email-masked]]
> Sent: Thursday, December 10, 1998 8:59 AM
> To: Tony Li
> Cc: [email-masked]; [email-masked]
> Subject: RE: ISIS Metric Limitation of 63
>
>
>

---

From: Tony Li <[email-masked]>
Date: Fri, 11 Dec 1998 09:42:25 -0800 (PST)

|  Is there a proposed RFC or the latest ISIS spec for changing the "metric"
|  byte available ???

Not yet.  It's on my plate...

Tony