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

From: "Parker, Jeff" <[email-masked]>
Date: Wed, 17 Nov 2004 14:48:01 -0500

Sundar -
    Thanks for the suggestions.  I will wait a week or two for other
comments and respin the draft.

- jeff parker

On 11/16/04 4:09 AM, "Sundar Ramachandran" <[email-masked]> wrote:

> Hello Jeff,
> 
> A few more suggestions (very minor) in the draft version of the IS-IS MIB.
> Some of these are based on internal review comments from MIB experts,
> so you don't have to worry about the correctness or reasoning behind the
> comments! :)
> 
> - Some Counter32 objects use an explicit UNITS clause "frames" to indicate
> that the count refers to the total number of frames. It's better to
> rephrase the
> description for such objects using the phrase "Number of frames.." where
> appropriate. For e.g., "Number of corrupted in-memory LSP frames" or
> "Number of frames with authentication type mismatches".
> 
> - I'd raised a point about the conflict between TimeTicks used as a SYNTAX
> along with a UNITS description of "seconds". For such MIB objects, I believe
> it is better to remove the UNITS clause so that there will be consistency
> between
> the TimeTicks definition and sysUpTime (since we're dealing with "hundredths
> of a second" and not "seconds"). This is better than modifying the UNITS
> clause as "hundredths of a second" which would make it redundant since
> that is understood from the definition of TimeTicks.
> 
> - Also, there are still a few cases where the DESCRIPTION clause does not
> distinguish between enum values and normal words. For instance, on => 'on',
> or False => 'false'.
> 
> - I'd like to clarify the access of MIB objects in isisCircLevelTable. Many
> of the
> objects are defined with "read-create" permissions. Is this based on the
> RowStatus SYNTAX for isisCircIndex which is used as INDEX into this table?
> Otherwise, the access would be read-write for these objects, so I just want to
> make sure!
> 
> Hope you can spare a few minutes to elaborate on these. If it takes some time,
> I'll understand!
> 
> thanks,
> Sundar.
> 
>> Date: Sat, 30 Oct 2004 19:07:33 +0530
>> To: "Parker, Jeff" <[email-masked]>
>> From: Sundar Ramachandran <[email-masked]>
>> Subject: Re: [Isis-wg] On draft version 17 of the IS-IS MIB
>> 
>> Jeff,
>> 
>> Thanks. As I wait for your response, I found some minor issues in some of the
>> "DESCRIPTION" clauses; some typos in the MIB that I believe were missed
>> while renaming objects in the MIB as it progressed to its current state.
>> These
>> make it hard to distinguish between the names of TLVs, ISO definitions and
>> actual MIB objects!
>> 
>> - isisSysLevelOrigLSPBuffSize: This MIB object is referenced in 2 places
>> in the
>> description of isisSysReceiveLSPBufferSize as "isisSysOrigLSPBuffSize",
>> giving
>> the impression that it's still associated with the isisSysObject family.
>> This needs
>> to be changed in the description of isisPduOriginatingBufferSize too.
>> 
>> - There also seems to be some confusion in the description of
>> isisOrigLSPBuffSizeMismatch. It has "isisOriginatingBufferSize" all over
>> the place!
>> Since it no longer has that name, a reference to it in the description of
>> isisOrigLSPBuffSizeMismatch is not correct.
>> 
>> The existing description is as follows:
>>             "A notification sent when a Level 1 LSP or Level
>>              2 LSP is received which is larger than the local
>>              value for isisOriginatingBufferSize, or when an
>>              LSP is received containing the isisOriginatingBufferSize
>>              option and the value in the PDU option field does
>>              not match the local value for isisOriginatingBufferSize...."
>> 
>> I think it should read as follows:
>>             "A notification sent when a Level 1 LSP or Level
>>              2 LSP is received which is larger than the local
>>              value for isisSysLevelOrigBuffSize, or when an
>>              LSP is received containing the originatingLSPBufferSize
>>              option and the value in the PDU option field does
>>              not match the local value for isisSysLevelOrigBuffSize...."
>> 
>> I really hope that I'm right and not confusing you, because this is what I
>> end up with
>> when I match it up with the ISO/IEC 10589:2002 standard definition. The
>> "option"
>> field is the originatingLSPBufferSize TLV on which the check is performed,
>> right?
>> Here's a snippet from the ISO definition of this notification:
>> "originatingLSPBufferSizeMismatch:
>> Generated when a Level 1 LSP or Level 2 LSP is received which is larger
>> than the local value for
>> originatingL1LSPBufferSize or originatingL2LSPBufferSize respectively or
>> when a Level 1 LSP or Level2 LSP is
>> received containing the originatingLSPBufferSize option and the value in
>> the PDU option field does not match the
>> local value for originatingL1LSPBufferSize or originatingL2LSPBufferSize
>> respectively."
>> 
>> - In draft version 17, the description of isisManualAddressDrops still has a
>> reference to isisManAreaAddr even though this object has been removed.
>> 
>> I also want to make sure I understand correctly the need for a zero-length
>> valued OCTET STRING for IsisLinkStatePDUID. i.e. SIZE(0|8). Is this to
>> indicate that the Decision Process does not process any LSPs, i.e. when
>> it's unable to split a single incoming LSP into separate PDUs?
>> 
>> That's it for now! Thanks for your time.
>> 
>> - Sundar.
>> P.S.: I was involved with the IS-IS MIB (and IS-IS itself!) pretty late
>> during it's
>> evolution, so haven't really had a chance to share my understanding on any
>> major or minor issues in the contents of the MIB prior to this.
>> 
>> At 10:38 AM 10/29/2004 -0400, you wrote:
>>> Thanks for your careful review.  There were a large number of changes that
>>> went into this update, and these got missed.
>>> 
>>> I will review and report back.
>>> 
>>> - jeff parker
>>> 
>>> 
>>> On 10/29/04 9:44 AM, "Sundar Ramachandran" <[email-masked]> wrote:
>>> 
>>>> 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
> 

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