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

["Jan Novak (janovak)" <janovak at cisco.com>]

Hi,

 

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

 

You refer to draft-ietf-ipfix-architecture-12.txt section 5.1.1., good!
However, why not revert the definition?

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: bmwg-bounces at ietf.org [mailto:bmwg-bounces at ietf.org] On Behalf Of Benoit Claise (bclaise)
Sent: 29 July 2008 16:20
To: bmwg at ietf.org
Subject: [bmwg] Some feedback on draft-novak-bmwg-ipflow-meth-00.txt

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
bmwg at ietf.org
https://www.ietf.org/mailman/listinfo/bmwg