Subject: [ipfix-req] new version of requirements draft

From: Juergen Quittek <[email-masked]>
Date: Tue, 01 Oct 2002 01:37:38 +0200

Dear all,

Today I posted a new version of the IPFIX requirements I-D.
You can preview it at
ftp://ftp.ccrle.nec.de/pub/internet-drafts/draft-ietf-ipfix-reqs-06.txt

The number of discussed issues is still growing, maybe also because
the advocates and the evaluators are reading the requirements in
more detail now.

Benoit, Sebastian, Tanja and I discussed and edited a lot of
these issues and tried to identify a consensus or some solution
close to consensus. Also Sebastian did a very detailed review.

We think that discussion will get simpler, if some of the solutions
get integrated into a new version of the I-D. All modifications
we applied, are described below. If you disagree with one or more
of them, please raise the issues again.

Another reason for posting a new version is, that it is not
really easy to follow all issues and to cover every issue raised.
Thereore, I suggest that each of us raising an issue, gives the
issue an identifier, for example composed by his/her name an a
number, like Paul-13 or Tanja-02.

Then it would be great if everyone who discusses the issue,
uses the issue name in the subject field of messages concerning
the issue. Maybe we can even spend the effort of numbering
issues which are already under discussion. The best way of doing
so would be that everybody takes care of the issues raised by
herself/himself.

It would be great, if we could find consensus on all remaining
issues within a month. This would allow us to have a new version
before the Atlanta cut-off date.

    Juergen

=========================================================================
Changes from draft-ietf-ipfix-reqs-05.txt to draft-ietf-ipfix-reqs-06.txt
=========================================================================

There were 12 fixed typos and 25 minor editorial changes.
In addition, the following changes were committed:

2.1  IP Traffic Flow
  - replace numbered list by
    "1. one or more packet header field (e.g. destination IP address),
        transport header field (e.g. destination port number), or
        application header field (e.g. RTP header fields)

     2. one or more characteriscs of the packet itself (e.g.
        number of MPLS labels, etc...)

     3. one or more of fields derived from packet treatment (e.g.
        next hop IP address, the output interface, etc...)"

2.3  Metering Process, 1st line:
  - "Input to the process are IP packet headers"
    -> "Input to the process are packet headers"
  - extended second sentence by
    "and packet treatment at the observation point, for example the
     selected output interface".

4.  Distinguishing Flows, last line before 4.1:
  "the BGP Autonomous Systems.
  -> "the BGP Autonomous System number of the IP destination address.

5.3.  Overload Behavior
  replaced last paragraph by
  "Overload behavior is not restricted to the four options listed above. But
   in case the overload behavior induces a change of the metering process
   behavior, the overload behavior MUST be clearly defined.

   For some flows, the change of behavior might have an impact on the data
   that would be stored in the associated flow records after the change,
   for example if the packet classificaton is changed or the sampling
   rate. These flows MUST be considered as terminated and the associated
   flow records MUST be exported separately from new ones generated after
   the behavior change. The terminated flow records and new ones generated
   after the behavior change MUST NOT be merged by the metering process. The
   collecting process MUST be able to distinguish the affected flow records
   generated before and after the change of behavior. This requirement does
   not apply to flows and associated flow records not affected by the
   change of metering process behavior."

5.5.  Time Synchronization, entire section:
  replaced
   "Metering processes and collecting processes SHOULD be time-
    synchronized with each other. Using NTP or GPS are possible ways of
    achieving this. However selecting a method for time synchronization
    is not in the scope of this document."
  by
   "It MUST be possible to synchronize timestamps generated by a metering
    process with Coordinated Universal Time (UTC).

    Note that the possibility of synchronizing timestamps of each single
    metering process with UTC implies the possibility of synchronizing
    timestamps generated by different metering processes.

    Note that this does not necessarily imply that timestamps generated
    by the metering process are UTC timestamps. For example, this
    requirement can be met by using local system clock values as
    timestamps and adding an additional timestamp when exporting a report
    to a collecting process. Then the collecting process can synchronize
    the timestamps by calculating the offset between UTC and the system
    clock of the metering process."

5.8.  Packet Fragmentation, this section was added:
  In case of IP packet fragmentation and depending
  on the classificaiton scheme, only the zero-offset fragment of
  a single initial packet might contain sufficient information to
  classify the packet. Note that this fragment should be the first
  one generated by the router imposing the fragmentation [RFC791],
  but might not be the first one observed by the IPFIX device, due
  reordering reasons. The metering process MAY keep state of IP
  packet fragmentation in order to map fragments that do not contain
  sufficient header information correctly to flows.

6.1.  Information Model:
  - moved MUST attribute "7. input interface (ifIndex)" to SHOULD section:
    "18. input interface (ifIndex)".
  - moved MUST attribute "8. output interface (ifIndex)" to SHOULD section:
    "19. output interface (ifIndex)".
  - replaced "9. in case of IPv4: Type of Service"
    by "9. type of service octet (in case of IPv4), traffic class
    octet (in case of IPv6)"
  - replaced "11. if MPLS is supported at the observation point: MPLS label"
    by "11. if MPLS is supported at the observation point: the top MPLS
        label or the corrsponding forwarding equivalence class (FEC,
        [RFC3031]) bound to that label. The FEC is typically defined
        by an IP prefix."
  - removed item 12: DSCP.
  - removed MUST attribute "13. if BGP is supported at the observation
    point: BGP AS number" and instead appended to the end of section 6.1:
    "In addition, the exporting process MAY be able to report attributes
     related to inter-autonomous system routing of a flow, for example
     by reporting BGP Autonoumous System numbers."
  - replaced "20. Time To Live"
  - by "20. Time To Live (in case of IPv4) or Hop Limit (in case of IPv6)"
  - appended to SHOULD attribute "19. multicast replication factor":
    "The computation of the factor MUST be clearly defined."
  - added "25. next hop IP address"

7.2.  Configuration of the Exporting Process:
  - inserted new item into bullet list:
    "3. the reporting interval
        This requirement only applies if the exporting process supports
        reporting in regular intervals."
  - appended to 4. notifications ...
    "This requirement only applies if the exporting process supports
     notifications."

8.3.  Several Collecting Processes
  appended
  "If an exporting process is able to export flow records to multiple
   collecting processes then it MUST be able to ensure that the flow
   records can be identified so that duplicates can be detected between
   different collecting processes and double counting problems can be
   avoided."

12.  References
  added reference to RFC791.

    Juergen

--
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/