Re: Improvements for the sample tech document

[Maurizio Molina <Maurizio.Molina@ccrle.nec.de>]

Thomas,
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.

Maurizio

Thomas Dietz wrote:

> Hallo, 
>
> 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, 
>
> Thomas 
>  



--
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/>