RE: RE: EFM OAM MIB and the DateAndTime TC

Matt asked for opinions.  Here's one from the cheap seats:

I agree wholeheartedly on the value of having accurate timestamps that can be correlated to other system events.  However, without a clear idea of the time/date capabilities of the range of devices for which .3ah OAM may be desired, I'd have to say, make the information universally "ok" for everybody, rather than "good" just for the folks with time/date capabilities.  Some thoughts and questions:

- If zeroes are returned for timestamps on systems where date/time isn't available, then useful information (not "perfect information") maintained in the OAM sublayer is being purposefully ignored and concealed.  That doesn't help anybody solve problems.

- Mandating date/time-or-nothing might place additional burden on some .3ah device designs that wish to support timestamps, when it's too early to tell what kinds of devices could benefit from .3ah OAM.  I don't have an application which would benefit one way or the other, but I'm just guessing.

- Not every network device with date/time functionality has the date and time configured, or configured properly.  Have seen more than a few switches and routers with files in flash with the date March 1 1993.  I know, this is a configuration problem and the gear shouldn't be operated that way, but sometimes they are.

- OAM sublayer timestamps are at 100msec granularity.  Time/date can't be any more precise than that (for OAM timestamps).  Is sysUpTime any worse from an accuracy standpoint?

I don't feel that strongly about this and David made some very good points below, but I just recall that one of the intents of the 100msec timestamps in .3ah OAM was that any device capable of implementing the OAM sublayer would be able to generate these timestamps.  Somehow seems wrong to suppress useful capabilities in the MIB for some .3ah OAM devices in favor of enhanced capabilities in other .3ah OAM devices.

Thanks,

Brian


At 01:16 PM 12/9/2004 -0500, Matt Squire wrote:

>Hi David - 
>
>I don't really argue with most of the arguments you give below - date/time is better if you have it.  I guess the big question is whether its more important for this application to take steps to make things better when you have date/time, or to make things better when you don't have date/time.  Either approach sacrifices something for the other guy.   On the one hand, we can take an approach that gives "ok" information for everybody, or an approach that gives better information when you have date/time and no information when you don't.  All of the other stuff (return 0s, excpetions, errors, etc.) seems like noise.  
>
>If the market was clear and there were a bunch of volume shipments then we could probably just look at the existing market and make a determination.  At this point, its just guessing what kind of capabilities will exist in products that implement 802.3ah OAM functionality.  
>
>There were at least a couple of people that mentioned to me that date/time would be a problem for them, so I leaned in the direction of supporting their application better.  I'm hoping to get some more opinions.  
>
>- Matt
>
>
>
>
>> 
>> 1) I did not suggest returning an error code; I suggested returning an
>> exception. Returning a noSuchObject exception does not invalidate the
>> response, only the specific varbind. Exceptions were added to SNMP to
>> mitigate the problem of invalidating complete responses, a problem
>> which existed in SNMPv1. The problem you cite only exists if you use
>> error codes. You are limited to using error codes only if you use
>> SNMPv1.
>> 
>> 2) I read the security considerations section to determine whether the
>> sensitivity of the information counter-indicated the use of SNMPv1.
>> The security considerations section says that the information is
>> sensitive, and that security is important for this mib module. It goes
>> into great detail about ensuring that the non-secure L2 OAM protocol
>> is secured, and goes on to say that SNMPv1 is not recommended because
>> it is not secure. Since the use of SNMPv1 is not recommended, and
>> later versions of SNMP support exceptions, the problem you cite should
>> not be an issue.
>> 
>> 3) The application receiving a timestamp of zeroes has no more
>> information than if it had received an exception. In both cases, it
>> knows that the device that had the event does not support the
>> date/time capability, and the event occurred sometime prior to the
>> application receiving it. So it makes little difference when getting
>> the object from a device that doesn't support a clock. It makes a big
>> difference when getting the object from a device that does support a
>> clock.
>> 
>> 4) If knowing WHEN an event occurred is important, then I would think
>> it would make more sense to know when it occurred at the remote device
>> that had the event rather than when it was received by the local
>> agent. 
>> 
>> 5) sysUpTime is relative to the last restart of the management system,
>> and if the application doesn't know quite when that was, relative to
>> clock-time, all it can do is ESTIMATE when the event occurred. The
>> estimate will be muddied by any network latency. Given the inaccuracy
>> already introduced by timestamping a remote event with the agent-local
>> time, and adding to that the imprecision of roughly estimating when an
>> event ocuured based on sysUpTime, it strikes me that the precision is
>> getting very poor. If this object lacks precision, is it still really
>> useful?
>> 
>> 6) Assuming an agent's clock is consistent with other agents' clocks,
>> an application receiving a date/time timestamped event report has more
>> useful information than one receiving a sysUpTime timestamp. With a
>> date/time timestamp, the application can do a much better job of
>> correlating events across multiple devices, which can be important for
>> troubleshooting. Correlating events properly can be important for
>> troubleshooting problems such as worms, viruses, routing/switching
>> updates, performance bottlenecks, etc. 
>> 
>> 7) Lack of accuracy in correlating the times of multiple events could
>> lead operators to incorrectly dismiss some paths of investigation, and
>> waste time pursuing other paths, because the timestamped event
>> information is so inaccurate. 
>> 
>> I question the wisdom of using a sysUpTime timestamp rather than a
>> date/time timestamp in this table.
>> 
>> 
>> David Harrington
>> [email protected]
>> IETF MIB Doctor
>> 
>
>_______________________________________________
>Hubmib mailing list
>[email protected]
>https://www1.ietf.org/mailman/listinfo/hubmib