Subject: [ipfix] WG Last Call for Requirements I-D

From: Nevil Brownlee <[email-masked]>
Date: Tue, 4 Feb 2003 15:03:24 +1300

Hello all:

   draft-ietf-ipfix-reqs-08.txt has been published, and
   Juergen has posted the list of changes in the -08 version.

   The WG last call for this I-D (the IPFIX Requirements document)
   starts today, and closes in two weeks, i.e. on 20 Feb 03 (UTC).

At this stage we have one requested change to the draft, from Carter
Bullard, who asked for following text to be added to the section
describing anonymisation:

    When the source produces anonymized flow data, an indication
    that some form of anonymization has been performed MUST be
    present, in order to help distinguish truthful vs. non-truthful
    data.

We will produce one more version of the draft incorporating this,
and any other significant changes, before submitting the draft to
IESG for publication as an Informational RFC.

Please note that we really need to get the Requirements draft submitted
as an RFC so that we can regain momentum on the evaluation process.
Also, authors of the advocacy drafts should be making the revisions
which we discussed at the Atlanta IETF - that's required groundwork for
the next meeting in San Francisco in March.

FUrthermore, we can't keep adding more requirements as we happen to
think of them.  Any further new ideas need to be introduced (by WG
consensus) into the Architecture and/or Data Model drafts.

Cheers, Nevil

-----------------------------------------------------------------------
   Nevil Brownlee                   Director, Technology Development
   Phone: +64 9 373 7599 x88941     ITSS, The University of Auckland
   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand

-------------------------------------------------
This mail sent through University of Auckland
http://www.auckland.ac.nz/

--
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: [email-masked]
Date: Thu, 06 Feb 2003 09:49:00 -0500

Sorry I've been absent from the discussion as of late.
No objections to the outcome on the various threads. 
However, there is one point of clarification, in one of 
Nevil's messages was the following

>> If noone else shares this memory or has other concerns, then I
>> suggest to accept Tal's proposal but use a less solution-oriented
>> phrasing instead of the suggested one:
>> 
>>    "- acknowledgement of flow records by the collecting process."
>
>1) Your memory is correct, application-level acks are out of scope.

	When did application level acks become out of scope?
	We talked at the last meeting about multiple levels
	of reliability and application level was certainly
	one of them. I only recall that we agreed these 
	higher levels are MAY requirements.

	Paul

---

From: [email-masked]
Date: Thu, 06 Feb 2003 10:05:27 -0500

From the last meeting I have one addition. I apologize 
for being late, Juergen asked for the text but I didn't
get it to him.

        - It MUST be possible to determine the key used to
          distinguish a flow. For example, if only one key
          is in use for long periods of time (e.g. months) and 
          the operator can glean that key from reviewing the 
          configuration,  the requirement is satisfied. However, 
          if multiple keys are in use or the keys change dynamically, 
          then some other mechanism must be in place to map flows 
          to their corresponding key.

Recall the need for this is to allow data from multiple vendors
to be analyzed (i.e. apply mathematical functions). In order
to do that, you need to know how flows were distinguished.

Paul

---

From: Juergen Quittek <[email-masked]>
Date: Thu, 06 Feb 2003 16:34:01 +0100

Paul,

>           to their corresponding key.

I have two questions:

Where exactly in the rquirements draft do you suggest to insert this text?

We need to define the term 'flow key' if we use it in a MUST requirement.
Could you (or someone else) in addition to this text give a definition
of 'flow key' that fits in the terminology section?

Cheers,

    Juergen

---

From: [email-masked]
Date: Thu, 06 Feb 2003 17:38:05 -0500

> Where exactly in the rquirements draft do you suggest to insert this text?

	At the end of section 4 (before 4.1).

> of 'flow key' that fits in the terminology section?

	In section 2.1 you have the majority of text. Just
	add this modification...

	"A packet is defined to belong to a flow if it completely
	 satisfies all the defined properties of the flow.
	 [NEW TEXT START] A set of defined properties is known 
	 as a flow key. [ NEW TEXT END]"

	My modified text for end of section 4 (before
	section 4.1) is below...

          It MUST also be possible to determine the
	  combination of properties is used for distinguishing 
	  flows i.e. the flow key. For example, if only one flow key
          is in use for long periods of time (e.g. months) and 
          the operator can glean that flow key by reviewing the 
          configuration, the requirement is satisfied. However, 
          if multiple flow keys are in use or the flow keys change 
          dynamically, then some other mechanism must be in place 
          to map flows to their corresponding flow key.

---

From: Benoit Claise <[email-masked]>
Date: Fri, 07 Feb 2003 17:40:59 +0100

Paul,

I see one confusing issue with this definition: a set of defined 
properties is known as a flow key

Because you speak of multiple flow keyS in your proposed paragraph.

For example, if you separate flows by IP adddresses, Application ports, input ifIndex, protocol and DCSP,
how many flow key do you have? 7?
how many set of defined properties do you have? 1?

Regards, Benoit.

---

From: [email-masked]
Date: Fri, 07 Feb 2003 12:17:14 -0500

> Benoit Claise wrote:

	No, there is one flow key made up if 7 fields.

		"set of defined fields" == flow key
		 ===

	However, if you distinguish flows based on

		src-ip, dest ip

	and also based on

		SRC-AS, dest-AS

	You have 2 sets of defined properties and 2 flow
	keys.

	Juergen was very specific in this area indicating
	that you can have more than one property, field, 
	function, etc... and a packet must satisfy all the
	properties. This is why I felt comfortable just 
	giving that concept a name so we could refer to it.

---

From: Benoit Claise <[email-masked]>
Date: Tue, 11 Feb 2003 21:06:19 +0100

Dear all,

I read the req-08 one more time (hopefully the last one).
I have a few comments. Most of them minor editorial changes.

1. In Section "5.2.  Sampling"
  If the sampling configuration is changed during operation, the new
  sampling configuration with its parameters MUST be indicated to all
  collecting processes receiving the affected flow records. Changing
  the sampling configuration includes: start sampling, stop sampling,
  change sampling method, and change sampling parameter.

Stop sampling. I don't think it means when the metering process stops; 
that is covered by the section "6.6.  Notification on Specific Events"
It means: going from a metering process doing sampling to a metering 
process doing non-sampling.

So I would like to adapt a little the text:
If the sampling configuration is changed during operation, the new
  sampling configuration with its parameters MUST be indicated to all
  collecting processes receiving the affected flow records. Changing
  the sampling configuration includes: start sampling, stop sampling 
(going from a metering process doing sampling to a metering process 
doing non-sampling)
  change sampling method, and change sampling parameter.
...

What do you think?

All the rest is composed of minor editorial changes.

2.
Abstract
  This memo defines requirements for the export of measured IP flow
  information out of routers, traffic measurement probes and
  middleboxes.
-> metered IP flow instead of measured IP flow, to be consistent with 
the rest of the doc?

2. In section "2.1.  IP Traffic Flow"
Also, please note that although packet properties may depend on 
application headers, there is no requirement defined in
this document related to applicaton headers.
-> application headers.

3.
In section "3.3.  Traffic Engineering"
  Traffic Engineering (TE) comprises methods for measurement, modeling,
  characterization and control of a network. The goal of TE is the
  optimization of network resource utilization and traffic performance
-> modelling

4.
In section "9.  Special Device Considerations"
headers are transfered from observation points to metering processes,
-> transferred

5.
In section "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 single port of a
  router, or a set of interfaces (physical or logical) of a router.

I would remove a ","
  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 single port of a
  router, or a set of interfaces (physical or logical) of a router.

6. In section "4.  Distinguishing Flows"
  The following subsections list a set of properties which a metering
  process MUST, SHOULD, or MAY be able to evaluate for mapping packets
  to flows. Please note that requiring the ability to evaluate a
  certain property does not imply that this property must be evaluated
  for each packet.

  In other words, meeting the IPFIX requirements means that the
  metering process in general must be able, via its configuration, to
  somehow support to distinguish flows via all the MUST fields, even if
  in certain circumstances/for certain applications, only a subset of
  the MUST fields is needed and effectively used to distinguish flows.

-> combine the 2 paragraphs

7. In section "3.5.  QoS Monitoring"

  One example application is the validation of QoS parameters
  negotiated in a service level specification (SLS).
Why do we need the acronym SLS? It's not used anywhere else in the doc.

8.
In section "6.3.2.  Reliability"
     4. Collecting process limitations: it may be experiencing
        congestion and not able to buffer new flows records."
-> Remove the quotes at the end of the sentence.

9. In section "11.  Acknowledgments"

  Many thanks Georg Carle for contributing to the application analysis, 
  to K.C. Norseth for several fine-tunings, and to a lot of further
  people on the mailing list providing valuable comments and   
suggestions including Nevil Brownlee, Carter Bullard, Paul Calato,   Ram 
Gopal, Tal Givoly, Jeff Meyer, Reinaldo Penno, Sonia Panchen,   Simon 
Leinen, David Plonka, Ganesh Sadasivan, Kevin Zhang, and may   more.
-> and many more

Regards, Benoit.

---

From: Benoit Claise <[email-masked]>
Date: Wed, 12 Feb 2003 14:41:01 +0100

Hi,

I can't decrypt the document:
http://ipfix.doit.wisc.edu/IETF55/
    -> ipfix_evaluation_report.pdf

Am I the only one to face this problem?

Regards, Benoit.

---

From: Benoit Claise <[email-masked]>
Date: Wed, 12 Feb 2003 14:59:50 +0100

Acrobat reader version 5 solved the issue.
Thanks Carter!

Note: with version 5, I can read when opening the file "the file is 
damaged but can be repaired"

Regards, Benoit.

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 25 Feb 2003 07:30:11 +0100

Benoit,

Great to have another careful review!

-- Benoit Claise wrote on 11 February 2003 21:06 +0100:

> Stop sampling. I don't think it means when the metering process stops; that is covered by the section "6.6.  Notification on Specific Events"
> It means: going from a metering process doing sampling to a metering process doing non-sampling.
>
>   the sampling configuration includes: start sampling, stop sampling (going from a metering process doing sampling to a metering process doing non-sampling)

I used the following phrase which matches with the terminology used when
defining the metering process:

  If the sampling configuration is changed during operation, the new
  sampling configuration with its parameters MUST be indicated to all
  collecting processes receiving the affected flow records. Changing the sampling
  configuration includes: adding a sampling function to the metering process,
  removing a sampling function from the metering process, change sampling
  method, and change sampling parameter(s).

> -> metered IP flow instead of measured IP flow, to be consistent with the rest of the doc?

I am not sure.
Does anyone have a strong opinion on this?
(Not changed yet.)

> Also, please note that although packet properties may depend on application headers, there is no requirement defined in

fixed.

>   optimization of network resource utilization and traffic performance

I think "modelling" is UK english, while "modeling" is US English.
Therefore, I left it unchanged.

> headers are transfered from observation points to metering processes,

Yes, this is a typo in both, UK and US English.
Fixed.

>   router, or a set of interfaces (physical or logical) of a router.

Done.

> -> combine the 2 paragraphs

Done.

> Why do we need the acronym SLS? It's not used anywhere else in the doc.

Yes. Removed.

> -> Remove the quotes at the end of the sentence.

Fixed.

>   Many thanks Georg Carle for contributing to the application analysis,   to K.C. Norseth for several fine-tunings, and to a lot of further
>   people on the mailing list providing valuable comments and   suggestions including Nevil Brownlee, Carter Bullard, Paul Calato,   Ram Gopal, Tal Givoly, Jeff Meyer, Reinaldo Penno, Sonia Panchen,   Simon Leinen, David Plonka, Ganesh Sadasivan, Kevin
> Zhang, and may   more. -> and many more

Fixed.