Re: IS-IS MIB

[Steve Moulton <moulton@snmp.com>]

On Thursday, May 30 2002, Jeff Parker <jparker@axiowave.com> wrote:

> Bert W. has suggested I take the following question to the mibs group.
> 
> ISIS defines an object called a Link State PDU (Protocol Data Unit) or LSP.
> Since ISIS does not fragment, the LSP is designed to be as big at the MTU
> will allow.  The max size of LSPs is often 1492, though there are provisions
> to make the MTU large in networks with all point-2-point links, so the LSP
> can be 4K or larger.  
> 
> The LSP is a fundamental object in the IS-IS world, and many systems provide
> a command that shows the user the LSP broken down into components.  Thus
> there is interest in providing an SNMP get for the LSP.  (Set is not
> appropriate)  The question before us is
> 
> 	Can we in good conscience define an SNMP object that is bigger than
> 1472 bytes? 
> 
> 	If so, and applying the salami principle, does 4K break things? 9K?
> 
> 
> - jeff parker
> - axiowave networks
> - All those who believe in psychokinesis, raise my hand.

There is no fundamental problem with having an object of the size
you suggest in SNMP.  There are some considerations to bear in mind. 
   
.  If the object size plus packet overhead is larger than the 
   MTU for the entire path from the agent to the manager, the
   packet will get fragmented at the IP level, and reassembled
   at the destination.  This has no bearing directly on the
   SNMP implementation, but does increase the probability that
   the datagram cannot be reassembled due to one or more of the
   fragments getting lost.  Datagrams that cannot be reassembled
   are silently dropped.  The only action one might take here 
   is to increase the number of times the manager retries sending
   the request before it decides that it cannot communicate with 
   the agent.

   Note that NFS has been operated satisfactorily with
   datagram fragmentation for years, though generally on networks
   of fairly small radius.  There is no problem peculiar to SNMP here.

   To quote rfc1270: 

               Fragmentation and Reassembly does reduce the overall
               robustness of network management since, if any single
               fragment is lost along the way, the operation will fail.
               The worse the network operates, the higher the
               probability that a fragment will get lost or delayed.
               For monitoring and data gathering while the network is
               operating normally, Fragmentation and Reassembly is not a
               problem. When the network is operating poorly (and the
               network operators are typically trying to diagnose and
               repair a failure), small packets should to be used,
               preventing the packet from being fragmented.

   As this is a monitoring application, fragmentation is not an issue.

.  There is an implementation-specific issue.  Agents and managers often
   have an implementation-defined limit on the size of the SNMP message
   they can deal with.  While this is a simple issue of buffer sizes,
   it often requires a constant change and recompilation in the agent
   and manager code.

   If an object this size is specified in a MIB document, I recommend
   that a NOTE WELL be included regarding making sure the managers and
   agents utilizing the objects from this MIB document have an
   adequate snmpEngineMaxMessageSize [rfc2571]. Since there is some
   overhead in SNMP packets for the header and encoding, the
   maximum message size should be rather greater than the object
   size; I use two times the maximum object size as a rule of thumb.

   While rfc2571 describes snmpEngineMaxMessageSize as being the
   minimum of the maximum message sizes available to the agent
   (maximum size available to the transport layer,
   not the link layer), SNMP engines commonly use a smaller value
   to minimize allocated buffer size.

.  rfc2578 (the now-applicable SMIv2 document) suggests that some
   implementations restrict the maximum OCTET STRING size to
   255.  This, too, is often a recompilation issue.  An implementation
   I am familiar with places the same size restriction on OCTET STRINGs
   as it does on messages.  Display strings are still limited to 255 octets
   (rfc2579).

Best Regards,

Steve

---
Steve Moulton        SNMP Research, Inc            voice: +1 865 573 1434
Sr Software Engineer 3001 Kimberlin Heights Rd.    fax: +1 865 573 9197
moulton@snmp.com     Knoxville, TN 37920-9716 USA  http://www.snmp.com