Subject: [Isis-wg] Additional comments on draft-ietf-isis-wg-mib-16

From: Sundar Ramachandran <[email-masked]>
Date: Thu, 07 Oct 2004 21:43:54 +0530

Greetings Jeff et al.,

I have some comments on draft-ietf-isis-wg-mib-16. Forgive me for proposing
changes to the MIB at this time, but I'd like you to review the suggestions and
hopefully consider incorporating changes if you find good use for them. The 
issues
are as follows:

1.  The ISIS MIB includes a few objects that have AF scope. i.e. in the context
of using IS-IS in an IPv6 environment, there are at the least a couple MIB 
objects
which can take on different values depending on whether we use IPv4 or IPv6.

- isisSysMaxPathSplits
- isisSysL2toL1Leaking

The MIB does not provide this information. It will be useful to add more 
comments
that describe what changes can be expected in the case of IPv4 or IPv6.

2. The OSPF MIB (RFC 1850) defines an initial period when trap notifications
are suppressed. This is described in Section 4.3 of the RFC and helps to avoid
a flood of traps during initial bootup activity when OSPF is enabled. It 
will be very
useful to mimic this behavior in ISIS-MIB since there are traps which are not
edge-triggered and can be generated after the bootup phase. One example is the
isisSequenceNumberSkip notification. During initial activity, when there are no
LSPs, new LSPs are re-issued with incremented sequence number. Multiple traps
get generated since the sequence number is greater than 1.
Do you think it's possible to make some provision in the MIB to handle this?

3. Upon running smilint on the ISIS-MIB module, there was one "minor" error and
atleast one warning that seemed to pose a concern:

- {notification-object-access} object `isisManAreaAddr' of notification 
`isisManualAddressDrops' must not be `not-accessible'
- {index-element-accessible} warning: index element `isisSysLevelIndex' of 
row `isisSysLevelEntry' should be not-accessible in SMIv2 MIB

isisManAreaAddr must be not-accessible since it's an INDEX as well as a 
part of the
conceptual table. But there seems to be a problem with this being a part of the
isisManualAddressDrops NOTIFICATION-TYPE. Should this be changed to 
"read-only"?
I've seen one such example in ifIndex (IF-MIB) which is an INDEX to 
ifTable, present in
the table and also part of a NOTIFICATION-TYPE. Does MAX-ACCESS for these two
objects need to be fixed?

Hope you can comment on these. Thanks for your time.

- Sundar.

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

---

From: Hannes Gredler <[email-masked]>
Date: Thu, 07 Oct 2004 18:53:33 +0200

Sundar Ramachandran wrote:
> hopefully consider incorporating changes if you find good use for them. 
> The issues
> are as follows:
> 
> of using IS-IS in an IPv6 environment, there are at the least a couple 
> MIB objects

i slightly disagree:

ad isisSysMaxPathSplits:

   load sharing / next-hop selection is typical a
   route-resolver (=system) function and not a per-AF function;

ad isisSysL2toL1Leaking:

   assume the most likely case that you have a policy that leaks based
   on admin-tags - i.e. every prefix (irrespective of AF) that carries
   a certain tag will get leaked:

   carrying redundant L2toL1Leaking is IMHO not necessary;

/hannes