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

From: Ganesh Sadasivan <[email-masked]>
Date: Tue, 04 Jun 2002 18:03:40 -0700

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: "Reinaldo Penno" <[email-masked]>
Date: Mon, 10 Jun 2002 11:19:31 -0700

well,

there also tons other of RFCs that are objective and clean. Not to mention
that I haven't seen many RFCs with pseudo code. Pseudo code (or actually
code) is typical of ITU-T.

Anyway, consensus & last call will decide.

-Reinaldo

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: Monday, June 10, 2002 7:22 AM
>To: Ganesh Sadasivan
>Cc: Penno, Reinaldo [SC101:T327:EXCH]; [email-masked];
>[email-masked]
>Subject: Re: [ipfix] Comments on IPFIX-architecture draft
>
>
>
>I for one think examples lend to clarity in a way that pure
>textual description cannot. See RFC 3031, the MPLS architecture
>document as one RFC that does this. Also look at RFC 826
>the ARP protocol. They give pseudocode in their description.
>
>My 2 cents,
>
>Paul
>