Subject: [Isis-wg] Comments on draft-ietf-isis-wg-mib-13.txt

From: Jonathan Harrison <[email-masked]>
Date: Thu, 1 Apr 2004 14:07:44 +0100

Hi,

We've recently been examining the IS-IS MIB, draft-ietf-isis-wg-mib-13.  In
addition to a number of minor details (which will follow in a separate
mail), we have come up with a number of issues.  These are described below,
along with our initial thoughts on the suggested solutions.

If you could let me know if you think the solutions are along the right
lines, I can propose any detailed re-wording required in the MIB text.

Thanks,
Jon
-------------------------------------------
Jon Harrison
Network Protocols Group
Data Connection Ltd
Tel:	+44 20 8366 1177                 
Fax:	+44 20 8363 1039
Email:	[email-masked]    
Web:	http://www.dataconnection.com

MIB ISSUES
==========

1) The isisIPRATable has just the system instance and destination prefix as
the index.  However, a single destination prefix may be associated with
multiple equal cost next hops, and so we should extend the MIB to make any
additional next hops accessible.  The simplest way to do this would be to
make the next hop itself part of the index.

2) Where possible, it is helpful to provide default values for MIB objects.
Could we default isisCirc3WayEnabled to 'true'?  Also, would it be possible
to provide a default for isisCircExtendedCircID?  (In fact, it would make
sense to always use isisCircIndex for the extended circuit ID, since it has
the same requirement for uniqueness.)

3) The description of isisPacketCountIIHello could be changed to "IIH PDUs
are counted at the lowest enabled level: at L1 on L1 or L1L2 circuits, and
at L2 otherwise."  This makes the object consistent with
isisPacketCountISHello and isisPacketCountESHello.

4) There are two MIB objects that count the number of mismatches of max area
addresses.  Each circuit has the isisCircMaxAreaAddrMismatches count, plus
there is the overall count in the system statistics table,
isisSysStatMaxAreaAddrMismatches.  I think we should remove one of these
superfluous objects.

5) RFC 2763 allows a hostname to be included in the local non-pseudonode
LSP.  Although this will normally be the system name, the RFC does allow the
hostname TLV to contain any string that the operator wants to use for the
router.  This suggests that the IS-IS MIB should allow this string to be
configured.  This could be done using a new object in the isisSys table,
such as isisSysHostname.  Some implementations will always want to configure
the hostname automatically, so we would need to add some comments similar to
those describing the ManualOrAutomatic behavior.

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

---

From: Jeff Parker <[email-masked]>
Date: Thu, 1 Apr 2004 09:28:08 -0500

Jon -
	Thanks for the suggestions.  Comments below.
 
> 1) The isisIPRATable ... may be associated with
> multiple equal cost next hops

I'd be happy to look at a proposal
 
> 2) Could we default isisCirc3WayEnabled to 'true'?  

Fair enough

> ... provide a default for isisCircExtendedCircID? 

Can we use a variable as a default?  I will need to 
consult with the Mib Doctors

> it would make sense to always use isisCircIndex 
> for the extended circuit ID, since it has

Does anyone have an issue with that?  The isisCircIndex
is not required to match the underlying ifIndex.

RFC 3373             Three-Way Handshake for IS-IS        September 2002
   ....
   Extended Local Circuit ID
      Unique ID assigned to this circuit when it is created by this
      Intermediate system.

Katz & Saluja                Informational                      [Page 5]

vs
    isisCircIndex OBJECT-TYPE
        SYNTAX Integer32 (1..2000000000)
        MAX-ACCESS not-accessible
        STATUS current
        DESCRIPTION
            "The identifier of this circuit, unique within the
             instance of the IS-IS protocol. This object follows
             the index behavior.  This is for SNMP Indexing
             purposes only and need not have any relation to
             any protocol value."
    ::= { isisCircEntry 1 }

I think that Dave Katz had a request to drop arbitrary restraints,
such as that in the SYNTAX clause above

> 3) The description of isisPacketCountIIHello could be changed 
> to "IIH PDUs are counted at the lowest enabled level: at L1 
> on L1 or L1L2 circuits, and at L2 otherwise."  This makes 
> the object consistent with isisPacketCountISHello and 
> isisPacketCountESHello.

Will do

> addresses.  Each circuit has the 
> isisCircMaxAreaAddrMismatches count, plus

I will take a look

> 5) RFC 2763 allows a hostname to be included in ... LSP
> Although this will normally be the system name, the RFC 
> does allow the hostname TLV to contain any string that 
> the operator wants to use for the router.  This suggests 
> that the IS-IS MIB should allow this string to be
> configured.  This could be done using a new object in the 
> isisSys table, such as isisSysHostname.  Some 
> implementations will always want to configure
> the hostname automatically, so we would need to add some 
> comments similar to those describing the 
> ManualOrAutomatic behavior.

I would prefer not to add another value that is close to,
but different enough from, a standard value.  Can you 
give me a reason why we would want to have the IS-IS
hostname be different from the system name?  

- jeff parker

---

From: Jonathan Harrison <[email-masked]>
Date: Fri, 2 Apr 2004 10:53:33 +0100

Jeff,

I agree with your comments on 2), 3), 4) and 5).

On 1), I would suggest changing isisIPRATable as follows:

-- The IP Reachable Address Table

-- Each entry records information about a path to an IP reachable
-- address manually configured on this system or learned from
-- another protocol.

    isisIPRATable OBJECT-TYPE
        SYNTAX SEQUENCE OF IsisIPRAEntry
        MAX-ACCESS not-accessible
        STATUS current
        DESCRIPTION
            "The table of IP Reachable Addresses to networks,
             subnetworks or hosts either manually configured or
             learned from another protocol."
    ::= { isisIPReachAddr 1 }

    isisIPRAEntry OBJECT-TYPE
        SYNTAX IsisIPRAEntry
        MAX-ACCESS not-accessible
        STATUS current
        DESCRIPTION
            "Each entry defines a route to an IP Reachable Address to 
             a network, subnetwork or host.

             Each IP Reachable Address may have multiple entries in the
             table, one for each equal cost path to the reachable address." 
        INDEX { isisSysInstance,
                isisIPRADestType,
                isisIPRADest,
                isisIPRADestPrefixLen,
                isisIPRANextHopType,
                isisIPRANextHop }

In addition, isisIPRANextHopType and isisIPRANextHop are changed to have
MAX-ACCESS not-accessible.

Does this sound OK to you?

Thanks,
Jon

-----Original Message-----
From: Jeff Parker [mailto:[email-masked]]
Sent: 01 April 2004 15:28
To: Jonathan Harrison; [email-masked]
Subject: [Isis-wg] RE: Comments on draft-ietf-isis-wg-mib-13.txt

Jon -

 

Fair enough

vs

Will do

I will take a look

- jeff parker