Subject: RE: [ipfix] Comments on IPFIX-architecture draft

From: "Reinaldo Penno" <[email-masked]>
Date: Tue, 4 Jun 2002 23:30:34 -0700

-----Original Message-----
From: Ganesh Sadasivan [mailto:[email-masked]]
Sent: Tuesday, June 04, 2002 7:33 PM
To: Penno, Reinaldo [SC101:T327:EXCH]
Cc: [email-masked]; [email-masked]
Subject: Re: [ipfix] Comments on IPFIX-architecture draft

Hi Rienaldo, 
   Not really. If the definition is fairly generic (which is the case here)
it is 
   always useful to point out its coverage. That's what  thse examples are
meant 
   for. There had been a lot doubts raised on flow definition and explicitly
putting 
   examples can avoid a lot of mailing list traffic and for future readers. 
   Having said that I am ok removing them out if that is the general
consensus - 
   but not because one person asserts multiple times what he does not like
about 
   the doc. 

Reinaldo Penno wrote: 

Hello Ganesh,I disagree with your statement about the examples. If people
need examples to understnad the definition of a flow, then is because the
definition is not clear. Instead of attacking the root cause of the problem
you are putting "paches" around it which makes the drafts full of fat.

I would be very, very surprised if this architecture draft pass last call
with all the implementation specific details it has justified under the
"readability" umbrella. I've never seen an IETF architecture draft saying
how many process I should code to realize some task, what they should do,
etc, etc,

And where is all these details of "how many process I should code to realize
some task" 
in the arch. spec?  
 
In the part where you say what the meter should do, the exported should do,
and how is the internal organization of a exporter. I believe this is
implementaion specific, isn't it? 

I understand that some people get attached to their drafts but if you rip
those sessions of and read the draft again you will see that nothing is
lost, and is much more objective and charter compliant.regards,Reinaldo

This doc. is not my property it is a effort from a group of  contributors.
So what goes in 
would be what is the "rough consensus" & not a single person's opinion. 
BTW I would appreciate if you can avoid personal references.  

Ganesh, 
 
don't be so sensitive.  I meant "you" generally. Besides I wonder why you
ask me that if you said previously "but not because one person asserts
multiple times". But that's okay...
 
-Reinaldo
 
Thanks 
Ganesh 

-----Original Message----- 
From: Ganesh Sadasivan [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Tuesday, June 04, 2002 6:04 PM 
To: Penno, Reinaldo [SC101:T327:EXCH] 
Cc: [email-masked]; [email-masked] 
Subject: Re: [ipfix] Comments on IPFIX-architecture draft
Hello Reinaldo, 

Reinaldo Penno wrote: 

Here it goes my comments. Sorry if some of them were already mentioned, but
I finally found time to read through this. 

General: 

My main problem with this draft as it stands today is that it has a lot of
fat that comes from dwelling in certain areas that I do not think it
believes in an architecture document. For example, section 4.4.2 and 4.4.3
and the whole notion of match and filter functions is totally an
implementation decision that has nothing to do with the ipfix protocol we
will select or the definition of a flow (or should not have).

What is the  implementation (or design) specific details you are referring
to? 
These are just 2 broad catgories of flow collection (.i.e field dependent
and field 
independent ways). Regarding IPFIX protocol itself, it is a separate set of
sections. 
This is just another piece in the general architecture. 

The definition of a flow should stick to what is proposed in the beggining
of section 3. If I'm going to use the "mother of all rule sets", do it in a
stepwise manner (using match or filter functions), or use complex logical
constructs has nothing to do with the architecture.

These examples are used to illustrate the breadth of coverage of the
defintion 
and has been found useful to many other people others in this mailing list
to 
undrestand the flow definition. 

Other comments: 

Section 3 - Typo - Phrase is repeated twice 

"Each property is defined as the result of applying a function to the values
of. 
Each property is defined as the result of applying a function to the values
of:"

Ok. 

Section 3 - Wording 

"Each of the fields from 1., 2. 
       and 3. are referred to as flow keys." 

Not sure what are these fields you are talking about...Are them the above
mentioned list in the text?

Yes.  How does this look:  "Each of the fields from 1., 
2. and 3. mentioned above are referred to as flow keys" 

Section 3 - Wording 

"Though a flow could match a 
       general application-level end-to-end stream, its definition is 
       not restricted to this alone. The above definition covers a broad 
       range from a flow containing all packets observed on a set of 
       observation points to a flow consisting of just a single packet 
       between two applications with a specific sequence number observed 
       at a single observation point." 

I think we just remove this whole text without loss of generality or
meaning. It seems to me it is repetitive based on the fact that this is
already clear given the "flow keys" (1,2 and 3).

Yes. I had the same opinion. But again it is for the clarification for many 
who mistook the scope of the definition to be restricted to 
application-to-application. 

Section 3. - Document structure. 

Not sure about putting flow examples in a terminology section...The examples
use several terms that are only defined later in the text. I suggest move
tall the examples to a new section somewhere after the terminology.

This general feedback is that these examples improve the clarity of the 
definition. 

Section 3 - Clarification on the match/filter functions on the examples 

IMO this "match/filter" function mentioned in example 2 does not belong in a
architecture draft. This is an implementation internal decision. IMO the
only think the architecture document should say is that

Already explained above. 

Section 3 - Typo 

"Each of the field which belongs to" 

s/field/fields

Changed to "Each of the fields which belong to" 

Section 3 - Terminology 

"   * Flow Type: 
       A function F which would take input as a set of flow keys and the 
       output would be one or more flows depending on the combination of 
       values for the set of flow keys." 

A set of "common properties", which the real world instantion would be the
so-called fields already defines a flow. As mentioned in the beggining of
secion 3 

"All packets belonging to 
       a particular flow have a set of common properties" 

So, the notion of flow type seems redundant. If its purposes in life is to
justify the other text in the draft which talks about match/filter, is one
more reason to remove this definition.

I think I responded on this topic sometime back too. 
Flow Type defines a class of flows. If F(a,b) is the flow type 
applying (a1,b1); (a2,b2); (a3,b3) could result in 1, 2 or 
3 different flows depending on what F does. Where is this 
useful? This is kind of information is required by the collecting 
side if it needs to understand fully what is being done on the 
exporter side. 

Section 4 - Clarification 

In general I think dwelling in the internal of a device in a IETF
architecture document is not a good practice, but that's MHO. At least in
the "typical ipfix device" picture the functional boxes of the "selection
criteria for flow export" and "metering process" should be removed.  It is
not a process that talks to external entities (a.k.a IETF Ipfix's protocol)
and neither has anything to do with defining a flow. 

Anyway, my opinion is that we only need the first picture in section 4.
Everything else is perfectly described in the text (section 4.1 onwards).

In my opinion with the picture the explanation looks much clearer. 

Section 4.3 - Wording 

"The typical functions of 
   an Observation Domain may include:" 

and then 

"    * May perform appropriate middle-box functions to translate the 
       flow information." 

There is already a "may" on the first phrase

Ok. 

Section 4.4.1 - Typo 

" MAY need the 
   following interpreting the flow records further:" 

suggestion 

"May need the following information to interpret the flow records further"

Ok 

Section 4.4.2. - Remove 

IMO this section has no bearing in a architecture draft. It is completely an
implementation decision that not even affect the IPfix protocol per se.

explained above 

Section 4.4.3. - Remove 

IMO this section has no bearing in a architecture draft. It is completely an
implementation decision that not even affect the IPfix protocol per se.

explained above 

Section 5.2.1 - Conflicting terms 

"   As mentioned in the selection criteria, the control and data stream 
   MUST be transported over a congestion-aware transport protocol"

Ok. How about changing this to "SHOULD". 

In the selection criteria, ability to use a congestion-aware protocol is a
SHOULD. Quote follows from section 5.1: 

"   The following is the list of criteria that the candidate protocol 
   SHOULD meet in order to be the..."

Section 5.2.1 - Redundancy and possible conflict of terms 

"   The data stream MAY be exported over an reliable or unreliable 
   transport protocol."

Reliability & congestion awareness are 2 different aspects. 

Thanks 
Ganesh 

In section 5.1 congestion-aware is SHOULD, later is MUST and now (section
5.2.1) is MAY. I suggest removing this phrase. Everything related to which
protocol must be used as a transport is already discussed on the beggining
of this section. 

regards, 

Reinaldo

---

From: Ganesh Sadasivan <[email-masked]>
Date: Wed, 05 Jun 2002 18:32:43 -0700

Rienaldo,
* The text tells that it is a "typical IPFIX device"
* The diagram has blocks defined by the terminology section
   with a skeletal model of the flow collection & export path.
   I don't think this has any specific implementationd details.
Ganesh
Reinaldo Penno wrote:

>         Not really. If the definition is fairly generic (which is
>      the case here) it is
>         always useful to point out its coverage. That's what
>      thse examples are meant
>         for. There had been a lot doubts raised on flow
>      definition and explicitly putting
>         Having said that I am ok removing them out if that is the
>      general consensus -
>         but not because one person asserts multiple times what he
>      does not like about
>         the doc.
>
>      Reinaldo Penno wrote:
>
>     > Hello Ganesh,I disagree with your statement about the
>     > examples. If people need examples to understnad the
>     > definition of a flow, then is because the definition is
>     > not clear. Instead of attacking the root cause of the
>     > problem  you are putting "paches" around it which makes
>     > the drafts full of fat.
>
>     > I would be very, very surprised if this architecture draft
>     > pass last call with all the implementation specific
>     > details it has justified under the "readability" umbrella.
>     > I've never seen an IETF architecture draft saying how many
>     > process I should code to realize some task, what they
>     > should do, etc, etc,
>
>      And where is all these details of "how many process I should
>      code to realize some task"
>      in the arch. spec? In the part where you say what the meter
>      should do, the exported should do, and how is the internal
>      organization of a exporter. I believe this is implementaion
>      specific, isn't it?
>
>
>
>     >
>     >
>     > I understand that some people get attached to their drafts
>     > but if you rip those sessions of and read the draft again
>     > you will see that nothing is lost, and is much more
>     > objective and charter compliant.regards,Reinaldo
>
>      This doc. is not my property it is a effort from a group of
>      contributors. So what goes in
>      BTW I would appreciate if you can avoid personal
>      references. Ganesh, don't be so sensitive.  I meant "you"
>      generally. Besides I wonder why you ask me that if you
>      said previously "but not because one person asserts multiple
>      times". But that's okay...-Reinaldo
>
>
>
>      Thanks
>      Ganesh
>
>     >
>     >
>     >      > Here it goes my comments. Sorry if some of them
>     >      > were already mentioned, but I finally found
>     >      > time to read through this.
>     >      >
>     >      > General:
>     >      >
>     >      > My main problem with this draft as it stands
>     >      > today is that it has a lot of fat that comes
>     >      > from dwelling in certain areas that I do not
>     >      > think it believes in an architecture document.
>     >      > For example, section 4.4.2 and 4.4.3 and the
>     >      > whole notion of match and filter functions is
>     >      > totally an implementation decision that has
>     >      > nothing to do with the ipfix protocol we will
>     >      > select or the definition of a flow (or should
>     >      > not have).
>     >
>     >      What is the  implementation (or design) specific
>     >      details you are referring to?
>     >      These are just 2 broad catgories of flow
>     >      collection (.i.e field dependent and field
>     >      independent ways). Regarding IPFIX protocol
>     >      itself, it is a separate set of sections.
>     >      > The definition of a flow should stick to what
>     >      > is proposed in the beggining of section 3. If
>     >      > I'm going to use the "mother of all rule sets",
>     >      > do it in a stepwise manner (using match or
>     >      > filter functions), or use complex logical
>     >      These examples are used to illustrate the
>     >      breadth of coverage of the defintion
>     >      and has been found useful to many other people
>     >      others in this mailing list to
>     >      > "Each property is defined as the result of
>     >      > applying a function to the values of.
>     >      > Each property is defined as the result of
>     >      > applying a function to the values of:"
>     >
>     >      Ok.
>     >
>     >      >
>     >      >
>     >      > Section 3 - Wording
>     >      >
>     >      > Not sure what are these fields you are talking
>     >      > about...Are them the above mentioned list in
>     >      > the text?
>     >
>     >      > I think we just remove this whole text without
>     >      > loss of generality or meaning. It seems to me
>     >      > it is repetitive based on the fact that this is
>     >      > Not sure about putting flow examples in a
>     >      > terminology section...The examples use several
>     >      > terms that are only defined later in the text.
>     >      > I suggest move tall the examples to a new
>     >      > section somewhere after the terminology.
>     >
>     >      > IMO this "match/filter" function mentioned in
>     >      > example 2 does not belong in a architecture
>     >      > draft. This is an implementation internal
>     >      > decision. IMO the only think the architecture
>     >      > document should say is that
>     >
>     >      Already explained above.
>     >
>     >      >
>     >      >
>     >      > Section 3 - Typo
>     >      >
>     >      > A set of "common properties", which the real
>     >      > world instantion would be the so-called fields
>     >      > already defines a flow. As mentioned in the
>     >      > beggining of secion 3
>     >      >
>     >      > So, the notion of flow type seems redundant. If
>     >      > its purposes in life is to justify the other
>     >      > text in the draft which talks about
>     >      > match/filter, is one more reason to remove this
>     >      > definition.
>     >
>     >      > In general I think dwelling in the internal of
>     >      > a device in a IETF architecture document is not
>     >      > a good practice, but that's MHO. At least in
>     >      > the "typical ipfix device" picture the
>     >      > functional boxes of the "selection criteria for
>     >      > flow export" and "metering process" should be
>     >      > removed.  It is not a process that talks to
>     >      > external entities (a.k.a IETF Ipfix's protocol)
>     >      > Anyway, my opinion is that we only need the
>     >      > first picture in section 4. Everything else is
>     >      > perfectly described in the text (section 4.1
>     >      > onwards).
>     >
>     >      > In the selection criteria, ability to use a
>     >      > congestion-aware protocol is a SHOULD. Quote
>     >      > follows from section 5.1:
>     >      >
>     >      > In section 5.1 congestion-aware is SHOULD,
>     >      > later is MUST and now (section 5.2.1) is MAY. I
>     >      > suggest removing this phrase. Everything
>     >      > related to which protocol must be used as a
>     >      > transport is already discussed on the beggining
>     >      > of this section.
>     >      >
>     >      > regards,
>     >      >
>     >      > Reinaldo
>     >      >
>     >      >
>     >      >
>     >      >
>     >