Re: Implementation questions

dsiinc! Fri, 30 July 1993 14:04 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa04858; 30 Jul 93 10:04 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04854; 30 Jul 93 10:04 EDT
Received: from CS.UTK.EDU by CNRI.Reston.VA.US id aa10643; 30 Jul 93 10:04 EDT
Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA08845; Fri, 30 Jul 93 09:25:23 -0400
X-Resent-To: fddi-mib@CS.UTK.EDU ; Fri, 30 Jul 1993 09:25:21 EDT
Errors-To: owner-fddi-mib@CS.UTK.EDU
Received: from relay2.UU.NET by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA08822; Fri, 30 Jul 93 09:25:16 -0400
Received: from (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA18261; Fri, 30 Jul 93 09:25:10 -0400
Date: Fri, 30 Jul 93 09:25:10 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: dsiinc!
Message-Id: <9307301325.AA18261@relay2.UU.NET>
Received: from dsiinc.UUCP by with UUCP/RMAIL (queueing-rmail) id 092335.3329; Fri, 30 Jul 1993 09:23:35 EDT
To: Anil Rijsinghani <uunet!!>
Cc: uunet!!
Subject: Re: Implementation questions
Content-Type: text
Content-Length: 2886

>Anil writes:
>"Initialization of the management system" has rather more severe
>implications than you attribute to it below.  For example, it would wipe
>out counters in all other areas of the FDDI MIB, and presumably in all
>other SNMP MIBs reported by the device.  This would make hot swapping
>defeat its own purpose (at least from the management point of view :-)

"Initialization of the management system" [from a SMT perspective] does
not guarantee reinitialization of counters.  From section 6.4.4 in the
SMT document:

[Talking about discontinuity in the instantiation of object classes]

    A statistical counter attribute may assume its latest prior value, 
    if known, and if the resource index for its associated object is 
    known not to have changed; oterhwise it shall be reset to its initial
    value.  The value of statistical information is generally enhanced
    if the continuity of counters is maintained.

Perhaps a better phrase than "initialization of the management system"
would be "discontinuity of a managed object".  SMT is not required to
maintain the state of any MIB object across a discontinuity in the
management of the object.

>We do want to retain continuity across all variables that remain
>unaffected by the change -- this is precisely why the requirement for
>contiguity of indices was removed.  (The current draft of the
>new ifmib has quite a bit of detail on the subject of how ifNumber
>and indexing were redefined to accomodate hot swapping.)

But, who decides which variables are unaffected by a particular change?
Pick almost any FDDI variable, and I can give you an example of how it 
can "magically" change as a result of a particular hot swap.  For 
instance, when you swap a MAC card, when the user reads the MAC counts, 
how do they know if they are reading from the old card or the new card?

Even worse, swapping in a new PORT or MAC card may affect other SMT 
and PATH variables as well as just the PORT and MAC variables.  Put 
in a new card and SMTMac-Ct may change as well as SMTNonMaster-Ct, 
SMTAvailablePaths, SMTConfigCapabilities, etc.  The PATH information 
is almost guaranteed to change, as there are no guarantees that the 
new card resides on the same paths as the old card or you may have 
inserted a completely new card which inserts a completely new path.

In short, with the ability to hot swap, I don't believe you'll find
very many FDDI variables that are GUARANTEED NOT to change during the
hot swap.  Anyone accessing the FDDI MIB must be aware of the potential 
for inconsistencies of this type.

Of course, in reality, hot swaps are not likely to occur with any great
frequency, so the periods of inconsistency should not prove to be a 
problem in most cases.

Ron Mackey			Distributed Systems International, Inc.			531 W. Roosevelt Road, Suite 2
708-665-4639			Wheaton, IL 60187-5057