Subject: [bmwg] Some feedback on draft-novak-bmwg-ipflow-meth-00.txt

From: Benoit Claise <[email-masked]>
Date: Tue, 29 Jul 2008 16:19:41 +0100

Hi Jan,

Here are a few comments on your draft.

- In the active and inactive timeout, I would express in terms of flow 
expiration.
You refer to draft-ietf-ipfix-architecture-12.txt section 5.1.1., good! 
However, why not revert the definition?
For inactive timeout, something such as:

    if no packet of the flow has been seen for the inactive timeout,
    then the flow is expired.

- While you speak about:

  The network operator concern is always twofold:
      a. what will be CPU usage
      b. what will be the forwarding performance

I would add:
      c. bandwidth

- As I mentioned during the PMOL meeting, maybe we want to give a warning about generated traffic: 
if we use increasing IP addresses, then we might have more hash collisions than in real live cases
The next point is: do we want to have a metric for the hash collisions?

- Sometimes, I'm confused by too many new acronyms. Maybe it's just me...
"the BPU of the CPU does contain the FMPU on the UT" seems like 
we're talking an expert cryptic language  ;-) 
Now, I understand that the UT is a common term in BMWG

Regards, Benoit.

_______________________________________________
bmwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bmwg

---

From: "Jan Novak (janovak)" <[email-masked]>
Date: Tue, 29 Jul 2008 17:30:36 +0200

Hi,
 
Thanks for the comments - will update it in the draft.

Yes, thanks - had troubles to express myself clearly but could not find
some definitions
at the time in the IPFIX draft - quite happy to use it - it isn't easy
to define that ...
 
I would add:
      c. bandwidth

Yes, have that already on my list :-) from elsewhere.
 
- As I mentioned during the PMOL meeting, maybe we want to give a
warning about generated traffic: 
if we use increasing IP addresses, then we might have more hash
collisions than in real live cases
The next point is: do we want to have a metric for the hash collisions?

I thought about this - is hashing of the flows into shorter keys for
storing/lookups in the cache common
for all the Flow Monitoring implementation or is it cisco specific ??
 
- Sometimes, I'm confused by too many new acronyms. Maybe it's just
me...
"the BPU of the CPU does contain the FMPU on the UT" seems like 

Well, yes it is quite awkward actually - will browse the draft for
occurences of those ...
 
Jan

The climate of Edinburgh is such that the weak
succumb young .... and the strong envy them.

                                 Dr. Johnson 

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Benoit Claise (bclaise)
	Sent: 29 July 2008 16:20
	To: [email-masked]
	Subject: [bmwg] Some feedback on
draft-novak-bmwg-ipflow-meth-00.txt

	Hi Jan,

	- In the active and inactive timeout, I would express in terms
of flow 
	expiration.
	You refer to draft-ietf-ipfix-architecture-12.txt section
5.1.1., good! 
	However, why not revert the definition?
	For inactive timeout, something such as:

		if no packet of the flow has been seen for the inactive
timeout, then the flow is expired.

	- While you speak about:

	I would add:
	      c. bandwidth
	
	- As I mentioned during the PMOL meeting, maybe we want to give
a warning about generated traffic: 
	if we use increasing IP addresses, then we might have more hash
collisions than in real live cases
	The next point is: do we want to have a metric for the hash
collisions?
	
	- Sometimes, I'm confused by too many new acronyms. Maybe it's
just me...
	"the BPU of the CPU does contain the FMPU on the UT" seems like 
	we're talking an expert cryptic language  ;-) 
	Now, I understand that the UT is a common term in BMWG
	
	Regards, Benoit.