Subject: Re: [Isis-wg] MIB again :)

From: [email-masked]
Date: Sat, 02 Oct 2004 20:22:45 -0400

HI Chris,

The MIB does not compile cleanly with the smicng and smiLint MIB compilers
which are recommended by the MIB Dr. review.  I would prefer to see
the MIB compile cleanly before making comments, but will re-interate 
comments I have made so far to the list.  Some may have been discussed
but am putting them in one email for completeness.   
(I sent output for smicng to the list already.)

Comments:
                                  
* MAJOR comment on the following Notifications:
   
     Having an agent keep track of ALL the source addresses
     so that a check is performed on every packet from every source to detect
     the following situations for these notifications and then 
     send a single notification is extremely resource intensive for the
device. 
                                                    
  - isisIDLenMismatch
  - isisMaxAreaAddressesMismatch
  - isisAuthenticationTypeFailure
  - isisAuthenticationFailure
  - isisVersionSkew
  - isisAreaMismatch
  - isisRejectedAdjacency
  - isisLSPTooLargeToPropagate
  - isisOrigLSPBuffSizeMismatch
  - isisProtocolsSupportedMismatch

    My suggestion would be to have an OPTIONAL table which kept track of 
    sources and a counter for each of these situations, such that an operator
    could send notifications (or not) based on some threshold he/she
determined

    The reason that I would make this table OPTIONAL is because it is not
    clear to me that anyone would want their device to check every single
    packet from every single source look for these errors.  
    I also question wheter VersionSkew would
    happen for a protocol that only has one version.  

* The isisCircIndex has a
    SYNTAX Integer32 (1..2147483647)
 
  As we discussed in an earlier email a few weeks ago,
  this Index was to get its value from the
  isisNextCircIndex object.  As in the DIFFSERV-MIB
  (rfc 3289), the actual index (i.e. the isisCircIndex)
  needs to have the type IndexInteger.

  Please replace the above with
 
    isisCircIndex OBJECT-TYPE
        SYNTAX IndexInteger

* could isisCircIfSubIndex be renamed to something else?
  (The description of this object shows that it is not an "ifIndex"
   but the name of the object leads one to believe that it is.)
                                                                             
* could isisCircSmallHellos appear in the
  conformance statement as optional, it doesn't seem like
  this feature is part of ISIS
    
*  The isisManAreaAddrTable and the isisAreaAddrTable
   could be combined because they contain the same info.
   The only difference being that area addresses in the 
   Manual Area Address Table are manually configured.
   An object could be added to denote how the address
   appeared in the table, e.g.

   cnIetfAreaAddressType OBJECT-TYPE
   SYNTAX INTEGER {
                     unknown(1),
                     manuallyConfigured(2),
                     learned(3)
                  }
   MAX-ACCESS read-only
   STATUS current
   DESCRIPTION
     "This object is used to denote whether or not
      this entry was configured by an operator, or
      learned by ISIS.

       unknown(1) - this value indicates that it is not
                    known if this entry has been
                    configured or learned,
                   
       manuallyConfigured(2) - this value indicates that
                               this entry was configured
                               by an operator
 
      learned(3) - this value indicates taht this entry
                   was learned dynamically by ISIS."

* The following indices seem to have somewhat random
  terminating values.  If there is a reason for the choosen
  value, could this be described in the DESCRIPTION clause for
  that index?

    isisLSPTLVIndex OBJECT-TYPE
        SYNTAX Unsigned32 (1..1000000)
 
    isisCircIndex OBJECT-TYPE
        SYNTAX Integer32 (1..2147483647)
 
    isisISAdjIndex OBJECT-TYPE
        SYNTAX Integer32 (1..2000000000)
 
    isisISAdjAreaAddrIndex OBJECT-TYPE
        SYNTAX Integer32 (1..2000000000)
  
    isisISAdjIPAddrIndex OBJECT-TYPE
        SYNTAX Integer32 (1..2000000000)
 
    isisRAIndex OBJECT-TYPE
        SYNTAX Integer32 (1..2000000000)
 
    isisIPRANextHopIndex OBJECT-TYPE
        SYNTAX Integer32 (1..65535)

   The mib review guidelines state:
   " - Unsigned32 with a range that excludes zero is RECOMMENDED for
       most index objects.  It is acceptable to include zero in the
       range when it is semantically significant or when it is used as
       the index value for a unique row with special properties.   Such
       usage SHOULD be clearly documented in the DESCRIPTION clause."
 
  If there is no reasons for these specific terminating values, then
  could the above indices be changed to Unsigned32(1..4294967295)?

*  Could the isisISAdjProtSuppProtocol object be added to
   the IsisISAdjEntry?  The isisISAdjProtSuppTable and
   isisISAdjTable have the same
   indices of (isisCircIndex, isisISAdjIndex) and so
   moving the isisISAdjProtSuppProtocol object into the
   isisISAdjTable would simplify the MIB and more importantly,
   group information that is the same in the same table.

* The conformance statements should specify address types and lengths of
addresses
   for example from rfc3289:

    OBJECT diffServMultiFieldClfrAddrType
    SYNTAX  InetAddressType { unknown(0), ipv4(1), ipv6(2) }
    DESCRIPTION
       "An implementation is only required to support IPv4 and IPv6
       addresses."

    OBJECT diffServMultiFieldClfrDstAddr
    SYNTAX  InetAddress (SIZE(0|4|16))
    DESCRIPTION
       "An implementation is only required to support IPv4 and globally
       unique IPv6 addresses."

* Also, if you could add a conformance for the RowStatus objects
  such that createAndWait and notInService are not required that would 
  be more flexible and especially
  appropriate for those tables that contain only a RowStatus object.

  For example from rfc3289:

  OBJECT diffServClfrStatus
     SYNTAX RowStatus { active(1) }
     WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) }
     DESCRIPTION
        "Support for createAndWait and notInService is not required."

At 10:44 AM 9/30/04 -0700, Christian Hopps wrote:
>Ok I made the bold claim that we would be done with the MIB by this 
>month. I think it's fair to say we won't be able to achieve that goal.
>
>Anyway, I'd like to come to an understanding about what we think the 
>open issues are and close them.
>
>A brief read through my mailbox highlighted at least a couple issues:
>
>1) Protocol supported
>    . Should we use a BITS scalar?
>    . Should we have 2 scalars, "Supported" and "Enabled"?
>

I believe that some consensus was reached to have 2 scalar objects to
replace the
table.  Here is email which attempted to summarize this.
Perhaps 2 scalars are needed.

One which is read-only which Don outlined, because the operator is going
to need to know what protocols are supported by the router.  Even though
the MIB object specifies the possibility 3 different protocols, it might be
that
a router vendor does NOT support all 3 of these to begin with.  It would be
very clear to an operator what is or is not supported with this read-only
object.
This would be new to the MIB.

    isisSysProtSupported OBJECT-TYPE
        SYNTAX BITS {
                    iso8473 (0),
                    ipv4 (1),
                    ipv6 (2)
                  }
        MAX-ACCESS read-only
        STATUS current
        DESCRIPTION
            "This attribute contains the set of protocols
             supported by this Intermediate System."
    ::= { isisSysObject 12 }

The  other object  is read-write would be for the reasons you state below,
and would
replace the isisSysProtTable.

I would be in favor of removing the isisSysProtSuppTable and replacing this
with 2 scalars. 

>2) isisCircLevelEntry/isisSyslevelEntry Rows
>    . Should the values in the isisCircLevelEntrys be read-write or 
>read-create
>

I believe we agreed on read-write, and that the 2 rows per Circuit or System
would always be there (and automatically created by the agent).  
There was ongoing (and inclusive) discussion on adding
OperStatus objects.  I would be in favor of adding OperStatus objects since
sometimes the rows are "active" and sometimes they are just there.

>For 1) Yes to both seems reasonable to me. I didn't see anyway comment 
>on this and the thread sort of died before this was answered.
>

I pasted in the email above which I hope summarizes the email discussion
for 1.

>For 2) my understanding with the isisCircLevelEntry (similar for 
>isisSysLevelEntry) is that currently the rows will be created *if they 
>don't exist already* according to what the user has set isisCircLevel 
>to in the isisCircEntry Row for the given circuit; however, the user 
>could create (read-create access) a value in a isisCircLevelEntry row 
>to configure a row that isn't supported by the isisCircLevel value in 
>the isisCircEntry.
>
>This seems somewhat useful, but complex. Are there examples of this in 
>other protocol MIBs?
>

I am not really in favor of preconfiguring using MIB objects, unless there
are OperStatus objects to let me know what the status of the rows are when
they
go active.

>From my experience with operators, they tend to not do much preconfiguration
either.  Nevertheless, it seemed there was more support having the 2 rows
(level1 and level2) created by the agent.  I do believe that more description
for the relationships between some scalars and these tables is needed.  I
suggested
some text in one of the emails to the list as an example:

"This table will contain 2 rows (one for level1 and one for level2) per 
circuit.  Both of the rows per circuit will be "in use" if the SysType and 
CircuitType corresponding to this row is Level1Level2. If the
value of SysType is Level1 or Level1Level2 and the value of CircuitType is
Level1, then
only the level1 row will be in use and the level2 row is not in use.  
If the value of SysType is Level1Level2 or Level2 and the value of 
CircuitType is Level2, then only the level2 row will be in use and the 
level1 row is not in use."

Additionally, error return values need to be specified for certain situations
that could occur in modify SysType/CircuitType under the wrong conditions.

Thanks,
  -Joan

>IANAME (I am not a MIB expert).
>
>Chris.
>
>
>_______________________________________________
>Isis-wg mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/isis-wg
>

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

---

From: [email-masked]
Date: Mon, 04 Oct 2004 09:45:33 -0400

At 02:08 PM 10/3/04 -0400, Parker, Jeff wrote:
>Thanks for the comments
>These are packets that the protocol needs to verify.
>My intent is not that we keep track of every instance of these errors: the
>MIB specifies only that we keep track of the first such error per interface.

According to what ISIS specification?  Furthermore, I have not seen this
ever requested
by members of the working group except for you.  Making these optional
certainly
gives more flexibility and that's all I'm asking for.  I don't see that
these are required by any specification, so seems like making them optional
is a completely reasonable request.

You say that you do NOT need to track every instance, and yes, the 
damping policy is such that AFTER the first error occurs for that particular
source address, that particular error does not need to be detected again, but
that is not flexible damping policy (and I don't know of any other standard
MIB that doesn't allow such things to be configurable).  Regardless, my
point is that this is an incredible amount of overhead to check for these
errors on every single packet.  I would like to ask that an informal poll
be taken to see who has this implemented, and if operators find it useful
to receive a single notification about a single occurance.

Most operators would be interested if a node was acting up by repeatedly
sending bad packets, so one bad packet is NOT indicative of a node which
is problematic.

>Not providing the padding that 10589 requires is what is at stake here.  I
>would argue that 10589 defines what is and isn't a feature of ISIS

Jeff,

Sorry, yes, we agreed in prior email(s) that this was okay to add.
My mistake.  Like I said, I cut and pasted from a bunch of my
original emails and most of resolved issues did not put in again.
I mistakenly added this one and should NOT have.

>Nope.  I have added values to silence the MIB compiler.  I would be much
>happier not having any such limits.

I don't understand your response.  These terminating values where NOT 
causing any MIB compiler issues, this is a semantic issue (one which
is specified in the MIB review guidelines, see below where I quote from
the MIB review guidelines).

>The issue is that an adjacency might support multiple protocols.

Yes, and why can't an additional object in the isisISAdjTable convey this
information?

>> that could occur in modify SysType/CircuitType under the wrong conditions.

Since many of my comments/concerns were not addressed, does this
mean that they will be incorporated in the next version of the MIB?
I'd sort of like some clarification since I have made most/all of the
comments to the list before and would like to understand if these 
are going to be incorporated into the next version of the MIB.

thanks, 
  -Joan

---

From: "Parker, Jeff" <[email-masked]>
Date: Sun, 03 Oct 2004 14:08:30 -0400

Thanks for the comments

---

From: "Parker, Jeff" <[email-masked]>
Date: Mon, 04 Oct 2004 09:52:08 -0400

> According to what ISIS specification?

Joan -
    This is pretty standard error checking for all but one of these.  I
agree tha BufferSizeMismatch is not required, but everything else must be
checked on every packet.  So there is no extra processing required: just
extra storage per circuit.
    What the MIB specifies is that you keep a bit mask of 10 bits per
interface, and that you send an event when you get your first error.  A
number of vendors have debug options that let you see this kind of check in
real time, and the operators I have talked to find it essential in brining
up links between different versions of the protocol.

> Furthermore, I have not seen this
> ever requested
  
>>>   could the above indices be changed to Unsigned32(1..4294967295)?

I can try that.  
 
> Yes, and why can't an additional object in the isisISAdjTable convey this

My point is simply that a scalar cannot capture this.  What do you propose?
 
> are going to be incorporated into the next version of the MIB.

Joan -
    I will work on a new draft, and hope to get it out this week.  I am
reviewing your comments.

- jeff parker

---

From: [email-masked]
Date: Tue, 05 Oct 2004 13:58:02 -0400

>up links between different versions of the protocol.

The description that you are giving here is far from what is in the current
MIB.  It sounds like you are suggesting that these notifications are going to
be changed to a single notification which returns a BITs object to say
what the problem might be if an adjacency can't be set up.  Is this what you
are saying?

Also, if I understand you correctly, then operators can also disable this 
checking and turn it on if they see that an adjacency is not being set up,
is this correct?  

I still don't completely understand your comment about "bringing up links
between different versions of the protocol"  Isn't there only 1 version?

>>>>   could the above indices be changed to Unsigned32(1..4294967295)?

Great! 

>My point is simply that a scalar cannot capture this.  What do you propose?

I'm suggesting adding another object to
isisISAdjEntry, e.g.

isisISAdjNeighborProtocol OBJECT-TYPE
   SYNTAX SupportedProtocol
   MAX-ACCESS read-only
   STATUS current
   DESCRIPTION
      "The protocol as reported in the IIH PDUs received from
       the neighbor."
::= { isisISAdjEntry x }

The additional object alleviates the need for the isisISAdjProtSuppTable.

-Joan