[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: support for new work

Hummm, I'm surprised Andy's mail didn't elicit more response. I agree with
Andy's points below. I think Wes's proposal is right on, and goes a long way
towards addressing real operator needs.


> -----Original Message-----
> From: Andy Bierman [mailto:abierman@cisco.com]
> Sent: Friday, August 16, 2002 12:55 PM
> To: eos@ops.ietf.org
> Subject: support for new work
> Hi,
> This email is intended to state my opinion on the new work proposals
> made to the EOS WG, because the WG Chair is trying to gauge consensus,
> and silence means no opinion.
> MIB proposals:  I do not think any of the various MIB proposals
> should be pursued by this WG. 

[Dave] I absolutely agree. The MIB proposals simply make the problem worse,
trying to fix protocol problems in the data model is not helpful, it makes
already complicated network management even more complex.
> OID optimizations: I favor protocol mechanisms for OID compression
> and suppression, because this would be a generalized solution.
> I do not support any solution which relies on opaque, packed 
> OCTET STRINGs to achieve these goals, because an engine would
> not be able to generically unpack the data. There are also
> issues with holes in rows and MIB versioning that make this approach
> undesirable.

[Dave] Again agree. SNMP OID handling makes even the extremely verbose XML
encodings look efficient! The protocol is the only reasonable place to fix
this problem.
> Protocol Operations: I support Wes Hardaker's proposal,
> Object Oriented PDUs for SNMP. There are a lot of details
> to work out, but it looks promising for supporting SMIv3
> hierarchical data structures, as well as addressing some
> current inefficiencies in the protocol.  
[Dave] Agree. Wes's proposal is right on.

> Backward and Forward Compatibility: I think new features should only 
> be supported in new protocol operations because this allows
> the most flexibility to do proper design. Retrofitting existing
> protocol operations with new features will result in hacks,
> and create more implementation complexity than it solves.
> Old protocol operations should continue to be supported,
> exactly as currently defined.
[Dave] Regardless, the implementation still has to go somewhere. Might as
well attack the problem at the bottleneck itself: the protocol operations.
(do we add 1K LoC to support a few new protocol ops, or 100K LoC to
implement some complex work-around. We've made these mistakes in the past,
let's not repeat them moving forward (I can still hear the operators
laughing at the futility of the work-around approach).

> Transport: This new protocol version (with object oriented 
> protocol operations) should be run over UDP or TCP.  No
> complex hacks should be added to support large PDU fragmentation
> if UDP is used. Large PDUs should only be supported over TCP.
> Session based features (e.g., security, compression) should
> be considered for the TCP version.
[Dave] Agree... Welcome to 2002. My watch can run TCP just fine thank you.
UDP is great for app-level pinging, and checking interface status. Leave the
bigger jobs for the better transport.

> Andy