Subject: [IPFIX] IPFIX-based file format: feedback

From: Benoit Claise <[email-masked]>
Date: Mon, 10 Mar 2008 23:13:27 -0400

Brian, Elisa, Lutz, Tanja, Arno,

The draft improved a lot compared to last version.
I have some feedback anyway.

A couple of points to be discussed:
- during the last IETF meeting, I mentioned that it would be nice to 
have a delimiter, in order to get some diagnostics information. Note: my 
(biased) view is the one from a router vendor, so I'm thinking about 
router diagnostics. You mention "IPFIX files contain only IPFIX 
messages". I would like to remove that restriction.
You inserted the opaqueOctets. This is nice, but heavy compared to a 
file delimiter
- I would like to have a few words about writing into a file directly 
from a router, for example in section 6.4
- I think that you would benefit from the per-SCTP stream, as the order 
is From [email-masked]  Mon Mar 10 20:15:56 2008
Date: Mon, 10 Mar 2008 23:13:27 -0400
From: Benoit Claise <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [IPFIX] IPFIX-based file format: feedback
Sender: [email-masked]

This is a multi-part message in MIME format.

Brian, Elisa, Lutz, Tanja, Arno,

The draft improved a lot compared to last version.
I have some feedback anyway.

A couple of points to be discussed:
- during the last IETF meeting, I mentioned that it would be nice to 
have a delimiter, in order to get some diagnostics information. Note: my 
(biased) view is the one from a router vendor, so I'm thinking about 
router diagnostics. You mention "IPFIX files contain only IPFIX 
messages". I would like to remove that restriction.
You inserted the opaqueOctets. This is nice, but heavy compared to a 
file delimiter
- I would like to have a few words about writing into a file directly 
from a router, for example in section 6.4
- I think that you would benefit from the per-SCTP stream, as the order 
is maintained. It might be worth stressing that, if the per-SCTP stream 
is implemented, we would not have the timing issue related to data 
records sent to multiple SCTP stream.
- While I understand that you would like to have the Template(s) at the 
beginning of the file, it will require huge buffers on a router... 
unless the per-SCTP stream is supported. That's another advantage of 
that draft.
- how do we treat SCTP assocation and TCP connection reset? the file 
must be ended?
- informationElementAnonymized was in the previous version, but not 
anymore in this draft. I see "The data described by this Template 
contains anonymized source and destination IPv4 addresses.". How is it 
possible without this I.E.? Btw, we should have an anomized I.E., 
similar to the key IE.
- messageScope, sessionScope, etc...: instead of multiplying the 
information elements "...Scope", for which the content is ignored, why 
not have a "scope" IE with some values in there. Like in RFC3954:

 Scope 1 Field Type
         The relevant portion of the Exporter/NetFlow process to which
         the Options Template Record refers.
         Currently defined values are:
            1 System
            2 Interface
            3 Line Card
            4 Cache
            5 Template

- 7.1.2 and 7.1.3. Why minFlowStartSeconds, maxFlowStartSeconds, 
minExportSeconds, maxExportSeconds? Why not any of the time related 
I.E.? Not to duplicate the I.Es?

Some editorial feedback
- IPFIX file reader and writer: instead of "analogous to", what about a 
"special case of"
- section 3, why do you repeat the definition of the IPFIX file... just 
after the section 2 "terminology" btw
- a couple of terms from RFC5101 are not capitalized. For example, "flow"
- you mentioned a few times "flow data". Why not Flow Record? unless you 
want to be generic?
- section 5.1 is "record format flexibility" and you speak about 
"extensibility"
- I don't understand what you mean in
      "The IPFIX Message format has no direct support for indexing.
However, its template mechanism and the technique described in
"Reducing Redundancy in IPFIX and PSAMP Reports"
[I-D.ietf-ipfix-reducing-redundancy 
<http://tools.ietf.org/html/draft-ietf-ipfix-file-01#ref-I-D.ietf-ipfix-reducing-redundancy>] 
can be used to describe the
contents of a file in a limited way."
- acronyms RAID, CBC
- As testing is certainly not the primary use, I would order the section 
6.x in this order
     6.1 storage of ipfix-collected flow data
     6.2 testing IPFIX collecting process
- I'm not sure 6.3 "storage of NetFlow version 9-collected flow data" is 
an applicability of this draft.
- in Section 6.2, you have "MAY". This is a specification while this is 
the applicability section.
- IPFIX Transport -> IPFIX transport
- message -> IPFIX Message (a few instances)
- "options record" is not a valid term according to RFC5101
- that would be good to explicitely show that the IPFIX header is 
included. For example, in figure 1

Regards, Benoit.

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

---

From: Paul Aitken <[email-masked]>
Date: Tue, 11 Mar 2008 10:18:35 +0000

Benoit, Brian, Elisa, Lutz, Tanja, Arno,

>          Currently defined values are:

By all means have a scope IE - but please don't begin to define a new 
value registry for it.

Instead, allow it to be populated with any existing IE, extending the 
existing IE list if necessary.

The RFC3954 registry above is comparable to existing IPFIX IEs:

     1 System       #149 observationDomainId
     2 Interface    #10  ingressInterface, #14 egressInterface
     3 Line Card    #141 lineCardId
     4 Cache
     5 Template     #145 templateId

Cheers.
-- 
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.
_______________________________________________
IPFIX mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipfix

cii"
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Errors-To: [email-masked]

Benoit, Brian, Elisa, Lutz, Tanja, Arno,

>          Currently defined values are:

By all means have a scope IE - but please don't begin to define a new 
value registry for it.

Instead, allow it to be populated with any existing IE, extending the 
existing IE list if necessary.

The RFC3954 registry above is comparable to existing IPFIX IEs:

     1 System       #149 observationDomainId
     2 Interface    #10  ingressInterface, #14 egressInterface
     3 Line Card    #141 lineCardId
     4 Cache
     5 Template     #145 templateId

Cheers.
-- 
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.
_______________________________________________
IPFIX mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipfix

---

From: Andrew Johnson <[email-masked]>
Date: Wed, 12 Mar 2008 12:57:07 +0000

Hi Benoit et al.

On Mon, 2008-03-10 at 23:13 -0400, Benoit Claise wrote:
[SNIP]
>          Currently defined values are:

A series of IEs that are only useful for defining the scope may seem
undesirable but I think the principle could be very useful.

We already have Template ID and Line Card IDs that can be used more
explicitly for scoping options.  Perhaps defining streamID, messageID
and sessionID would be more palatable, with the special case of using
them with a length of zero means *this* message or *this* session.

The messageID could reference the message sequence number sent for each
message.  The sessionID is trickier, but it is possible to have the
Exporting Process choose the ID and communicate it to the Collector.

Cheers

Andrew

---

From: Andrew Johnson <[email-masked]>
Date: Wed, 12 Mar 2008 12:57:07 +0000

Hi Benoit et al.

Cheers

Andrew

---

From: Brian Trammell <[email-masked]>
Date: Wed, 12 Mar 2008 15:16:18 -0400

Andrew, Paul, Benoit, all,

Thanks for the comments; I'll respond in more detail to the rest of  
them in another thread, but I did want to get into this issue  
specifically...

Basically, what Andrew said. Details inline.

On Mar 12, 2008, at 8:57 AM, Andrew Johnson wrote:

>> not have a "scope" IE with some valueFrom [email-masked]  Wed Mar 12 12:19:12 2008
From: Brian Trammell <[email-masked]>
To: Andrew Johnson <[email-masked]>
Date: Wed, 12 Mar 2008 15:16:18 -0400
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [IPFIX] IPFIX-based file format: feedback
Sender: [email-masked]

Andrew, Paul, Benoit, all,

Thanks for the comments; I'll respond in more detail to the rest of  
them in another thread, but I did want to get into this issue  
specifically...

Basically, what Andrew said. Details inline.

> them with a length of zero means *this* message or *this* session.

Yes, indeed. The whole meaning of messageScope is to scope things to  
_this_ message, and the ability to scope to other messages by  
messageID would make the proposed mechanism more powerful. However,
there are a few problems/unresolved issues here:

1. Multiple messages in the same session can have the same sequence  
number (non-data records don't increment sequence, so template-only  
messages or withdrawals will repeat sequence numbers)

2. Sequence number wraparound will occur; how to handle this?

3. Would sequence numbers have to match, or would addressing any  
record with a messageID refer to the message containing that record?  
If not, how to handle the error?

4. Would CPs be _required_ to handle Message ID correctly? If so, that  
has serious resource implications...

These (well, these and laziness) are the reasons that messageScope was  
designed to refer only to the current message.

> Exporting Process choose the ID and communicate it to the Collector.

Session ID, i.e., allowing information in one transport session to be  
scoped to another, violates the assumption in 5101 that the transport  
session is the root scope, and scoped information and templates in one  
session are independent from those in any other. Referring to sessions  
other than *this* session is impossible, because in IPFIX, other  
sessions _do not exist_.

So, while we certainly could recommend that these IEs be sent with  
reduced-length encoding (we're not in the text or examples now, I  
don't think) I don't think that expanding the meaning for cross- 
message or cross-session references is something that should we should  
do _at this point_.

Cheers,

Brian

> them with a length of zero means *this* message or *this* session.

Yes, indeed. The whole meaning of messageScope is to scope things to  
_this_ message, and the ability to scope to other messages by  
messageID would make the proposed mechanism more powerful. However,
there are a few problems/unresolved issues here:

1. Multiple messages in the same session can have the same sequence  
number (non-data records don't increment sequence, so template-only  
messages or withdrawals will repeat sequence numbers)

2. Sequence number wraparound will occur; how to handle this?

3. Would sequence numbers have to match, or would addressing any  
record with a messageID refer to the message containing that record?  
If not, how to handle the error?

4. Would CPs be _required_ to handle Message ID correctly? If so, that  
has serious resource implications...

These (well, these and laziness) are the reasons that messageScope was  
designed to refer only to the current message.

> Exporting Process choose the ID and communicate it to the Collector.

Session ID, i.e., allowing information in one transport session to be  
scoped to another, violates the assumption in 5101 that the transport  
session is the root scope, and scoped information and templates in one  
session are independent from those in any other. Referring to sessions  
other than *this* session is impossible, because in IPFIX, other  
sessions _do not exist_.

So, while we certainly could recommend that these IEs be sent with  
reduced-length encoding (we're not in the text or examples now, I  
don't think) I don't think that expanding the meaning for cross- 
message or cross-session references is something that should we should  
do _at this point_.

Cheers,

Brian

---

From: Brian Trammell <[email-masked]>
Date: Thu, 13 Mar 2008 15:06:08 -0400

On Mar 12, 2008, at 8:10 PM, Andrew Johnson wrote:

>
> On Wed, 2008-03-12 at 15:16 -0400, Brian Trammell wrote:
>>> On Mon, 2008-03-10 at From [email-masked]  Thu Mar 13 12:09:34 2008
Date: Thu, 13 Mar 2008 15:06:08 -0400

On Mar 12, 2008, at 8:10 PM, Andrew Johnson wrote:

>
> On Wed, 2008-03-12 at 15:16 -0400, Brian Trammell wrote:
> This is a very good point.   Perhaps the answer is as simple as it  
> will
> apply to all these messages.  This could be good or bad depending on
> what you're trying to say.

For the current application of messageScope, the MD5 checksum, this is  
very, very bad. Messages must be uniquely identified in order to  
checksum them.

> I would say that the messageID would be a forward reference to either
> this message or a future one.  In general options are scoped to future
> info rather than past stuff.  That said, it would seem hard to  
> predict a
> future sequence number, or at the very least the exporter could delay
> the sending of the option until the message it is needed in.

Again for checksums, it's much better to have the reference go _back_  
in time. So there are a couple of use cases here, and they conflict.

> That said, what about the case where the scoped data fills a packet
> completely, perhaps because of a really big packet section field.  We
> might want to send the option in one packet referencing the next.

_That_'s a good example, but the right way to do that right now, I  
think, would be to use an existing identifier; flowID or the  
universally useful commonPropertiesID.

> I would say we want an exact match.  If the sequence passes without an
> exact match then the CP can discard the info and log an error.
>
>
> I'm not so sure.  If we consider that the info is only valid for one
> message in the near future then really the CP will only have to hold  
> on
> for a couple at a time.
>
> One other minor issue is that each stream has independent sequence
> numbers so you could have the same messageID in multiple streams.   
> This
> can be fixed by scoping the messageID to the stream or insisting that
> the streamID is sent as scope too.

You'd have to do the latter (streams are not universal, and  
restricting message ID scope to stream might break stream selection  
approaches other than per-stream).

>> designed to refer only to the current message.

I'll reply to myself here to sum up. This is a very interesting  
discussion, but it's getting bigger, and bigger, and further and  
further from the context in which it originated. I don't think we want  
to define direct inter-message and inter-session metadata references  
-- which look to be a whole lot of work and potentially quite  
restrictive if not done very, very right -- in the file draft.

I'll propose the following: the messageMD5Checksum IE could be  
redefined such that it contains the MD5 checksum for the containing  
message regardless of how it's scoped; this would obviate the need for  
the messageScope IE entirely within the file draft.

(I'm not yet sure how to do the same for sessionScope. The "right"  
thing to do here would be to allow scope-length zero -- such that the  
only scope is the implicit root, observation domain and transport  
session -- but we made that illegal in 5101.)

> Does RLE allow you to reduce them to 0 bytes?

Per 5101 section 6.2 para 4, zero is not explicitly forbidden, but  
there is an example stating the minimum size for unsigned64 is 1.  
However, octet is not a data type for which RLE (actually, RSE,  
reduced-size encoding) is allowed. So no, this won't work, anyway...

Cheers,

Brian

23:13 -0400, Benoit Claise wrote:
> This is a very good point.   Perhaps the answer is as simple as it  
> will
> apply to all these messages.  This could be good or bad depending on
> what you're trying to say.

For the current application of messageScope, the MD5 checksum, this is  
very, very bad. Messages must be uniquely identified in order to  
checksum them.

> I would say that the messageID would be a forward reference to either
> this message or a future one.  In general options are scoped to future
> info rather than past stuff.  That said, it would seem hard to  
> predict a
> future sequence number, or at the very least the exporter could delay
> the sending of the option until the message it is needed in.

Again for checksums, it's much better to have the reference go _back_  
in time. So there are a couple of use cases here, and they conflict.

> That said, what about the case where the scoped data fills a packet
> completely, perhaps because of a really big packet section field.  We
> might want to send the option in one packet referencing the next.

_That_'s a good example, but the right way to do that right now, I  
think, would be to use an existing identifier; flowID or the  
universally useful commonPropertiesID.

> I would say we want an exact match.  If the sequence passes without an
> exact match then the CP can discard the info and log an error.
>
>
> I'm not so sure.  If we consider that the info is only valid for one
> message in the near future then really the CP will only have to hold  
> on
> for a couple at a time.
>
> One other minor issue is that each stream has independent sequence
> numbers so you could have the same messageID in multiple streams.   
> This
> can be fixed by scoping the messageID to the stream or insisting that
> the streamID is sent as scope too.

You'd have to do the latter (streams are not universal, and  
restricting message ID scope to stream might break stream selection  
approaches other than per-stream).

>> designed to refer only to the current message.

I'll reply to myself here to sum up. This is a very interesting  
discussion, but it's getting bigger, and bigger, and further and  
further from the context in which it originated. I don't think we want  
to define direct inter-message and inter-session metadata references  
-- which look to be a whole lot of work and potentially quite  
restrictive if not done very, very right -- in the file draft.

I'll propose the following: the messageMD5Checksum IE could be  
redefined such that it contains the MD5 checksum for the containing  
message regardless of how it's scoped; this would obviate the need for  
the messageScope IE entirely within the file draft.

(I'm not yet sure how to do the same for sessionScope. The "right"  
thing to do here would be to allow scope-length zero -- such that the  
only scope is the implicit root, observation domain and transport  
session -- but we made that illegal in 5101.)

> Does RLE allow you to reduce them to 0 bytes?

Per 5101 section 6.2 para 4, zero is not explicitly forbidden, but  
there is an example stating the minimum size for unsigned64 is 1.  
However, octet is not a data type for which RLE (actually, RSE,  
reduced-size encoding) is allowed. So no, this won't work, anyway...

Cheers,

Brian

---

From: Brian Trammell <[email-masked]>
Date: Sat, 15 Mar 2008 11:51:53 -0400

Benoit,

Thanks for the comments! Replies and, where appropriate, a summary of  
our 8am Friday meeting, inline.

On Mar 10, 2008, at 11:13 PM, Benoit Claise wrote:

> - during the last IETF meeting, I mentioned that it wouldFrom [email-masked]  Sat Mar 15 08:55:56 2008
From: Brian Trammell <[email-masked]>
To: Benoit Claise <[email-masked]>
Date: Sat, 15 Mar 2008 11:51:53 -0400
Cc: Arno Wagner <[email-masked]>, [email-masked],
	Lutz Mark <[email-masked]>,
	Elisa Boschi <[email-masked]>
Subject: Re: [IPFIX] IPFIX-based file format: feedback
Sender: [email-masked]

Benoit,

Thanks for the comments! Replies and, where appropriate, a summary of  
our 8am Friday meeting, inline.

On Mar 10, 2008, at 11:13 PM, Benoit Claise wrote:

> have a delimiter, in order to get some diagnostics information.  
> Note: my (biased) view is the one from a router vendor, so I'm  
> thinking about router diagnostics. You mention "IPFIX files contain  
> only IPFIX messages". I would like to remove that restriction.

There are two problems to address here, and since addressing them  
separately will not cause any interoperability problems, I think we  
should make an attempt to address both:

1. Embedding non-IPFIX information in an IPFIX message stream. The  
opaqueOctets IE as described in revision -01 addresses this, with the  
inherent limitations of the IPFIX message format itself (mainly, a  
maximum opaque chunk length of 65515 bytes, or 65513 for variable- 
length encoding).

2. Embedding an IPFIX file within a non-IPFIX file. On first glance,  
this seemed out of scope (which is why we proposed the opaqueOctets  
mechanism to address your comments in Vancouver) -- any process  
wanting to write a data stream embedding an IPFIX file could define  
its own external framing. Also, the simplest way to do this (end  
delimiter only; basically, a specification that File Readers MUST stop  
reading a file and assume no error if the first four bytes of the next  
message are not a valid IPFIX Version number; per 5101, 0x000A)  
conflicts with the compression and encryption error recovery  
strategies for long-term storage.

However, the application you're trying to support here -- router  
diagnostics -- doesn't have compression or encryption error recovery  
as requirements, so there's no conflict; and opaqueOctets framing is a  
bit of a heavyweight thing to expect a router to handle during  
debugging or crash reporting.

So, as per Friday, we'll attempt to come up with 1. a delimiter  
mechanism that's a bit less brittle than the simplest one and 2.  
language handling the conflict between this use case and compressed  
archival storage for -02.

> - I would like to have a few words about writing into a file  
> directly from a router, for example in section 6.4

Section 6 needs a bit of expansion, I think; the file format now has a  
set of mechanisms to meet each of the addressed requirements; however,  
there are not specific use-case guidelines for combining these  
requirements (and the associated mechanisms) for each area of  
applicability. Router (or IPFIX device) diagnostics is one we need to  
address; perhaps we should also address the file-based workflow issue  
we mention in the frontmatter, too...

> - I think that you would benefit from the per-SCTP stream, as the  
> order is maintained. It might be worth stressing that, if the per- 
> SCTP stream is implemented, we would not have the timing issue  
> related to data records sent to multiple SCTP stream.

Since each file is its own stream, the only way to implement per- 
stream storage for files is one file per stream. We'll add the  
required language.

> - While I understand that you would like to have the Template(s) at  
> the beginning of the file, it will require huge buffers on a  
> router... unless the per-SCTP stream is supported. That's another  
> advantage of that draft.

We probably need to give up recommending a single Template management  
strategy for every use case; we should expand template management  
specifications and guidelines in parallel with the applicability.

> - how do we treat SCTP assocation and TCP connection reset? the file  

Not defined; nor am I sure it should be. There's a bit of a disconnect  
here. This draft addresses Files as first-class, as opposed to File  
Writers and Readers. We then added some language to clarify things for  
people building File Writers that happen to be pulling data directly  
from a Collecting Process; that's one use case...

However, there has been it seems a _lot_ of confusion created by this  
choice. It seems like people are _expecting_ that the _only_  
application for the format is to write collected IPFI be nice to  
> have a delimiter, in order to get some diagnostics information.  
> Note: my (biased) view is the one from a router vendor, so I'm  
> thinking about router diagnostics. You mention "IPFIX files contain  
> only IPFIX messages". I would like to remove that restriction.

There are two problems to address here, and since addressing them  
separately will not cause any interoperability problems, I think we  
should make an attempt to address both:

1. Embedding non-IPFIX information in an IPFIX message stream. The  
opaqueOctets IE as described in revision -01 addresses this, with the  
inherent limitations of the IPFIX message format itself (mainly, a  
maximum opaque chunk length of 65515 bytes, or 65513 for variable- 
length encoding).

2. Embedding an IPFIX file within a non-IPFIX file. On first glance,  
this seemed out of scope (which is why we proposed the opaqueOctets  
mechanism to address your comments in Vancouver) -- any process  
wanting to write a data stream embedding an IPFIX file could define  
its own external framing. Also, the simplest way to do this (end  
delimiter only; basically, a specification that File Readers MUST stop  
reading a file and assume no error if the first four bytes of the next  
message are not a valid IPFIX Version number; per 5101, 0x000A)  
conflicts with the compression and encryption error recovery  
strategies for long-term storage.

However, the application you're trying to support here -- router  
diagnostics -- doesn't have compression or encryption error recovery  
as requirements, so there's no conflict; and opaqueOctets framing is a  
bit of a heavyweight thing to expect a router to handle during  
debugging or crash reporting.

So, as per Friday, we'll attempt to come up with 1. a delimiter  
mechanism that's a bit less brittle than the simplest one and 2.  
language handling the conflict between this use case and compressed  
archival storage for -02.

> - I would like to have a few words about writing into a file  
> directly from a router, for example in section 6.4

Section 6 needs a bit of expansion, I think; the file format now has a  
set of mechanisms to meet each of the addressed requirements; however,  
there are not specific use-case guidelines for combining these  
requirements (and the associated mechanisms) for each area of  
applicability. Router (or IPFIX device) diagnostics is one we need to  
address; perhaps we should also address the file-based workflow issue  
we mention in the frontmatter, too...

> - I think that you would benefit from the per-SCTP stream, as the  
> order is maintained. It might be worth stressing that, if the per- 
> SCTP stream is implemented, we would not have the timing issue  
> related to data records sent to multiple SCTP stream.

Since each file is its own stream, the only way to implement per- 
stream storage for files is one file per stream. We'll add the  
required language.

> - While I understand that you would like to have the Template(s) at  
> the beginning of the file, it will require huge buffers on a  
> router... unless the per-SCTP stream is supported. That's another  
> advantage of that draft.

We probably need to give up recommending a single Template management  
strategy for every use case; we should expand template management  
specifications and guidelines in parallel with the applicability.

> - how do we treat SCTP assocation and TCP connection reset? the file  

Not defined; nor am I sure it should be. There's a bit of a disconnect  
here. This draft addresses Files as first-class, as opposed to File  
Writers and Readers. We then added some language to clarify things for  
people building File Writers that happen to be pulling data directly  
from a Collecting Process; that's one use case...

However, there has been it seems a _lot_ of confusion created by this  
choice. It seems like people are _expecting_ that the _only_  
application for the format is to write collected IPFIX data, and that  
this is the Writing Files from IPFIX Collectors draft.

Perhaps we should expand the IPFIX Collection applicability section,  
to provide more detailed specifications for this specific case.

> contains anonymized source and destination IPv4 addresses.". How is  
> it possible without this I.E.? Btw, we should have an anomized I.E.,  
> similar to the key IE.

Yep. Typo. Will fix.

> information elements "...Scope", for which the content is ignored,  
> why not have a "scope" IE with some values in there. Like in RFC3954:
>  Scope 1 Field Type
(See the other thread, but...)

Per our conversation Friday, we realized that doing things this way  
essentially uses IPFIX options to implement ever-so-slightly more  
flexible V9 options, which is not what we want. All architecture  
components can _already_ be scoped by emitting Options scoped to the  
given architecture component, explicitly identified.

Transport Sessions and Messages are _not_ yet explicitly identifiable,  
and making them so is out of scope for the file draft. It's also not  
clear that we understand all the implications of making these  
explicitly identifiable OTHER than to refer to "this message" or "this  
session".

So, while sessionScope and messageScope are perhaps not the most  
elegant or extensible way do to what they do, doing something else is  
perhaps less elegant, and I'm reasonably convinced we don't need to  
create any more than these other two. I'd recommend leaving them as  
they are.

> I.E.? Not to duplicate the I.Es?

Basically, yes; the idea is that when you're using the first two IEs  
to attach time windows to files, second resolution is sufficient, and  
there's no need to get more precise than that. This may be an overly  
restrictive assumption. The export time window information, however,  
is explicitly in seconds, because it describes the IPFIX Export Time,  
which is also in seconds.

> Some editorial feedback

We've not yet made the following changes; we'll have to review them  
before editing -02:

> - IPFIX file reader and writer: instead of "analogous to", what  
> about a "special case of"
> [I-D.ietf-ipfix-reducing-redundancy] can be used to describe the

The following are already changed in my -02 working copy:

> - in Section 6.2, you have "MAY". This is a specification while this  
> is the applicability section.
> - As testing is certainly not the primary use, I would order the  
> section 6.x in this order

Other comments:

> - section 3, why do you repeat the definition of the IPFIX file...  
> just after the section 2 "terminology" btw

As an introduction to the design overview, for people who skip  
straight to the overview to see what this document is all about.

(Also, that sentence used to be far lower in the document, where it  
seemed less repetitive. So I'll X data, and that  
this is the Writing Files from IPFIX Collectors draft.

Perhaps we should expand the IPFIX Collection applicability section,  
to provide more detailed specifications for this specific case.

> contains anonymized source and destination IPv4 addresses.". How is  
> it possible without this I.E.? Btw, we should have an anomized I.E.,  
> similar to the key IE.

Yep. Typo. Will fix.

> information elements "...Scope", for which the content is ignored,  
> why not have a "scope" IE with some values in there. Like in RFC3954:
>  Scope 1 Field Type
(See the other thread, but...)

Per our conversation Friday, we realized that doing things this way  
essentially uses IPFIX options to implement ever-so-slightly more  
flexible V9 options, which is not what we want. All architecture  
components can _already_ be scoped by emitting Options scoped to the  
given architecture component, explicitly identified.

Transport Sessions and Messages are _not_ yet explicitly identifiable,  
and making them so is out of scope for the file draft. It's also not  
clear that we understand all the implications of making these  
explicitly identifiable OTHER than to refer to "this message" or "this  
session".

So, while sessionScope and messageScope are perhaps not the most  
elegant or extensible way do to what they do, doing something else is  
perhaps less elegant, and I'm reasonably convinced we don't need to  
create any more than these other two. I'd recommend leaving them as  
they are.

> I.E.? Not to duplicate the I.Es?

Basically, yes; the idea is that when you're using the first two IEs  
to attach time windows to files, second resolution is sufficient, and  
there's no need to get more precise than that. This may be an overly  
restrictive assumption. The export time window information, however,  
is explicitly in seconds, because it describes the IPFIX Export Time,  
which is also in seconds.

> Some editorial feedback

We've not yet made the following changes; we'll have to review them  
before editing -02:

> - IPFIX file reader and writer: instead of "analogous to", what  
> about a "special case of"
> [I-D.ietf-ipfix-reducing-redundancy] can be used to describe the

The following are already changed in my -02 working copy:

> - in Section 6.2, you have "MAY". This is a specification while this  
> is the applicability section.
> - As testing is certainly not the primary use, I would order the  
> section 6.x in this order

Other comments:

> - section 3, why do you repeat the definition of the IPFIX file...  
> just after the section 2 "terminology" btw

As an introduction to the design overview, for people who skip  
straight to the overview to see what this document is all about.

(Also, that sentence used to be far lower in the document, where it  
seemed less repetitive. So I'll look into whether a change makes  
sense...)

> - a couple of terms from RFC5101 are not capitalized. For example,  

We reviewed these, as I recall, and I think we left all the lowercase  
"flows" there on purpose, as they were adjectives in generic phrases  
(i.e. flow analysis...)

> - you mentioned a few times "flow data". Why not Flow Record? unless  
> you want to be generic?

Usually, because we want to be generic. I'll review these again...

> - I'm not sure 6.3 "storage of NetFlow version 9-collected flow  
> data" is an applicability of this draft.

As we discussed in Philadelphia, will leave in.

> included. For example, in figure 1

indeed. will also add ipfix message headers where they belong in the  
example...

That should about cover it. Thanks again!

- Brian

---

From: Paul Aitken <[email-masked]>
Date: Sun, 16 Mar 2008 22:48:32 +0000

Brian,

>> order is maintained. It might be worth stressing that, if the
>> per-SCTP stream is implemented, we would not have the timing issue
> Since each file is its own stream

Why do you say that? It'd be perfectly possible to record multiple
streams into a single file, and to recreate multiple streams from a
single file.

> the only way to implement per-stream storage for files is one file
> per stream.

A single file with a stream indicator for each record would also suffice
- though that isn't absolutely necessary unless you want the replayed
data to be 100% faithful to the original.

It'd be quite straightforward to save all the streams into a single
file, and to rebuild individual streams from the file just as the
original exporter does. However, without saving an "original stream"
indicator, the new streams may not be quite the same as the originals.

---

From: Paul Aitken <[email-masked]>
Date: Sun, 16 Mar 2008 22:48:32 +0000

Brian,

---

From: Gerhard Muenz <[email-masked]>
Date: Mon, 17 Mar 2008 16:00:22 +0100

Brian, Paul, Benoit,

I have not read the current version of the draft, yet I have the
impression that things are mixed up a little bit. Maybe I can help
clarifying.

>> Since each file is its own stream

If I understood correctly, Benoit wanted to point out that the timing
issue is solved if (1) IPFIX messages are delivered in order, (2) a
Template aFrom [email-masked]  Mon Mar 17 08:03:15 2008
Date: Mon, 17 Mar 2008 16:00:22 +0100
From: Gerhard Muenz <[email-masked]>
To: Paul Aitken <[email-masked]>
Cc: [email-masked]
Subject: Re: [IPFIX] IPFIX-based file format: feedback
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

Brian, Paul, Benoit,

I have not read the current version of the draft, yet I have the
impression that things are mixed up a little bit. Maybe I can help
clarifying.

>> Since each file is its own stream

If I understood correctly, Benoit wanted to point out that the timing
issue is solved if (1) IPFIX messages are delivered in order, (2) a
Template and its associated Data Records and Withdrawal Message are sent
over the same stream, and (3) Template IDs are not reused on different
streams.

These considerations are part of per-SCTP stream draft. They ensure that
Templates arrive before Data Records, Template Withdrawal Messages
before new Templates with same ID etc.

You still can save everything in the same file if the purpose is to save
the information without ambiguities. In this case, you can even forget
the information on which streams you received the messages.

> data to be 100% faithful to the original.

Exactly. You can drop the stream information unless you want to replay
the Transport Session using the same streams as the original.

> indicator, the new streams may not be quite the same as the originals.

Is there really a need to replay Transport Sessions as the original?

If the goal is just to let a new Exporting Process export the saved
data, we can leave the decision about the stream assignment to this
Exporting Process.

Regards,
Gerhard

-- 
Dipl.-Ing. Gerhard Münz
Computer Networks and Internet
Wilhelm Schickard Institute for Computer Science
University of Tuebingen
Sand 13 (Room B309), D-72076 Tuebingen, Germany
Phone:  +49 7071 29-70534       Fax: +49 7071 29-5220
E-mail: [email-masked]
WWW:    http://net.informatik.uni-tuebingen.de/~muenz

---

From: Paul Aitken <[email-masked]>
Date: Mon, 17 Mar 2008 15:20:29 +0000

Gerhard,

I quite agree with all your points.

> Is there really a need to replay Transport Sessions as the original?

There may be a need to transparently store and replay IPFIX information.

Further, being able to specify which stream each template, option or
data record is to be sent on allows the file format to recreate and test
unusual bugs which may be difficult or impossible to create otherwise.

> data, we can leave the decision about the stream assignment to this 

Absolutely.

---

From: Paul Aitken <[email-masked]>
Date: Mon, 17 Mar 2008 15:20:29 +0000

Gerhard,

Absolutely.

---

From: Brian Trammell <[email-masked]>
Date: Mon, 17 Mar 2008 11:47:06 -0400

Gerhard, Paul,

Agreed as well.

I think what I'm reading here is that we can store multistream  
information interleaved, and provide an sctpStream IE for the Message  
Details Options Template to support replay, should it be necessary...  
yes?

- Brian

---

From: Brian Trammell <[email-masked]>
Date: Mon, 17 Mar 2008 11:47:06 -0400

Gerhard, Paul,

Agreed as well.

- Brian

---

From: Paul Aitken <[email-masked]>
Date: Mon, 17 Mar 2008 16:10:25 +0000

Brian,

> Details Options Template to support replay, should it be necessary... yes?

Pretty much. You might need to store the stream IE with every received 
record, template and option - and not allow it to be transmitted on the 
wire.

---

From: Paul Aitken <[email-masked]>
Date: Mon, 17 Mar 2008 16:10:25 +0000

Brian,