headers
Jonathan Harrison | 1 Apr 2004 15:07
Favicon

Comments on draft-ietf-isis-wg-mib-13.txt

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:	jrh <at> dataconnection.com    
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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeff Parker | 1 Apr 2004 16:28

RE: Comments on draft-ietf-isis-wg-mib-13.txt

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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeff Parker | 1 Apr 2004 17:37

Updates to Mib

The IS-IS Mib editor is open for comments. 

There have been a few pending about the Notifications, which was a recent
addition.  Here is what I have done this morning.  

A number of compilers balk at the accessible-for-notify keyword.  I am told
that this is the correct keyword, and that the mib compilers need updating.
It is a royal pain.  

- jeff parker

--  Changes in version 14
--
--      Set DEFVAL for isisCirc3WayEnabled to true
--      Revised description for isisPacketCountIIHello
--      Removed isisSysStatMaxAreaAddrMismatches as
--          duplicating isisCircMaxAreaAddrMismatches
--      Replaced isisManAreaAddrExistState with isisManAreaAddr
--          in isisManualAddressDrops 
--      Drop isisSysLevelIndex in isisDatabaseOverload

19c26
<         LAST-UPDATED "200401191200Z" 
---
>         LAST-UPDATED "200404011200Z" 
1362a1370
>         DEFVAL { true }
1655,1656d1662
<             isisSysStatMaxAreaAddrMismatches
<                 Counter32,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jonathan Harrison | 2 Apr 2004 11:53
Favicon

RE: RE: Comments on draft-ietf-isis-wg-mib-13.txt

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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jonathan Harrison | 2 Apr 2004 11:55
Favicon

Minor comments on draft-ietf-isis-wg-mib-13.txt

Hi,

We've got a number of minor suggested clarifications and typo fixes to the
MIB, itemized below.  Hopefully, these won't be too controversial!

Please let me know what you think.

Thanks,
Jon
-------------------------------------------
Jon Harrison
Network Protocols Group
Data Connection Ltd
Tel:	+44 20 8366 1177                 
Fax:	+44 20 8363 1468
Email:	jrh <at> dataconnection.com    
Web:	http://www.dataconnection.com

SUGGESTED FIXES
===============

 - The MIB defines the type WideMetric for 24 bit values and the type
FullMetric for 32 bit values.  The syntax for FullMetric should be "SYNTAX
Unsigned32" rather than "SYNTAX Unsigned32 (0..16777215)".

 - The second sentence of the description of isisSysMaxAge should read "This
should be at least 300 seconds greater than isisSysMaxLSPGenInt."

 - isisSysInstance and isisSysLevelIndex are used in notifications, and so
the MIB compiler we use gives warnings because these objects have MAX-ACCESS
(Continue reading)

Permalink | Reply | 0 comments |
headers
Don Goodspeed | 5 Apr 2004 19:22
Picon
Favicon

RE: Minor comments on draft-ietf-isis-wg-mib-13.txt


Jon,

Had a chance to review your comments since I helped generate/
contribute to a couple of the attributes, tables, TCs, etc.
that you mentioned.  I agree with most of the text changes.
The only points I did not have an opinion on were:
 - the change of the isisSysInstance and isisSysLevelIndex
   to accessible-for-notify
 - the references to "l1" vs "l2" being more consistent
 - The rename of the isisISAdjAddress... objects to Addr...

On your last discussion point on isisCircLevelID, I think the
latter suggestion is the one to go with (purely used as the
ptPtCircuitID) but I'd like others to comment.

Cheers,
Don
=======================================
Hi,

We've got a number of minor suggested clarifications and typo fixes to the
MIB, itemized below. Hopefully, these won't be too controversial!

Please let me know what you think.

Thanks,
Jon
-------------------------------------------
Jon Harrison
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeff Parker | 5 Apr 2004 22:21

Minor comments on draft-ietf-isis-wg-mib-13.txt

More private comments on the Mib: the issue of Corrupted LSP and
AuthFailures.  Relevant portions of mib are below.  

1) The isisCorruptedLSPDetected states that it is to announce the detection
of an in-mmeory corruption.  I have found it much more useful to announce
the detection of on-the wire corrupted LSPs.  

Proposal: 
	A) modify the Description to include Corrupted LSPs found on the
wire
	B) modify the object to include the isisCircIfIndex where we found
the packet.  If the LSP is really corrupted, the sysid would be suspect.  

2) For isisAuthenticationTypeFailure and isisAuthenticationFailure, we
include the packet header, level, and circ index.  Would it be useful to
include the packet type?  While this is contained in the PDU fragment, it
may help developers working on trap handlers to know the packet type.  If
so, do we want all packet types, or just to distinguish between hello
packets and the rest, as the authenetication for these packets are
configured differently.

Proposal: Add an object to both Auth Traps that will ease dispatching on
packet type.  

- jeff parker

    isisCorruptedLSPDetected NOTIFICATION-TYPE
        OBJECTS {
            isisSysInstance,
            isisSysLevelIndex,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeff Parker | 5 Apr 2004 22:51

Minor comments on draft-ietf-isis-wg-mib-13.txt

Jonathan -

I am accepting almost all of you helpful suggestions.  
However, this gave me pause.  I would thnk that the
two reasons you spell out would apply to isisCircRejAdjs, 
while InitFails would count link problems, such as NCP
failures on PPP.  You are probably right about the reference,
but I would argue that there are more reasons to drop adjacencies
today (non-matching IP adress, disagreements on 3-way handshake,..)
and we should put your two events in CircRejAdjs.  

- jeff parker

 - isisCircInitFails refers to "ISIS.aoi initialisationFailures", which
counts specific adjacency initialization failures due to having no version
or area address in common.  The MIB should spell this out.  For example,
"The number of times initialization of an adjacency on this circuit has
failed due to the peer having either no version or no area address in common
with the local system." 

Relevant objects below

    isisCircInitFails OBJECT-TYPE
        SYNTAX Counter32
        MAX-ACCESS read-only
        STATUS current
        DESCRIPTION
            "The number of times initialization of this circuit has
             failed."
        REFERENCE "{ISIS.aoi initialisationFailures (41)}"
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeff Parker | 5 Apr 2004 23:03

Minor comments on draft-ietf-isis-wg-mib-13.txt

Jon -
	Since we have the isisCircLevelDesIS to define the CircID for LANs,
I see no problem restricting isisCircLevelID to P2P circuits. 
	Any issues with this?

	Your mail, and relevant portions of mib follow.  

- jeff parker

- Finally, isisCircLevelID.  I'd like to clarify whether this object is
only used for point to point circuits (as suggested by the reference to
ptPtCircuitID), or whether this field can be given a sensible value for a
LAN (since the CircuitID syntax doesn't give an option to return a zero
length OCTET STRING).

If the field does take a value on a LAN (with the disadvantage of making the
meaning of the field less clear), then the following text could be used.

"On a point to point circuit with a fully initialized adjacency to a peer
IS, the value of this object is the circuit ID negotiated during adjacency
initialization.  In all other cases, the value is the concatenation of the
local system ID and the one byte isisCircLevelIDOctet for this circuit.
This is the value that would be proposed for the circuit ID on a point to
point circuit, or for the LAN ID should this node be chosen as the LAN
Designated IS."

Or if the field is purely for use as the ptPtCircuitID, I suggest we change
the Circuit ID syntax to "OCTET STRING (SIZE(0|7))", and change the
description as follows:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jonathan Harrison | 7 Apr 2004 11:51
Favicon

RE: Minor comments on draft-ietf-isis-wg-mib-13.txt

Jeff,

I agree.  It is clearer to have isisCircLevelID restricted to P2P circuits.

Jon

-----Original Message-----
From: Jeff Parker [mailto:jparker <at> axiowave.com]
Sent: 05 April 2004 22:04
To: Jonathan Harrison; Jeff Parker; isis-wg <at> ietf.org
Subject: [Isis-wg] Minor comments on draft-ietf-isis-wg-mib-13.txt

Jon -
	Since we have the isisCircLevelDesIS to define the CircID for LANs,
I see no problem restricting isisCircLevelID to P2P circuits. 
	Any issues with this?

	Your mail, and relevant portions of mib follow.  

- jeff parker

- Finally, isisCircLevelID.  I'd like to clarify whether this object is
only used for point to point circuits (as suggested by the reference to
ptPtCircuitID), or whether this field can be given a sensible value for a
LAN (since the CircuitID syntax doesn't give an option to return a zero
length OCTET STRING).

If the field does take a value on a LAN (with the disadvantage of making the
meaning of the field less clear), then the following text could be used.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane