Improvements for the sample tech document

["Thomas Dietz" <Thomas.Dietz@netlab.nec.de>]

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