RE>Re- FddiTime

[James Reeves <[e-mail]>]

         Reply to:   RE>Re:  FddiTime
[e-mail] writes:
>>After doing some quick math I came up with 2.86 minutes as a max
>>on a signed 32 bit integer in 80 nanosecond units.  Looking over SMT 7.1, it
>>looks like none of the MAC timers get even close to this value, which
>>leaves PORTMACLoopTime and SMTTrace-MaxExpiration as possible points of
contention.  PORTMACLoopTime does have its range explicitly 
>>stated in SMT 7.1 (2500000..4294967295 in 80 nanosecond units), but its
status is optional so it's likely to be dropped from the SNMP MIB.  
>>SMTTrace-MaxExpiration has a range greater than 6 seconds, but it's unlikely
that a user would need to set the value between 2.56 and 5.12 minutes.

Agreed. Having 2 minutes, 51 seconds as the upper bounds for BOTH MACLoopTime
and SMTTraceMAXExp is more than reasonable. MACLoopTime is used to allow a Port
to connect to a neighboring MAC during PCM link establishment. Anyone who
expects to hold a connection in that state for more than a few seconds does not
understand the problem. SMTTraceMaxExp is the upper bound for an unterminated
trace to exist before the station enters a Path Test. Most people would want to
REDUCE this timeout not increase it. The only reason a Trace Max would be in
the range of minutes would be in extreeeemely large rings (i.e. 5000-10000
nodes). Let's get serious.

Let's do our job. Map the bleepping SMT MIB into SNMP format and move on. There
is no sane reason for redefining the SMT MIB. If you feel that parameters in
the SMT MIB are in the wrong format then you should submit a public review
comment to that effect. (Public review of 7.2 begins in August). Otherwise,
stop impeding progress. The SMT standard has come a long way and take a long
time; right or wrong, our job is to define the mapping rules which should be as
close to the SMT MIB as SNMP will allow.

James Reeves
SynOptics Communications

"The views expressed here are mine. If the company does not agree, to hell with
them."