Subject: Re: [Isis-wg] question on the relationship between isisSysType, isisCircType and isisCircLevelIndex

From: [email-masked]
Date: Fri, 20 Aug 2004 10:56:38 -0400 (GMT-04:00)

-----Original Message-----
> From: Jeff Parker <[email-masked]>
> Sent: Aug 19, 2004 2:22 PM
> To: [email-masked], [email-masked]
> Cc: [email-masked]
> Subject: Re: [Isis-wg] question on the relationship between isisSysType,  isisCircType and isisCircLevelIndex
>
> >At 10:03 AM -0400 8/19/04, [email-masked] wrote:
> >
> >Hi Jeff,
> >
> >This is related to my question of yesterday on
> >how to populate the isisCircLevelTable....
> > 
> >In the isisCircTable, the object's description
> >below is unclear.  Since this object is a read-create,
> >it is set by an operator, what does the isisSysType scalar
> >object have to do with this object?
> >
> >
> >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 }

> If the router is running at Level 1, and the circuit is configured to 
> be L1 and L2, only L1 packets will appear.  That is the imapct of 
> isisSysType on the effectiveness of the circuit.
> 
> Different implementations could react differently: rejecting values 
> of CircLevel that don't match SysLevel, or silently accepting them. 
> But CircLevel cannot overrule SysLevel.

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.

> >
> >
> >Also, with regard to the isisCircLevelTable, is  this object
> >supposed to indicate which Level needs to be populated by the agent?
> >In other words, does this object (above) denote what value the
> >isisCircLevelIndex (below) takes on?
> >
> >If this is correct, then why are only leve1IS(1) and level2IS(2)
> >the only options for the isisCircLevelIndex?
> >
> >
> >isisCircLevelIndex OBJECT-TYPE
> >         SYNTAX INTEGER
> >             {
> >                 level1IS (1),
> >                 level2IS (2)
> >             }
> >         MAX-ACCESS not-accessible
> >         STATUS current
> >         DESCRIPTION
> >             "The level that this entry describes."
> >     ::= { isisCircLevelEntry 1 }
> >
> >
> >Can these MIB descriptions be clarified?   There appears to
> >be some relationship between the isisSysType (scalar), the
> >isisCircType object, and how an agent creates rows in the
> >isisCircLevelTable (i.e. the value of the isisCircLevelIndex),
> >but this is not documented anywhere in
> >the MIB and is very confusing from a developer's point of view.
> >
> >   Thanks,
> >     -Joan

> The CircLevel is an index into a table for values that are specific 
> to a level.  The MTU of a circuit is level independent, while the 
> Hello Timers can have different values for different levels.

The use of read-create in the isisCircLevelTable is extremely confusing.
As I stated above, read-write should be fine if the agent is always supposed
to create 2 rows per circuit.  Could this be changed?

  -Thanks,
    Joan

> - jeff parker

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

---

From: [email-masked]
Date: Fri, 20 Aug 2004 13:16:28 -0400 (GMT-04:00)

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

>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

---

From: [email-masked]
Date: Thu, 26 Aug 2004 09:17:04 -0400

At 11:24 AM 8/23/04 +0100, Jonathan Harrison wrote:
>Joan, Jeff,

Hi Jon,

>
>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.
>

The text in the descriptions needs to be clarified to explain
this relationship.  Also, shouldn't there be some errors returned under
certain circumstances? For example, if the sysType object is Level1, then
an operator should receive an error if the circType is set to Level2 or
Level1Level2
(would guess an Inconsistent Value error would be appropriate).
This should all be specified in the MIB.  As I said before, a person
looking at this MIB for the first time (like myself) needs this information
to develop an agent which is consistent with other vendors.

> - 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."
>

This is not clear if the SysType and CircuitType are set to Level1, then
that second level row is not being used.  That is not how I 
interpret the phrase  "used by Integrated IS-IS"
as the second level row is not "used" in my humble opinion.

So again, am just asking for better text here.  I would think something
like, "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."

The above description assumes that the operator receives an error if he/she
sets the CircuitType to be a superset of SysType (as discussed above).

> - 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 }

I do think this is a good idea, but a physical link failure would 
show up in ifOperStatus, but these do add some slightly different
descriptions so this is fine.

>
>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.
>

Isn't it possible that a circuit on a specific level could fail, without
the circuit on the other level failing?   Especially if an operator 
preconfigures a row, I would think that an operStatus object of some sort
would be a good idea here.  

> - 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.)"
>

I get a warning/error in my compiler so will ask on the mibs list
about this, it could be the compiler.  In any case, I prefer
one table with an additional object to denote manual/learned, but can see
that we don't agree on this point ;) so 2 tables are acceptable.
 
-Joan

>Jon
>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