Subject: [ipfix-info] IPFIX-INFO open issue 1: octet count including layer 2 payload

From: Benoit Claise <[email-masked]>
Date: Tue, 07 Jun 2005 23:53:57 +0200

Dear all,

The last-call finishes on June 15th, so it's time to get a consensus regarding this open issue described in the latest section of [IPFIX-INFO]

      octet count including MPLS header: Does the octet count concern IP
      packets only or also sub-IP layers such as MPLS?

This is a follow up on the thread http://ipfix.doit.wisc.edu/archive/2783.html

The two important questions are:
1. do we agree that we need a single series of counters?
(see http://ipfix.doit.wisc.edu/archive/2808.html)
Am I right to say that this is the WG consensus?

2. If the answer is yes to the question 1, do we include the layer 2 payload in the counters?
Please give your point of view.
You know mine already: I think it makes sense.

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, 12 Jun 2005 00:18:46 +0200

Dear all,

RFC 3031 (MPLS Architecture) defines the following terminology:

>       layer 3                   the protocol layer at which IP and its
>                                 associated routing protocols operate

>       layer 2                   the protocol layer under layer 3 (which
>                                 therefore offers the services used by
>                                 layer 3).  Forwarding, when done by the
>                                 swapping of short fixed length labels,
>                                 occurs at layer 2 regardless of whether
>                                 the label being examined is an ATM
>                                 VPI/VCI, a frame relay DLCI, or an MPLS
>                                 label.

I clearly vote for including layer 3 octets only in our basic IPFIX octet
counters.  This means counting IP packets only and not any layer two headers,
frames, etc.

The alternative suggestion we are discussing would include some layer 2
technologies in the octet counters (MPLS, ISL, dot1q) and would
exclude others (Ethernet, ...).

This is conceptually complicated and we would have to maintain lists
of included and excluded layer 2 technologies.  Anyone who would interpret measured values would need to check carefully which layer 2 technology was
used at the observation point for the particular flow, because this would
have an effect on the measure numbers.

Compared to this, just including IP in the octet count is a very clean
solution for the counters #1 octetDeltaCount, #85 octetTotalCount,
#23 postOctetDeltaCount, #160 postOctetTotalCount,
#132 droppedOctetDeltaCount, #134 droppedOctetTotalCount,
and #20 postMulticastOctetCount.

    Juergen

---

From: Lutz Mark <[email-masked]>
Date: Mon, 13 Jun 2005 18:10:14 +0200

> You know mine already: I think it makes sense.

I vote for only having a single series of counters and like
Juergen's proposal to keep IPFIX simple via only counting
layer3 bytes.

The disadvantage is that one would have to use vendor specific IEs to
export layer2 bytes and that different vendors have to use different IEs.

What about allowing the use of the above counters also for the
export of layer2+3 bytes. Per default the counters only export
layer3 bytes. If an exporter wants to count also some bearer layer bytes
it has to announce this via an option record.

Best regards,
Lutz

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 13 Jun 2005 19:26:14 +0200

Hi Lutz,

> it has to announce this via an option record.

For this solution we would need at least one more information element
indicating layer 2 technologies that are included in the octet count.
An array of bit fields may be a possibility.  but it would probably not
be easy to extend it to new upcoming layer 2 technologies??

Definitely, the option record you suggest must be standardized in order
to be understood by every compliant collector.

Thanks,

    Juergen

---

From: Lutz Mark <[email-masked]>
Date: Tue, 14 Jun 2005 14:31:31 +0200

Hi Juergen,

> be easy to extend it to new upcoming layer 2 technologies??
maybe it is feasible just to announce the number of layer 2 bytes.

> to be understood by every compliant collector.
sure. If we run out of time, we can reserve
this feature for IPFIX version 2 ;-)

Best regards,
Lutz

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 14 Jun 2005 14:44:21 +0200

Hi Lutz,

> this feature for IPFIX version 2 ;-)

So you suggest to drop it for now?

Thanks,

    Juergen

---

From: Sven Anderson <[email-masked]>
Date: Tue, 14 Jun 2005 15:38:45 +0200

Dear all,

Benoit Claise schrieb:
> The last-call finishes on June 15th, so it's time to get a consensus 
> regarding this open issue described in the latest section of [IPFIX-INFO]
> 

For the case you are interested in an opinion from "outside" here's my
comment:

The project is about "IP flows", so I would of course expect, that such a
flow consists of nothing but IP packets, although it can be defined by
flow keys from sub-IP layers. I agree, that there are a lot of other
useful things to count, but these shouldn't be included in the basic octet
counters of the _IP_flow_ itself.

Imagine the same IP flow is measured at two observation points, and only
at one of them MPLS is used. These two flow measurements would have
different sizes, even if the IP packets haven't been altered (like
fragmented), although the defining attributes are the same. This will be a
source of confusion, I think.

Cheers,

Sven

-- 
Sven Anderson
Institute for Informatics - http://www.ifi.informatik.uni-goettingen.de
Georg-August-Universitaet Goettingen
Lotzestr. 16-18, 37083 Goettingen, Germany

---

From: Benoit Claise <[email-masked]>
Date: Tue, 14 Jun 2005 15:58:59 +0200

Lutz,

> this feature for IPFIX version 2 ;-)

If the consensus is to keep the counters for IP only, fair enough.
As the last-call is almost over (June 15th), I concur with Lutz's point 
of view.

Regards, Benoit.

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 15 Jun 2005 18:55:33 +0200

Sven,

Thanks for stating your opinion on this issue.
Unfortunately, the number of comments received so far is very short.

    Juergen

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 15 Jun 2005 19:35:38 +0200

> Unfortunately, the number of comments received so far is very short.

One inline :)

> >>      packets only or also sub-IP layers such as MPLS?

Of course *not*.

reasoning, mostly the same as Sven's, but to add some support to the
case:

If you would take IP over ethernet as an example:
   +---------------------+
   | Ethernet header.... |
   +---------------------+
   | IP -> flow size=500 |
   +---------------------+

Thus this flow is now sized 500 bytes, as IP shows this. Now on the
other side of your network, it passes over a router which has ATM or
MPLS or PPP or SLIP, whatever.

   +---------------------+
   | Whatever header.... |
   +---------------------+
   | IP -> flow size=500 |
   +---------------------+

Still the size is 500 bytes, nothing more nothing less. If you would add
the header this would marginally change +/- a couple of bytes.
If one wants to have counters for the complete frame, on whatever layer,
then we might want to add "L1_OCTETS" "L1_PACKETS" "L2_OCTETS" and
"L2_PACKETS" or something similar to solve this.

But *don't* stick it into the current counters, this is not what NetFlow
v9 does and not what, afaik, most implementations will expect to be
doing because of that. Also now it is quite easy to see, in above
scenario, that, based on src/dst/size pair the flow is most likely the
same one on the first router and on the second one, which allows nice
things like timings. While if you have different sizes, it is a
different flow most likely.

To put it differently IN/OUT_BYTES/PACKETS (1/2/23/24) describe the
Layer 3 flow and not the Layer 2 Flow, which might differ.

One sidenote though, with IPv6 one could have option headers, a router
might, under some circumstances add/remove such a header and thus change
the size of the L3 flow...

Greets,
 Jeroen

---

From: Sven Anderson <[email-masked]>
Date: Fri, 17 Jun 2005 02:28:37 +0200

Dear Jeroen, dear all,

> If you would take IP over ethernet as an example:

hmm... I have the feeling there is a misunderstanding. If I understood the
mails of Benoit correctly, there was never the question to include L2
headers like normal Ethernet headers in the counters. It was more about
technologies, which sit between L2 and L3 and therefore are placed in the
_payload_ of the L2 encapsulation (like the "shim" headers of generic MPLS
encapsulation, RFC 3031/3032). Let my try to explain to verify my understanding:

   Data Link         Case 1:   or    Case 2:
     Layer             IP          Shim Header
+-----------+        Only            + IP
|  Header   |
+-----------+....+----------+....+-----------+
|           |    |          |    |Shim Header|
|           |    |          |    |(e.g. MPLS)|
|           |    |    IP    |    +-----------+
|  Payload  |    |  Packet  |    |           |
|           |    |          |    |    IP     |
|           |    |          |    |  Packet   |
|           |    |          |    |           |
+-----------+....+----------+....+-----------+
|  Trailer  |
+-----------+

In the normal case 1 the size of L2 payload and IP-packet is the same, so
there is no problem. The question comes up in case 2, when not only the IP
packet but also other information like MPLS shim headers are included in the
L2 payload. You have to decide, if you count all payload bytes, or just the
IP packet size. If I understood Benoit right, Netflow v9 in this case counts
the whole payload, so not only the IP packet.

But all the mentioned arguments are valid anywa, because the shim headers 
can vary a lot from section to section. (MPLS labels for example can not 
only be stored in shim headers but can for instance also be included in ATM 
headers itself: RFC 3035). So I still would suggest to let the counters only 
count the bytes of the IP packets and not of the whole L2 payload, if they 
are different. If there is really the frequent need to count the whole L2 
payload size, I would suggest a second set of counter I.E.'s for the non-IP 
payload bytes in general (not technology depenend), which would be 0 in the 
usual case 1, and which could just be added to the basic counters if needed. 
If this need is not so common, it can be still defined as enterprise I.E.'s.

Correct so far?

Regards,

Sven

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 17 Jun 2005 06:25:11 +0200

Sven,

Thanks you for clarifying the issue.  I agree to your statements.
I just have a small comment on terminology.  Please find it inline.

> technologies, which sit between L2 and L3 and therefore are placed in the

Yes, it sits in between IP on L3 and some L2 technology, but it MPLS is
considered as part of L2 itself, see RFC 3031, MPLS architecture,
terminology section 2.2.

Thanks.

    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

>|           |    |          |    | Shim Header|
>|           |    |          |    | (e.g. MPLS)|
> But all the mentioned arguments are valid anywa, because the shim headers can vary a lot from section to section. (MPLS labels for example can not only be stored in shim headers but can for instance also be included in ATM headers itself: RFC 3035). So
> I still would suggest to let the counters only count the bytes of the IP packets and not of the whole L2 payload, if they are different. If there is really the frequent need to count the whole L2 payload size, I would suggest a second set of counter
> I.E.'s for the non-IP payload bytes in general (not technology depenend), which would be 0 in the usual case 1, and which could just be added to the basic counters if needed. If this need is not so common, it can be still defined as enterprise I.E.'s.
>
> Correct so far?
>
>
> Regards,
>
> Sven
>
> --
> Sven Anderson