Subject: RE: [ipfix-req] list of issues

From: "Tal Givoly" <[email-masked]>
Date: Thu, 14 Nov 2002 13:31:21 -0800

Juergen,

My view on the open issues attached below (I found it less convenient to
spawn independent threads, as it is difficult to follow which threads were
spawned as a result of the ongoing debate):

-----Original Message-----
From: majordomo listserver [mailto:[email-masked]]On Behalf
Of Juergen Quittek
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)

Tal> Should not be mandatory (i.e. remove) - would inflate data structure
for all devices that do not have ability (for any reason) to expose this
attribute.

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.

Tal> Should not be mandatory (i.e. remove) - same reason as above.

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?

Tal> I strongly believe that the protocol MUST support a mode in which it
operates fail-over. It should be noted that failover implicitly requires
bi-directional communication (minimally offered by transport protocol).
Therefore the way I see it, protocol MUST have a MODE in which it can fail
over to a backup collector in one of several cases. These cases may include
(but are not limited to), failure of the collector, failure of the link to
the collector, overload of the collector, lack of acknowledgement from
collector, signal from collector, and negative acknowledge from collector.
I'm sure there would be a debate whether that mode must exist in each
implementation or it merely be optional to support that mode. The protocol
itself must have such a mode, IMHO.

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?

Tal> I believe that overload in the collector or in the network needs to be
handled and be included as part of overload behavior.

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.

Tal> I don't believe we have arrived at consensus. I would welcome the
opportunity to take a stab at phrasing the consensus or even the options for
consensus once we, first, achieve consensus on at least two principles:
- We are not here to standardize NetFlow
- The question of reliability level of the protocol is in scope for the
IPFIX WG

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.

Tal> I believe this should be classified as a SHOULD.

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?

Tal> I believe it can be removed for reasons described above regarding VPN.

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.

Tal> Concur.

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.

Tal> No strong opinion.

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

--
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: Juergen Quittek <[email-masked]>
Date: Fri, 15 Nov 2002 01:40:23 +0100

Tal,

> Tal> Should not be mandatory (i.e. remove) - would inflate data structure

What do you mean? a requirement that is NOT MANDATORY can still be RECOMMENDED
or OPTIONAL. "removes" sounds like "no requirement on this at all".

> for all devices that do not have ability (for any reason) to expose this

There is a requirement on a flexible datastructure. Therefore it would only
inflate the data structure, if you configure the exporting process to report
this flow attribute. I you have a look at the number of attributes already
defined in the information model draft, my guess is that in real life you
never ever configure the device for reporting every attribute (except for
testing).

> Tal> Should not be mandatory (i.e. remove) - same reason as above.

Same ocmment as above.

    Juergen

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 15 Nov 2002 01:49:51 +0100

Tal,

> itself must have such a mode, IMHO.

What about the following change:

in draft-ietf-ipfix-reqs-07 replace

   If the exporting process is capable of detecting loss of connection
   to a collecting process, it SHOULD be able to perform failover to a
   specified backup collecting process.

by

   The exporting process MUST support a mode in which it can detect
   loss of connection to one or more of the collecting processes.
   If the exporting process detects loss of connection it MUST be
   able to perform failover to one or more specified backup
   collecting processes.

    Juergen

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 15 Nov 2002 01:57:35 +0100

Tal,

> handled and be included as part of overload behavior.

Ever though about becoming a politician? Your sentences is probably
agreed by most of the people on the list and related to the question,
but it does not at all answer the question ;-)

Again: It is implicitly included. Is a clarification needed?
If yes, please suggest concrete text and please suggest where
in the current draft to insert it.

    Juergen

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 15 Nov 2002 02:06:40 +0100

Tal,

> - We are not here to standardize NetFlow

So far, I don't see any reason to exclude NetFlowV9 from the
list of candidates.  If you want to do so, please explain why.

> - The question of reliability level of the protocol is in scope for the

Yes, hopefully we can get closer to consensus in Atlanta.

    Juergen

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 15 Nov 2002 02:12:15 +0100

Tal,

> Tal> I believe this should be classified as a SHOULD.

I agree. In the current draft it is listed in section 6.1 as a MUST
attribute. We should move it to SHOULD. But I changed my opinion
on this issue already two times. Are there other people having a more
firm opinion?

    Juergen

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 15 Nov 2002 02:14:46 +0100

Tal,

> for all devices that do not have ability (for any reason) to expose this

How does this relate to ignoring port copy?

    Juergen

---

From: "Tal Givoly" <[email-masked]>
Date: Thu, 14 Nov 2002 18:15:54 -0800

Jurgen,

I must have explained myself very poorly in this response... I did not at
all mean to exclude NFv9 from the list of candidates being evaluated. In
fact, in a previous submission today I actually said EXACTLY the opposite
(in http://ipfix.doit.wisc.edu/archive/1428.html): "...although NetFlow is a
perfectly viable candidate protocol and may be selected after
evaluation...".

The fact we are not here to "(merely) standardize NetFlow" doesn't imply
NetFlow cannot be a viable candidate. NetFlow does, today, serve many of the
applications this working group has set out to solve - but it is left to the
evaluation process to determine whether it is a good choice for solving the
bigger picture, as stated in charter and requirements.

I don't think we are that far apart - it is probably my poor expressive
skills...

Tal

-----Original Message-----
From: majordomo listserver [mailto:[email-masked]]On Behalf
Of Juergen Quittek
Sent: Thursday, November 14, 2002 5:07 PM
To: Tal Givoly
Cc: [email-masked]
Subject: improve reliability section, was: RE: [ipfix-req] list of
issues

Tal,

    Juergen

---

From: "Tal Givoly" <[email-masked]>
Date: Thu, 14 Nov 2002 18:16:00 -0800

Juergen,

I have rarely been called a politician... there was no intent to politicize
the issue in any way.

To answer your question - after rethinking the issue, I don't believe a
clarification is necessary.

Tal

-----Original Message-----
From: majordomo listserver [mailto:[email-masked]]On Behalf
Of Juergen Quittek
Sent: Thursday, November 14, 2002 4:58 PM
To: Tal Givoly
Cc: [email-masked]
Subject: RE: [ipfix-req] list of issues

Tal,

    Juergen

---

From: "Tal Givoly" <[email-masked]>
Date: Thu, 14 Nov 2002 18:16:10 -0800

Juergen,

I believe this requirement should be changed to "VPN-ID SHOULD be exported
in devices that have the notion of VPN-ID". Even devices that have the
notion of VPN-ID may not easily be able to populate this attribute and
mandating its metering and export is more than required.

Same goes for all other attributes that may exist in some devices - the
device should expose those attributes, if it has a notion of those
attributes.

No doubt, the statement "...(i.e. remove)" leads to the confusion in
interpreting my response. Thanks for identifying this.

Tal

-----Original Message-----
From: majordomo listserver [mailto:[email-masked]]On Behalf
Of Juergen Quittek
Sent: Thursday, November 14, 2002 4:40 PM
To: Tal Givoly
Cc: [email-masked]
Subject: VPN-IDs, was: RE: [ipfix-req] list of issues

Tal,

> Tal> Should not be mandatory (i.e. remove) - would inflate data structure

What do you mean? a requirement that is NOT MANDATORY can still be
RECOMMENDED
or OPTIONAL. "removes" sounds like "no requirement on this at all".

Same ocmment as above.

    Juergen

---

From: [email-masked]
Date: Fri, 15 Nov 2002 07:07:28 -0500

> on this issue already two times. Are there other people having a more
	SHOULD. Many platforms do not distinguish on this field and
	it does not make sense to report it if not part of the key.

---

From: Benoit Claise <[email-masked]>
Date: Fri, 15 Nov 2002 14:59:26 +0100

Juergen,

>   able to perform failover to one or more specified backup

"The exporting process MUST support a mode in which it can detect
  loss of connection to one or more of the collecting processes."

Or

"The exporting process MUST support a mode in which it can detect
  loss of connection to one or more of the collecting process hosts."

The second one means. Transport protocol detection is enough
The first one  implies application level ACK.

And we're back to the reliability discussion...

Regards, Benoit.