Subject: [Isis-wg] questions on draft-ietf-isis-wg-mib-15.txt

From: [email-masked]
Date: Tue, 15 Jun 2004 15:09:03 -0400 (EDT)

Hi Jeff,
 
I had some questions/comments on the ISIS-MIB.  I do
apologize as I realize these comments appear late
in the life of the MIB. 
 
  thanks,
   -Joan

These are mostly in the order they appear in the MIB.
 
* Is there really a need for the
  OBJECT-IDENTITY part.  These are not really used
  as OBJECT-IDENTITY's, so think that using
  an OBJECT-IDENTIFIER is probably more appropriate.

* The TC "SupportedProtocol" includes iso8473(129) and                                                                             
  the beginning of this MIB says it is for ipv6 and
  ipv4, so was wondering why this included here?
  If so, then maybe the only needed TC would be
  from the INET-ADDRESS-MIB (InetAddressType)
  and conformance statements could be used to support
  a subset such as { unknown(0), ipv4(1), and ipv6(2) }
                                                                             
* isisSysVersion is an SnmpAdminString and it would be
  easier for the Network Management apps
  if this were an enum such as
                                                                             
  INTEGER {
            unknown(0),
            one(1)
          }

* (related to the comment about the TC "SupportedProtocols" above)
  Could cnIetfIsisSysProtSuppProtocol have a conformance
  statement such that only ipv4 and ipv6 are supported
  and iso8473(129) is not supported?
                                                                             
* since the isisSys is no longer a table, think that
  removing the word Entry from these objects would
  be better, as they are now scalars.
                                                                             
  so isisSysEntry could be isisSysObjects
  Also, some of the descriptions refer to "this instance" and
  maybe this could be changed to say, the instance of ISIS on
  this router.

* is isisSysLogAdjacencyChanges part of the protocol?
  Usually objects like these are left for enterprise MIBs
  for example, I worked on enterprise MIBs which have all these
  sort of logging options in one MIB instead of spread in
  various protocol MIBs.  Can this object be removed?
                                                                             
* isisSysNextCircIndex could be moved to just prior to the
  isisCircTable and become part of the isisCircObjects
  rather than with the isisSysObjects.
                                                                             
  Also, from an implementation point, the IndexInteger and
  IndexIntegerNext TCs from the DIFFSERV-MIB (rfc3289)
  are easier to implement so would prefer those TC rather
  than the TestAndIncr TC.

* Now that these system Objects are scalars, you probably
  don't need the cnIetfIsisSysExistState scalar.
                                                                             
* could isisCircIfIndex be InterfaceIndex ?
                                                                             
* could isisCircIfSubIndex be
  InterfaceIndexOrNull
  (or at least these should start with 1 which
   is the minimum value for ifIndex)
                                                                             
* could isisCircSmallHellos appear in the
  conformance statement as optional, it doesn't seem like
  this feature is part of ISIS

* MAJOR comment on the following Notifications:
                                                                             
Since the agent needs to keep track of
sources for a bunch of situations which trigger
notifications, it might be better to have a table
which tracks this, and configurable threshold values such
that if these occur from a source, that these can
be tracked back to the source.  My point is that if
the agent is supposed to track these sources internally
as to only send a notification after one occurance, then why not make this
table of sources visable and then have thresholds with
defVal of 1 which will trigger the notification.  With a external table
there is more info and this table can
be polled by NMS.  (My point is that if the agent is already tracking
this information internally, then maybe adding a table to the MIB
will allow this information to be external and visable to operator/NMS.
                                                                             
I would also encourage that these Notifications and 
this external table  be made optional in the Conformance, as this is
really a lot of work for not much gain that I could see.
In other words, it's lots of overhead for the router to track all these
situations which seem sort of unlikely to occur.
                                                                             
The notifications which could possibly benefit from
such a table are:
  - isisIDLenMismatch
  - isisMaxAreaAddressesMismatch
  - isisAuthenticationTypeFailure
  - isisAuthenticationFailure
  - isisVersionSkew
  - isisAreaMismatch
  - isisRejectedAdjacency
  - isisLSPTooLargeToPropagate
  - isisOrigLSPBuffSizeMismatch
  - isisProtocolsSupportedMismatch

  the beginning of this MIB says it is for ipv6 and
  ipv4, so was wondering why this included here?
  If so, then maybe the only needed TC would be
  from the INET-ADDRESS-MIB (InetAddressType)
  and conformance statements could be used to support
  a subset such as { unknown(0), ipv4(1), and ipv6(2) }

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

---

From: Jeff Parker <[email-masked]>
Date: Tue, 15 Jun 2004 15:44:12 -0400

Thanks for the thoughtful review.
 
>   an OBJECT-IDENTIFIER is probably more appropriate.

Will investigate the difference.  

>   a subset such as { unknown(0), ipv4(1), and ipv6(2) }

IS-IS isn't really ours to modify: we just get to play with
it.  IS-IS was designed to route iso8473 and the like.  
So while the IETF isn't interested in iso8473, ISO is.  

>             one(1)
                 
Fine                                                               
              
>   and iso8473(129) is not supported?

See above

>   maybe this could be changed to say, the instance of ISIS on

Will try to address

>   various protocol MIBs.  Can this object be removed?

If there are no objections
               
>   rather than with the isisSysObjects.

I'm not sure I follow.  The Circ Table has an entry for
each circuit.  The NextCircIndex is a system wide item.
There is no system wide Circ specific table.  

Where are you suggesting this be placed?
                
>   are easier to implement so would prefer those TC rather

Comments from others?

>   don't need the cnIetfIsisSysExistState scalar.

Good point
                
> * could isisCircIfIndex be InterfaceIndex ?

It could, and it probably is the same thing.  
But don't you think there is some value in the
naming convention used here?
              
>    is the minimum value for ifIndex)

This isn't really an ifIndex: it was added by
request for some sub-interface identifiers.  
               
>   this feature is part of ISIS

Padded hellos were an important part of the protocol at
one time.  This provides a way for the administrator to
tell if the other side is not padding, or really thinks
that the MTU is 36.  

> will allow this information to be external and visable to 

I may have stepped over the line with the requirement that these
be damped.  However, I am uncomfortable requireding a specific 
damping strategy.  
                
> situations which seem sort of unlikely to occur.

I agree that there is some overhead here.  
I will try to reword so that a bitmap per interface would
suffice for conformance.  
                
>   a subset such as { unknown(0), ipv4(1), and ipv6(2) }

This is here so that contact with a router that is 
only supporting iso8473 can be documented and tracked.  

- jeff parker

---

From: Jeff Parker <[email-masked]>
Date: Tue, 15 Jun 2004 18:00:17 -0400

Joan -

	Here is a list of diffs for the changes you proposed, modulo my
reservations expressed in the previous mail.

	I will also send you a new version for your review: I'd be happy to
send to other interested parties

- jeff parker

---

From: [email-masked]
Date: Wed, 16 Jun 2004 19:27:06 -0400

Hi Jeff,

A few responses inline...I saw the diff file and
that looked good.  Thank you for your quick response.

>So while the IETF isn't interested in iso8473, ISO is.  

Okay.  Could this value be made optional in the Conformance
Statement?

>Where are you suggesting this be placed?

I'm suggesting this be placed before the table that
uses it.  Admittedly this is a style issue.  DIFFSERV-MIB
has examples of this (you can grep on IndexIntegerNextFree
and you'll see that the objects are actually prior to the 
table where it is used.

>>   don't need the isisSysExistState scalar.
>
>Good point
>                

The range of Integer32 and InterfaceIndex differ
because ifIndices do not have a value of zero.
My preference would be to use InterfaceIndex from IF-MIB,
but could you at least supply a range value?

>request for some sub-interface identifiers.

The DESCRIPTION makes it sound like an ifIndex, and name
(use of "if") make it sound like an InterfaceIndex.   Maybe
a name change and clarifying the description would help.
I don't have any idea of what value this is supposed to be
except for some sublayer ifIndex.
  
>tell if the other side is not padding, or really thinks

okay.

>I will try to reword so that a bitmap per interface would

Okay, thanks!  From my perspective, I think the burden being
put on the router is excessive for not very much gain (with regard
to the notifications below).  Making these optional in the Conformance
would be my preference....Maybe others could relate what their
experience is with these notifications?   

Thanks,
  -Joan

---

From: "Don Goodspeed" <[email-masked]>
Date: Wed, 16 Jun 2004 20:18:43 -0400 (EDT)

All,

My comments are inline marked with DG>>.  I am also
looking at Jeff's proposed changes in the followup
email as I type this.  Any places I did not comment
mean I am in implicit agreement.  My comments come
from having worked with both routing protocols AND
SNMP/NMS systems for a number of years, meaning I've
had these discussions many times before.

Cheers,
Don
===============================================
Thanks for the thoughtful review.

DG>> Changes look OK

> one(1)

Fine
DG>> Looks OK

See above

> maybe this could be changed to say, the instance of ISIS on

Will try to address
DG>> Looks OK

If there are no objections
DG>> True, this is better left to the enterprise MIBs

DG>> I think she means instead of having it at isisSysObject 10,
to have it at isisCirc 2.

Comments from others?

DG>> The issue here is that TestAndIncr functionality is
already implemented in the working code and while we can
change that, we'd make a lot of ISIS developers unhappy
while making only a few MIB people happy.  Also, TestAndIncr
is defined in SNMPv2-TC which 99% of implementations already
support whereas DIFFSERV-MIB is supported in a far smaller
number of implementations.

> don't need the cnIetfIsisSysExistState scalar.

Good point
DG>> OK with me

DG>> I think she means changing the SYNTAX from Integer32
to InterfaceIndex as IMPORTed from IF-MIB

DG>> True, this does not comply with an existing textual
convention in the IF-MIB

DG>> True, reporting the value should be mandatory, not
optional

DG>> General damping strategies are best left out of individual
MIBs and handled either by a separate Operations and Management
group or by the individual enterprise.  Also, the DESCRIPTION
clauses use "should" in every location, so that's a suggestion,
not a hard requirement, so it's up to the implementation to
adhere or not.  I'm OK with the existing language.

DG>> Once again, any damping strategies or supported trap
bitmaps are best left out of this MIB and handled either on
a global basis as defined by the O&M Area or by the individual
enterprises.  We don't want a bitmask like the OSPF-TRAP-MIB
has, do we?

- jeff parker

_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!

---

From: "Don Goodspeed" <[email-masked]>
Date: Wed, 16 Jun 2004 20:29:46 -0400 (EDT)

OK, I won't repeat any items I addressed in my last email
but only new ones here.   Cheers, Don

========================
Hi Jeff,

DG>> I think the point is that this MIB applies to ISO
implementations as well and it is most definitely not optional
to them.

DG>> Addressed in previous email.

DG>> See previous email.

DG>> Yes, isisCircSubIndex would be better

okay.

DG>> See my previous email for mine

Thanks,
-Joan

---

From: Jeff Parker <[email-masked]>
Date: Thu, 17 Jun 2004 10:38:39 -0400

> Okay.  Could this value be made optional in the Conformance

Joan -
	You don't need to support CLNS, and you don't need to
generate this value.  You will see it on the wire.  
 
> and you'll see that the objects are actually prior to the 

Joan -
	I am a bear of very little brain.  Can you suggest
a specific edit?  Perhaps to the version I sent you?
 
> but could you at least supply a range value?

Fine.  I can do this  
         
> except for some sublayer ifIndex.

I will try some word smithing
  
> >only supporting iso8473 can be documented and tracked.  
 
Much of this is historic: values such as MaxAreaAddress
and IDLen were not fixed in older versions.  So checking
for these values is probably a good idea.  Others, such
as AuthFailure, provide an easy way to debug a problem
that we certainly see while testing

- jeff parker

---

From: Jeff Parker <[email-masked]>
Date: Thu, 17 Jun 2004 12:23:47 -0400

Joan -

	As per your suggestions.

% diff mib ~/mib
18,21c18,19
<         InterfaceIndex 
<                 FROM IF-MIB
1029c1027
<                 InterfaceIndex,
---
>                 Integer32,
1059c1057
<         SYNTAX Integer32 (1..4294967294)
---
>         SYNTAX Integer32 (1..2000000000)
1071c1069
<         SYNTAX InterfaceIndex 
---
>         SYNTAX Integer32

---

From: Jeff Parker <[email-masked]>
Date: Thu, 17 Jun 2004 15:40:48 -0400

> > rather than with the isisSysObjects.
....
> to have it at isisCirc 2.

The circ table is a sequence of circuits.  The NextCircIndex is
a scalar.  The only table of pure scalars is the system table,
so I still don't see a solution here.

    isisCircTable OBJECT-TYPE
        SYNTAX SEQUENCE OF IsisCircEntry
        MAX-ACCESS not-accessible
        STATUS current
        DESCRIPTION
            "The table of circuits used by this
             Intermediate System."
    ::= { isisCirc 1 }
    ...
    IsisCircEntry ::=
        SEQUENCE {
            isisCircIndex
                Integer32,
            isisCircIfIndex

> number of implementations.

Dan - 
	How big a difference is this?  Is what Joan is 
proposing Right enough that we should fix this now?
  
> to InterfaceIndex as IMPORTed from IF-MIB

Done

> > - isisProtocolsSupportedMismatch
 
Don raises a good point: this is SHOULD, not MUST.  
The overhead of a word per circuit seems a small
price to pay for the increased visibility provided.
While most of these are rare, there are several that
we see with some frequency.  

If I see any of the issues above, I want to be able to 
debug the situation without haveing to run through 
syslog files.  For many of these, the problem indicates 
a serious mismatch.  In each case, knowing the circuit 
the packet was seen on is a first step in debugging 
the problem.  

- jeff parker

---

From: [email-masked]
Date: Fri, 18 Jun 2004 08:31:50 -0400

Hi Jeff,

Here's an edit.  Basically, it involves moving the scalar
object to right before the table.  Scalars do not have to
be grouped together, although you do see that many usually
appear together.  But for this particular scalar, think it
is best to appear before the table as it sort of goes with
the table.  Note the name change (removing Sys and also the
OID change).  There are many examples of this sort of scalar
being in front of the table that the scalar is associated 
with, so it is an accepted MIB style.

isisNextCircIndex OBJECT-TYPE
        SYNTAX TestAndIncr
        MAX-ACCESS read-only
        STATUS current
        DESCRIPTION
            "This object is used to assign values to
             isisCircIndex as described in 'Textual
             Conventions for SNMPv2'.  The network manager
             reads this object, and then writes the value
             back as the isisCircIndex in a SET that creates
             a new instance of isisCircEntry.  If the SET
             fails with the code 'inconsistentValue', then
             the process must be repeated; If the SET succeeds,
             then the object is incremented, and the new
             isisCircuit is created according to the manager's
             directions."
    ::= { isisCirc  1 }

 isisCircTable OBJECT-TYPE
        SYNTAX SEQUENCE OF IsisCircEntry
        MAX-ACCESS not-accessible
        STATUS current
        DESCRIPTION
            "The table of circuits used by each instance of
             Integrated IS-IS on this system."
    ::= { isisCirc 2 }

    isisCircEntry OBJECT-TYPE
        SYNTAX IsisCircEntry
        MAX-ACCESS not-accessible
        STATUS current
        DESCRIPTION
            "An isisCircEntry exists for each circuit used by
             Integrated IS-IS on this system."
        INDEX { isisCircIndex }
    ::= { isisCircTable 1 }

    IsisCircEntry ::=
        SEQUENCE {
            isisCircIndex
                Integer32,
            isisCircIfIndex
                Integer32,
            isisCircIfSubIndex
                Integer32,
            isisCircAdminState
                AdminState,
            isisCircExistState
                RowStatus,
            isisCircType
                INTEGER,
            isisCircExtDomain
                TruthValue,
            isisCircLevel
                INTEGER,
            isisCircPassiveCircuit
                TruthValue,
            isisCircMeshGroupEnabled
                INTEGER,
            isisCircMeshGroup
                Unsigned32,
            isisCircSmallHellos
                TruthValue,
            isisCircLastUpTime
                TimeTicks,
            isisCirc3WayEnabled
                TruthValue,
            isisCircExtendedCircID
                Unsigned32
        }

    isisCircIndex OBJECT-TYPE
        SYNTAX Integer32
        MAX-ACCESS not-accessible
        STATUS current
        DESCRIPTION
            "The identifier of this circuit, unique within the
             instance of the IS-IS protocol. This object follows
             the index behavior.  This is for SNMP Indexing
             purposes only and need not have any relation to
             any protocol value."
    ::= { isisCircEntry 1 }

Thanks,
  -Joan