[Isis-wg] ISIS MIB question

[Brad Hazen]

Jeff,

 Thanks for the clarification, but a couple of
points still aren't clear.

>Let's start with the easy one.

>You might have multiple adjacencies on a LAN interface,
>such as Ethernet.  In this case, you will need to 
>distinguish adjacencies which share the same circuit
>attributes.  The AdjIndex serves to mark such different
>adjacencies: clearly no circuit index can do that job.  

I understand that you can have multiple adjacencies on
a LAN interface. But my question is why do you need to
'assign' an AdjIndex to distinguish adjacencies when 
there seems to be enough other information to uniquely
identify an adjacency without it?  Specifically, why can't
you use isisISAdjNeighSNPAAddress in combination with the
circuit attributes to distinguish an adjacency?  Are SNPA
addresses not unique?

         isisISAdjIndex OBJECT-TYPE
             SYNTAX Integer32
             MAX-ACCESS not-accessible
             STATUS current
             DESCRIPTION
                 "A unique value identifying the IS adjacency from all
                 other such adjacencies on this circuit. This value is
                 assigned by the system when the adjacency is created
                 automatically."
         ::= { isisISAdjEntry 3 }

>While there seem to be too many circuit indicies, they
>play different roles.  The CircIndex may match the
>IfIndex, but it need not.  Your implementation is
>free to make these the same value: the overhead of
>supporting the two names is minimal, and allows 
>implementations that make the CircIndex match a
>physical interface (port 3 on card 2) which the
>IfIndex is not well suited for.  Since most SNMP
>port management depends on the IfIndex, I found it
>helpful to include both.  

OK. 

>We felt that the subInterface was useful to support
>circuits on interfaces such as ATM and Frame Relay
>which split one physical interface into multiple
>portions.  This allows you to quickly find the
>fiber via the IfIndex and then the VCI via the
>SubInterface.  

OK. 

Is there a default value for this object when a
subinterface index might not apply? On a LAN
circuit, for instance.


Thanks again,

  Brad


>         isisCircIndex OBJECT-TYPE
>            SYNTAX Integer32
>            MAX-ACCESS not-accessible
>            STATUS current
>            DESCRIPTION
>               "The identifier of this circuit, unique within the
>                instance of the protocol. This object follows the index
>                behaviour.  This is for SNMP Indexing purposes only
>                and has no relation to any protocol value."
>        ::= { isisCircEntry 2 }
>
>        isisCircIfIndex OBJECT-TYPE
>            SYNTAX Integer32
>            MAX-ACCESS read-only
>            STATUS current
>            DESCRIPTION
>                "The value of ifIndex for the interface to which this
>                circuit corresponds.   This object cannot be modified
>                after creation"
>        ::= { isisCircEntry 3 }
>
>        isisCircIfSubIndex OBJECT-TYPE
>             SYNTAX Integer32
>             MAX-ACCESS read-only
>             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"
>         ::=    { isisCircEntry 4 }


>>   I'm trying to figure out why it's necessary to use
>> isisCircIndex and isisISAdjIndex as indices for the
>> isisCircTable and the isisISAdjTable.
>> 
>>   Neither object has any relationship to any protocol
>> value.
>> 
>>   It seems to me that there are already enough objects
>> available (isisCircIfIndex, isisCircIfSubIndex, and
>> isisISAdjNeighSNPAAddress) to uniquely identify rows
>> in both tables.
>> 
>>   What is the reason that isisCircIndex and 
>> isisISAdjIndex are required?
>> 
>>  Brad