Subject: [Isis-wg] few more questions on draft-ietf-isis-wg-mib-16

From: [email-masked]
Date: Wed, 18 Aug 2004 15:30:45 -0400 (GMT-04:00)

Hi Jeff,
 
A few more MIB questions...
 
#1  The isisCircIndex has a
    SYNTAX Integer32 (1..2147483647)
 
As we discussed in an earlier email a few weeks ago,
this Index was to get its value from the
isisNextCircIndex object.  As in the DIFFSERV-MIB
(rfc 3289), the actual index (i.e. the isisCircIndex)
needs to have the type IndexInteger.
 
#2  Can the isisManAreaAddrTable and the isisAreaAddrTable
    be combined?
 
These seem to be the same info, except in one case
the address is configured by an operator, and in the
other case, an address is learned by ISIS.
 
If an object were added to indicate if the object
were manually configured, or learned, then these 2 tables
could be combined.  This would get rid of the
a compile error with the read-only Index in the
isisAreaAddrTable.

The object which denotes if the entry was configured
or learned would look something like:
 
cnIetfAreaAddressType OBJECT-TYPE
   SYNTAX INTEGER {
                     unknown(1),
                     manuallyConfigured(2),
                     learned(3)
                  }
   MAX-ACCESS read-only
   STATUS current
   DESCRIPTION
     "This object is used to denote whether or not
      this entry was configured by an operator, or
      learned by ISIS.

       unknown(1) - this value indicates that it is not
                    known if this entry has been
                    configured or learned,
                   
       manuallyConfigured(2) - this value indicates that
                               this entry was configured
                               by an operator
 
      learned(3) - this value indicates taht this entry
                   was learned dynamically by ISIS."

#3.  One last question on the isisCircLevelTable.  When a
circuit is created in the isisCircTable, do 2 entries
automatically appear in the isisCircLevelTable (one
for Level1 and one for Level2)??
 
 I think allowing operators to create rows in this table (by adding
a RowStatus object) would be better.   Under what
circumstances would a circuit participate in
both Level1 and Level2??
 
thanks,
  -Joan

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

---

From: Jonathan Harrison <[email-masked]>
Date: Thu, 19 Aug 2004 17:13:34 +0100

Joan,

A few comments on your questions.

Point #1 looks fine.

On #2, I don't think there is any need to combine the tables.  Each has a
different purpose, and the tables are easier for the operator (and the
implementer) as they are.

 - The isisAreaAddrTable reports information about area addresses learnt
from other nodes (and must therefore be read-only).

 - The isisManAreaAddrTable is the set of area address configured on this
node (and must therefore be read-create).

Typically, there will be an overlap in these tables.  However, it is much
clearer to an operator of IS-IS to be able to view the configured and learnt
addresses separately.  In addition, I believe it is much simpler to
implement separate read-create and read-only create tables than to implement
a table where some entries are read-only and some are read-create.  

On #3, two entries in the isisCircLevelTable should be created automatically
when the corresponding isisCircTable entry is created, as these are required
for the operation of the circuit.  

Note that since the configured level of the circuit can change, the rows
that are present should not depend on the isisCircLevel.  For example, if an
operator changes isisCircLevel from level1L2 to level1 and then back to
level1L2, they would not want to lose the old level 2 configuration.)

I also think that there is no benefit to be gained from allowing an operator
to create or delete rows in this table.
 - It would give an operator additional (unnecessary) work to do.
 - It would add unnecessary complication to an implementation of IS-IS.  For
example, an implementation would need to cope with an operator attempting to
delete MIB rows that may be essential to the correct operation of the
circuit.

Jon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 18 August 2004 20:31
To: [email-masked]
Cc: [email-masked]
Subject: [Isis-wg] few more questions on draft-ietf-isis-wg-mib-16

Hi Jeff,

 

 

                   

  

thanks,
  -Joan

---

From: [email-masked]
Date: Fri, 20 Aug 2004 11:05:36 -0400 (GMT-04:00)

-----Original Message-----
> From: Jonathan Harrison <[email-masked]>
> Sent: Aug 19, 2004 12:13 PM
> To: "[email-masked]'" <[email-masked]>,  [email-masked]
> Cc: [email-masked]
> Subject: RE: [Isis-wg] few more questions on draft-ietf-isis-wg-mib-16
> 
> Joan,
> 

Hi Jon,

> Point #1 looks fine.

Thanks.

> a table where some entries are read-only and some are read-create.  

This is the reason that I suggested the other object.  CLI or NMS could display Manually configured
or learned addresses separately, but the agent could combine this into one table.
The only difference with these 2 tables is that one is configured by an operator and
one is learned but both tables contain L1 area addresses.  

Keep in mind that the isisAreaAddressTable does not compile as the index is
read-only which is not allowed in smiV2.  So that would resolve that error.

> level1L2, they would not want to lose the old level 2 configuration.)

Okay, I understand this now, thank you.

> delete MIB rows that may be essential to the correct operation of the

Yes, I agree.   

   thanks,
    -Joan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 18 August 2004 20:31
To: [email-masked]
Cc: [email-masked]
Subject: [Isis-wg] few more questions on draft-ietf-isis-wg-mib-16

Hi Jeff,

 

 

                   

  

thanks,
  -Joan