Re: [bmwg] WGLC: draft-ietf-bmwg-ipflow-meth-00 - New Version draft-ietf-bmwg-ipflow-meth-02.txt

["Jan Novak (janovak)" <[e-mail]>]

Hi,

Ok, thanks Brian for looking at it - will do.

Jan

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



-----Original Message-----
From: Brian Trammell [mailto:[e-mail]] 
Sent: 22 June 2011 10:11
To: Jan Novak (janovak)
Cc: Paul Aitken (paitken); Al Morton; [e-mail]
Subject: Re: [bmwg] WGLC: draft-ietf-bmwg-ipflow-meth-00 - New Version
draft-ietf-bmwg-ipflow-meth-02.txt

Hi, Jan,

I've reviewed the -01 and -02 diff and agree that the document is
greatly improved; this revision, after addressing Paul's comments,
should be ready to go.

I have two points of discussion/clarifiction, inline, below.

Best regards,

Brian

> 2) Export of options and templates
> 
>> Also, I didn't yet read anything about allowing for export templates
>> and/or options. Should these be included or excluded from the 
>> measurements?
> 
> I would like to strongly disagree here. We had extensive discussions 
> about it already with one of the previous reviewers and I always
> pointed to the definition of Control Information by RFC5470
> (and I think also other IPFIX documents) section 2 which in
> my opinion covers for the export of options and templates but I never
> got
> any answer regarding that - neither from you yet.
> The reviewed document has explicit statements about export of this
> information
> in several places unless my understanding of the RFC5470 definition is
> wrong.
> I hope not though since I wouldn't like to dive into the definitions
of
> what those are in IPFIX. I hope you can comfirm that.

The issue here is that template and option export should (in the normal
case) be negligible in terms of export bandwidth (i.e., data records
should  far, far outnumber options records and templates), the
performance of exporting and/or collecting processes may be
significantly impacted by the number of _simultaneous_ templates or
options in effect on a transport session at any given time. Template
lookup should be O(log t) at worst (unless you're being incredibly
lazy), but might need to be done for every set (which implies O(n log
t)). So at the very least, there should be parameters for the number of
active templates in the session during benchmarking -- even if that
number is 1.

> 3) Packet Sampling 
> 
>> PJ: I'd like to see a greater discussion of the relevance of
sampling, 
>> throughout this document. I've already indicated a few places where
> sampling 
>> would impact the test.
> 
> Packet sampling is out of the scope of this document. If you prefer I
> will
> replace section 4.5 of the reviewed document with an explicit
statement
> saying just that instead. It is a separate I would say research
subject
> which can be undertaken by a future work/document.

Packet/flow sampling, however, is one of the approaches often used in
production networks when flow collection performance is insufficient...
so at the very least there should be a strong statement that this
document applies to situations without packet or flow sampling. 

> 
> -----Original Message-----
> From: Paul Aitken (paitken) 
> Sent: 20 June 2011 10:18
> To: Jan Novak (janovak); Al Morton
> Cc: [e-mail]
> Subject: Re: WGLC: draft-ietf-bmwg-ipflow-meth-00
> 
> Jan,
> 
> In reviewing this draft, I objected to numerous places where you 
> discussed the cache as holding Flow Records.
> 
> eg, "the cache doesn't hold flow records, because the cache is a 
> function of the metering process while flow records are a product of
the
> 
> exporting process."
> 
> While RFC 5101 (IPFIX) doesn't specifically mention caches, it does
say:
> 
>       The Metering Process generates Flow Records.
> 
> 
> And
> 
>       The Metering Process consists of a set of functions that
includes
>       packet header capturing, timestamping, sampling, classifying,
and
>       maintaining Flow Records.
> 
> 
> "maintaining Flow Records" could be interpreted as cache maintenance.
> 
> So I'll relax my objection because this isn't clearly defined in
IPFIX.
> 
> Thanks,
> P.
> 
> 
> On 13/06/11 14:02, Paul Aitken wrote:
>> Al, Jan,
>> 
>> I've attached a version of draft-ietf-bmwg-ipflow-meth-01 with 
>> numerous comments inline (look for "PJ:").
>> 
>> I've made numerous small changes directly to the text. Hopefully you 
>> can see those with in the change history (see "track changes").
>> 
>> I anticipate an updated document and a further WGLC.
>> 
>> Cheers,
>> P.
> 
> <bmwg-PJ-review-1.txt>_______________________________________________
> bmwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bmwg