Subject: [ipfix-req] list of issues

From: Juergen Quittek <[email-masked]>
Date: Tue, 22 Oct 2002 11:24:46 +0200

Dear all,

Since the posting of the last requirements I-D, I took some
'vacation' from the ipfix list. Now I find that I missed
participating in some very interesting discussions.

Below I try to summarize raised requriements issues.
It might be incomplete. Please add issues I missed.

My intention is to check all issues and identify an already
existing consensus, or to trigger completion of the discussion
on these issues in order to get consesus soon.

If you want to contribute to the further discussion of these
issues, please use separate emails per issues and please state
the issue in the subject field. ("Re: list of issues" is not
really helpful for continuing the MPLS label discussion).

    Juergen

Reinaldo-1a: adding a VPN-ID attribute in section 6.1

    I think this is a good point. Still I have three questions:
    - Would it be a MUST, a SHOULD, or a MAY?
    - Shall we ask it to be required only where applicable (on devices
      supporting VPN-IDs?
    - Is it required too much for an IP meter? (see MPLS label discussion)

Reinaldo-1b: export NATed flows (before and after)

    We already discussed this issue earlier this year and decided to not
    stating a requirement. However, it is already considered by the
    information model I-D.

Reinaldo-2a: Add failover requirements, for example on the ability
             to detect loss of connectivity with the collector and
             trigger the appropriate action (eg. a switch over to
             an alternate collector.)

    I haven't seen many responses on that. Is this a nice-to-have
    or a MUST?
    What would be appropriate actions?
    Is the requirement just "do something senseful in case of
    loosing a connection (or something like this) to the collector?

Reinaldo-2b: Add optional export of flow records to multiple collectors

    This is already covered.

Reinaldo-2c: Add optional re-transmission of lost flow records.

    This should be part of the requirements discussion (see Reinaldo-3).

Reinaldo-2d: Add: Exchange control information from the collector, monitor
             export process and detect any overload in the process of
             exporting.

    I do not think, an exchange of control information from the collector
    is required.

    Monitoring the exporter and detecting overload is not explicitly
    discussed, but implied in the reliability requirement ("indicate
    missing reliability"). Is a clarification needed that for indicating
    missing reliability a detection of overload is required?

Reinaldo-3: Rephrase or modify Section 6.3.2. "Reliability"

    There was an extended discussion on this. Can one of the participants
    tell me what he considers to be the consensus concerning the new
    phrasing.

Reinaldo-4: Add MUST requirement for exporting ICMP codes in Section 6.1

    There were not many responses on this suggestion. Personally, I do
    not consider it a MUST, but a nice-to-have.

Reinaldo-5: Remove Section 5.8. "Ignore Port Copy"?

    This is not a strong requirement. It's a nice-to-have.
    Is there a consesus on either keeping or removing it?

Reinaldo-6: Section 6.6. "Anonymization"

    As far as I understood the discussion, there was a request to more
    clearly state what kind/level of anonymization is required. I find
    this hard to decide. Therefore, I suggest keeping the more vague
    current version.

Simon-1: Drop MPLS label

   This covers two sections:
       - Requiring the metering process to be able to separate flows by the MPLS label
       - requiring the ability to export the MPLS label or FEC

   It has been discussed controversially for a long time. I still do not see
   a clear consensus on this issue. Fortunaltely, I do not see a considerable
   impact on the protocol evaluation.

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

---

From: David Moore <[email-masked]>
Date: Tue, 22 Oct 2002 09:58:27 -0700

>    not consider it a MUST, but a nice-to-have.

I would like to see this as a MUST, because of its usefulness for
both debugging certain events and for potential security related
tracking.

-- david

---

From: Simon Leinen <[email-masked]>
Date: 28 Oct 2002 00:29:19 +0100

> both debugging certain events and for potential security related

I agree, as I have used ICMP type/codes in flow data for the same
purposes.

Note that "old" NetFlow versions (1/5/6/7) had a very efficient and
easy-to-use method of encoding the ICMP type and code in the fields
that are used for port numbers in TCP/UDP.

Things like this will probably take more effort as we move to a "real"
data model.
-- 
Simon.