[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
* 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
* filtering on extension headers in IPv6 is also very tedious with the current
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
and has to be implemented from scratch which consumes additional memory and is
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
It would be great if we could improve the sample tech document in a way that
makes it easy and fast to implement.
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.