FDDI mib comments

[dsiinc![e-mail]]

I'm having trouble remembering all the changes we made to the
FDDI mib at the last IETF meeting and I want to make sure I
understand everything correctly.

[By the way, I've needed 16 different conversion routines to 
translate between the SMT and SNMP variable encodings.]

According to the published meeting notes:
>        Minutes of the FDDI MIB Working Group  November 19, 1992
>  FddiTime
>    The group agreed to express FddiTime as a positive integer in 1 nanosecond
>    units.  The editor was directed to include a complete, appropriate,
>    example to eliminate the confusion surrounding two's complement.

This means we can represent values up to 2,147,483,648 nanoseconds.
While this should be sufficient for all the TimerTwosComplement 
variables, it is definitely not sufficient to hold 
SMTTraceMAXExpiration (which, by default, is 7 seconds).

As this particular variable really doesn't require nanosecond 
precision, I recommend we convert it to 1 ms units, just like the
timestamps.

>  Timestamp
>    The group agreed to rescale Timestamp to express it in 1 millisecond units.

I'm assuming from this that these will become simple Counters or 
INTEGERs so we drop the 8-byte OCTET STRING encoding.

I can't remember the what we decided to do with the optional 
variable "Setcount".  I can't remember if we agreed to remove 
it or not, but I am now very sure that I want it removed.  
After many attempts, I can't figure out how this provides any 
locking or consistency control at all.

In SMT, the Setcount is tightly coupled with every MIB access. 
If implemented, it is required to change any time an attribute
is changed through a PMF frame or a local management process.

However, in SNMP, there is no way to guarantee this consistency.
First, suppose Setcount is not implemented in your particular SMT.  
This means that the SNMP agent (or proxy) must maintain this 
locally.  For an SNMP proxy, there is no way to guarantee that the 
SMT MIB (and hence the SNMP MIB as well) doesn't change through an 
SMT interface.  There is no mechanism for SMT to inform SNMP that 
a MIB change has occurred.

In the second case, assume Setcount is implemented in SMT.
In this case, the SNMP agent must read Setcount before it attempts 
to change a variable.  However, in the time between the SNMP agent 
reads Setcount and the time it actually performs the Set, an SMT 
frame could come in and change the variable.

Therefore, I don't believe that any SNMP SetCount would be 
tightly enough coupled with SMT to provide any reliable
locking mechanism.  In my opinion, an unreliable lock is
worse than no lock at all.

Next, it is not clear to me how to encode PORTRequestedPaths.
In the current FDDI mib document, this is specified as an 
INTEGER [0..255].  However, this is incorrect.  PORTRequestedPaths 
is actually 3 separate integers, each [0..255].  I recommend
representing this as a 3-byte OCTET STRING, with the first byte 
corresponding to 'none', the second byte corresponding to 'tree' 
and the last byte corresponding to 'peer.'

Last, there were no responses to my last message, which asked 
about ghost resources.  I'll include the message again, in 
hopes that someone will respond with their views about ghost
resources.

[Hello, is anyone out there?]

[From my last message:]
>I was working on implement the new FDDI MIB, and I realized I am 
>absolutely clueless as how to handle ghost resources.
>
>For those not familiar with SMT, ghost resources provide the
>underlying mechanism for dealing with "hot insertion" of MACs and
>PORTs.  The example is a modular concentrator that you can plug 
>port cards in while it is running.  Magically, the concentrator 
>recognizes the new ports and brings them into service.
>
>In SMT, these variables are handled through the use of "mandatory, 
>if present".  In other words, access to "mandatory, if present" 
>variables fails if the fddiPORTHardwarePresent or fddiMACHardwarePresent
>flags are not set, indicating a physically present resource.
>
>I was thinking about something Jeff Case said at the last IETF meeting.
>He said that if you don't support an entire group, you can't claim
>conformance to the group.  In addition, you'd better not fake it 
>by making up values to return for the variables you can't support.
>With ghost resources, I don't see how we can simultaneously meet 
>both criteria without modifications to the MIB.
>
>For example, some of MAC variables are mandatory, regardless of whether 
>or not the MAC is physically present.  GETs, SETs and (powerful) 
>GET-NEXTs of this should return good values for all cases.  However, 
>if an SNMP manager is doing a mib walk, what should they get when they 
>access snmpFddiMACFrameCts for a MAC that is not physically present?  
>
>If you adhere to the rule that the entire group must be supported, the 
>agent would have to make up some appropriate value.  However, it can't 
>do this because there is no way to represent the value "not present."  
>
>In addition, SNMP managers would continually have to retrieve the 
>hardware present flag every time they accessed one of these variables, 
>to ensure the answers they were receiving made sense.  
>
>The alternative is to just skip those table variables when they are 
>not present, as SMT does.  For SNMP GETs/SETs, NoSuchName would
>be returned and GET-NEXT would just step over them to the next 
>physically present resource.  However, according to Jeff, this would 
>mean that no one claiming to support ghost resources could ever claim 
>that they support the FDDI MIB, since they wouldn't adhere to the 
>"all or nothing" principle.  The whole reason we added the MAC 
>Counters table, was to keep us from having to support stuff like this.
>
>A clean and simple solution to this problem is to create separate 
>tables for the "mandatory, if present" variables.  Thus, if the resource 
>is not physically present, the entire table does not exist.  This seems 
>to be consistent with SNMP's constraints.
>
>This would require creating two new tables:
>
>          -- groups in the FDDI MIB module
>
>          snmpFddiSMT           OBJECT IDENTIFIER ::= { thisDraft 1 }
>          snmpFddiMAC           OBJECT IDENTIFIER ::= { thisDraft 2 }
> *NEW*    snmpFddiMACPresent    OBJECT IDENTIFIER ::= { thisDraft 3 }
>          snmpFddiMACCounters   OBJECT IDENTIFIER ::= { thisDraft 4 }
>          snmpFddiPATH          OBJECT IDENTIFIER ::= { thisDraft 5 }
>          snmpFddiPORT          OBJECT IDENTIFIER ::= { thisDraft 6 }
> *NEW*    snmpFddiPORTPresent   OBJECT IDENTIFIER ::= { thisDraft 7 }
>
>The new groups would be indexed just like the existing MAC 
>and PORT groups.  The MACCounters table for a specific MAC 
>would exist iff the hardware is physically present.  
>
>The existing MAC and PORT variables can then be partitioned 
>into the two new groups:
>
>snmpFddiMAC group would contain:
>	  snmpFddiMACSMTIndex
>	  snmpFddiMACIndex
>	  snmpFddiMACRequestedPaths
>	  snmpFddiMACFrameErrorThreshold
>	  snmpFddiMACHardwarePresent
>	  snmpFddiMACMAUnitdataEnable
>
>snmpFddiMACPresent group would contain:
>	  snmpFddiMACFrameStatusFunction
>	  snmpFddiMACTMaxCapability
>	  snmpFddiMACTVXCapability
>	  snmpFddiMACAvailablePaths
>	  snmpFddiMACCurrentPath
>	  snmpFddiMACUpstreamNbr
>	  snmpFddiMACDownstreamNbr
>	  snmpFddiMACOldUpstreamNbr
>	  snmpFddiMACOldDownstreamNbr
>	  snmpFddiMACDupAddrTest
>	  snmpFddiMACDownstreamPORTType
>	  snmpFddiMACSMTAddress
>	  snmpFddiMACTReq
>	  snmpFddiMACTNeg
>	  snmpFddiMACTMax
>	  snmpFddiMACTvxValue
>	  snmpFddiMACFrameCts
>	  snmpFddiMACCopiedCts
>	  snmpFddiMACTransmitCts
>	  snmpFddiMACErrorCts
>	  snmpFddiMACLostCts
>	  snmpFddiMACFrameErrorRatio
>	  snmpFddiMACRMTState
>	  snmpFddiMACDaFlag
>	  snmpFddiMACUnaDaFlag
>	  snmpFddiMACFrameCondition
>	  snmpFddiMACMAUnitdataAvailable
>	  snmpFddiMACChipSet
>
>snmpFddiPORT group would contain:
>	  snmpFddiPORTSMTIndex 
>	  snmpFddiPORTIndex 
>	  snmpFddiPORTMyType
>	  snmpFddiPORTConnectionPolicies
>	  snmpFddiPORTRequestedPaths
>	  snmpFddiPORTLerCutoff
>	  snmpFddiPORTLerAlarm
>	  snmpFddiPORTHardwarePresent
>	  snmpFddiPORTAction (Why is this mandatory in SMT?  How can 
>			      you send an action to a port that is not
>			      physically present?)
>
>snmpFddiPORTPresent group would contain:
>	  snmpFddiPORTNeighborType
>	  snmpFddiPORTMACIndicated
>	  snmpFddiPORTCurrentPath
>	  snmpFddiPORTMACPlacement
>	  snmpFddiPORTAvailablePaths
>	  snmpFddiPORTPMDClass
>	  snmpFddiPORTConnectionCapabilities
>	  snmpFddiPORTBSFlag
>	  snmpFddiPORTLCTFailCts
>	  snmpFddiPORTLerEstimate
>	  snmpFddiPORTLemRejectCts
>	  snmpFddiPORTLemCts
>	  snmpFddiPORTConnectState
>	  snmpFddiPORTPCMState
>	  snmpFddiPORTPCWithhold
>	  snmpFddiPORTLerFlag
>	  snmpFddiPORTChipSet
>
>Comments?
 
Ron Mackey			Distributed Systems International, Inc.
[e-mail]			531 W. Roosevelt Road, Suite 2
708-665-4639			Wheaton, IL 60187-5057