Subject: Re: [IPFIX] WG Last Call for draft-ietf-ipfix-information-model-rfc5102bis-05.txt

From: Paul Aitken <[email-masked]>
Date: Thu, 01 Nov 2012 17:16:55 +0000

Brian,

>>> What verb does the MP apply to a unit of information when it gives it to the EP?
>>>
>>> A delta counter counts only observations made since the last Flow Record for a given Flow was measured.
>>>
>>> Or maybe we can sidestep the action completely:
>>>
>>> A delta counter counts only observations made since the previous Flow Record for a given Flow.
>> No, that's still involving export.
>>
>> What should the MP do if the flow ends *but isn't exported* ?
> In the idealized architecture, the MP can't know, so it just keeps exporting, clearly.

NB the MP doesn't export. As you say, I don't think we have any verb for 
the MP -> EP handoff.

> If your implementation allows loss between the MP and the EP, there is nothing conceptually different between this situation and loss between the EP and the CP, except you can't use wireshark to debug it. :)

The MP has no knowledge of what happens to the data it produces, so the 
infomodel definitions simply can't be expressed in export terms.

eg, suppose traffic from a first level cache is aggregated into a second 
level cache. Although traffic isn't "exported" per se, we want the delta 
counters to begin from zero next time around.
(Even if this isn't strict IPFIX, the caches are using the IPFIX 
infomodel, and 5102bis recognises this as valid: "the model is defined 
in an open way that easily allows using it in other protocols, 
interfaces, and applications.")

The point is that the definitions have to work for other potential uses 
of the infomodel.

>> Just the same as when the flow *is* exported. So the definition of deltaCount is independent of export, flow records, etc.
>>
>> So the definitions have to be about the metering time, and particularly that we've started metering again. However, we can't write that, because some implementations may not hold state that tells them this. So all we know is that totalCounters meter from the start of the MP, while delta counters meter a potentially shorter interval, reporting the value metered since the start of that interval.
> I've stared at this for a while and I can't come up with a way to express it that's unconvoluted enough for my taste. I still don't see why my last attempt at a definition above necessarily invokes export -- it's the MP sending on the information in a proto-Flow Record to the EP and deciding to start the counters over. So I suppose for the corner case that the MP sends something up to the EP and the EP drops it we could complicate the language a bit:
>
> A delta counter counts only observations made since the previous Flow Record for a given Flow, as seen from the point of view of the Metering Process (i.e., discounting any failure or refusal to export the Flow Record on the part of the Exporting Process or failure to receive the Flow Record on the part of the Collecting Process).
>
> although truth be told I think this overly complicated and unreadable for the magnitude of the corner case it addresses. Maybe without the i.e. phrase?

Agreed; this is just too cumbersome.

So since MPs generate Flow Records, your earlier definition seems to be 
best, except that there may not have been any previous Flow Record.

So, how about "A delta counter only counts observations made since the 
previous Flow Record (if any) for a given Flow."

P.

---

From: Brian Trammell <[email-masked]>
Date: Thu, 1 Nov 2012 22:42:28 -0500

Hi, Paul,

On 1 Nov 2012, at 12:16, Paul Aitken <[email-masked]> wrote:

> The MP has no knowledge of what happens to the data it produces, so the infomodel definitions simply can't be expressed in export terms.
> 
> eg, suppose traffic from a first level cache is aggregated into a second level cache. Although traffic isn't "exported" per se, we want the delta counters to begin from zero next time around.
> (Even if this isn't strict IPFIX, the caches are using the IPFIX infomodel, and 5102bis recognises this as valid: "the model is defined in an open way that easily allows using it in other protocols, interfaces, and applications.")
> 
> The point is that the definitions have to work for other potential uses of the infomodel.

Good point. Which means any definition should be even more removed from the cache.

> So since MPs generate Flow Records, your earlier definition seems to be best, except that there may not have been any previous Flow Record.
> 
> So, how about "A delta counter only counts observations made since the previous Flow Record (if any) for a given Flow."\

This works for me.

Cheers,

Brian

---

From: Gerhard Muenz <[email-masked]>
Date: Mon, 05 Nov 2012 20:58:10 +0100

Hi Paul, Brian,

>> So, how about "A delta counter only counts observations made since the previous Flow Record (if any) for a given Flow."

This statement seems sufficiently clear and sufficiently flexible.
For example, as I understand it, it does not imply that all observations 
since the previous Flow Record must be counted. Some observations might 
get lost or omitted on purpose. Also, at some time, the next interval 
will end, so the following observations are not counted. Also, it does 
not imply that the Flow Record is actually exported.

Regards,
Gerhard

---

From: Benoit Claise <[email-masked]>
Date: Thu, 08 Nov 2012 10:49:15 -0500

Paul, Brian
>
>>>
>>>> 1.1. Changes since RFC 5102
>>>>
>>>>     This document obsoletes the Proposed Standard revision of the 
>>>> IPFIX
>>>>     Protocol Specification [RFC5102].  The following changes have been
>>>>     made to this document with respect to the previous document:
>>>>
>>>>        - All outstanding technical and editorial errata filed on the
>>>>     [RFC5102] as of publication time have been corrected
>>>>        - All references into [RFC5101] have been updated to 
>>>> [RFC5101bis],
>>>>     reflecting changes in that document as necessary
>>>>        - Information element definitions have been removed, as the
>>>>     reference for these is now [IPFIX-IANA]; categorizations of
>>>>     information elements as defines in [RFC5102] have been retained in
>>>>     section 5.
>>>>        - The process for modifying [IPFIX-IANA] has been improved, 
>>>> and is
>>>>     now described in [IPFIX-IE-DOCTORS]; Section 6 has been updated
>>>>     accordingly, and a new section 7.3 gives IANA considerations 
>>>> for this
>>>>     process.
>>>>        - Definitions of timestamp data types have been clarified
>>>>        - Appendices A and B have been removed
>>> BTW, the indentation of that section makes it difficult to read. Can 
>>> you get all the text - including the wrapped lines - to the right of 
>>> the bullets?
>> I'm not an nroff hacker. Any pointers?
>
> Personally, I had to hack rfc2xml to make it do what I wanted.
>
>
>> It's also not clear that this section should survive IESG processing 
>> / RFC editor processing.
>
> Since this doc obsoletes 5102, I find it useful to get a high level 
> overview of what was changed, and for that overview to be given early 
> in the document.

We should keep this section. This is much appreciated during the IESG 
review, and for historical reasons.

Regards, Benoit

---

From: Benoit Claise <[email-masked]>
Date: Thu, 08 Nov 2012 10:56:30 -0500

On 31/10/2012 10:58, Brian Trammell wrote:
> Hi, Paul,
>
> On 31 Oct 2012, at 15:55 , Paul Aitken wrote:
>
>> How about:
>>>
>>> A delta counter counts only observations made since the last export of a Flow Record for a given Flow.
>> That's back to my point that the observation might not be exported.
>>
>> More to the point, delta/total counting is a function of the MP. Whether the MP hands data to the EP, and what the EP does or does not do with that data, should have no bearing on how the MP meters subsequent data. So the definition should be purely in MP terms ("last export" being an EP term).
I've been using "expire"

Regards, Benoit (as a contributor)
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix
>
>

---

From: Benoit Claise <[email-masked]>
Date: Thu, 08 Nov 2012 10:58:43 -0500

On 5/11/2012 14:58, Gerhard Muenz wrote:
>
> Hi Paul, Brian,
>
>>> So, how about "A delta counter only counts observations made since 
>>> the previous Flow Record (if any) for a given Flow."
>
That works for me

> For example, as I understand it, it does not imply that all 
> observations since the previous Flow Record must be counted. Some 
> observations might get lost or omitted on purpose. Also, at some time, 
> the next interval will end, so the following observations are not 
> counted. Also, it does not imply that the Flow Record is actually 
> exported.
>
> Regards,
> Gerhard
>
>
>
>
>

---

From: Paul Aitken <[email-masked]>
Date: Thu, 08 Nov 2012 16:29:53 +0000

Benoit,

>> What verb does the MP apply to a unit of information when it gives it 

This sees to imply a certain architecture (ie a cache), which isn't 
mentioned in 5101.

eg, a PSAMP MP might not have a cache, so there wouldn't be anything for 
the MP to expire.

Also with a permanent cache, entries aren't expired - although they're 
exported, they also remain in the cache.

So "expire" works in some cases, though not all.

P.