Subject: [ipfix-protocol] One correction in the "octets" information elements

From: Benoit Claise <[email-masked]>
Date: Wed, 04 May 2005 10:03:15 +0200

Juergen,

We realized that the Information Element #1 octetDeltaCount, which is in line with NetFlow version 9, is not correctly specified.

5.9.1  octetDeltaCount
  Description:
     The number of octets since the previous report (if any) in
     incoming packets for this flow at the Observation Point.  The
     number of octets include IP header(s) and IP payload.

-> New Description:
     The number of octets since the previous report (if any) in
     incoming packets for this flow at the Observation Point.  The
     number of octets exclude the data link header and trailer.

This allows to account for the length of MPLS labels, for the ISL bytes, etc...

Several I.E. below the 128 should be updated
octetDeltaCount #1, 
postOctetDeltaCount #23,
octetTotalCount #85,
postMulticastOctetCount #20

And to be consistent amongst the I.E., the I.E. above 128 should be updated as well
postOctetTotalCount #160,
droppedOctetDeltaCount #132,
droppedOctetTotalCount #134 

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: Juergen Quittek <[email-masked]>
Date: Sun, 08 May 2005 01:44:43 +0200

Hi Benoit,

--On 5/4/2005 10:03 AM +0200 Benoit Claise wrote:

> Juergen,
>
> We realized that the Information Element #1 octetDeltaCount,
> which is in line with NetFlow version 9, is not correctly specified.
>
> 5.9.1  octetDeltaCount
>   Description:

I see the following problems with this change.

  - This implies that we count more than just the IP packet.
    Since this is counter is fundamental for IPFIX, we would need
    to discuss precisely what is measured.  I do not like the
    inclusion of non-IP octets in the count to be hidden in these
    three lines.

  - How useful would this information be?  How would the collector
    know that the MPLS labels are included in the count?

  - Even if the collector knows that MPLS labels are included in the
    count, it would not be able to just subtract them for calculating
    the pure IP octet number, because it does not necessarily known
    how many labels are on the label stack.

  - Which information elements should a device use that supports MPLS
    but is able to calculate the precise IP octet count, for example
    at the end of the MPLS tunnel where both counts (with and without
    labels) are available?  Instead of defining another information
    element for this case, I would rather define a new one for the
    IP+MPLS octet counter.

  - The definition of data link header and trailer is vague.
    Do we have a reference defining these terms?
    Without such a definition, Some people may consider MPLS
    as a data link layer protocol particularly since this is
    correct for some applications of GMPLS.

  - I am not sure which other technologies besides MPLS would potentially
    include octets in the stream that do not belong to IP but are counted
    by this counter.

Best regards,

    Juergen
-- 
Juergen Quittek        [email-masked]       Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de

> octetDeltaCount #1, postOctetDeltaCount #23,
> octetTotalCount #85,

---

From: Benoit Claise <[email-masked]>
Date: Mon, 09 May 2005 11:05:43 +0200

Juergen,

>  - How useful would this information be?  

Just one example: capacity planning with a MPLS core, when you want to 
know exactly what has been sent and not only the IP part of the packet.

> How would the collector

Counted by default.

>    how many labels are on the label stack.

If you really want to do it, you can export the number of labels as a 
different I.E.

>    element for this case, I would rather define a new one for the

Defining a new set of counters might prove to be the only remaining 
solution.
I would keep the I.E. #1 (octetDeltaCount) for IP + MPLS, as this is 
what NetFlow version 9 does now.

>    include octets in the stream that do not belong to IP but are counted

ISL, dot1q

Regards, Benoit.

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 09 May 2005 12:56:07 +0200

--On 5/9/2005 11:05 AM +0200 Benoit Claise wrote:

> Just one example: capacity planning with a MPLS core, when you want to know exactly what has been sent and not only the IP part of the packet.
>
>> How would the collector
> If you really want to do it, you can export the number of labels as a different I.E.
>
>>
> Defining a new set of counters might prove to be the only remaining solution.
> I would keep the I.E. #1 (octetDeltaCount) for IP + MPLS, as this is what NetFlow version 9 does now.

What about renaming #1 to subIpOctetDeltaCount and introducing a new one for pure IP
that will then inherit the name octetDeltaCount?
(Sub-IP was the name of the IETF area that dealt with MPLS.)
We probably would have to do this for all counters of octets in packets, i.e.

postOctetDeltaCount #23, octetTotalCount #85, postMulticastOctetCount #20,
postOctetTotalCount #160, droppedOctetDeltaCount #132, droppedOctetTotalCount #134.

Cheers,

    Juergen

---

From: Sebastian Zander <[email-masked]>
Date: Wed, 11 May 2005 18:41:50 +1000

> droppedOctetTotalCount #134.

having both counter types seems to be a good idea.

cheers,

Sebastian

-- 
Sebastian Zander
http://caia.swin.edu.au

---

From: Tanja Zseby <[email-masked]>
Date: Fri, 13 May 2005 11:52:08 +0200

Hi Jürgen and Benoit,

I think that it is extremely important to have the IP octet counter 
consistent, so that always the same is counted regardless of the traffic 
(e.g. whether it is MPLS or not). So I would prefer to have one counter 
that only counts the IP octets. Since counting IP+MPLS may be of 
advantage for capacity planing etc., I think the best solution is to 
provide a further counter as Jürgen proposed.

Regards
Tanja

Juergen Quittek wrote:

>> Just one example: capacity planning with a MPLS core, when you want 
>> to know exactly what has been sent and not only the IP part of the 
>> packet.
>>
>>> How would the collector

-- 
Dipl.-Ing. Tanja Zseby			    	      	
Fraunhofer Institute FOKUS			Email: [email-masked]	
Kaiserin-Augusta-Allee 31			Phone: +49-30-3463-7153
D-10589 Berlin, Germany				Fax:   +49-30-3463-8153
-------------------------------------------------------------------------------------- 
"Living on earth is expensive but it includes a free trip around the sun." (Anonymous)
--------------------------------------------------------------------------------------

---

From: Benoit Claise <[email-masked]>
Date: Fri, 13 May 2005 16:08:31 +0200

Dear all,

I've been thinking about this issue for some time and I'm wondering if 
we're not going in the wrong direction. Let me explain

Tanja is right that IPFIX needs some consistent counters definitions. 
After all, these counters are the fundamental information elements in 
IPFIX, as Juergen explained.

Personally, I see some value in exporting counters with "The number of 
octets exclude the data link header and trailer." as opposed to "The 
number of octets include IP header(s) and IP payload.". However, I 
understand both the pros and cons arguments.
These pros and cons arguments logically lead to the creation of two 
series of counters, one for subIP and one for IP.
Note that a series is composed of counters for all the combinations of 
(pre/post, delta/total, dropped or not, multicast or not), so A LOT OF 
counters.

If we start to systematically multiply the number of counters per 
technology, we will have so many to choose from that it can be a risk 
for interoperability.
Another risk is that we could multiply the counterS for any new 
technology to monitor: MPLS? ISL? dot1q? something else in the future? 
If we want to be complete, we should duplicate all the counters each time.

Maybe we want to take a step back, and keep a single series of counters. 
If the consensus is "The number of octets include IP header(s) and IP 
payload." as it was initially in the draft, fair enough. At least we 
would keep IPFIX simple.

If a vendor would like to use a very specific I.E. (ex: number of octets 
including the MPLS labels length), this could still be done with an 
enterprise-specific I.E., with an extra I.E (example: exporting the 
number of labels would allow to recompute the MPLS + IP length), with a 
request to IANA for one specific I.E.  In this last case, it would be 
based on customer requests, so a good reason, as opposed trying to 
specify a full set of I.E. at the IPFIX information model creation time.

In conclusion, I don't think multiplying all the counters is a good 
choice for the future adoption of IPFIX.
Feedback?

Regards, Benoit.

> consistent, so that always the same is counted regardless of the 
> traffic (e.g. whether it is MPLS or not). So I would prefer to have 
> one counter that only counts the IP octets. Since counting IP+MPLS may 
> be of advantage for capacity planing etc., I think the best solution 
> is to provide a further counter as Jürgen proposed.
>
> Regards
> Tanja
>
>
> Juergen Quittek wrote:
>
>>
>>

---

From: Brian Trammell <[email-masked]>
Date: Fri, 13 May 2005 11:37:20 -0400

Benoit,

I strongly agree, for two reasons. From a protocol simplicity 
standpoint, IPFIX is basically a key-value protocol with a flat key 
space. The issue at hand seems to come up quite often for flat key 
spaces, that is, at some point it seems to make sense to "tree up" the 
key space a little, and suddenly you've got combinatorial explosion and 
you're completely out of bits. Given that it seems like we don't want 
to tear the protocol down to the studs and throw out the flatness of 
the key space (thereby making "real" implementations infeasible on the 
router side), avoiding this combinatorial explosion is a very good 
thing.

Second, and this is a little more selfish, I'm interested in IPFIX for 
network security applications. IP is really all that matters to me, 
because it's all that's visible at the end-node. I'm not an operator, 
and I'm not well-versed in either of the dark arts of MPLS or capacity 
planning in general, but it seems label sized should be relatively 
estimable; that is, by looking at the packet counters you can roughly 
account for sub-IP overhead on your network. It doesn't seem that the 
results WRT capacity planning from this admittedly less-optimal 
solution are significantly worse than counting every last sub-IP octet.

One concern: from the router-side implementation standpoint, are there 
performance implications for mandating that only IP octets be counted 
on an MPLS network?

Regards,

Brian

On May 13, 2005, at 10:08 AM, Benoit Claise wrote:

> Maybe we want to take a step back, and keep a single series of 
> counters. If the consensus is "The number of octets include IP 
> header(s) and IP payload." as it was initially in the draft, fair 
> enough. At least we would keep IPFIX simple.
>
> If a vendor would like to use a very specific I.E. (ex: number of 
> octets including the MPLS labels length), this could still be done 
> with an enterprise-specific I.E., with an extra I.E (example: 
> exporting the number of labels would allow to recompute the MPLS + IP 
> length), with a request to IANA for one specific I.E.  In this last 
> case, it would be based on customer requests, so a good reason, as 
> opposed trying to specify a full set of I.E. at the IPFIX information 
> model creation time.
>
--
Brian H. Trammell / MTS, CERT/NetSA / <[email-masked]> / 412.268.9748

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 13 May 2005 16:34:55 +0100

I have been out of the loop, so sorry for jumping into the
middle of the thread.

Tanja Zseby wrote:

> that only counts the IP octets. 

I agree. We need this simple counter, no matter what else we do.

> Since counting IP+MPLS may be of 

Do we want to have one counter per type, or a compound counter
that is the bitmask of included fields, followed by value itself.

i.e. to define an IE of the form:

  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| | | | | | | | |   64 bit Counter value.........
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
  ^ ^ ^ ^ ^ ^ ^ ^
  | | | | | +-+-+- Reserved must be zero
  | | | | +------- Datalink trailer
  | | | +--------- Payload
  | | +----------- IP header
  | +------------- MPLS label Stack
  +--------------- datalink header

This would allow the exporter to provide a counter of
whatever type the application needed.

- Stewart

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 13 May 2005 19:46:51 +0200

Dear all,

Independent of what we choose, I think it is important having a very clear
definition of the octet counter.  If we go for the inclusion of MPLS labels
and other sub-IP components, then doubt that "The number of octets excluding
the data link header and trailer." is clear enough.  Would we have an RFC or
other reference that defines what is the data link header (and why the MPLS
label isn't one?

Thanks,

    Juergen

--On 5/13/2005 4:08 PM +0200 Benoit Claise wrote:

> Dear all,
>
> I've been thinking about this issue for some time and I'm wondering if we're not going in the wrong direction. Let me explain
>
> Tanja is right that IPFIX needs some consistent counters definitions. After all, these counters are the fundamental information elements in IPFIX, as Juergen explained.
>
> Personally, I see some value in exporting counters with "The number of octets exclude the data link header and trailer." as opposed to "The number of octets include IP header(s) and IP payload.". However, I understand both the pros and cons arguments.
> These pros and cons arguments logically lead to the creation of two series of counters, one for subIP and one for IP.
> Note that a series is composed of counters for all the combinations of (pre/post, delta/total, dropped or not, multicast or not), so A LOT OF counters.
>
> If we start to systematically multiply the number of counters per technology, we will have so many to choose from that it can be a risk for interoperability.
> Another risk is that we could multiply the counterS for any new technology to monitor: MPLS? ISL? dot1q? something else in the future? If we want to be complete, we should duplicate all the counters each time.
>
> Maybe we want to take a step back, and keep a single series of counters. If the consensus is "The number of octets include IP header(s) and IP payload." as it was initially in the draft, fair enough. At least we would keep IPFIX simple.
>
> If a vendor would like to use a very specific I.E. (ex: number of octets including the MPLS labels length), this could still be done with an enterprise-specific I.E., with an extra I.E (example: exporting the number of labels would allow to recompute
> the MPLS + IP length), with a request to IANA for one specific I.E.  In this last case, it would be based on customer requests, so a good reason, as opposed trying to specify a full set of I.E. at the IPFIX information model creation time.
>
> In conclusion, I don't think multiplying all the counters is a good choice for the future adoption of IPFIX.
> Feedback?
>
> Regards, Benoit.
>
>> Hi Jürgen and Benoit,
>>
>>> postOctetDeltaCount #23, octetTotalCount #85, postMulticastOctetCount
>>> # 20,