Subject: [ipfix-req] List of open issues - Please post your comments

From: "Reinaldo Penno" <[email-masked]>
Date: Wed, 23 Oct 2002 12:56:45 -0700

Folks on the list,

a lot of the open issues here have impact on the evaluation of the
protocols. If we do not reach a consensus we are going to be on this on-hold
position where we cannot complete the full evalation because the
requirements themselves are not completed.

So, if you have any opnion regarding these open issues, please speak up.

regards,

Reinaldo

> -----Original Message-----
> From: Juergen Quittek [mailto:[email-masked]]
> Sent: Tuesday, October 22, 2002 2:25 AM
> To: [email-masked]
> Subject: [ipfix-req] list of issues
> 
> 
> 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/
>