Subject: [Isis-wg] Version 21 of ISIS MIB

From: [email-masked]
Date: Fri, 24 Jun 2005 20:38:18 -0400

The following which is preceeded with > is my original email
for the Last call of this MIB.  A few concerns have not been
addressed in version 21 and these are indicated inline below.

At 03:50 PM 5/28/05 -0400, [email-masked] wrote:
>
>Most of my comments deal with the following 2 objects:
>
>
>isisSysType OBJECT-TYPE
>        SYNTAX INTEGER
>            {
>                level1IS (1),
>                level2IS (2),
>                level1L2IS (3)
>            }
>        MAX-ACCESS read-write
>        STATUS current
>        DESCRIPTION
>            "At which levels is the Intermediate System
>             running? This object may not be modified when
>             the isisSysAdminState variable is in state 'on'
>             for this Intermediate System."
>        REFERENCE "{ISIS.aoi iSType (2)}"
>        DEFVAL { level1L2IS }
>    ::= { isisSysObject 2 }
>
>
>isisCircLevel OBJECT-TYPE
>        SYNTAX INTEGER
>            {
>                level1(1),
>                level2(2),
>                level1L2(3)
>            }
>        MAX-ACCESS read-create
>        STATUS current
>        DESCRIPTION
>            "Indicates which type of packets will be sent and
>             accepted on this circuit. The values used will be
>             modified by the settings of isisSysType. This
>             object follows the replaceOnlyWhileDisabled behavior."
>        DEFVAL { level1L2 }
>    ::= { isisCircEntry 8 }
>
>
>
>1a)  Why can't the TC IsisAdjLevel be used for isisSysType and isisCircLevel?
>
>
>IsisAdjLevel ::= TEXTUAL-CONVENTION
>        STATUS current
>        DESCRIPTION
>            "Identifies one or more levels."
>        SYNTAX INTEGER
>            {
>                level1(1),
>                level2(2),
>                level1and2(3)
>            }
>
>
>If this TC can be used (and I think that it can/should) then 
>please rename this to something more generic such as IsisLevelType
>

done.  Thank you.

>
>1b)  The naming is inconsistent for the following related objects
>
>  
>isisSysType and
>isisCircLevel
>
>
>Since these are related, could they be renamed 
>so as to indicate they are related, e.g. isisSysType, isisCircType
>or isisSysLevel, isisCircLevel, or isisSysLevelType, isisCircLevelType?
>

not done, so why not?

>
>1c)  Could the description of isisCircLevel be clarified such that
>an implementor understands what the agent is supposed to
>return for an error in the event that isisSysType has a value of level1(1)
>and an operator attempts to set isisCircLevel to level2(2) or level1and2(3)?
>

not done and the behavior of this object has been changed.
I am not in favor of allowing this object to be set and having no
indication of whether or not the specific circuit level
is passing packets and would like to understand why 
this change was made.  

If this is thought by the working group to be a change for the
better, then I would ask that an CircLevelOperStatus object be
added to the CircLevel Table. 

>2)  Several Entry descriptions contain a phrase similar to 
>    "Configured values will survive an agent reboot", I don't understand
>    why this would be dictated by a MIB?  In other words, why isn't 
>    a StorageType object present in these tables?

Mike explained why the original description is valid.

>
>
>3)  The following object's
>
>
>
>   isisCircIfSubSelector OBJECT-TYPE
>        SYNTAX Integer32
>        MAX-ACCESS read-create
>        STATUS current
>        DESCRIPTION
>            "A specifier for the part of the interface ifIndex to which
>             this circuit corresponds, such as a DLCI or VPI/VCI.
>             This object cannot be modified after creation.
>
>             Holds 0 if not used."
>        DEFVAL { 0 }
>    ::= { isisCircEntry 3 }
>
>DESCRIPTION is confusing.  In the case of ATM, does this value contain
>an ifIndex or zero, and if so, what is the ifType that corresponds to this
>ifIndex?
>
>Or, could it contain an actual VPI/VCI in which case 0 could be a valid
>VPI/VCI?
>
>Furthermore, the Abstract states:
>
>   "This document describes a management information base for the IS-IS
>   Routing protocol when it is used to construct routing tables for IP
>   networks."
>
>so why is there a need to have this object at all?  
>

The description has changed slightly, but the original concerns have
not been addressed.  

Additionally, if there is an ifIndex which corresponds to an IS-IS circuit,
as this new description says, then an ifType should also be defined.  

Thanks, 
  -Joan

>Thanks, 
>  -Joan
>
>
>
>
>
>At 08:43 AM 5/18/05 -0700, Christian Hopps wrote:
>>As the MIB doctor review is complete the IS-IS MIB is now in WG last  
>>call. Please recall that we are only looking for issues with the  
>>current version of the MIB as we need to get this document published.  
>>It was pointed out that we could add support for graceful restart;  
>>however, changes such as this will have to be addressed in a later  
>>revision of the MIB.
>>
>>Please post any comments by June 1st.
>>
>>Chris and Dave.
>>
>>_______________________________________________
>>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
>

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

---

From: Jeff Parker <[email-masked]>
Date: Fri, 24 Jun 2005 23:04:00 -0400

>addressed in version 21 and these are indicated inline below.

Julia -
	Sorry that you missed the earlier discussion and diffs.

>>or isisSysLevel, isisCircLevel, or isisSysLevelType, isisCircLevelType?

There is already something called isisCircType, so I could not use 
that name.  I changed the name to isisCircLevelType in an attempt to 
address your concern.

Do you have a specific proposal?

>added to the CircLevel Table.

I'm sorry if the intent was not clear: this has been my aim all along.

I think it is useful to allow an administrator to have a system 
running at level L1, and prepare circuits to run at  L2 or L1L2 
before switching the system to L1L2 to reduce the changes in state 
that are seen in the network.

You can find out if the circuit is passing packets or not by 
performing a logical OR on the system level and the circuit level.

>The description has changed slightly, but the original concerns have

There were several original concerns.  Is your remaining concern the value 0?

Do you have a specific suggestion?

>as this new description says, then an ifType should also be defined. 

There is an isisCircIfIndex which refers to the ifIndex.  Can't you 
fetch the ifType out of the Interface MIB?

I admit that we have more circuit indicies than any two MIBs need, 
but this dates back to a specific request. It sounds to me as though 
your implementation has no need for this field.  Can't you can return 
0 and be done with this?

- jeff parker

---

From: [email-masked]
Date: Tue, 28 Jun 2005 09:15:42 -0400

>Do you have a specific proposal?

Yes, isisSysLevelType and isisCircLevelType.  This way the
suffixes are the SAME and indicate that there is a relationship
between these objects.

>that are seen in the network.

Operators typically do not make sweeping changes as you describe
above.
Typically they would change the system level and then turn
up one circuit at a time to make sure that the network 
comes back as expected.  They don't tend to trust preconfiguration.

>performing a logical OR on the system level and the circuit level.

What about at the far end of a circuit, and it all of a sudden
stops receiving packets?

An CircLevelOperStatus object would be beneficial in this case.

>Do you have a specific suggestion?

Yes, since this object is not IP specific, it should be removed.

>fetch the ifType out of the Interface MIB?

As I state above the DESCRIPTION now refers to an ISIS circuit as
having an ifIndex, if this is accurate, then there needs to be
an ifType and I couldn't find one, so am asking what this would be?

>your implementation has no need for this field.  Can't you can return 

Jeff, the point is that this object is not sufficiently defined, 
so am asking for it to be removed, OR be better
defined. Perhaps an additional object which states the ifType
needs to be added.  Also, why isn't this doesn't this object
have the SYNTAX of InterfaceIndexOrZero?

-Joan