Subject: [ipfix-req] Proposed changes to draft-ietf-ipfix-reqs-00.txt

From: Juergen Quittek <[email-masked]>
Date: Mon, 11 Feb 2002 11:13:24 +0100

Hi all,

Here is my list of proposed changes to draft-ietf-ipfix-reqs-00.txt.

I know that Benoit also is going to send some suggestions.
And of course anyone else should feel free to do so.

Cheers,

    Juergen
-- 
Juergen Quittek     [email-masked]     Tel: +49 6221 90511-15
NEC Europe Ltd.,    Network Laboratories     Fax: +49 6221 90511-55
Adenauerplatz 6, 69115 Heidelberg, Germany   http://www.ccrle.nec.de

1. insert new section "2. Terminology"

2. Make section "1.1  IP Flows" new section "2.1. IP Traffic
   Flows or Flows"

3. Add sections 2.2 to 2.8:
  2.2. Observation Point
       The observation point is a location in the network
       where IP packets can be observed. Examples are a line
       to which a probe is attached, a shared medium, such as
       an Ethernet-based LAN, a port of a router, or an
       entire router with several ports.

  2.3. Trafic Flow Meter or Meter
       A meter observes packets at one or more obsrvation
       points. It analyzes the content of the packets and maps
       them to flows. For each observed flow the meter computes
       statistics and maintains a flow record where it stores
       relevant flow infromation.

  2.4. Metering Process
       The metering process includes all actions performed by a
       meter with respect to observing packets, timestamping
       them, analyzing them, mapping them to flows, computing
       flow statistics, detecting flow expiration, and
       maintaining flow records.

  2.5. Flow Record
       A flow record keeps information a flow including
       characteristic properties of the flow, for example the
       source IP address, and measured properties of the flow,
       for example the total number of bytes of all packets of
       the flow.

  2.6. Flow Information Exporter or Exporter
       The exporter sends flow records created and maintained
       by one or more meters to one or more data collectors.

  2.7. Flow Information Data Collector or Data Colletor
       The data collector receives flow records from one or
       more exporters. The data collector might process or
       store received flow record, but these actions are out
       of the scope of this document.

  2.8. Flow Information Exort
       Flow information export denotes the process of
       transferring flow records from an exporter to a data
       collector.

4. Remove section 2.5 Network Surveillance

5. In section 2.6, 3rd paragraph:
   remove "'Heisenberg' effects,"

6. In section 4.1, last sentence:
   replace "then it SHOULD be stored ... inaccurately."
   by "then the measuring device MUST be able to detect
   this failure and to report about it."

7. Replace section "4.2 Sampling" by section "4.2 Overload
   Behavior":
   In case of an overload, e. g. lack of memory or
   processing power, the measuring device MAY change the
   metering process in order to cope with the lack of
   resources. Possible reactions include:

   - Reduce the number of flow accounts. This can be
     achieved by more coarse grained flow measurement or
     by a restriction of the flow accounts to a subset of
     the set of original ones.
   - Sample packets before they are processed by the meter.
   - Stop metering.

   Overload behavior is not restricted to the three options
   listed above. But in any case, the overload behavior
   MUST be clearly defined. For example in case of sampling,
   the sampling method and all its parameters MUST be known
   or indicated.

8. Append to section "4.3 Timestamps"
   Also in case of a switch to overload behavior, a
   timestap MUST be generated for this event as well as for
   a switch back to regular behavior.

9. Change section 5.3.1. "Congestion Awareness" to
   "Congestion-Friendlyness"
   Replace text of subsection by "For the flow information
   export a congestion-friendly protocol MUST be supported."

10. Insert new section 5.3.3 Robustness
    Data transfer SHOULD be robust against network and
    system fault conditions. Robustness may be supported for
    example by
    - flow control
    - by deploying redundant data receiving systems
    - fail-over/fail-back procedures.
    However, robustness should not be traded with
    congestion-friendlyness which has higher priority.

11. Update reference [MIDBOXTAX] which is now updated to
    version -03.

12. Remove all entries for network surveillance from table
    in Appendix

13. Update Table in appendix according to changes in text.

--
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: Benoit Claise <[email-masked]>
Date: Tue, 12 Feb 2002 17:19:18 +0100

Juergen,

> And of course anyone else should feel free to do so.

1. I have one question whose answer should in the requirement draft.
What do we do with ICMP, IGMP?  others?
Do we report this traffic with IPFIX. If yes, this must be described.

2. I think we should have statements in the requirement document about:
- configuration will be done out-bound
  Note: this is at least the direction I see in the working group on that one:
Will, KC, Juergen, Mike, Ganesh and I versus Reinaldo, Kevin
  a version 2 of the IPFIX protocol could investigate the needs of in-band
configuration
- no transport negotiation (which transport)
- no capability negotiation

But the decisions about the last 2 bullets are still under discussion. These are
the 2 next big points the group has to agree on.

3. We also want to stress that we are trying to standardize the direction
exporter -> collector and not necessarely the direction collector -> exporter.
Maybe in the chapter about "push and pull mode reporting" 5.4, next to "The
measuring device MUST support push mode reporting, it MAY support pull mode
reporting."

4. all occurences of measuring device should be replaced by exporter

5. Let's not forget the comment from Nevil
Section 4.5 Timeouts.  More detail needed here.
  At least we need to say "user must be able to specify timeout interval
  for fixed timeout intervals."  And maybe we should allow for some
  kinds of dynamic timeouts too, e.g. "timeout after specified minimum
  time, when no packets have been seen for twice the average inter-packet
  time while the flow was active."  ???

6. I would remove the remotely from sectiont 6., this could be confusing.
   The measuring device MUST provide a way of configuring the traffic
   measurement and the traffic data export remotely.

>     Juergen

- Maybe the flow definition will have to be adapted.
  See our terminology thread.
- The observation point definition should be removed from there.

> 3. Add sections 2.2 to 2.8:

Sure we will have to insert the definitions but there are still under discussion.

> 7. Replace section "4.2 Sampling" by section "4.2 Overload

I tend to disagree.
The metering can do sampling versus full
And in case of overload, the metering process might switch to sampling.
These are 2 different topics.
If you want to keep overload behavior, here is what I can propose:

4.2. Sampling

   The measuring device MAY support measuring traffic by packet
   sampling. If sampling is supported the sampling method and its
   parameters MUST be well defined.

4.2.1 Overload Behavior

>    a switch back to regular behavior.

I'm not too sure what you mean.

That's it for now.

Regards, Benoit

---

From: Sebastian Zander <[email-masked]>
Date: Tue, 12 Feb 2002 19:41:50 +0100

Hi Benoit,

I have some comments on your proposal.

> Do we report this traffic with IPFIX. If yes, this must be described.

I think IPFIX should report them and you are right that we have to add
something in the draft.
 
> the 2 next big points the group has to agree on.

I agree to your points. However I don't think that these are requirements for
IP flow information export and thus they don't belong into the draft.
 
> measuring device MUST support push mode reporting, it MAY support pull mode

We could add a statement in 6.
 
>   time while the flow was active."  ???

We could add in 4.5:
Flow timeouts MAY be fixed timeout intervals or dynamic timeouts e.g. "
Nevils text".

In section 6 we have already specified that the configuration of the timeout is
a MAY. So far there are no specific MUST requirements. At least we should make
it a SHOULD.
 
>    measurement and the traffic data export remotely.

Why is that confusing?

Cheers,

Sebastian

-- 
Sebastian Zander                         E-mail: [email-masked]
FhI FOKUS / Global Networking (GloNe)    Tel: +49-30-3463-7287
Kaiserin-Augusta-Allee 31                Fax: +49-30-3463-8287 
D-10589 Berlin, Germany                  www.fokus.fhg.de/usr/sebastian.zander

---

From: Benoit Claise <[email-masked]>
Date: Tue, 12 Feb 2002 23:50:34 +0100

Hi Sebastian,

[I skip the points on which we agree]

> IP flow information export and thus they don't belong into the draft.

Someone please correct me if I'm wrong but the requirement draft is, not only what
is required in the IPFIX protocol but also the scope of IPFIX protocol proposal.
This is the reason why I wanted to add the IPFIX the big principles, to limit the scope

of what will propose in IPFIX.

Any other thought?

> >    measurement and the traffic data export remotely.

What does the remotely refer to?
- The way of configuring traffic measurement. Then I disagree
  because the exporter configuration should be out of the scope of IPFIX
- The traffic data export. Then remotely is implicit

Regards, Benoit

---

From: Sebastian Zander <[email-masked]>
Date: Wed, 13 Feb 2002 11:20:30 +0100

Hi Benoit,

> of what will propose in IPFIX.

In priciple if have no problems with your proposal if there is wg consensus on it. But if 
we extend the scope of the draft as you propose it must be made very clear e.g. by 
adding some words to section 1. I assume you envision an additional section for defining 
the scope of the protocol?
 
> - The traffic data export. Then remotely is implicit

It refers to configuration. If configuration will be declared out of scope then 
I agree to remove it.

Sebastian

---

From: [email-masked]
Date: Wed, 13 Feb 2002 08:15:18 -0500

> is required in the IPFIX protocol but also the scope of IPFIX protocol proposal.

	That's how I understand it.

> of what will propose in IPFIX.

	Not sure what you mean by "the big principals" but
	it is important to list both what you are covering
	and what you are intentionally not covering. Saying
	configuration is out-of-band and out of scope seems
	appropriate (assuming that is what we agree to).

	But even that cannot be used as the golden rule. For
	example, I still think configuring which fields to
	send should be done in band.

---

From: Tanja Zseby <[email-masked]>
Date: Tue, 19 Feb 2002 14:28:22 +0100

Hi Jürgen,

I have a further remark to your proposed changes in ipfix requirements 
(I forgot to mention it in my last mail).
I would not rename the section 4.2 from "Sampling" into "Overload 
behavior" because I think we should allow sampling in general as an 
option and not only if the meter is overloaded.  I would propose to 
leave the sampling section as it is and add "Overload behavior" as an 
additional section.

Regards
Tanja

-- 
Dipl.-Ing. Tanja Zseby			    	      	
FhI FOKUS/Global Networking			Email: [email-masked]	
Kaiserin-Augusta-Allee 31				Phone: +49-30-3463-7153
D-10589 Berlin, Germany				Fax:   +49-30-3463-8153
-------------------------------------------------------------------------------------- 
"Living on earth is expensive but it includes a free trip around the sun." (Anonymous)
--------------------------------------------------------------------------------------

---

From: [email-masked]
Date: Tue, 19 Feb 2002 10:44:24 -0500

> leave the sampling section as it is and add "Overload behavior" as an

	Also, sampling is not the only overload strategy. For example,
	aggregation might be another one.