Subject: RE: [Isis-wg] question on the relationship between isisSysType, i sisCircType and isisCircLevelIndex

From: Jonathan Harrison <[email-masked]>
Date: Mon, 23 Aug 2004 11:24:19 +0100

Joan, Jeff,

Some comments to hopefully clarify the use of the isisCircLevel and
isisSysType objects, and to sum up the discussion so far.

 - The isisSysType object is required, as it defines the level(s) at which
the IS-IS instance operates.

 - Even if isisSysType is level1L2IS, some circuits may be required to act
at level 1 only or level 2 only.  Hence the isisCircLevel object is required
to define the level(s) at which a circuit operates.

 - Two entries in the isisCircLevelTable exist for every isisCircTable
entry.  One for level 1 and one for level 2.  The comments for
isisCircLevelEntry are pretty clear about this: "An isisCircLevelEntry
exists for each level on each circuit used by Integrated IS-IS on this
system."

 - A physical link failure could cause a circuit with isisCircAdminState
'on' to become unusable.  This should probably be reflected in the MIB by an
oper status object in the isisCircTable.  For example, we could define an
isisCircOperState object as follows.

  isisCircOperState OBJECT-TYPE
    SYNTAX      INTEGER {
                  operStatusUp(1),       -- active
                  operStatusDown(2),     -- inactive
                  operStatusGoingUp(3),  -- activating
                  operStatusGoingDown(4),-- deactivating
                  operStatusActFailed(5) -- activation failed
                }
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
       "The operational state of this circuit."
    ::= { isisCircEntry 5 }

With this change, I don't believe there is a need for an oper-status for the
isisCircLevel table, as the status of each level could be deduced from the
circuit oper-status, together with the isisSysType and isisCircLevel
objects.

 - As Joan says, because there is no row status in the isisCircLevel table,
the MAX-ACCESS for the modifiable objects must be "read-create" rather than
"read-write".

 - With regards to the isisAreaAddr and isisManAreaAddr table, I still
believe that they are correct as  they are at present.  The tables should be
separate, because the two tables perform different functions.  There should
be no compiler problems with the isisAreaAddr table - a read-only index is
allowed by SMIv2 if the object is the only one in the table (see for
example, RFC2578, 7.7:

 "(2)  a conceptual row must contain at least one columnar object which is
       not an auxiliary object.  In the event that all of a conceptual
       row's columnar objects are also specified in its INDEX clause, then
       one of them must be accessible, i.e., have a MAX-ACCESS clause of
       "read-only". (Note that this situation does not arise for a
       conceptual row allowing create access, since such a row will have a
       status column which will not be an auxiliary object.)"

Jon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of [email-masked]
Sent: 20 August 2004 18:16
To: [email-masked]; [email-masked]
Cc: [email-masked]; Jonathan Harrison
Subject: Re: [Isis-wg] question on the relationship between isisSysType,
isisCircType and isisCircLevelIndex

Hi,

My comments are prefaced with "jec>"

-----Original Message-----
From: Jeff Parker <[email-masked]>
Sent: Aug 20, 2004 11:38 AM
To: [email-masked]
Cc: [email-masked], <;[email-masked]>
Subject: Re: [Isis-wg] question on the relationship between isisSysType,
isisCircType and isisCircLevelIndex

>
>
>I assume you mean CircType in the above paragraph (not CircLevel), right?
>
>I don't understand this answer.  The agent is ALWAYS supposed to create
>2 rows for every circuit in the CircLevelTable, one row which is circ +
Level1
>and the 2nd row which is circ + Level2, correct?    Then the agent is
>supposed to look at SysLevel (scalar) object to figure out if one or both
>(i.e. Level1 or Level2 or both) are actually being used in ISIS routing.  
>
>I think that a better design would be to add an operStatus type of object
>to the CircLevelEntry to specify that the row is or is not being 
>used in routing.
>
>Could the DESCRIPTION clauses of the scalar object and
>the circLevelTable be clarified so that the relationship between the
>sysLevel scalar and how rows are created in this table is described? 
>
>Additionally, the read-create objects in the
>circLevelTable need to be changed to read-write.  The agent is responsible
>for creating these rows, thus, read-write should be fine.
>
>What is the purpose of the isisCircType object in the isisCircEntry?   I
don't
>see any purpose for this object, should it be removed?  If a Circuit 
>is referring
>to SysLevel to see what types  of packets to send/receive on the circuit,
>then isisCircType is useless.

jec>  Could you respond to the above concern?  I don't see a need for
jec>  the isisCircType object since sysLevel overrides this, so could
jec>  this object be removed?  Please comment.

My mail is not appearing on the mail list, probably because my POP 
and SMTP servers are different.

Jon has proposed language that I can accept.  I trust this addresses 
your issue about how the fields interact.

jec>  The text does not mention how rows are to be created by the
jec>  agent in the isisCircLevelTable, so that needs to be called out. 
jec>  A person that is reading this MIB for the first time is not likely to
jec>  understand.  From an agent developer's point of view, this was
jec>  not at all clear.  

If the CircLevel table is read-only, I will fix.  At present, I am 
between offices.

jec>  The objects in the CircLevelTable that are read-create need
jec>  to be made "read-write".   (I didn't mention anything about
read-only.)

As to configuration, I can imagine configuring an interface/level 
that is not enabled yet.  Since changing many attributes will force 
you to cycle adjacencies, you may want to configure them first, and 
then enable the Circuit for that level.  Like selecting options on a 
car you don't own yet, it is less disruptive than trying to change 
them once the car is operational.

jec>  I think you have made my point for adding an OperStatus object 
jec>  to this (CircLevelEntry) entry.  It is all well and good if you expect
that 
jec>  you will always buy the perfect car that works as you expect
jec>   and as you pre-configured it, but you don't really know until 
jec>  you actually get the car and turn  it on and look at the gages/setting
to
jec>  make sure that it really works.
jec>  Can you please comment on  if you will be adding an OperStatus object?

thanks,
  -Joan

- jeff parker

_______________________________________________
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