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


Hi David, thanks for the prely. See my comments below.

-----Original Message-----
From: David T. Perkins [mailto:dperkins@dsperkins.com]
Sent: Wednesday, December 05, 2001 4:33 PM
To: Subrata Goswami; eos@ops.ietf.org
Subject: Re:

On the following....

At 03:54 PM 12/5/2001 -0800, Subrata Goswami wrote:
>Questions on the draft "Efficient Transfer of Bulk SNMP Data".
>1. Why is an TLV type encoding required ? Is it not possible to
>   simple ASCII encoding (is done HTML).

TLV is better than just "simple ASCII".

>> Can you please provide an example, or elaborate ?

>2. How much overhead does BER added compared to simple ASCII ?
BER encoding in most cases is more efficient to encode than
ASCII, and in many cases it is smaller in size. Remember, that
most bulk data is statistics (numbers) and status (typically
a small number or a few bits).

>> I fail to understand how TLV type BER encoding is more efficient than

>3. I am trying to understand what the following section imply.  To the
>   best of my knowledge most devices now a days have HTTP servers embedded
>   for device management. So no extra overhead would be there as the device
>   understands both HTTP and HTML.

It is not the case that most devices have embedded WEB servers. Using
a WEB server takes up much more resources than SNMP or an FTP client,
or FTP server.

>> I do not see how a HTTP server takes more resources than a FTP or TELNET
If fact, in the last 2 years I have not come across a single
network device that does not have an embedded HTTP server ( expect may be
the 4 port hub I bought for my home).

>   "Other non-SNMP alternatives for bulk transfer include using MIME or
>   XML Document Type Definition (DFD) to encode the MIB data. The data
>   can then be transferred via the well-known HTTP protocol since it is
>   well suited for bulk transfer of MIME-encapsulated data. However,
>   since HTTP is primarily intended for transferring World Wide Web
>   data, it has many features and options that are not required for
>   management data. However, a compliant implementation will
>   nevertheless have to implement those features thereby increasing the
>   size and complexity of the SNMP implementations without additional
>   benefit. In addition, future evolution of HTTP may add features or
>   requirements that make it unsuitable for transferring MIB data."
Here is a description of the problem....
* In "small" network devices that are used in homes, small offices,
  and small enterprises, there is not much data, so bulking it
  is not a problem. These are typically the class of devices
  that have an embedded WEB server. These devices are not
  typically CPU max'ed out.

Disagree, we have build 50+ port  GigE boxes with web-servers. Most of
these large boxes have have CPU solely for box management functions.
When you are saying CPU maxed out,  it depends on the design of the

* For devices that are used in medium sized (and larger) enterprise
  networks, and ISP networks, there is much data, and bulking is
  important. For these devices, they typically are not managed with
  an embedded WEB server. For lower-end devices (and older devices),
  they are typically CPU max-out when loaded (and, thus, have a
  lot of data). For higher end devices, they can have massive
  quantities of data.

>>agreed, but I am not sure  how BER or FTP is any  better than ASCII/HTTP
in this context.

* the manager side issues are easily resolved. If you run out of
  CPU cycles, then it is easy (and not too costly) to upgrade the
  manager station (or even distribute the work). Likewise, adding
  memory, disks, network interfaces is easy and inexpensive
  compared to "upgrading" a network device. With a network
  device, you have very limited choices (if any) from the vendor
  in increasing the processing power or adding memory, or

So, my conclusion is that ASCII HTML encoding and using HTTP seem
to be undesirable choices from the device side of things compared
to, say, an efficient SNMP encoding or using FTP.

>> Well I  disagree again, do you have any  numbers to show that support
   your conclusion ? Back of the envelope calculation would be good enough.


/david t. perkins