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

[Brian Trammell <[e-mail]>]

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