Subject: Improvements for the sample tech document

From: "Thomas Dietz" <[email-masked]>
Date: Sun, 11 Jul 2004 19:46:26 +0200

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/psamp/>

---

From: Maurizio Molina <[email-masked]>
Date: Wed, 14 Jul 2004 12:14:01 +0200

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

---

From: Nevil Brownlee <[email-masked]>
Date: Thu, 15 Jul 2004 09:30:10 +1200

Hi Thomas:

I think Maurzio summarised 'filtering rules' well.

> not what is MUST, what SHOULD and MAY.....

As another example of current practice, you might have a look at 
RTFM's Simple Ruleset Language, RFC 2723.

SRL uses simple (equality under mask) tests of RTFM attribute values
from the packet.  Using the RTFM attributes to select fields from
the packet has the advantage that they're well defined, and RTFM's
IANA considerations (in RFC 2722) saying how new attributes can be
added.

It has the disadvantage that it was built on top of the RTFM packet
matching engine, which is very general, and hence difficult (but
certainly not impossible) to implement in a high-speed metering
system.

Cheers, Nevil

-----------------------------------------------------------------------
   Nevil Brownlee                 Computer Science Department | ITSS
   Phone: +64 9 373 7599 x88941           The University of Auckland
   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand

-------------------------------------------------
This mail sent through University of Auckland
http://www.auckland.ac.nz/