Hi, I pointed out the SNMP limitation only in consideration of SNMP/syslog integration - for example, many SNMP managers and agents are probably not going to be able to handle notifications with payloads in excess of 1472 bytes easily, and some won't handle payloads above 484 octets. I don't think we should design for the worst case though. I think it is reasonable to expect most current SNMP/UDP/Ethernet implementations to support 1472 octets, especially since RFC3417 recommends supporting that size for a UDP mapping.
The SNMP notification should set a limit on the size or mention that there may be interoperability issues above 1472 octets. dbh > -----Original Message----- > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > Sent: Thursday, February 12, 2004 9:18 AM > To: Harrington, David; [EMAIL PROTECTED]; Anton Okmianski > Subject: RE: syslog message size and fragmentation > > David, > > > You should also keep in mind, for SNMP/syslog interaction, > > that SNMP/UDP > > messages should not be fragmented if possible, to handle > the case when > > some packets are dropped. > > > > To claim compliance with the standard, implementors must support > > messages up to and including 484 octets. They are encouraged > > to support > > larger sizes up to 1472 octets. The 1472 number is the largest SNMP > > message that will fit into an Ethernet packet without forcing > > fragmentation, if I remember correctly. > > as I outlined in a message in reply to Anton (which probably did not > reach you by now), I am in strong favour of NOT extending beyond 1024 > bytes. But do you have a recommendation/experience on what we > should do > if the transport can not (reliably) support those 1024 bytes? > 484 octets > is very short for syslog. So if we set a fixed limit and set > it to 484, > there is virtually no space left for actual payload in some > circumstances. > > And the bad thing... syslog is SIMPLEX... That means the sender has no > way to discover the MTU via the syslog protocol - simply because there > is no interaction with the receiver (and definitely not with the > ultimate receiver in a relay chain). > > MTU discovery, at least in IPv4, does not work reliably (eg firewall > filtering ICMP), so I don't think this is an option. Its also quite > complex. > > I have to admit I am currently struck and have no clue about > what a good > way to handle this situation would be. Again, please keep in > mind syslog > is SIMPLEX! > > Any advise is deeply appreciated, > Rainer > > > > > dbh > > > > > -----Original Message----- > > > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > > > Sent: Wednesday, February 11, 2004 11:57 AM > > > To: [EMAIL PROTECTED]; Anton Okmianski > > > Subject: syslog message size and fragmentation > > > > > > Hi WG, > > > > > > I had an off-list discussion with Anton that lead to the > > > discovery of a > > > new issue in -protocol, that of message fragmentation. -protocol > > > specifies a message size limit of 1024 characters, but also > > > assumes that > > > message of this size can always be transmitted without (transport) > > > fragemention. In the real world, datagram based transport > > > mappings will > > > probably not be able to assure that the message will not become > > > fragmented. The MTU can at least be as low as 576 bytes. > > > > > > Must this issue be addressed in the context of -protocol? If > > > so, what is > > > the best solution? > > > > > > Thanks, > > > Rainer > > > > > > > > > > > >
