Subject: [IPFIX] feedback on draft-ietf-ipfix-biflow-03.txt

From: Benoit Claise <[email-masked]>
Date: Tue, 20 Mar 2007 01:04:01 +0100

Dear all,

Here is my feedback on this draft. I know I might be late regarding 
last-call (on the other hand, feedback from only two persons was 
received), but I think that some of the issues below must be fixed.

Note that some of the feedback has been given live to Brian and Elisa 
today. Anyway, for the sake of the discussion tomorrow, let's me send it 
to the list.

- it doesn't cover the fact that the "deduced" direction of long lived 
flows may changed in case of direction by initiator
- I was confused by too many capitalized terms, which seems to refer to 
definition. It turned out to be section names.
- some more introduction text should explain whether a middelbox 
produces biflows or not.
    Basically, it depends on the flow definition and which parameters 
the middlebox changes.
    For example: a middlebox that changes the DSCP=0 to DSCP=1 will only 
produce biflow if the DSCP is not a flow key
- Biflow definition
    each Non-directional Key Field ->     each Non-directional Key Field 
value
    each Directional Key Field ->     each Directional Key Field value
- We discussed this draft in the past with several proposals, and I had 
to wait for the end before knowing what the proposal is about.
    You should really include a high level figure at the beginning 
explaining what the high level solution is,
    exactly as we did for the redundancy draft, figure 2 and 3
-  "Note that, for IANA-registered Information
    Elements or those defined by the IPFIX Information Model
    [I-D.ietf-ipfix-info], Source Key Fields are represented by
    Information Elements whose names begin with "source", and Destination
    Key Fields are represented by Information Elements whose names begin
    with "destination"; it is recommended that vendor-specific
    information elements follow these conventions, as well."
    -> this should really be part of [IPFIX-INFO] in section 2.3
- "the two directions of a Biflow may be roughly thought of as the two 
Uniflow halves"
What's a uniflow halve? half a flow? guess not ;)
Bottom line, I think the halve in uniflow halve should be completely 
removed from the draft
- I don't understand the paragraph starting with:
"Note that since the IPFIX information model makes no distinction 
between zeroes and null values, ..."
You should explain some more what this implies ...
- " As the method selection is dependent on Metering Process position, it
     is sufficient to configure the direction assignment method at
    Collecting and Exporting Processes out-of-band."
First of all, the "and" is a "or" or (if you insist) "and/or"
Second, you should explain how you do that: mapping an internal/external 
per interface or ifIndex
-
"Regardless of the direction assignment method selected, the Exporting
Process MAY export additional information about each Biflow (e.g.,
TCP flags information, high-precision timestamps) in order to assist
the Collecting Process in determining the flow initiator or revising
the Metering Process' direction selection."
    My concern is that you don't specify what the Collecting Process 
should do if there is a discrepancy
-

   "Note that direction assignment by initiator is most easily done by a
   single Metering Process positioned on a local link layer, or a single
   Metering Process observing bidirectional packet flows at a symmetric
   perimeter routing point. "
  We could only multiple Metering Process if we have a Concentrator Metering Process.
  But then we don't really have a single Observation Domain (could be debated, but my view is no)
  And you clearly stated, biflows are within an Observation Domain
  Finally the next figure didn't help, as I didn't know exactly what N0 and N1 were...
- 
   No facility is provided for exporting the address set defining the
   interior of a perimeter; this set may be deduced by the Collecting
   Process observing the set of Biflow destination addresses.
	-> 
   No facility is provided for exporting the address set defining the
   interior of a perimeter; this set may be deduced by the Collecting
   Process observing the set of Biflow _source or _destination addresses.
- not sure what the figure in section 5.2 wants to point out.
- section 5.3 "Arbitrary Direction"
   "In this case, the Metering Process SHOULD be consistent in its choice
   of direction.  Arbitrary direction assignment MAY use Flow Key
   fields, for example the interface number, in order to maintain this
   consistency."
   How could we be consistent if this is an "Arbitrary Direction"
   Consistent amongst all flows? Or consistent for a (long-lived) flow?
   This makes a big difference.
- section "6.1.  Reverse Information Element Private Enterprise Number"
   "Note that certain Information Elements in the IPFIX Information Model
   [I-D.ietf-ipfix-info] are not reversible; that is, they are
   semantically meaningless as reverse Information Elements.  A
   Collecting Process MUST note the Information Element identifier of
   any Information Element so used as a Reverse Information Element, and
   MAY discard that Information Element from the Flow Record, as with
   unassigned Information Elements as in section 9 of the IPFIX Protocol
   document [I-D.ietf-ipfix-protocol]."
   First of all, I don't see what you mean by section 9 of [IPFIX-PROTO]
   Second of all, this paragraph puts the stress on the Collecting Process 
   to understand whether IE are reversible or not. I would put the stress 
   (ie the spec) on the exporter -> MUST NOT export non reversible IE, or
   meaningless IE... Otherwise, if an old collector doesn't understand that 
   IE is reversible in a specific new situation, it MAY discard the IE?
- section 6.1
   "Note that Information Elements commonly used as Flow Keys (e.g.
   header fields defined in sections 5.4 and 5.5 of the Information
   Model) are not necessarily non-reversible, as they may be used as
   value fields in certain contexts, as when associating ICMP error
   messages with the flows that caused them."
   maybe we can improve the "not necessarily non-reversible" ;)
- some inconsistencies in the capitalized terms coming from [IPFIX-PROTO],
  for example Flow/flow
- section 6.3 "biflowDirection Information Element"

   Description:   A description of the biflow direction assignment
      method used to assign source and destination to this flow.  This
      Information Element MAY be present in a Flow Data Record, or
      applied to all flows exported from an Exporting Process or
      Observation Domain using IPFIX Options.  If this Information
      Element is not present in a Flow Record or associated with a flow
      via scope, it is assumed that the configuration of the biflow
      direction assignment method is done out-of-band.  This field may
      take the following values:

   If we use UDP, how do we know if "this Information Element is 
   associated or not with a flow via a scope as we might loose the
   options record?
   I searched in your draft for UDP and SCTP. Could not find anything.
   Solution1: biflow always present (prefered IMHO)
   Solution2: SCTP (reliable) or TCP
- The previous remark leads to the Appendix A that doesn't show any 
  biflowDirection IE. That puzzled me, as this draft is specifically 
  about its specifications.
  Solution1: you give two examples, with/without
  Solution2: it's always present and you get only one example

Regards, Benoit.

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