Re: [802.1] MSTP MIB - mstpMapTable

[Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>]

On Thu, Sep 08, 2005 at 10:45:49AM +0300, Romascanu, Dan (Dan) wrote:
> Juergen, 
> 
> I agree with your argumentation, I know that fitting notifications in
> one PDU is not the only problem, and I know that enforcing the 484 limit
> is not enough, and does not provide a non-fragmentation warranty. There
> is however one basic issue, the fact that a >484 bytes OCTET string
> object is an obvious case where no single set or get operation will
> succeed in any situation, and this happens for classes of SNMP entities
> defined as fully standard compatible by RFC 3417. No tools are needed to
> see this contradiction, and my question is whether we want to mention
> this case in the review guidelines, as we do for example with the OID
> size limitations in Section 4.6.6. 

The point is that if you have an object which is > 400 bytes or so (as
I said, I am not so sure what the size of the typical header is),
splitting it into smaller pieces might make you sleep better but
depending on the semantics of the split object (and relationship to
other objects), you might wake up later with some headache.

If something should be added to the guidelines, then I think we should
suggest something along the lines what Bert said:

  MIB module authors should carefully check what the minimum message
  requirements for a given MIB module are. In general, SNMP is only
  guaranteed to support message sizes of 484 bytes over the default
  UDP transport [RFC3417]. If the 484 byte maximum message size
  constraint is too tight for a given application domain, MIB module
  authors must state in the MIB module description that
  implementations must support larger message sizes. Note that
  [RFC3417] recommends that SNMP engines support message sizes up to
  1472 bytes and so it might be viable for a given MIB module to
  assume messages sizes up to 1472 bytes. However, assuming message
  sizes above 1472 bytes is discouraged since such message sizes are
  very likely to cause IP layer fragmentation.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany