Subject: [Isis-wg] On draft version 17 of the IS-IS MIB

From: Sundar Ramachandran <[email-masked]>
Date: Fri, 29 Oct 2004 19:14:12 +0530

Hello Jeff,

Some concerns on the latest yet-to-be-approved draft revision of the MIB:

1. There were some comments earlier in the month from Jonathan Harrison
about minor bugs in draft version 16 of the MIB. One of them related to the
inconsistent textual definition of "seconds" for objects using the syntax
TimeTicks. As he pointed out, TimeTicks represents the time (4294967296)
in hundredths of a second since an epoch. I see from the latest draft revision
17 that some of the objects previously using TimeTicks have been modified
as follows:
e.g.,
     isisSysLevelSetOverloadUntil OBJECT-TYPE
         SYNTAX Unsigned32(1..4294967295)
         UNITS "seconds"
         MAX-ACCESS read-write
         STATUS current
         DESCRIPTION
             "If isisSysLevelSetOverload is true, the overload
              bit should be set at startup, and cleared after
              sysUpTime exceeds this value."
     ::= { isisSysLevelEntry 6 }
But the description indicates that the determination of it's value depends on
sysUpTime, which is encoded based on TimeTicks. So do we have an
inconsistency here? I mean, do we maintain the SYNTAX as TimeTicks and
change the UNITS, or should it remain as you've modified it?
Moreover, I find that not all similar definitions have been corrected.
For instance, you still have:
     isisCircLastUpTime OBJECT-TYPE
         SYNTAX TimeTicks
         UNITS "seconds"
         MAX-ACCESS read-only
         STATUS current
         DESCRIPTION
             "If the circuit is enabled, the value of sysUpTime
              when isisCircAdminState most recently entered
              the state on.  If the circuit is not on,
              the value of sysUpTime when the circuit last
              entered state on, 0 if the circuit has never
              been on."
     ::= { isisCircEntry 13 }
and
     isisISAdjLastUpTime OBJECT-TYPE
         SYNTAX TimeTicks
         UNITS "seconds"
         MAX-ACCESS read-only
         STATUS current
         DESCRIPTION
             "If the isisISAdjState is in state 'up', the value
              of sysUpTime when the adjacency most recently
              entered the state 'up',  or 0 if it has never
              been in state 'up'."
     ::= { isisISAdjEntry 11 }

So I believe the inconsistency still remains. Correct me if I'm wrong.

2. The isisOrigLSPBuffSizeMismatch notification is generated for two
conditions:
     a) When the received L1 or L2 LSP is larger than the local value of
isisOriginatingBufferSize,
     b) When there's a mismatch between the value in the PDU of the
received LSP (with the isisOriginatingBufferSize field present) and the
local isisOriginatingBufferSize value.
In the description of this notification, it is mentioned that:
"            We pass up the size from the option field or the
              size of the LSP that exceeds our configuration."

So is it possible to tell whether the trap was generated as a result of 
condition
"a" or "b" above? ISO/IEC 10589:2002 uses the notificationLSPHeader parameter
to report the contents of the LSP header and this is part of the equivalent OSI
notification, thus helping to identify the cause of the trap event. I don't 
think
PduLspId, SysLevelIndex and CircIfIndex will be sufficient to determine which
condition caused the trap generation. It's useful to indicate which condition
resulted in a buff. size mismatch. I'd like to know what you think.

3. I also need clarification on something not very specific to the current MIB
revision. This has to do with the SIZE 0 for OSINSAddress:
         SYNTAX OCTET STRING (SIZE(0..20))
I'd like to know when a string object with zero-length value will be applicable
considering that this TC is used to encode isisAreaAddr,
isisISAdjNeighSNPAAddress, isisISAdjAreaAddress, isisRASNPAAddress,
isisRASNPAMask and isisRASNPAPrefix? My guess is that it applies in
situations when no address is configured. For example, when we have no area
address configured, or we have no neighbor SNPA addresses? Or is there a
different reason? The DEFVAL of ' 'H (the empty string) is provided only for
isisRASNPAAddress and isisIPRASNPAAddress, so it's not very clear. I just
want to make sure that it's valid to use OSINSAddress as SYNTAX with the
prescribed size restriction for all the respective MIB objects.

4. Finally, based on my earlier post with queries on draft 16, I'd like to know
if it's useful enough to define or make provisions in the MIB for an 
initial activity
period where traps are suppressed, much along the lines of the RFC1850
OSPF-MIB definition.

Hope to hear suggestions and corrections where necessary!
Thanks for your time.
- Sundar.

_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg