Hi David, I think we are probably talking about two different things here.
Let me start with this: > One protocol does not travel within the other; they are > independent protocols. Honestly, I think there was something different being discussed on this list, and I used this as a sample. I am primarily refering to this thread here: http://www.syslog.cc/ietf/autoarc/msg00992.html Let me sum it up as *I* understand it: There is some concensus that it is helpful to allow a syslog message to be feed to an SNMP based system. To do so, there should be a mapping between a syslog message and an SNMP trap (or inform?) message. I think the quoted thread was about this. So what I see is the following picture: Device --> syslog relay/gateway --> SNMP As written, the syslog relay is no less a simple relay but more an application level gateway between syslog protocol and SNMP protocol. It must encapsulate/map the syslog message to SNMP. In general, this is relatively straightforward. Move the syslog MSG to the SNMP message equivalent and copy some of the header fields (like timestamp) to the SNMP properties. It becomes complicated, if the syslog message is of large size (e.g. 1024 byte) and the SNMP implementation only supplies message text up to 512 bytes (due to MTU restrictions). Please note that the numbers are randomly taken - actual values may be different but I wanted to save some time on an exact research. I think the provided random numbers give a good-enough idea. Now we have the issue that the syslog2SNMP gateway can not forward the full message via SNMP, simply because the message text does not fit. So it has these choices: - discard message at all (if it can't deliver it completely, it does deliver nothing) - discard the 512 octets at the end that do not fit. These are LOST - use syslog multi-part messages and create 3 SNMP messages (why three? Syslog multi-part messaging takes some extra space, so the overall message size becomes larger than 1024.) This is the model I have in mind. Now to the answers: > Assuming you use snmpv3 with e2e encryption, the relay > wouldn't be able > to access the message contents to fragment it. An SNMP message should > never be fragmented anyway, so using snmp for the example is a bad > choice. The SNMP message will not get "fragmented". It is syslog multi-part messaging, that is applied to the syslog part of the gateway, only. SNMP syntax and semantic will not be touched. > You should definitely not think of snmp as just some type of > transport; > it is a network management protocol at the same level as syslog. You > shouldn't talk about sending snmp over syslog, and you shouldn't talk > about sending syslog over snmp. SNMP is a parallel NM protocol for > specific types of management communications, such as notifications, so > syslog doesn't need to reinvent that wheel. Well, actually I find some value in the ability to integrate syslog message into an SNMP solution. I think we all know this is probably not the best way to do it, but it may be very handy if the syslog-talking device in question does not at all support SNMP... I think that was the spirit behind the quoted discussion thread above. > It would be good if the > format selected for content in the syslog protocol could be reused > easily in the parallel SNMP protocol. I think the format is far different. The header fields and some other structured elements will probably be be able to be mapped to SNMP. But I think it is a mapping (gateway level), not a pure resue. And keep in mind, I am *ONLY* talking about syslog-type message being sent as TRAPS. I am NOT talking about MIB GET/SET requests. > The idea of a syslog relay fragmenting an snmp notification is just > wrong. I agree ... and a syslog relay will never fragment a SNMP message, because it does not know SNMP at this level. What I could forsee, however, is: SNMP Trap --> SNMP/syslog Gateway --> syslog server In this case, the same semantics as in my first example would need to apply. If I take the SNMP trap message AND its size is larger than what is supported in the syslog system, then the SNMP to syslog Gateway has the same choices. If I had to implement the gatway, I would probably use syslog multi-part messaging to transmit the whole message. > One protocol does not travel within the other; they are > independent protocols. >From a high-level point of view, I would find it desirable to have rules that would >allow to travel syslog data over an SNMP tunnel and SNMP messages to travel over a >syslog tunnel. In this case, if the sender AND receiver is both syslog (or both >SNMP), I would assume that the message should be received as a native, unalterated >message on the receiver. I think, however, that this goal is not worth putting big >effort into achieving this. But I don't see anything bad to at least keep it in mind. I don't see any bad per sé in allowing one protocol to travel inside another as long as this does not force any degradation in either of the protocols. Rainer > > dbh > > > -----Original Message----- > > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > > Sent: Friday, February 13, 2004 12:55 PM > > To: [EMAIL PROTECTED] > > Subject: -procotol relay operations > > > > Hi WG, > > > > we talked quite a bit about different MTUs for different transport > > mapping. We may run into a situation where a message is > larger than is > > actually supported by the transport (e.g a hypothetical SNMP trap > > transport supporting only ~500 octets). As we have multi-part > > message in > > -protocol, a relay COULD create a multi-part message at this > > time. This > > could be an elegant solution to the minimum size problem, > too. You can > > directly compare it it IP fragmentation. > > > > Question now: Is there any objection against specifying it in > > that way, > > at least as a MAY rule for relays. I think it definitely has > > advantages > > - it allows us to care for the unsual cases... > > > > Rainer > > > > > > > > >
