Subject: [ipfix] Comments on IPFIX-architecture draft

From: "Reinaldo Penno"<[email-masked]>
Date: Thu, 23 May 2002 09:29:07 -0700

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). 

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.

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:"

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?

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).

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.

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  

Section 3 - Typo

"Each of the field which belongs to"

s/field/fields

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. 

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).

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

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"

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. 

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. 

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"

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."

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: Randy Bush <[email-masked]>
Date: Thu, 23 May 2002 11:58:04 -0700

> 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).

i don't understand more than you don't understand.  perhaps i am
confused by taking the wg's charter seriously.

    Deliverables

    Best Current Practice: IETF Recommendations for the Emergency
    Telecommunications Service using existing protocols - what can
    be done with existing protcols and what can not be done.

    Informationals: Requirements for Internet Emergency
    Preparedness in the Internet. Framework for Supporting Internet
    Emergency Preparedness in IP Telephony.

randy

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/