Subject: [ipfix-data] draft-ietf-ipfix-data-00.txt - comments

From: Ganesh Sadasivan <[email-masked]>
Date: Thu, 14 Feb 2002 19:28:28 -0800

Hi,
Here are my first pass comments, questions and
suggestions on draft-ietf-ipfix-data-00.txt.
Thanks
Ganesh

What is the idea behind putting Section 4.1-4.4? Is this a
rough list or a complete list? Is this section supposed to
cover all the fields in section 5?

5.1.1. Version Number
Which version # is this refering to -  IPV4/V6?

5.1.2. FLOWS
This is # of flows which got aggergated at a second
level meter.

5.2.1.  Source Address IE
5.2.2.  Destination Address IE
5.2.3.  NEXT_HOP_IP IE
Are we not distinguishing between V4 and V6 addresses by different IEs?
To me separate IE  is better than infering through version# .

5.3.3.  Delta Time IE
Just curious. How does this field get used?

5.3.4.    LAST_SWITCHED
SysUptime at which the last packet of this flow was processed
by the meter before the flow record was exported or the
flow ended.

5.3.5.    FIRST_SWITCHED
SysUptime at which the first packet of this flow was processed
by the meter.

5.4.1.  Class of Service IE
There should be separate IEs to distinguish between
Cos for V4, V6, MPLS & VLAN. A packet can have more
than one Cos fields, each associated with
{<v4 | v6> & <mpls> & <vlan>}

5.4.4
"This information is used by applications to later correlate the
ingress/egress port with a specific Exporter. "

What does this mean?
This looks to me as a part of the flow header extension which
is optional.

5.5.  Flow State IE
A better way to put this would be "export reason" which could
be:
1. Inactive
2. End of flow detected
3. Forced export
4. Cache full

5.6. Statistical Elements
Some of the IEs that I can think of:

From the observation domain
* Flows collected
* Flows dropped

From exporter
* Export data packets sent
* Export control packets sent
* Export data packets dropped

5.6.1.  Byte Count IE
5.6.2.  Packet Count IE
How does one distinguish between delta counter and running
counter at the collector?

5.6.3.  Dropped Byte Count IE
I'm not sure how accurate one can get here. The packets may be dropped
before the actual metering itself happened or well after the metering
has
happened (like another LC in a distributed system). But yes,
in some cases this would work fine.

5.6.5.    IPM_DPKTS
Total number of packets after replication for this multicast flow.

5.6.6.    IPM_DOCTETS
Total number of octets after replication for this multicast flow.

5.8.3. Next Hop AS IE
Don't we need a "Previous Hop AS IE"?

5.11. BGP & Vlan IE's
May be better to split these 2 into 2 different sections (BGP related
and VLAN related).

5.11.4.  Source VLAN ID IE
5.11.5.  Destination VLAN ID IE
Is there not a one-to-one correspondence between VLAN-ID and
interface Index? I am wondering where this would useful.
Is there a plan to distinguish between .1p and .1q?

5.13.7.    IGMP_TYPE
Types of IGMP messages of concern to the host-router
interaction.

--
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: [email-masked]
Date: Tue, 19 Feb 2002 15:36:36 -0500

> To me separate IE  is better than infering through version# .

	It is just an encoding thing. Either there is
	a field that is part of the address encoding that
	gives address family (ala RFC 1700 - which is now
	obsolete) or you have a separate IE for each. We
	can get to those details later.

> Just curious. How does this field get used?

	***IF*** there is any kind of Flow update then
	this field tells you how much time is covered
	by the update. Don't know if we are doing
	flow update messages yet, so it is here as
	a placeholder for now.

> by the meter before the flow record was exported or the

	Do you actually know the time of the last switched
	packet??

> {<v4 | v6> & <mpls> & <vlan>}

	Why can't we just use the same element more than
	once? I'm just concerned about having hundreds of
	IE's to document and implement because of slight 
	variations.

> This looks to me as a part of the flow header extension which

	I agree, we should move it out.

> A better way to put this would be "export reason" which could

	I like that.

> * Export data packets dropped

	Are these stats that might be better
	available through a MIB? 

> counter at the collector?

	Just an encoding thing again, could be a bit or
	could be a separate IE.

> in some cases this would work fine.

	Agreed. Same is true for sent count. Might get dropped
	later.

> Total number of octets after replication for this multicast flow.

	Let me see if I understand. If we are reporting a
	Multi-cast flow (e.g. A to B,C and D) then there
	might be 2 counts in the flow 1) the original byte
	count and 2) the replication byte count.

> Don't we need a "Previous Hop AS IE"?

	Never thought of that. Why not.
> interface Index? I am wondering where this would useful.

	There can be complicated rules for determining the
	VLAN (e.g. in on this port with this IP is VLAN 5
	and the default is 10. This is the end result.

> Is there a plan to distinguish between .1p and .1q?
	Not sure what you mean. .1p is the priority info
	and .1q is the VLAN ID. Each can get reported.