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

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
> the same requirement for uniqueness.)

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

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

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

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

---

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