Subject: [ipfix-info] Information Element naming convention

From: Benoit Claise <[email-masked]>
Date: Tue, 23 Nov 2004 13:46:59 +0100

Dear all,

We know that information elements can come from the packet header, the 
characteristics of the packet itself, or the fields derived from packet 
treatment, as defined in the "IP flow" terminology section.

 IP Traffic Flow or Flow 
 
   There are several definitions of the term 'flow' being used by the 
   Internet community.  Within the context of IPFIX we use the 
   following definition:
   A Flow is defined as a set of IP packets passing an Observation 
   Point in the network during a certain time interval.  All packets 
   belonging to a particular Flow have a set of common properties.  
   Each property is defined as the result of applying a function to the 
   values of: 
    
      1. one or more packet header field (e.g. destination IP address),    
      transport header field (e.g. destination port number), or  
      application header field (e.g. RTP header fields [RFC1889]) 
    
      2. one or more characteristics of the packet itself (e.g. number  
      of MPLS labels, etc...) 
    
      3. one or more of fields derived from packet treatment (e.g. next  
      hop IP address, the output interface, etc...) 

I would like to propose the following convention in [IPFIX-INFO].
The information elements exported after packet treatment would start 
with "post"

Example:

classOfServiceIPv4
   Description:
      The value of the IPv4 TOS field observed for packets of this flow.

postClassOfServiceIPv4
   Description:
      The value of the IPv4 TOS field for packets of this flow, 
      after packet treatment.

Feedback?

Regards, Benoit.

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/

---

From: Simon Leinen <[email-masked]>
Date: Tue, 23 Nov 2004 15:11:15 +0100

> Feedback?

I think "post" is somewhat unspecific, unless it is clear what exactly
the "packet treatment" consists of.  It assumes that an observation
point has access to these values in exactly two points: "" (meaning
"pre"), and "post".

Looking at your example, it seems clear that your observation point
must be "inside" the packet treatment (integrated somewhere into the
forwarding/filtering/classification/marking decision logic).  Note
that this doesn't fit nicely into the (idealized) IPFIX architecture
as it currently stands.

In any case it would make sense to talk about "pre" and "post", not
just "post" for all properties that can be changed in the course of
packet treatment.

But the real question is, shouldn't we specify (pre- or) "post-WHAT"?

For some treatments this immediately seems to make sense, e.g.

deltaOctetCountBeforeIngressACL
deltaOctetCountAfterIngressACL
deltaOctetCountAfterIngressPolicing
deltaOctetCountAfterEgressACL
deltaOctetCountAfterEgressShaping

- where the actual order or presence of different steps will be highly
implementation-dependent.

The clean/naive solution would be to have multiple observation points,
which could contribute different values for observed properties of the
same identical flows.  But the current IPFIX architecture doesn't
support this.

Now... if templates could somehow specify a "scope" (or
"observation-sub-point" :-) for each field (in addition to
enterprise/type and field length), then multiple instances of fields
such as "classOfServiceIPv4" or "deltaOctetCount" could peacefully
coexist in a single Data Set, without any explosion of field types.

What about aligning the Template Set Format with the Options Template
Set Format, so that (data) Templates could have sections for different
Scopes, just like Option Templates? (At least that's what I understand
the current Option Template should support.)

Then enterprises (or maybe even the IETF) could define Scope Field
Types corresponding to different well-defined points in packet
treatment.

Regards,
-- 
Simon.

---

From: Benoit Claise <[email-masked]>
Date: Mon, 29 Nov 2004 16:58:58 +0100

Simon Leinen wrote:

>forwarding/filtering/classification/marking decision logic). 
>
I'm not sure why? The observation point is something abstract.
Let's take a simple router, composed of 2 interfaces.
You would like to account for flows as packets enter the router, so 
observed packets with the observation point = the incoming interface
You would potentially like to account for flows as packets leave the 
router, so the packets transmitted (*) by the observation point = the 
outgoing interface
(*) to say transmitted, we can say "after packet treatment"
However, you could also see the router as one big observation point (I 
guess this is what you are referring to in your previous sentence): this 
doesn't change the logic. We want the packets observed as they enter, 
and transmitted as they leave.

> <> Note

> <>In any case it would make sense to talk about "pre" and "post", not

I used "post" as opposed to observed. Observed is the default behaviour 
of IPFIX; "An Observation Point is a location in the network where IP 
packets can be observed.". So implicetely, you observe the packet(s) 
before you change anything on it/them.
As a default behaviour, I don't think we need to specify "pre" for all 
the information elements.

>deltaOctetCountAfterEgressShaping
Let's ask an easier question first: how to report egress NetFlow
(http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_guide09186a00802d41ea.html)?

>implementation-dependent.
Exactly. And we standardize the export, not the metering process

>same identical flows.  But the current IPFIX architecture doesn't
Potentially. Again, that would be exporter architecture-dependent. And 
we standardize the export, not the metering process

>Types corresponding to different well-defined points in packet
I'm afraid that all the different vendors will have different exporter 
architecture, different "internal" scope or "observation-sub-point".
And that at the end, it will be difficult for the collectors to conclude 
anything common about the flows from different vendors
This is the reason why I was proposing something simple, for a simple 
problem first
    Observerd = pre = default
    Transmitted = post = after all packet treatments => use post in 
information element naming convention

Regards, Benoit