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

Re: Improvements for the sample tech document

being probably the first one really reasoning about how to write an info model for the PSAMP exporting (and how an implementation can follow it) you're the first one stepping in the (unresolved) issue of which syntax to use for describing a filter. This was already raised at the IETF in Wien 1 Year ago.
To summarize it:
there are two options about how to describe a filter:
1) describe it with a "high level" syntax (like the one you propose) probably easy to implement and to export, that can build on existing common practice and code, but with the risk that it is "incomplete" and has to be proprietarily extended to match each vendors' implemented filtering rules (thus risking low interoperability)
2) describe it with a "low level" syntax, in which whatever high level syntax can be translated (thus 100% interoperable and complete), with the (limited??) drawback of bigger exporting overhead and the (big??) drawback of needing to write, on each equipment, the code that converts the description of a propriatery high level filter into that one?

Just to explain the current situation: in the absence of a decision, I described in the sample tech draft the low level syntax only, but I'm not engaged to it...
If we want to take the other approach fine, but in this case the group should reach some agreement of what this syntax should look like. Thomas stated his proposal, but it's necessary to have a more extensive discussion on it. In particular, other vendors should state what their common practice in filtering is (which fields do you filter on? can you define masks, intervals, etc.?.).

The group should also decide if 1) and 2) are mutually exclusive, and if not what is MUST, what SHOULD and MAY.....

After that, it makes sense to change the sample tech draft.


Thomas Dietz wrote:


my name is Thomas Dietz and I am the editor of the PSAMP info model and MIB draft. I am currently reviewing my drafts for the changes made especially in the sample tech document. Reviewing the document I encountered some problems with the filtering techniques. I have some trouble with the information model defined in the sampling tech document.

I think that these bit specifications combined with the selection intervals is not really easy to understand and has several disadvantages:

* to encode many selection interval into one information model field is very complicated to encode and thus also very complicated to decode at the receiver * always encoding a complete header bitfield (20 bytes IPv4, 40 bytes IPv6) will create very large fields while exporting the filtering options from the sampling node * defining the header as a fixed number of bytes is (at least within IPv6) not right, because the header may have several extension headers * you may want to filter on some specify transport layer fields like tcp/udp port or icmp type: filtering on these gets very difficult especially in the IPv6 case because you don't exactly know where the transport header starts. * filtering on extension headers in IPv6 is also very tedious with the current approach

I would prefer to concentrate one some header characteristics like

* network protocol (IPv4, IPv6, IPX, Appletalk...) * transport layer protocol (TCP, UDP, SCTP, ICMP...) * transport layer dst/src port (if applicable) * IPv4/v6 dst/src address I know that the above is far of being complete but I don't think we need to have every single header field in the basic standard. If a vendor really needs some more fields he/she can define the fields and extend the info model. Most of the fields I mentioned above are computed in current hardware products anyway, because most of the products support filtering mechanisms. So using these fields also for exporting packet samples would imply a rather small overhead for the manufacturer. On the other hand implementing a bitfield computation as you propose currently is not that common in the current products and has to be implemented from scratch which consumes additional memory and is error prone.

I also dislike the idea of several ranges within one filter. I would rather define at most one range per filter and add another filter after the previous one. This would as well as the proposal above improve the readability and is much easier to specify in the info model. It keeps exporting option data/templates small and fast.

Furthermore, if the info model is easy to understand it will also be easy to implement.

It would be great if we could improve the sample tech document in a way that makes it easy and fast to implement.

Best Regards,


-- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/psamp/>