Re: Various DECnet MIB questions

[EMA - we manage almost anything! <[e-mail]>]

Well, while I was out for a week of vacation this discussion sure got
interesting. A few observations...

First, I hope everyone has a copy of the Phase IV DECnet Network Management
Spec available. I don't see how you can interpret the mib without it.

Re: Question (3) Adjacency, where most of the discussion has centered...

    I think the approach of using two indices is best. Certainly that's what we
    used in Phase IV management (with NICE). The "right" order as others have
    pointed out is

    	INDEX { phivAdjCircuitIndex, phivAdjNodeAddr }

    At the risk of destabilizing the concensus, If you absolutely must keep the
    existing table with a single integer index (because some companies have
    implemented it and shipped code based on it) you probably ought to clarify
    how that table is ordered. That should be legal as it only involves a
    change of description text.

    Begin digression :-)

        I can see three ways off the top of my head that phivAdjIndex could
        have been implemented. The description text should reflect the actual
        implementations.

    1   phivAdjIndex is an arbitrary index without any additional organization,
        i.e. adjacencies might as well be assigned an index by a random number
        generator. Of course this forces a management station to search the
        whole table to find anything. If you can't agree on the meaning of
        adjacency index, or if there were different implementations, this is
        the fallback interpretation.

    2   It is the index (i) referenced in the Routing Spec (V2.0) pages 39-41
        that John Shriver noted. This at least divides the various kinds of
        adjacencies up into buckets, but within a bucket, adjacencies are
        randomly assigned an index. I don't see this as offering any advantage.

    3   It is derived from the circuit number and a node address by an
        algorithm, say...

    	adjIndex = 65536 * circuitIndex + 1024 * areaNumber + addressInArea

        This has the advantage of ordering the adjacencies naturally (in fact
        it gives the same order as the double index technique). However, I'll
        bet that no one has actually implemented it this way.
        
    End digression :-)

    A warning that might avoid problems...

    Because a node address is encoded in the mib as a Octet String (length 2),
    the object identifier arcs that it gets turned into are not what you might
    expect. RFC1212 (on pg 9) states that when a fixed length string of size N
    is used as an index, it is encoded as N sub-identifier arcs, each encoding
    1 octet. For example, the node address 4.941 is the integer 5037, and is
    the octet string '13 AD' (octet 1 is '13' octet 2 is 'AD') and is
    represented in the index as <stuff>.19.173 (someone should check my
    arithmatic). 

    Because node addresses  show up as indices in a couple of tables (the end
    table, and this table) I'd recommend you describe the mapping (by reference
    to RFC1212 and perhaps by example) on pgs 4&5 where you describe PhivAddr.
    It is especially important to state that a PhivAddr is treated as a fixed
    length string, not a variable length string.

Re: Locking Counters & Zero

    Counters in a Phase IV system that supports the NICE protocol can be zeroed
    using the zero or read-and-zero actions or by setting up periodic zeroing
    using the counter timer attribute.

    In the phiv-mib the equivalent function to the zero action is provided for
    by setting the phivCircuitCountZeroCount to reset(2). There is no exact
    equivalent to read and zero, although a Get followed by a zero is close.
    The mib does not support counter timers.

    DECnet Phase IV also provided events (counters zeroed and counter timer)
    which recorded the values of the counters just before they were zeroed. The
    mib has no equivalent traps.

    The seconds since last zeroed counter will latch after about 18 hours. The
    other counters (even the 32 bit ones) will eventually latch too. So using
    latching counters without periodically issuing get and zero actions has its
    problems. (I joke that in 1976 when Bob invented this stuff, no one
    expected a system to stay up for 18 hours straight :-). 

    For what it's worth, in Phase V we got rid of latching counters, made them
    all wrap and got rid of the idea of zeroing them also. SNMP follows the
    same tack.

    My understanding is that the mib tries to follow the phase IV specs on
    this. It wasn't the goal of the work to "improve" DECnet Phase IV (or SNMP
    for that matter), but simply to reflect how Phase IV works given the
    capabilities of SNMP. Given that set of goals, the approach taken in the
    mib seems about right to me.

Re Multiple equal cost routes to a node...

    Yes it's a problem, but we never solved it in Phase IV (or in Phase IV+)
    management. Equal cost paths work in routing, but the info available to
    management couldn't show anything but the first path. This messes up path
    tracing applications, which end up showing only one of the possible paths.

Mark