Re: [IPFIX] R: R: Last Call Expired: <draft-ietf-ipfix-flow-selection-tech-14.txt>

ramki Krishnan <ramk@Brocade.com> Thu, 25 April 2013 02:02 UTC

Return-Path: <ramk@Brocade.com>
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D28C321F90AF for <ipfix@ietfa.amsl.com>; Wed, 24 Apr 2013 19:02:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.264
X-Spam-Level:
X-Spam-Status: No, score=-3.264 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xw7BOhGQBxuy for <ipfix@ietfa.amsl.com>; Wed, 24 Apr 2013 19:02:47 -0700 (PDT)
Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by ietfa.amsl.com (Postfix) with ESMTP id 69EFC21F909A for <ipfix@ietf.org>; Wed, 24 Apr 2013 19:02:47 -0700 (PDT)
Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id r3P22jA7008133; Wed, 24 Apr 2013 19:02:45 -0700
Received: from hq1wp-exchub02.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 1bxna986k5-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 24 Apr 2013 19:02:44 -0700
Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by hq1wp-exchub02.corp.brocade.com (10.70.38.99) with Microsoft SMTP Server (TLS) id 14.2.309.2; Wed, 24 Apr 2013 19:02:42 -0700
Received: from HQ1-EXCH01.corp.brocade.com ([fe80::8c73:93bf:41b4:1443]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Wed, 24 Apr 2013 19:02:42 -0700
From: ramki Krishnan <ramk@Brocade.com>
To: Salvatore D'Antonio <salvatore.dantonio@uniparthenope.it>, "tanja@caida.org" <tanja@caida.org>, "lorenzo.peluso@unina.it" <lorenzo.peluso@unina.it>
Date: Wed, 24 Apr 2013 19:02:35 -0700
Thread-Topic: [IPFIX] R: R: Last Call Expired: <draft-ietf-ipfix-flow-selection-tech-14.txt>
Thread-Index: Ac45veJiRHrdfH9cTm69S7sEnZNliAEY1GBQALVtivAAFy3XgA==
Message-ID: <C7634EB63EFD984A978DFB46EA5174F2BFD824EFD2@HQ1-EXCH01.corp.brocade.com>
References: <20130401072846.32360.9502.idtracker@ietfa.amsl.com> <5162C44B.5030904@cisco.com> <005701ce3538$8f0b3480$ad219d80$@dantonio@uniparthenope.it> <516BCB97.9040404@cisco.com> <001001ce3e24$0a931840$1fb948c0$@dantonio@uniparthenope.it> <C7634EB63EFD984A978DFB46EA5174F2BFD824ED8F@HQ1-EXCH01.corp.brocade.com>
In-Reply-To: <C7634EB63EFD984A978DFB46EA5174F2BFD824ED8F@HQ1-EXCH01.corp.brocade.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_C7634EB63EFD984A978DFB46EA5174F2BFD824EFD2HQ1EXCH01corp_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-04-24_08:2013-04-24, 2013-04-24, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1211240000 definitions=main-1304240270
Cc: IPFIX Working Group <ipfix@ietf.org>
Subject: Re: [IPFIX] R: R: Last Call Expired: <draft-ietf-ipfix-flow-selection-tech-14.txt>
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list <ipfix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipfix>, <mailto:ipfix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipfix>
List-Post: <mailto:ipfix@ietf.org>
List-Help: <mailto:ipfix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Apr 2013 02:02:50 -0000

Dear Authors,

The technique I am suggesting is “Multistage Filters” in [EsVa01] and not “Sample and Hold”. Apologies for the error. I have fixed the text – my suggested changes will be in an addition to what is there currently.

I had a good discussion with Juergen on this topic. He suggested that I reach out to you folks at the earliest.

Probably a separate sub-section in section 6 ???
An example is “Multistage Filters” [EsVa01], or similar techniques, that try to prefer long-lived large volume flows in the selection. When a packet arrives, these packet selection techniques are applied only if a flow record for the packet does not exist. These packet selection techniques could have false positives but no false negatives; i.e. flows which are not long-lived large flows may be selected and learnt in the flow cache. The flows which are not long-lived large flows are later purged from the flow cache.

Suggested changes to Section 7
For techniques similar to “Multistage Filters”, the two parameters -- the observation interval, and the minimum bandwidth threshold over that observation interval -- should be programmable in a networking device to facilitate handling of different use cases and traffic characteristics.

From a bandwidth and time duration perspective, in order to identify long-lived large flows, we define an observation interval and observe the bandwidth of the flow over that observation interval. A flow that exceeds a certain minimum bandwidth threshold over that observation interval
would be considered a long-lived large flow.

For example, a flow which is at or above 10 Mbps for a time period of at least 30 seconds could be declared a long-lived large flow.

Suggested changes to Section 8 and Section 9
The parameters described in section 7

The parameters I described above are captured in sections 2.1.2/6.1 of the draft below. Other details are also captured in the draft below.
http://datatracker.ietf.org/doc/draft-krishnan-ipfix-flow-aware-packet-sampling/?include_text=1

Thanks,
Ramki

From: ipfix-bounces@ietf.org<mailto:ipfix-bounces@ietf.org> [mailto:ipfix-bounces@ietf.org] On Behalf Of ramki Krishnan
Sent: Wednesday, April 24, 2013 8:13 AM
To: Salvatore D'Antonio; tanja@caida.org<mailto:tanja@caida.org>; lorenzo.peluso@unina.it<mailto:lorenzo.peluso@unina.it>
Cc: IPFIX Working Group
Subject: Re: [IPFIX] R: R: Last Call Expired: <draft-ietf-ipfix-flow-selection-tech-14.txt>

Dear Authors,

I had a good discussion with Juergen on this topic. He suggested that I reach out to you folks.

Suggested changes to Section 6.4
An example is the  "Sample and Hold" algorithm [EsVa01], or similar techniques, that try to prefer long-lived large volume flows in the selection. When a packet arrives, these packet selection techniques are applied only if a flow record for the packet does not exist. These packet selection techniques could have false positives but no false negatives; i.e. flows which are not long-lived large flows may be selected and learnt in the flow cache. The flows which are not long-lived large flows are later purged from the flow cache.

Suggested changes to Section 7.2
For techniques similar to “Sample and Hold”, the two parameters -- the observation interval, and the minimum bandwidth threshold over that observation interval -- should be programmable in a networking device to facilitate handling of different use cases and traffic characteristics.

From a bandwidth and time duration perspective, in order to identify long-lived large flows, we define an observation interval and observe the bandwidth of the flow over that observation interval. A flow that exceeds a certain minimum bandwidth threshold over that observation interval
would be considered a long-lived large flow.

For example, a flow which is at or above 10 Mbps for a time period of at least 30 seconds could be declared a long-lived large flow.

Suggested changes to Section 8 and Section 9
The parameters described in section 7.2.

The parameters I described above are captured in section 2.1.2 of the draft below. Other details are also captured in the draft below.
http://datatracker.ietf.org/doc/draft-krishnan-ipfix-flow-aware-packet-sampling/?include_text=1

Thanks,
Ram (aka Ramki)
From: ipfix-bounces@ietf.org<mailto:ipfix-bounces@ietf.org> [mailto:ipfix-bounces@ietf.org] On Behalf Of Salvatore D'Antonio
Sent: Saturday, April 20, 2013 5:06 PM
To: 'Benoit Claise'
Cc: 'IETF discussion list'; draft-ietf-ipfix-flow-selection-tech@tools.ietf.org<mailto:draft-ietf-ipfix-flow-selection-tech@tools.ietf.org>; apps-discuss@ietf.org<mailto:apps-discuss@ietf.org>; 'General Area Review Team'; 'S Moonesamy'; ipfix-chairs@tools.ietf.org<mailto:ipfix-chairs@tools.ietf.org>; ipfix@ietf.org<mailto:ipfix@ietf.org>; iesg@ietf.org<mailto:iesg@ietf.org>; 'Joel M. Halpern'; 'A. Jean Mahoney'
Subject: [IPFIX] R: R: Last Call Expired: <draft-ietf-ipfix-flow-selection-tech-14.txt>

Dear Benoit, all

I submitted v16 of the Internet Draft.

I modified section 9.1.1 on the maintenance of the flowSelectorAlgorithm registry and fixed the editorial issue in section  6.1.1

I have also used MUST in section 6.1

Best regards,

Salvatore


Da: Benoit Claise [mailto:bclaise@cisco.com]
Inviato: lunedì 15 aprile 2013 11:43
A: Salvatore D'Antonio
Cc: draft-ietf-ipfix-flow-selection-tech@tools.ietf.org<mailto:draft-ietf-ipfix-flow-selection-tech@tools.ietf.org>; ipfix-chairs@tools.ietf.org<mailto:ipfix-chairs@tools.ietf.org>; 'S Moonesamy'; apps-discuss@ietf.org<mailto:apps-discuss@ietf.org>; iesg@ietf.org<mailto:iesg@ietf.org>; 'Joel M. Halpern'; 'A. Jean Mahoney'; 'General Area Review Team'; 'IETF discussion list'; rahulp@cisco.com<mailto:rahulp@cisco.com>; ipfix@ietf.org<mailto:ipfix@ietf.org>
Oggetto: Re: R: Last Call Expired: <draft-ietf-ipfix-flow-selection-tech-14.txt>

Salvatore
Dear all,

A new version of the Internet Draft on Flow Selection Techniques has been submitted. It contains the following changes:

-          A new section illustrating the difference between Intermediate Flow Selection Process and Intermediate Selection Process has been added,

-          The sentence "In order to be compliant with this document, at least the Property  Match Filtering MUST be implemented." has been removed in Section 1,

-          “MUST” has been replaced with “SHOULD” in Section 5.1,
Actually, the feedback was:
In Section 1:

  "In order to be compliant with this document, at least the Property
   Match Filtering MUST be implemented."

The above text is repeated in Section 5.1.  I suggest removing this sentence as it does not seem related to scope.

My reading of the "MUST" is that it is being used for compliance instead of the reasons described in RFC 2119.  I suggest reviewing the usage of RFC 2119 key words in Section 5.1.
So the solution is not to change MUST to SHOULD.
The question is whether "MUST" versus "must" must be used.
I understand the concern. For compliance reason with the PSAMP RFC 5475 (which is closely related) ...
7<http://tools.ietf.org/html/rfc5475#section-7>.  Parameters for the Description of Selection Techniques

   This section gives an overview of different alternative selection

   schemes and their required parameters.  In order to be compliant with

   PSAMP, at least one of proposed schemes MUST be implemented.


... I would keep the initial "MUST" from the previous draft version.

-          “The flowSelectorAlgorithm registry is maintained by IANA." has been replaced with “IANA is requested to create the flowSelectorAlgorithm registry.”

-          The sentence "The registry can be updated when specifications of the new  technique(s) and any new Information Elements are provided." has been removed since it did not clarify how the registry will be managed.

-           Section 6.1.1 “Property Match Filtering” has been changed by adding some text on how Property Match Filtering can be  used by an Intermediate Flow Selection Process in the Metering Process, in the  Exporting Process and within an IPFIX Mediator.
When publishing a new version, please correct this editorial issue.

 " ... and Flow duration. in

   the An example is the selection of the largest ..."


Best regards,

Salvatore

Da: Benoit Claise [mailto:bclaise@cisco.com]
Inviato: lunedì 8 aprile 2013 15:21
A: draft-ietf-ipfix-flow-selection-tech@tools.ietf.org<mailto:draft-ietf-ipfix-flow-selection-tech@tools.ietf.org>
Cc: ipfix-chairs@tools.ietf.org<mailto:ipfix-chairs@tools.ietf.org>
Oggetto: Fwd: Last Call Expired: <draft-ietf-ipfix-flow-selection-tech-14.txt>

Dear authors,

The IETF last call has finished.
Can you please update your draft based on the feedback received.
Then I will progress it.

Regards, Benoit


-------- Original Message --------
Subject:

Last Call Expired: <draft-ietf-ipfix-flow-selection-tech-14.txt>

Date:

Mon, 01 Apr 2013 00:28:46 -0700

From:

DraftTracker Mail System <iesg-secretary@ietf.org><mailto:iesg-secretary@ietf.org>

To:

iesg@ietf.org<mailto:iesg@ietf.org>, ipfix-chairs@tools.ietf.org<mailto:ipfix-chairs@tools.ietf.org>, draft-ietf-ipfix-flow-selection-tech@tools.ietf.org<mailto:draft-ietf-ipfix-flow-selection-tech@tools.ietf.org>

CC:

iesg-secretary@ietf.org<mailto:iesg-secretary@ietf.org>



Please DO NOT reply to this email.



I-D: <draft-ietf-ipfix-flow-selection-tech-14.txt>

ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/



IETF Last Call has ended, and the state has been changed to

Waiting for AD Go-Ahead.








________________________________
Nessun virus nel messaggio.
Controllato da AVG - www.avg.com<http://www.avg.com>
Versione: 2013.0.3272 / Database dei virus: 3162/6231 - Data di rilascio: 07/04/2013


*******************************************************************************************************

IL MERITO DEGLI STUDENTI VIENE RICONOSCIUTO



Il 5 per mille all'Università degli Studi di Napoli "Parthenope"incrementa le borse di studio agli studenti - codice fiscale 80018240632

http://www.uniparthenope.it/index.php/5xmille



http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la-parthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-proventi-del-5-per-mille


Questa informativa è inserita in automatico dal sistema al fine esclusivo della realizzazione dei fini istituzionali dell'ente.




*******************************************************************************************************

IL MERITO DEGLI STUDENTI VIENE RICONOSCIUTO



Il 5 per mille all'Università degli Studi di Napoli "Parthenope"incrementa le borse di studio agli studenti - codice fiscale 80018240632

http://www.uniparthenope.it/index.php/5xmille



http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la-parthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-proventi-del-5-per-mille


Questa informativa è inserita in automatico dal sistema al fine esclusivo della realizzazione dei fini istituzionali dell'ente.






*******************************************************************************************************

IL MERITO DEGLI STUDENTI VIENE RICONOSCIUTO



Il 5 per mille all'Università degli Studi di Napoli "Parthenope"incrementa le borse di studio agli studenti - codice fiscale 80018240632

http://www.uniparthenope.it/index.php/5xmille



http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la-parthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-proventi-del-5-per-mille


Questa informativa è inserita in automatico dal sistema al fine esclusivo della realizzazione dei fini istituzionali dell'ente.





*******************************************************************************************************

IL MERITO DEGLI STUDENTI VIENE RICONOSCIUTO



Il 5 per mille all'Università degli Studi di Napoli "Parthenope"incrementa le borse di studio agli studenti - codice fiscale 80018240632

http://www.uniparthenope.it/index.php/5xmille



http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la-parthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-proventi-del-5-per-mille


Questa informativa è inserita in automatico dal sistema al fine esclusivo della realizzazione dei fini istituzionali dell'ente.