From majordomo@mil.doit.wisc.edu Mon Feb 3 11:45:32 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12822 for ; Mon, 3 Feb 2003 11:45:31 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18fjM3-0004tz-00 for ipfix-list@mil.doit.wisc.edu; Mon, 03 Feb 2003 10:21:55 -0600 Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18fjM2-0004tu-00 for ipfix@net.doit.wisc.edu; Mon, 03 Feb 2003 10:21:54 -0600 Received: from cisco.com (bclaise-isdn-home5.cisco.com [10.49.4.222]) by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id h13GLmI28600; Mon, 3 Feb 2003 17:21:48 +0100 (CET) Message-ID: <3E3E971C.8040403@cisco.com> Date: Mon, 03 Feb 2003 17:21:48 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "M. ELK" CC: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] IPFIX Requirement & Netflow evaluation - NetFlow reply References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------050205030204020802020103" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------050205030204020802020103 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, [Sorry for the late reply. I haven't had much time to dedicate to IPFIX recently] Thanks for the feedback. Here are the answers to the NetFlow specific remarks. > > Hi > > Just few comments from average knowledge user > > Note : reference to draft-claise-ipfix-eval-netflow-03.txt is between > ( ) , reference to draft-ietf-ipfix-reqs-07-txt is between [ ] > > YYY- For netflow evaluation > > 1- IP Traffic flow (3.1.1) [2.1] > not clear how it is Total Compliance . in netflow the flow > definition is fixed . > Their is no possibility to have function "F" to define a flow . > agregation schema is not user configurable (may be it is possible > in V9 but no documentation ) . > In draft-ietf-ipfix-architecture-02.txt it list 3 examples in > section 3 , it is not clear/documented how netflow could implement > example 2 and 3 . Let me take the examples: 2. one or more characteristics of the packet itself (e.g. number of MPLS labels, etc...) 3. one or more of fields derived from packet treatment (e.g. next hop IP address, the output interface, etc...) Regarding example 2, NetFlow MPLS aware reports information about the labels http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120limit/120s/120s24/fsmnf24.htm Regarding example 3, NetFlow reports the IGP next hop and the output interface. Anyway, these are just examples. It's difficult to find a generic definition. I don't thinkk this IP traffic flow definition mandates that the function F can be configurable on the exporting process. Otherwise I'm sure a sentence about the subject containing a MUST/SHOULD/MAY would have been specified somewhere (for example section 4). When you speak about the function F, I think that you refer to the section "4. Distinguishing Flows" And I don't think that we require a flexible configuration of flow keys in there. We standardize the IP Flow Information Export, not the metering process. But anyway, NetFlow can distinguish all flows by all the MUST in section 4. Regarding the NetFlow aggregations you spoke about, that's right that the function F is not fully configurable but you can anyway choose from 11 different aggregations, which means basically eleven extra F functions. > > > 2- Metering procces (3.1.3) [2.3] > in [2.3] their is a requirement to apply sampling and > classification more than once . > netflow metering process is not able to do this ( it could be seen > that the agregation feature could achieve the same outcome but this is > only true > if the user is able to define his own agregation schema and option to > include function "F" in the agregation definition ) I can understand where you deduce this requirement from: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reqs-08.txt, section 2.3 "The sampling function and the classifying function may be applied more than once with different parameters." That's right that NetFlow doesn't allow that right now for the sampling; it does for the classification. But anway: - we don't try to standardize the metering process. IPFIX stands for IP Flow Information eXport - this is a "may" requirement - two sampling functions can be seen as a more complex single sampling function, that will not changed anything regarding the export protocol. two classification functions can been as a more complex single classification function, that will not changed anything regarding export protocol. > > > 3- Application requiring IP flow information [3] (3.2) > For "usage based accounting" ,is it assumed that netflow running > on top of SCTP or it will remain over UDP . > If the later : so Netflow can not staisfy the need/requirement for > "usage based accounting " application . We have customers using NetFlow for usage-based billing. If you plan carefully your private Data Communication Network in terms of bandwith, it will work fine! Anyway, UDP has discussed a long time ago and is not a valid solution, unless we rebuild the congestion awareness in the IPFIX protocol... I don't think this is a good idea. So let's forget about UDP! Don't forget that SCTP is evaluated as transport protocol for NetFlow. > > > 4-Distinguishing Flow > > A-by interfaces (3.3.1) [4.1] > the requirement call to distinguish packet by "output interface " . > "egress Netflow" is only applicable if the packet arrive from MPLS > enabled interface ,if the packet arrive from an IP interface it will not > be counted in the flow so this is a LIMITATION . > also ,say we are interseted to meter flow going out of interface > ifindex=3 : not clear how we could config netflow to do this . What you refer is "MPLS egress netflow": http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120limit/120st/120st10/egress.htm You are correct about your limitations. We have also "output sampled netflow": http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120limit/120s/120s24/12soutfl.htm you specify this one for an outgoing interface Note that, even if you use normal ingress netflow, you still have the output ifIndex populated. So you can do the accounting per output ifIndex if you enabled netflow on all incoming interfaces. Finally, don't forget that there are 2 "or" in the following sentence from draft-ietf-ipfix-reqs-08.txt "4.1. Interfaces The metering process MUST be able to separate flows by the incoming interface or by the outgoing interface or by both of them." > > B- by IP header fields [4.2] (3.3.2) > in [4.2] separation is MUST by prefix match . (3.3.2) did not > addressed this point . > Netflow could agregate by prefix match (from the routing table ) > and some granuality using "minimum prefix" cmmands but still > their is no way a user could specify a flow based on say 10.1/16 . Again, nothing mandates that you must be able configure the prefix yourself in the metering process. You come back to the point about the F function in the IP traffic flow that you would like to create yourself. Note: you will have to wait a little bit more for NetFlow to have the functionality that you want. > C- by Mpls (3.3.4) [4.4] > Unable to find a single cisco documentation describing this > fearure so how it is Total compliance . > if it is supported by cisco so they need to release the > documentation even a draft version . http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120limit/120s/120s24/fsmnf24.htm > > > 5- Information Model [6.1] (3.5.1) > A- For "if protocol type is ICMP: ICMP type and code" , it is not > addressed in (3.5.1) My draft was based on the req-06 This comment was inserted in req-07. Thanks, I will correct that. Anway we are compliant! > > B- For "packet counter" ,it is defined in [6.1] as " if a packet is > fragmented ,each fragment is counted as an individual packet" > in (3.5.1) it is indicated as Total compliance , unable to find a > cisco doc which describe/state that fragmented packet is > counted in the flow . This is not described anywhere. I just asked the NetFlow Developper for confirmation. If you really want a document on the web for that, I will put it on my list of to-do-things. > > C- for MPLS , unable to locate field type defined for MPLS label or > FEC in "Cisco IOS NetFlow V9 Flow record Format White paper" neither > in draft-bclaise-netflow-9-00.txt nor in > draft-gsadasiv-ipfix-proposal-00.txt . > again ,cisco need to open it's hand/disclose ongoing > extention to netflow . See the previous about MPLS aware NetFlow. > > > 6- Configuration for metering process [7.1] (3.6.1) > [7.1] call for "specification of flows to be metered" . (3.6.1) > claim Total compliance despite unable to locate cisco doc which > specify how a user ( in term of ios cmds ) could specify a flow . When defining the different aggregations, you implicitely define new flows. Again here, I know what you are after. The flow keys configuration to create your own F function; I answered that one before. Regards, Benoit. --------------050205030204020802020103 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,

[Sorry for the late reply. I haven't had much time to dedicate to IPFIX recently]
Thanks for the feedback.
Here are the answers to the NetFlow specific remarks.

Hi

Just few comments from average knowledge user

Note :  reference to draft-claise-ipfix-eval-netflow-03.txt is between ( ) , reference to draft-ietf-ipfix-reqs-07-txt is between [ ]

YYY- For netflow evaluation

1- IP Traffic flow (3.1.1) [2.1]
     not clear how it is Total Compliance . in netflow the flow definition is fixed .
     Their is no possibility to have function "F" to define a flow .  agregation schema is not user configurable (may be it is possible
     in V9 but no documentation )  .
    In draft-ietf-ipfix-architecture-02.txt it list 3 examples in section 3 , it is not clear/documented  how netflow could implement example 2 and 3 . 
Let me take the examples:

     2. one or more characteristics of the packet itself (e.g. number
        of MPLS labels, etc...)

     3. one or more of fields derived from packet treatment (e.g. next
        hop IP address, the output interface, etc...)

Regarding example 2, NetFlow MPLS aware reports information about the labels
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120limit/120s/120s24/fsmnf24.htm
Regarding example 3, NetFlow reports the IGP next hop and the output interface. 
Anyway, these are just examples. It's difficult to find a generic definition.

I don't thinkk this IP traffic flow definition mandates that the function F can be configurable on the exporting process.
Otherwise I'm sure a sentence about the subject containing a MUST/SHOULD/MAY would have been specified somewhere (for example section 4).

When you speak about the function F, I think that you refer to the section "4.  Distinguishing Flows"
And I don't think that we require a flexible configuration of flow keys in there.
We standardize the IP Flow Information Export, not the metering process.
But anyway, NetFlow can distinguish all flows by all the MUST in section 4.

Regarding the NetFlow aggregations you spoke about, that's right that the function F is not fully configurable but you can anyway choose from 11 different aggregations, which means basically eleven extra F functions.


2- Metering procces (3.1.3) [2.3]
   in [2.3] their is a requirement to apply sampling and classification more than once .
  netflow metering process is not able to do this ( it could be seen that the agregation feature could achieve the same outcome but this is only true
 if the user is able to define his own agregation schema and option to include function "F" in the agregation definition ) 
I can understand where you deduce this requirement from:
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reqs-08.txt, section 2.3
   "The sampling function and the classifying function may be applied
   more than once with different parameters."
That's right that NetFlow doesn't allow that right now for the sampling; it does for the classification. 
But anway:
- we don't try to standardize the metering process. IPFIX stands for IP Flow Information eXport
- this is a "may" requirement 
- two sampling functions can be seen as a more complex single sampling function, that will not changed anything regarding the export protocol.
  two classification functions can been as a more complex single classification function, that will not changed anything regarding export protocol.


3- Application requiring IP flow information [3] (3.2)
    For "usage based accounting" ,is it assumed that netflow running on top of SCTP or it will remain over UDP .
    If the later : so Netflow can not staisfy the need/requirement for "usage based accounting " application . 
We have customers using NetFlow for usage-based billing. If you plan carefully your private Data Communication Network in terms of bandwith, it will work fine!
Anyway, UDP has discussed a long time ago and is not a valid solution, unless we 
rebuild the congestion awareness in the IPFIX protocol... I don't think 
this is a good idea. So let's forget about UDP!
Don't forget that SCTP is evaluated as transport protocol for NetFlow.


4-Distinguishing Flow

  A-by interfaces (3.3.1) [4.1]
   the requirement call to distinguish packet by "output interface " .
  "egress Netflow" is only  applicable if the packet arrive from MPLS enabled interface ,if the packet arrive from an IP interface it will not
    be counted in the flow so this is a LIMITATION .
     also ,say we are interseted to meter flow going out of interface ifindex=3 : not clear how we could config netflow to do this .
What you refer is "MPLS egress netflow":
    http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120limit/120st/120st10/egress.htm
    You are correct about your limitations.
We have also "output sampled netflow":
    http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120limit/120s/120s24/12soutfl.htm
    you specify this one for an outgoing interface

Note that, even if you use normal ingress netflow, you still have the output ifIndex populated. So you can do the accounting per output ifIndex if you enabled netflow on all incoming interfaces.

Finally, don't forget that there are 2 "or" in the following sentence from draft-ietf-ipfix-reqs-08.txt
"4.1.  Interfaces

   The metering process MUST be able to separate flows by the incoming
   interface or by the outgoing interface or by both of them."

 B- by IP header fields [4.2] (3.3.2)
      in [4.2] separation is MUST by prefix match . (3.3.2) did not addressed this point .
      Netflow could agregate by prefix match (from the routing table ) and some granuality using "minimum prefix" cmmands but still
     their is no way a user could specify a flow based on say 10.1/16 .
Again, nothing mandates that you must be able configure the prefix yourself in the metering process.
You come back to the point about the F function in the IP traffic flow that you would like to create yourself.
Note: you will have to wait a little bit more for NetFlow to have the functionality that you want.
C- by Mpls (3.3.4) [4.4]
     Unable to find a single cisco documentation describing this fearure  so how it is Total compliance .
      if it is supported by cisco so they need to release the documentation even a draft version . 
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120limit/120s/120s24/fsmnf24.htm


5- Information Model [6.1] (3.5.1)
   A- For "if protocol type is ICMP: ICMP type and code" , it is not addressed in (3.5.1)
My draft was based on the req-06
This comment was inserted in req-07.
Thanks, I will correct that. Anway we are compliant!

   B- For "packet counter" ,it is defined in [6.1] as " if a packet is fragmented ,each fragment is counted as an individual packet"
   in (3.5.1) it is indicated as Total compliance , unable to find a cisco doc which describe/state that fragmented packet is
   counted in the flow . 
This is not described anywhere.
I just asked the NetFlow Developper for confirmation.
If you really want a document on the web for that, I will put it on my list of to-do-things.

   C- for MPLS , unable to locate field type defined for MPLS label or FEC in "Cisco IOS NetFlow V9 Flow record Format White paper" neither
        in draft-bclaise-netflow-9-00.txt nor in draft-gsadasiv-ipfix-proposal-00.txt .
        again ,cisco need to open it's hand/disclose  ongoing extention to netflow .
See the previous about MPLS aware NetFlow.


6- Configuration for metering process [7.1] (3.6.1)
    [7.1] call for "specification of flows to be metered" . (3.6.1) claim Total compliance despite unable to locate cisco doc which
    specify how a user ( in term of ios cmds ) could specify a flow .
When defining the different aggregations, you implicitely define new flows.
Again here, I know what you are after. The flow keys configuration to create your own F function; I answered that one before.

Regards, Benoit.


--------------050205030204020802020103-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Feb 3 13:02:44 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15220 for ; Mon, 3 Feb 2003 13:02:43 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18fkfM-0006ep-00 for ipfix-list@mil.doit.wisc.edu; Mon, 03 Feb 2003 11:45:56 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18fkfK-0006eV-00 for ipfix@net.doit.wisc.edu; Mon, 03 Feb 2003 11:45:54 -0600 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id h13HjlR66171 for ; Mon, 3 Feb 2003 18:45:47 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [10.1.1.128] (n-quittek.office [10.1.1.128]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 52CF588775 for ; Mon, 3 Feb 2003 19:51:03 +0100 (CET) Date: Mon, 03 Feb 2003 18:45:43 +0100 From: Juergen Quittek To: ipfix@net.doit.wisc.edu Subject: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-08.txt Message-ID: <38890972.1044297943@[10.1.1.128]> In-Reply-To: <200302031144.GAA03391@ietf.org> References: <200302031144.GAA03391@ietf.org> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Dear all, Let me give you an overview of the applied changes compared to version -07: 1. Replace in Section "2.1. IP Traffic Flow" in item 1., line 3: "RTP header fields" by "RTP header fields [RFC1889]" 2. Append to 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." 3. Move in section 6.1 "Information Model" item "7. if protocol type is ICMP: ICMP type and code" from the list of MUST attributes to the list of SHOULD attributes. Now it is item 17. 4. Replace the entire section "6.3.2. Reliability" by "Loss of flow records during the data transfer from the exporting process to the collecting process MUST be indicated at the collecting process. This indication MUST allow the collecting process to gauge the number of flow records lost. Possible reasons for flow records loss include but is not limited to: 1. Metering process limitations: lack of memory, processing power, etc. These limitations are already covered in section 5.1. 2. Exporting process limitations: lack of memory, processing power, etc. 3. Data transfer problems: packets that carry flow records sent from the exporting process to the collecting process, are dropped by the network. Examples are connection failures, congestions in combination with an unreliable transport protocol, etc. 4. Collecting process limitations: it may be experiencing congestion and not able to buffer new flows records. 5. Operation and Maintenance: the collecting process is taken down for maintenance or other administrative purposes." Please note that if an unreliable transport protocol is used, reliability can be provided by higher layers. In such a case only lack of overall reliability MUST be indicated. For example reordering could be dealt with by adding a sequence number to each packet. The data transfer between exporting process and collecting process MUST be open to reliability extensions including at least - retransmission of lost flow records, - detection of disconnection and fail-over, and - acknowledgement of flow records by the collecting process. This extensibility MAY be used to provide additional reliability." 5. Add to References: "[RFC1889] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996." 6. Update of the Acknowledgements section Cheers, Juergen -- Internet-Drafts@ietf.org wrote on 03 February 2003 06:44 -0500: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IP Flow Information Export Working Group of the IETF. > > Title : Requirements for IP Flow Information Export > Author(s) : J. Quittek et al. > Filename : draft-ietf-ipfix-reqs-08.txt > Pages : 29 > Date : 2003-1-31 > > This memo defines requirements for the export of measured IP flow > information out of routers, traffic measurement probes and > middleboxes. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reqs-08.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-ipfix-reqs-08.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-ipfix-reqs-08.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Feb 3 21:21:39 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27435 for ; Mon, 3 Feb 2003 21:21:38 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18fsQw-0002ck-00 for ipfix-list@mil.doit.wisc.edu; Mon, 03 Feb 2003 20:03:34 -0600 Received: from mailhost2.auckland.ac.nz ([130.216.1.4]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18fsQu-0002cW-00 for ipfix@net.doit.wisc.edu; Mon, 03 Feb 2003 20:03:32 -0600 Received: from mailhost.auckland.ac.nz (IDENT:mirapoint@mailhost [130.216.191.61]) by mailhost2.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id PAA21979 for ; Tue, 4 Feb 2003 15:03:25 +1300 (NZDT) Received: from localhost (hotlava.auckland.ac.nz [130.216.191.123]) by mailhost.auckland.ac.nz (Mirapoint Messaging Server MOS 3.3.2-CR) with ESMTP id AMN72855; Tue, 4 Feb 2003 15:03:24 +1300 (NZDT) Received: from nebbiolo.itss.auckland.ac.nz (nebbiolo.itss.auckland.ac.nz [130.216.4.167]) by hotlava.auckland.ac.nz (Horde) with HTTP for ; Tue, 4 Feb 2003 15:03:24 +1300 Message-ID: <1044324204.071e35ce8d835@hotlava.auckland.ac.nz> Date: Tue, 4 Feb 2003 15:03:24 +1300 From: Nevil Brownlee To: ipfix@net.doit.wisc.edu Subject: [ipfix] WG Last Call for Requirements I-D References: <1044304925.3c5cf7fc69f03@hotlava.auckland.ac.nz> <3120887.1044311390@[10.1.1.26]> In-Reply-To: <3120887.1044311390@[10.1.1.26]> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-Originating-IP: 130.216.4.167 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit 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:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Feb 6 10:07:02 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20565 for ; Thu, 6 Feb 2003 10:07:02 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18gnKk-0003FS-00 for ipfix-list@mil.doit.wisc.edu; Thu, 06 Feb 2003 08:48:58 -0600 Received: from [64.95.122.60] (helo=RS-SC-EXC4.rs.riverstonenet.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18gnKi-0003FL-00 for ipfix@net.doit.wisc.edu; Thu, 06 Feb 2003 08:48:56 -0600 Received: from riverstonenet.com ([134.141.176.88]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 6 Feb 2003 06:48:54 -0800 Message-ID: <3E4275DC.EDDA4E12@riverstonenet.com> Date: Thu, 06 Feb 2003 09:49:00 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10 i686) X-Accept-Language: en MIME-Version: 1.0 To: Nevil Brownlee CC: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] WG Last Call for Requirements I-D References: <1044304925.3c5cf7fc69f03@hotlava.auckland.ac.nz> <3120887.1044311390@[10.1.1.26]> <1044324204.071e35ce8d835@hotlava.auckland.ac.nz> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Feb 2003 14:48:55.0233 (UTC) FILETIME=[DF50F310:01C2CDEE] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit 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 Nevil Brownlee wrote: > > 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:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Feb 6 10:25:07 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21686 for ; Thu, 6 Feb 2003 10:25:06 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18gnaf-0003ag-00 for ipfix-list@mil.doit.wisc.edu; Thu, 06 Feb 2003 09:05:25 -0600 Received: from [64.95.122.60] (helo=RS-SC-EXC4.rs.riverstonenet.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18gnad-0003aa-00 for ipfix@net.doit.wisc.edu; Thu, 06 Feb 2003 09:05:23 -0600 Received: from riverstonenet.com ([134.141.176.88]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 6 Feb 2003 07:05:22 -0800 Message-ID: <3E4279B7.5C0FB375@riverstonenet.com> Date: Thu, 06 Feb 2003 10:05:27 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10 i686) X-Accept-Language: en MIME-Version: 1.0 To: Nevil Brownlee CC: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] WG Last Call for Requirements I-D References: <1044304925.3c5cf7fc69f03@hotlava.auckland.ac.nz> <3120887.1044311390@[10.1.1.26]> <1044324204.071e35ce8d835@hotlava.auckland.ac.nz> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Feb 2003 15:05:22.0949 (UTC) FILETIME=[2C0A7350:01C2CDF1] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit 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 Nevil Brownlee wrote: > > 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:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Feb 6 10:46:45 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23043 for ; Thu, 6 Feb 2003 10:46:45 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18go2i-0004Ev-00 for ipfix-list@mil.doit.wisc.edu; Thu, 06 Feb 2003 09:34:24 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18go2h-0004Ek-00 for ipfix@net.doit.wisc.edu; Thu, 06 Feb 2003 09:34:23 -0600 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id h16FY4R20343; Thu, 6 Feb 2003 16:34:04 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [10.1.1.128] (n-quittek.office [10.1.1.128]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 59F03892E3; Thu, 6 Feb 2003 17:38:52 +0100 (CET) Date: Thu, 06 Feb 2003 16:34:01 +0100 From: Juergen Quittek To: calato@riverstonenet.com, Nevil Brownlee Cc: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] WG Last Call for Requirements I-D Message-ID: <24065173.1044549241@[10.1.1.128]> In-Reply-To: <3E4279B7.5C0FB375@riverstonenet.com> References: <3E4279B7.5C0FB375@riverstonenet.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Paul, -- calato@riverstonenet.com wrote on 06 February 2003 10:05 -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. 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 > 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 > > > > Nevil Brownlee wrote: >> >> 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:majordomo@net.doit.wisc.edu and say "help" in message body >> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >> "unsubscribe ipfix" in message body >> Archive http://ipfix.doit.wisc.edu/archive/ > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Feb 6 17:52:30 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07679 for ; Thu, 6 Feb 2003 17:52:30 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18guei-0005gy-00 for ipfix-list@mil.doit.wisc.edu; Thu, 06 Feb 2003 16:38:04 -0600 Received: from [64.95.122.60] (helo=RS-SC-EXC4.rs.riverstonenet.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18gueg-0005gr-00 for ipfix@net.doit.wisc.edu; Thu, 06 Feb 2003 16:38:02 -0600 Received: from riverstonenet.com ([134.141.176.88]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 6 Feb 2003 14:38:00 -0800 Message-ID: <3E42E3CD.16111206@riverstonenet.com> Date: Thu, 06 Feb 2003 17:38:05 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10 i686) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Quittek CC: Nevil Brownlee , ipfix@net.doit.wisc.edu Subject: Re: [ipfix] WG Last Call for Requirements I-D References: <3E4279B7.5C0FB375@riverstonenet.com> <24065173.1044549241@[10.1.1.128]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Feb 2003 22:38:01.0343 (UTC) FILETIME=[67B480F0:01C2CE30] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Juergen Quittek wrote: > > Paul, > > -- calato@riverstonenet.com wrote on 06 February 2003 10:05 -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. > > I have two questions: > > Where exactly in the rquirements draft do you suggest to insert this text? At the end of section 4 (before 4.1). > > 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? 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. > > Cheers, > > Juergen > > > 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 > > > > > > > > Nevil Brownlee wrote: > >> > >> 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:majordomo@net.doit.wisc.edu and say "help" in message body > >> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > >> "unsubscribe ipfix" in message body > >> Archive http://ipfix.doit.wisc.edu/archive/ > > > > -- > > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > "unsubscribe ipfix" in message body > > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Feb 7 12:06:35 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15636 for ; Fri, 7 Feb 2003 12:06:34 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18hBgQ-00059q-00 for ipfix-list@mil.doit.wisc.edu; Fri, 07 Feb 2003 10:48:58 -0600 Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18hBgO-00059k-00 for ipfix@net.doit.wisc.edu; Fri, 07 Feb 2003 10:48:56 -0600 Received: from cisco.com (bclaise-isdn-home5.cisco.com [10.49.4.222]) by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id h17GexI15781; Fri, 7 Feb 2003 17:41:00 +0100 (CET) Message-ID: <3E43E19B.7050203@cisco.com> Date: Fri, 07 Feb 2003 17:40:59 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: calato@riverstonenet.com CC: Juergen Quittek , Nevil Brownlee , ipfix@net.doit.wisc.edu Subject: Re: [ipfix] WG Last Call for Requirements I-D References: <3E4279B7.5C0FB375@riverstonenet.com> <24065173.1044549241@[10.1.1.128]> <3E42E3CD.16111206@riverstonenet.com> In-Reply-To: <3E42E3CD.16111206@riverstonenet.com> Content-Type: multipart/alternative; boundary="------------070909020403010100000508" Precedence: bulk Sender: majordomo listserver --------------070909020403010100000508 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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. >Juergen Quittek wrote: > > >>Paul, >> >>-- calato@riverstonenet.com wrote on 06 February 2003 10:05 -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. >>> >>> >>I have two questions: >> >>Where exactly in the rquirements draft do you suggest to insert this text? >> >> > > At the end of section 4 (before 4.1). > > > >>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? >> >> > > 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. > > > > >>Cheers, >> >> Juergen >> >> >> >>>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 >>> >>> >>> >>>Nevil Brownlee wrote: >>> >>> >>>>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:majordomo@net.doit.wisc.edu and say "help" in message body >>>>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>>>"unsubscribe ipfix" in message body >>>>Archive http://ipfix.doit.wisc.edu/archive/ >>>> >>>> >>>-- >>>Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body >>>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>>"unsubscribe ipfix" in message body >>>Archive http://ipfix.doit.wisc.edu/archive/ >>> >>> > >-- >Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body >Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >"unsubscribe ipfix" in message body >Archive http://ipfix.doit.wisc.edu/archive/ > > --------------070909020403010100000508 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 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.


Juergen Quittek wrote:
  
Paul,

-- calato@riverstonenet.com wrote on 06 February 2003 10:05 -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.
      
I have two questions:

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

	At the end of section 4 (before 4.1).

  
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?
    

	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.


  
Cheers,

    Juergen

    
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



Nevil Brownlee wrote:
      
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:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/
        
--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/
      

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/

--------------070909020403010100000508-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Feb 7 12:31:43 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16177 for ; Fri, 7 Feb 2003 12:31:42 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18hC7j-0005j3-00 for ipfix-list@mil.doit.wisc.edu; Fri, 07 Feb 2003 11:17:11 -0600 Received: from [64.95.122.60] (helo=RS-SC-EXC4.rs.riverstonenet.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18hC7i-0005iw-00 for ipfix@net.doit.wisc.edu; Fri, 07 Feb 2003 11:17:10 -0600 Received: from riverstonenet.com ([134.141.176.88]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 7 Feb 2003 09:17:08 -0800 Message-ID: <3E43EA1A.2E16258F@riverstonenet.com> Date: Fri, 07 Feb 2003 12:17:14 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10 i686) X-Accept-Language: en MIME-Version: 1.0 To: Benoit Claise CC: Juergen Quittek , Nevil Brownlee , ipfix@net.doit.wisc.edu Subject: Re: [ipfix] WG Last Call for Requirements I-D References: <3E4279B7.5C0FB375@riverstonenet.com> <24065173.1044549241@[10.1.1.128]> <3E42E3CD.16111206@riverstonenet.com> <3E43E19B.7050203@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Feb 2003 17:17:08.0721 (UTC) FILETIME=[BEA94610:01C2CECC] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit > Benoit Claise wrote: > > 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? 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. > how many set of defined properties do you have? 1? > > Regards, Benoit. > > > Juergen Quittek wrote: > > > > > >> Paul, > >> > >> -- calato@riverstonenet.com wrote on 06 February 2003 10:05 -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. > >> > > >> > > >> I have two questions: > >> > >> Where exactly in the rquirements draft do you suggest to insert > >> this text? > >> > >> > > At the end of section 4 (before 4.1). > > > > > > > >> 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? > >> > >> > > 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. > > > > > > > > > >> Cheers, > >> > >> Juergen > >> > >> > >> > >> > 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 > >> > > >> > > >> > > >> > Nevil Brownlee wrote: > >> > > >> > > >> >> 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:majordomo@net.doit.wisc.edu and say "help" > >> >> in message body > >> >> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > >> >> "unsubscribe ipfix" in message body > >> >> Archive http://ipfix.doit.wisc.edu/archive/ > >> >> > >> >> > >> > -- > >> > Help mailto:majordomo@net.doit.wisc.edu and say "help" in > >> > message body > >> > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > >> > "unsubscribe ipfix" in message body > >> > Archive http://ipfix.doit.wisc.edu/archive/ > >> > > >> > > > -- > > Help mailto:majordomo@net.doit.wisc.edu and say "help" in > > message body > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > "unsubscribe ipfix" in message body > > Archive http://ipfix.doit.wisc.edu/archive/ > > > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Feb 10 19:58:55 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02912 for ; Mon, 10 Feb 2003 19:58:55 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18iOdc-0003Nd-00 for ipfix-list@mil.doit.wisc.edu; Mon, 10 Feb 2003 18:51:04 -0600 Received: from [64.95.122.60] (helo=RS-SC-EXC4.rs.riverstonenet.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18iOdZ-0003NW-00 for ipfix@net.doit.wisc.edu; Mon, 10 Feb 2003 18:51:02 -0600 Received: from riverstonenet.com ([134.141.172.71]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 10 Feb 2003 16:51:00 -0800 Message-ID: <3E4848FF.979B40CF@riverstonenet.com> Date: Mon, 10 Feb 2003 19:51:11 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10 i686) X-Accept-Language: en MIME-Version: 1.0 To: ipfixx Subject: [ipfix] Flow key Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Feb 2003 00:51:01.0072 (UTC) FILETIME=[A5A58500:01C2D167] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit After a conversation with Benoit there was general agreement that a couple examples would be helpful. So here is the updated text. Feel free to comment on the examples or suggest other ones (note - the first paragraph is the same as before). 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. Multiple flow keys may be in use, for example, if a metering process classifies a packet using two different flows keys, say K1 = {src-ip, dst-ip} and K2 = {src-AS , dst-AS} then there can be two separate flows reported. One containing the src-ip and dst-ip and the second containing the src-AS and the dst-AS. If on the other hand if a metering process distinguishes flows based on src-ip, dst-ip, src-port, dst-port, but the metering process then aggregates and reports one flow using src-as, dst-as as the flow key then only the latter flow and flow key need be reported. The last example, and likely the most common, is vendor A reports flows based on src-ip, dst-ip, src-port, dst-port and vendor B reports based on src-ip, dst-ip, src-port, dst-port and DSCP. If both vendors report flow key information, then both flows can be appropriately processed. -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Feb 11 08:22:44 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03958 for ; Tue, 11 Feb 2003 08:22:43 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18ia96-00041s-00 for ipfix-list@mil.doit.wisc.edu; Tue, 11 Feb 2003 07:08:20 -0600 Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18ia94-00041k-00 for ipfix@net.doit.wisc.edu; Tue, 11 Feb 2003 07:08:18 -0600 Received: from cisco.com (dhcp-peg3-vl30-144-254-7-224.cisco.com [144.254.7.224]) by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id h1BD0cI01442; Tue, 11 Feb 2003 14:00:39 +0100 (CET) Message-ID: <3E48F3F6.7080800@cisco.com> Date: Tue, 11 Feb 2003 14:00:38 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: calato , ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Flow key References: <3E4848FF.979B40CF@riverstonenet.com> In-Reply-To: <3E4848FF.979B40CF@riverstonenet.com> Content-Type: multipart/alternative; boundary="------------050001090401000403000708" Precedence: bulk Sender: majordomo listserver --------------050001090401000403000708 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Paul, A few minor comments. See inline. >After a conversation with Benoit there was general agreement >that a couple examples would be helpful. So here >is the updated text. Feel free to comment on the examples >or suggest other ones (note - the first paragraph is >the same as before). > > 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. > > Multiple flow keys may be in use, for example, if a metering > process classifies a packet using two different flows keys, > say K1 = {src-ip, dst-ip} and K2 = {src-AS , dst-AS} then > there can be two separate flows reported. One containing > flow _records _reported. > > the src-ip and dst-ip and the second containing the src-AS > and the dst-AS. > > If on the other hand if a metering process distinguishes > flows based on src-ip, dst-ip, src-port, dst-port, but > the metering process then aggregates and reports one flow > then aggregates_ (the classifying function is applied more than once, as foreseen in the metering process terminology _section) and reports _flow records_ > using src-as, dst-as as the flow key then only the latter > flow and flow key need be reported. > flow _record _and ... Regards, Benoit. > > The last example, and likely the most common, is vendor > A reports flows based on src-ip, dst-ip, src-port, dst-port > and vendor B reports based on src-ip, dst-ip, src-port, > dst-port and DSCP. If both vendors report flow key > information, then both flows can be appropriately processed. > >-- >Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body >Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >"unsubscribe ipfix" in message body >Archive http://ipfix.doit.wisc.edu/archive/ > > --------------050001090401000403000708 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Paul,

A few minor comments.
See inline.

After a conversation with Benoit there was general agreement
that a couple examples would be helpful. So here
is the updated text. Feel free to comment on the examples
or suggest other ones (note - the first paragraph is 
the same as before).

          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.

          Multiple flow keys may be in use, for example, if a metering 
          process classifies a packet using two different flows keys, 
          say K1 = {src-ip, dst-ip} and K2 = {src-AS , dst-AS} then 
          there can be two separate flows reported. One containing
flow records reported.
 
          the src-ip and dst-ip and the second containing the src-AS 
          and the dst-AS.

          If on the other hand if a metering process distinguishes
          flows based on src-ip, dst-ip, src-port, dst-port, but 
          the metering process then aggregates and reports one flow
then aggregates (the classifying function is applied more than once, as foreseen in the metering process terminology section)  and reports flow records 
          using src-as, dst-as as the flow key then only the latter
          flow and flow key need be reported.
flow record and ...

Regards, Benoit.

          
          The last example, and likely the most common, is vendor
          A reports flows based on src-ip, dst-ip, src-port, dst-port
          and vendor B reports based on src-ip, dst-ip, src-port,
	  dst-port  and DSCP. If both vendors report flow key
	  information, then both flows can be appropriately processed.

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/

--------------050001090401000403000708-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Feb 11 15:25:26 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17606 for ; Tue, 11 Feb 2003 15:25:26 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18igfl-0004o0-00 for ipfix-list@mil.doit.wisc.edu; Tue, 11 Feb 2003 14:06:29 -0600 Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18igfj-0004nr-00 for ipfix@net.doit.wisc.edu; Tue, 11 Feb 2003 14:06:27 -0600 Received: from cisco.com (bclaise-isdn-home5.cisco.com [10.49.4.222]) by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id h1BK6JI04841; Tue, 11 Feb 2003 21:06:20 +0100 (CET) Message-ID: <3E4957BB.3070604@cisco.com> Date: Tue, 11 Feb 2003 21:06:19 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nevil Brownlee CC: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] WG Last Call for Requirements I-D References: <1044304925.3c5cf7fc69f03@hotlava.auckland.ac.nz> <3120887.1044311390@[10.1.1.26]> <1044324204.071e35ce8d835@hotlava.auckland.ac.nz> In-Reply-To: <1044324204.071e35ce8d835@hotlava.auckland.ac.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit 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. >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:majordomo@net.doit.wisc.edu and say "help" in message body >Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >"unsubscribe ipfix" in message body >Archive http://ipfix.doit.wisc.edu/archive/ > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Feb 12 08:53:04 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02601 for ; Wed, 12 Feb 2003 08:53:04 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18ix8R-0003ql-00 for ipfix-list@mil.doit.wisc.edu; Wed, 12 Feb 2003 07:41:11 -0600 Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18ix8P-0003qc-00 for ipfix@net.doit.wisc.edu; Wed, 12 Feb 2003 07:41:09 -0600 Received: from cisco.com (dhcp-ams-cam-vl12-144-254-196-166.cisco.com [144.254.196.166]) by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id h1CDf2I14506; Wed, 12 Feb 2003 14:41:03 +0100 (CET) Message-ID: <3E4A4EED.1090708@cisco.com> Date: Wed, 12 Feb 2003 14:41:01 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nevil Brownlee , Dave Plonka CC: ipfix@net.doit.wisc.edu Subject: [ipfix] ipfix_evaluation_report.pdf References: <1044304925.3c5cf7fc69f03@hotlava.auckland.ac.nz> <3120887.1044311390@[10.1.1.26]> <1044324204.071e35ce8d835@hotlava.auckland.ac.nz> In-Reply-To: <1044324204.071e35ce8d835@hotlava.auckland.ac.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit 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. -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Feb 12 09:10:50 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02881 for ; Wed, 12 Feb 2003 09:10:50 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18ixQi-0004Io-00 for ipfix-list@mil.doit.wisc.edu; Wed, 12 Feb 2003 08:00:04 -0600 Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18ixQf-0004HA-00 for ipfix@net.doit.wisc.edu; Wed, 12 Feb 2003 08:00:01 -0600 Received: from cisco.com (dhcp-ams-cam-vl12-144-254-196-166.cisco.com [144.254.196.166]) by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id h1CDxoI10797; Wed, 12 Feb 2003 14:59:51 +0100 (CET) Message-ID: <3E4A5356.7070906@cisco.com> Date: Wed, 12 Feb 2003 14:59:50 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Benoit Claise CC: Nevil Brownlee , Dave Plonka , ipfix@net.doit.wisc.edu Subject: Re: [ipfix] ipfix_evaluation_report.pdf - solved References: <1044304925.3c5cf7fc69f03@hotlava.auckland.ac.nz> <3120887.1044311390@[10.1.1.26]> <1044324204.071e35ce8d835@hotlava.auckland.ac.nz> <3E4A4EED.1090708@cisco.com> In-Reply-To: <3E4A4EED.1090708@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit 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. > 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. > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in > message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Feb 13 09:56:09 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13978 for ; Thu, 13 Feb 2003 09:56:09 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18jKTq-0007Gy-00 for ipfix-list@mil.doit.wisc.edu; Thu, 13 Feb 2003 08:36:50 -0600 Received: from h65s138a81n47.user.nortelnetworks.com ([47.81.138.65] helo=zsc3s004.nortelnetworks.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18jKTo-0007Gp-00 for ipfix@net.doit.wisc.edu; Thu, 13 Feb 2003 08:36:48 -0600 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h1DEacX28945; Thu, 13 Feb 2003 06:36:39 -0800 (PST) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1LWHMT0Q>; Thu, 13 Feb 2003 06:36:38 -0800 Message-ID: <0A11633F61BD9F40B43ABCC694004F93F18D8F@zsc3c026.us.nortel.com> From: "Reinaldo Penno" To: "'Nevil Brownlee'" , ipfix@net.doit.wisc.edu Subject: RE: [ipfix] WG Last Call for Requirements I-D - Relilability Date: Thu, 13 Feb 2003 06:36:38 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D36D.5100CA5C" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2D36D.5100CA5C Content-Type: text/plain Some minor comments. 1) " Please note that if an unreliable transport protocol is used, reliability can be provided by higher layers. In such a case only lack of overall reliability MUST be indicated. For example reordering could be dealt with by adding a sequence number to each packet." Are we saying that when we use a unreliable protocol the reliability is going to be provided by higher layers AND in this case only the lack of overall reliability MUST be indicated by the ipfix protocol? Or The three sentences above are totally disconnected...i.e., the "in such case" refers to the unreliable transport and not the fact that the reliability can be provided by higher layers. I guess we mean the first option. In this case I suggest. Note that if an unreliable transport is used, only lack of overall reliability MUST be indicated. For example reordering could be dealt with by adding a sequence number to each packet. Optionally, when using an unreliable transport, the reliability can be provided by higher layers. 2) It seems to me that the phrase "This extensibility MAY be used to provide additional reliability." is not buying us anything. It seems pretty obvious that reliability extensions should used to provide reliability... Regards, Reinaldo ------_=_NextPart_001_01C2D36D.5100CA5C Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [ipfix] WG Last Call for Requirements I-D - = Relilability

Some minor comments.

1)

"
   Please note that if an unreliable = transport protocol is used,
   reliability can be provided by higher = layers. In such a case only
   lack of overall reliability MUST be = indicated. For example reordering
   could be dealt with by adding a = sequence number to each packet."

Are we saying that when we use a unreliable protocol = the reliability is going to be provided by higher layers AND in this = case only the lack of overall reliability MUST be indicated by the = ipfix protocol?

Or

The three sentences above are totally = disconnected...i.e., the "in such case" refers to the = unreliable transport and not the fact that the reliability can be = provided by higher layers.

I guess we mean the first option. In this case I = suggest.

Note that if an unreliable transport is used, only = lack of overall reliability MUST be indicated. For example = reordering

could be dealt with by adding a sequence number to = each packet. Optionally, when using an unreliable transport, the = reliability can be provided by higher layers.

2)

It seems to me that the phrase "This = extensibility MAY be used to provide additional reliability." is = not buying us anything. It seems pretty obvious that reliability = extensions should used to provide reliability...

Regards,

Reinaldo

------_=_NextPart_001_01C2D36D.5100CA5C-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Feb 20 20:04:41 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05356 for ; Thu, 20 Feb 2003 20:04:40 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18m1BN-0001Ps-00 for ipfix-list@mil.doit.wisc.edu; Thu, 20 Feb 2003 18:36:53 -0600 Received: from mailhost2.auckland.ac.nz ([130.216.1.4]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18m1BK-0001Pi-00 for ipfix@net.doit.wisc.edu; Thu, 20 Feb 2003 18:36:51 -0600 Received: from mailhost.auckland.ac.nz (IDENT:mirapoint@mailhost [130.216.191.61]) by mailhost2.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id NAA15672 for ; Fri, 21 Feb 2003 13:36:48 +1300 (NZDT) Received: from localhost (hotlava.auckland.ac.nz [130.216.191.123]) by mailhost.auckland.ac.nz (Mirapoint Messaging Server MOS 3.3.2-CR) with ESMTP id ANA92580; Fri, 21 Feb 2003 13:35:26 +1300 (NZDT) Received: from dyn54.caida.org (dyn54.caida.org [192.172.226.54]) by hotlava.auckland.ac.nz (Horde) with HTTP for ; Fri, 21 Feb 2003 13:35:25 +1300 Message-ID: <1045787725.ddd58ba3f519a@hotlava.auckland.ac.nz> Date: Fri, 21 Feb 2003 13:35:25 +1300 From: Nevil Brownlee To: ipfix@net.doit.wisc.edu Subject: [ipfix] 'Requirements' WG Last Call now done MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-Originating-IP: 192.172.226.54 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hello all: The WG Last Call for the IPFIX 'Requirements' draft has now ended, many thanks to those who posted comments and small improvements. Juergen (as document editor) will incoprporate those changes, and we'll submit the draft to IESG for publication as an Informational RFC. Now we need to get the evaluation process done. I've reminded the evaluation team and advocates about updating their various drafts, bearing in mind that our 'Goals and Milestones' are aimed at making a choice of protocol at the San Francisco IETF, or at least soon after it! Anyone with suggestions for how we can proceed, do please post them to thye list! 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:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Feb 25 01:42:29 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08285 for ; Tue, 25 Feb 2003 01:42:29 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18nYbw-0004ex-00 for ipfix-list@mil.doit.wisc.edu; Tue, 25 Feb 2003 00:30:40 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18nYbs-0004ei-00 for ipfix@net.doit.wisc.edu; Tue, 25 Feb 2003 00:30:36 -0600 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id h1P6TnR08056; Tue, 25 Feb 2003 07:29:49 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [10.1.1.26] (dial02.office [10.1.1.26]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id BC79A8E558; Tue, 25 Feb 2003 07:27:30 +0100 (CET) Date: Tue, 25 Feb 2003 07:30:11 +0100 From: Juergen Quittek To: Benoit Claise , Nevil Brownlee Cc: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] WG Last Call for Requirements I-D Message-ID: <5145568.1046158210@[10.1.1.26]> In-Reply-To: <3E4957BB.3070604@cisco.com> References: <3E4957BB.3070604@cisco.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Benoit, Great to have another careful review! -- Benoit Claise wrote on 11 February 2003 21:06 +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. > ... 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). > > 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? I am not sure. Does anyone have a strong opinion on this? (Not changed yet.) > 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. fixed. > 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 I think "modelling" is UK english, while "modeling" is US English. Therefore, I left it unchanged. > 4. > In section "9. Special Device Considerations" > headers are transfered from observation points to metering processes, > -> transferred Yes, this is a typo in both, UK and US English. Fixed. > 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. Done. > 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 Done. > 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. Yes. Removed. > 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. Fixed. > 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 Fixed. > Regards, Benoit. > > >> 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:majordomo@net.doit.wisc.edu and say "help" in message body >> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >> "unsubscribe ipfix" in message body >> Archive http://ipfix.doit.wisc.edu/archive/ >> >> > > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Feb 25 01:49:48 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08457 for ; Tue, 25 Feb 2003 01:49:48 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18nYlT-0004qN-00 for ipfix-list@mil.doit.wisc.edu; Tue, 25 Feb 2003 00:40:31 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18nYlR-0004qF-00 for ipfix@net.doit.wisc.edu; Tue, 25 Feb 2003 00:40:29 -0600 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id h1P6eSR08195; Tue, 25 Feb 2003 07:40:28 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [10.1.1.26] (dial02.office [10.1.1.26]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id B25798E37D; Tue, 25 Feb 2003 07:38:10 +0100 (CET) Date: Tue, 25 Feb 2003 07:40:52 +0100 From: Juergen Quittek To: Carter Bullard Cc: ipfix@net.doit.wisc.edu Subject: [ipfix] RE: [ipfix-eval] Re: next version of IPFIX requirements Message-ID: <5786630.1046158851@[10.1.1.26]> In-Reply-To: <5C8959A16A71B449AE793CF52FBBED6607A530@ptah.newyork.qosient.com> References: <5C8959A16A71B449AE793CF52FBBED6607A530@ptah.newyork.qosient.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Carter, Yes, I agree. Just used a slightly different phrasing: "When anonymized flow data is exported, this MUST be clearly indicated to all receiving collecting processes, such that they can distinguish anonymized data from non-anonymized data." Cheers, Juergen -- Carter Bullard wrote on 30 January 2003 23:54 -0500: > Hey Juergen, > With regard to section 6.7 Anonymization. Because > anonymization constraints/requirements have not been > described, it is important that there be some indication > that the data generated by the probe does not represent > truth. I recommend this additional text: > >> 6.7. Anonymization >> >> The exporting process MAY be capable of anonymizing source and >> destination IP addresses in flow data before exporting them. It MAY >> support anonymization of port numbers and other fields. Please note >> that anonymization is not originally an application requirement, but >> derived from general requirements for treatment of measured traffic >> data within a network. > > 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. > > I hope all see the need for this type of requirement given that > some of the applications that are envisioned for IP Flow Data > are critical applications that would require some truth assurances > in the data. While an anonymization indicator won't prevent > problems, it would help eliminate some obvious problems. > > Any suggestions on wording would be appreciated. > > > Carter > > > > >> -----Original Message----- >> From: majordomo listserver >> [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Nevil Brownlee >> Sent: Thursday, January 30, 2003 10:56 PM >> To: Juergen Quittek >> Cc: plonka@doit.wisc.edu; ipfix-eval@net.doit.wisc.edu; >> nevil@auckland.ac.nz >> Subject: [ipfix-eval] Re: next version of IPFIX requirements >> >> >> Quoting Juergen Quittek : >> >> > Hi Dave and Nevil, >> > >> > There is a new version of the IPFIX requirements. You can >> preview it at >> > >> > http://www.ibr.cs.tu-bs.de/~quittek/draft-ietf-ipfix-reqs-08.txt >> > >> > Before posting it I want to get your OK on changing the author list. >> > Following Dave's reminder on the mailing list, I checked >> the document >> > against the I-D nits. Among some minor issues, I found that >> the maximum >> > length of the author list is 5. In the last version of the >> requirements >> > the length of the list was 6. Therefore, I cut the list. >> When checking >> > the contribution of all listed authors, I found a big gap >> between the >> > first four and the remaining two authors. Therefore, I >> removed Georg and >> > KC from the author list and instead mentioned them explicitly in the >> > acknowledgements section. Additionally, I mentioned the >> names of many >> > other contributors in the acknowledgement. >> > >> > I will post the document as soon as I have your OK on this change. >> >> Good idea to check the I-D nits, we don't want little things >> like that >> to slow the RFC process ! >> >> I agree with your change to the authors list - Georg and KC came into >> the Requirements draft fairly late, as I remember. Go ahead >> and submit >> the draft, and at the same time, you'd better send a note to Georg and >> KC telling them about the change (and why we've made it). >> >> 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 >> vil@auckland >> >> ------------------------------------------------- >> This mail sent through University of Auckland >> http://www.auckland.ac.nz/ >> >> >> -- >> Help mailto:majordomo@net.doit.wisc.edu and say "help" >> in message body >> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >> "unsubscribe ipfix" in message body >> Archive http://ipfix.doit.wisc.edu/archive/ >> > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Feb 25 02:05:55 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16498 for ; Tue, 25 Feb 2003 02:05:55 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18nYts-0004zM-00 for ipfix-list@mil.doit.wisc.edu; Tue, 25 Feb 2003 00:49:12 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18nYtr-0004zH-00 for ipfix@net.doit.wisc.edu; Tue, 25 Feb 2003 00:49:11 -0600 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id h1P6n7R08298; Tue, 25 Feb 2003 07:49:07 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [10.1.1.26] (dial02.office [10.1.1.26]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 82A30873F9; Tue, 25 Feb 2003 07:46:50 +0100 (CET) Date: Tue, 25 Feb 2003 07:49:32 +0100 From: Juergen Quittek To: Reinaldo Penno , "'Nevil Brownlee'" , ipfix@net.doit.wisc.edu Subject: RE: [ipfix] WG Last Call for Requirements I-D - Relilability Message-ID: <6307089.1046159372@[10.1.1.26]> In-Reply-To: <0A11633F61BD9F40B43ABCC694004F93F18D8F@zsc3c026.us.nortel.com> References: <0A11633F61BD9F40B43ABCC694004F93F18D8F@zsc3c026.us.nortel.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Reinaldo, -- Reinaldo Penno wrote on 13 February 2003 06:36 -0800: > Some minor comments. > > 1) > > " > Please note that if an unreliable transport protocol is used, > reliability can be provided by higher layers. In such a case only > lack of overall reliability MUST be indicated. For example reordering > could be dealt with by adding a sequence number to each packet." > > Are we saying that when we use a unreliable protocol the reliability is > going to be provided by higher layers AND in this case only the lack of > overall reliability MUST be indicated by the ipfix protocol? I clarified this by replacing "In such a case" by "If reliability is provided by higher layers, " > > Or > > The three sentences above are totally disconnected...i.e., the "in such > case" refers to the unreliable transport and not the fact that the > reliability can be provided by higher layers. > > I guess we mean the first option. In this case I suggest. > > Note that if an unreliable transport is used, only lack of overall > reliability MUST be indicated. For example reordering > could be dealt with by adding a sequence number to each packet. Optionally, > when using an unreliable transport, the reliability can be provided by > higher layers. > > 2) > > It seems to me that the phrase "This extensibility MAY be used to provide > additional reliability." is not buying us anything. It seems pretty obvious > that reliability extensions should used to provide reliability... Yes, the sentence is redundant. It was just put there for clarification. Cheers, Juergen > > Regards, > > Reinaldo -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Feb 25 12:10:46 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06709 for ; Tue, 25 Feb 2003 12:10:46 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18niEA-0002wt-00 for ipfix-list@mil.doit.wisc.edu; Tue, 25 Feb 2003 10:46:46 -0600 Received: from kanfw1.ottawa.alcatel.ca ([192.75.23.69] helo=kanmx2.ca.alcatel.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 18niE7-0002wm-00 for ipfix-req@net.doit.wisc.edu; Tue, 25 Feb 2003 10:46:43 -0600 Received: (qmail 26194 invoked from network); 25 Feb 2003 16:48:50 -0000 Received: from unknown (HELO alcatel.com) (138.120.51.110) by kanmx2.ca.alcatel.com with SMTP; 25 Feb 2003 16:48:50 -0000 Message-ID: <3E5B9DF0.33FB8BAA@alcatel.com> Date: Tue, 25 Feb 2003 11:46:40 -0500 From: Mark Thibodeau X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ipfix-req@net.doit.wisc.edu Subject: [ipfix-req] Content Based Sampling Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi, I have some questions about the requirements for sampling. From requirements 8: .... 5.2. Sampling ... selection of one packet can for instance be triggered by its arrival time (time-based sampling), by its position in the flow (count-based sampling) or by the packet content (content-based sampling). .... What is meant by "content-based sampling"? Is this basically ACL filtering that tells you whether or not to monitor a flow? If it refers to ACL filtering, then I have some more questions. .... 6.1. Information Model .... 14. if sampling is used: sampling configuration .... If we are using content-based sampling, what information do we want exported with the flow? Is it basically an ACL rule identifier? Or do we want to export the entire ACL rule itself? If we need to export a rule identifier or something like that, then there is another situation which presents itself. Let's say there are multiple rules which can cause packets to be monitored. If we are also doing aggregation, there is the potential for 2 or more ACL rules to all point to the same flow record. When this flow record is exported, which rule identifier should it give? There is also another situation. An implementation could support simultaneously ACL filtering and packet sampling. For instance, only the flows that match a certain ACL rule will be monitored. However, only every 100th packet is sampled. If this combination is supported, what is the sampling configuration that is exported? Should we export the rule identifier as well as the sampling rate? Thanks, Mark -- **************************************************** * Mark Thibodeau, P Eng. * 670 RSP Development - Firmware Designer * Alcatel CID - (613) 784-5375 * Fax - (613) 599-3696 * mark.thibodeau@alcatel.com **************************************************** -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Feb 25 13:20:19 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09493 for ; Tue, 25 Feb 2003 13:20:19 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18njT6-0004gU-00 for ipfix-list@mil.doit.wisc.edu; Tue, 25 Feb 2003 12:06:16 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18njT3-0004gN-00 for ipfix@net.doit.wisc.edu; Tue, 25 Feb 2003 12:06:13 -0600 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id h1PI5UR42975; Tue, 25 Feb 2003 19:05:30 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [10.1.1.128] (n-quittek.office [10.1.1.128]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 8D9E78E98B; Tue, 25 Feb 2003 19:03:09 +0100 (CET) Date: Tue, 25 Feb 2003 19:05:56 +0100 From: Juergen Quittek To: Benoit Claise , calato , ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Flow key Message-ID: <36559830.1046199956@[10.1.1.128]> In-Reply-To: <3E48F3F6.7080800@cisco.com> References: <3E48F3F6.7080800@cisco.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Paul, I avoided the term 'flow key'. When discussing with Benoit, I found that the two of us have (both very reasonable) different understandings of this term. I think we should define this term, but we need a discussion on the list about it. Since time is pressing for the requirements, I suggest do it in the architecture document. Following the purpose of your suggestion, I added the following sentence to paragraph 3 of section 4: "But anyway, it MUST be ensured that a collecting process is able to clearly identify for each received flow record which flow key was used for distinguishing this flow from other ones." Cheers, Juergen -- Benoit Claise wrote on 11 February 2003 14:00 +0100: > Paul, > > A few minor comments. > See inline. > >> After a conversation with Benoit there was general agreement >> that a couple examples would be helpful. So here >> is the updated text. Feel free to comment on the examples >> or suggest other ones (note - the first paragraph is >> the same as before). >> >> 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. >> >> Multiple flow keys may be in use, for example, if a metering >> process classifies a packet using two different flows keys, >> say K1 = {src-ip, dst-ip} and K2 = {src-AS , dst-AS} then >> there can be two separate flows reported. One containing >> > flow _records _reported. > >> >> the src-ip and dst-ip and the second containing the src-AS >> and the dst-AS. >> >> If on the other hand if a metering process distinguishes >> flows based on src-ip, dst-ip, src-port, dst-port, but >> the metering process then aggregates and reports one flow >> > then aggregates_ (the classifying function is applied more than once, as foreseen in the metering process terminology _section) and reports _flow records_ > >> using src-as, dst-as as the flow key then only the latter >> flow and flow key need be reported. >> > flow _record _and ... > > Regards, Benoit. > >> >> The last example, and likely the most common, is vendor >> A reports flows based on src-ip, dst-ip, src-port, dst-port >> and vendor B reports based on src-ip, dst-ip, src-port, >> dst-port and DSCP. If both vendors report flow key >> information, then both flows can be appropriately processed. >> >> -- >> Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body >> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >> "unsubscribe ipfix" in message body >> Archive http://ipfix.doit.wisc.edu/archive/ >> >> > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Feb 25 13:30:13 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09763 for ; Tue, 25 Feb 2003 13:30:12 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18njhh-0004zk-00 for ipfix-list@mil.doit.wisc.edu; Tue, 25 Feb 2003 12:21:21 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18njhe-0004zX-00 for ipfix@net.doit.wisc.edu; Tue, 25 Feb 2003 12:21:19 -0600 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id h1PILGR43550 for ; Tue, 25 Feb 2003 19:21:16 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [10.1.1.128] (n-quittek.office [10.1.1.128]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 89A928E9BB for ; Tue, 25 Feb 2003 19:18:56 +0100 (CET) Date: Tue, 25 Feb 2003 19:21:42 +0100 From: Juergen Quittek To: ipfix@net.doit.wisc.edu Subject: [ipfix] new version of the IPFIX requirements I-D Message-ID: <37506301.1046200902@[10.1.1.128]> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Dear all, I just submitted a new version of the IPFIX requirements I-D to the IETF. You can preview it at ftp://ftp.ccrle.nec.de/pub/internet-drafts/draft-ietf-ipfix-reqs-09.txt Here is the complete list of changes compared to version -08: 1) section 2.1 "IP Traffic Flow", last line: "applicaton" -> "aplication" 2) section 2.2 "Observation Point", line 3: removed comma after "medium". 3) section 3.2 "QoS Monitoring", line 7: removed "(SLS)". 4) section 4 "Distinguishing Flows" joined paragraph 2 and paragraph 3 to a single one (without changing text). 5) section 4 "Distinguishing Flows", (former) paragraph 4: appended "But anyway, it MUST be ensured that a collecting process is able to clearly identify for each received flow record which flow key was used for distinguishing this flow from other ones." 6) section 5.2 "Sampling", paragraph 3, line 4: replaced "start sampling, stop sampling" by "adding a sampling function to the metering process, removing a sampling function from the metering process". 7) section 5.2 "Sampling", , paragraph 3, last line: "parameter" -> "parameter(s)" 8) section 6.3.2 "Reliability", item 4., last line: removed trailing double quote. 9) section 6.3.2 "Reliability", paragraph after item list, line 2: replaced "In such a case" by "If reliability is provided by higher layers,". 10) section 6.7 "Anonymization": appended new paragraph: "When anonymized flow data is exported, this MUST be clearly indicated to all receiving collecting processes, such that they can distinguish anonymized data from non-anonymized data." 11) section 9 "Special Device Considerations", paragraph 7, line 6: "transfered" -> "transferred" 12) section 11 "Acknowledgments", last but one line: "may" -> many" ======== Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.ccrle.nec.de -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Feb 26 06:46:37 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01628 for ; Wed, 26 Feb 2003 06:46:36 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18nzle-0003ov-00 for ipfix-list@mil.doit.wisc.edu; Wed, 26 Feb 2003 05:30:30 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18nzld-0003ok-00 for ipfix@net.doit.wisc.edu; Wed, 26 Feb 2003 05:30:29 -0600 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id h1QBUPR68579 for ; Wed, 26 Feb 2003 12:30:25 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [10.1.1.128] (n-quittek.office [10.1.1.128]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 33ED28ECD1 for ; Wed, 26 Feb 2003 12:27:58 +0100 (CET) Date: Wed, 26 Feb 2003 12:30:39 +0100 From: Juergen Quittek To: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] new version of the IPFIX requirements I-D Message-ID: <12021275.1046262639@[10.1.1.128]> In-Reply-To: <37506301.1046200902@[10.1.1.128]> References: <37506301.1046200902@[10.1.1.128]> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Dear all, I made a small mistake when editing the last version. I did not define the term 'flow key', but actually used it. Fortunately, our great reviewer Benoit found this in time. I fixed it on the ftp server where I put the I-D for submission and it looks like Benoit was quick enough: The keeper of the I-D repository has not downloaded it, yet. So the correct version will appear on the IETF's I-D server. Please find the updated version on the ftp server address given below. Also below, see a description of the change I made. Juergen -- Juergen Quittek wrote on 25 February 2003 19:21 +0100: > Dear all, > > I just submitted a new version of the IPFIX requirements I-D to the IETF. > You can preview it at > > ftp://ftp.ccrle.nec.de/pub/internet-drafts/draft-ietf-ipfix-reqs-09.txt > > Here is the complete list of changes compared to version -08: > > 1) section 2.1 "IP Traffic Flow", last line: > "applicaton" -> "aplication" > > 2) section 2.2 "Observation Point", line 3: > removed comma after "medium". > > 3) section 3.2 "QoS Monitoring", line 7: > removed "(SLS)". > > 4) section 4 "Distinguishing Flows" > joined paragraph 2 and paragraph 3 to a single one (without > changing text). > > 5) section 4 "Distinguishing Flows", (former) paragraph 4: > appended "But anyway, it MUST be ensured that a collecting process is > able to clearly identify for each received flow record which flow key replaced "flow key" by "set of properties" > was used for distinguishing this flow from other ones." > > 6) section 5.2 "Sampling", paragraph 3, line 4: > replaced "start sampling, stop sampling" by "adding a sampling function > to the metering process, removing a sampling function from the metering > process". > > 7) section 5.2 "Sampling", , paragraph 3, last line: > "parameter" -> "parameter(s)" > > 8) section 6.3.2 "Reliability", item 4., last line: > removed trailing double quote. > > 9) section 6.3.2 "Reliability", paragraph after item list, line 2: > replaced "In such a case" by "If reliability is provided by higher > layers,". > > 10) section 6.7 "Anonymization": > appended new paragraph: > "When anonymized flow data is exported, this MUST be clearly indicated > to all receiving collecting processes, such that they can distinguish > anonymized data from non-anonymized data." > > 11) section 9 "Special Device Considerations", paragraph 7, line 6: > "transfered" -> "transferred" > > 12) section 11 "Acknowledgments", last but one line: > "may" -> many" > > > ======== > Juergen > > -- > Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 > NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 > Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.ccrle.nec.de > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Feb 26 16:03:55 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25366 for ; Wed, 26 Feb 2003 16:03:54 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18o89m-0007FR-00 for ipfix-list@mil.doit.wisc.edu; Wed, 26 Feb 2003 14:27:58 -0600 Received: from mailhost2.auckland.ac.nz ([130.216.191.4]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18o89k-0007FI-00 for ipfix@net.doit.wisc.edu; Wed, 26 Feb 2003 14:27:56 -0600 Received: from mailhost.auckland.ac.nz (IDENT:mirapoint@mailhost [130.216.191.61]) by mailhost2.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id JAA02874 for ; Thu, 27 Feb 2003 09:27:54 +1300 (NZDT) Received: from localhost (hotlava.auckland.ac.nz [130.216.191.123]) by mailhost.auckland.ac.nz (Mirapoint Messaging Server MOS 3.3.2-CR) with ESMTP id ANF61965; Thu, 27 Feb 2003 09:27:51 +1300 (NZDT) Received: from dyn54.caida.org (dyn54.caida.org [192.172.226.54]) by hotlava.auckland.ac.nz (Horde) with HTTP for ; Thu, 27 Feb 2003 09:27:50 +1300 Message-ID: <1046291270.cde8bf0b7cef4@hotlava.auckland.ac.nz> Date: Thu, 27 Feb 2003 09:27:50 +1300 From: Nevil Brownlee To: ipfix@net.doit.wisc.edu Subject: [ipfix] Requirements Draft submitted to IESG MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-Originating-IP: 192.172.226.54 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hello all: Now that we've done its WG Last Call, I've submitted draft-ietf-ipfix-reqs-09.txt to the IESG to be considered for publication as an Informational RFC. Now we need to move forward on the evaluation process, i.e. to select the protocol which is the closest fit to the requirements. Then we can get back to work on the IPFIX Architecture amd Data Model drafts! Right now, we need to put together an Agenda for the IPFIX meeting at the San Francisco IETF. Here's a starting point: ..................................................... IPFIX Agenda for San Francisco ------------------------------ The IPFIX WG meeting is scheduled for Thursday 20 Mar 03, at 1530 (last session Thursday afternoon). 1) Agenda Review 2) Requirements Draft draft-ietf-ipfix-reqs-09.txt + Review of changes since Atlanta meeting 3) Evaluation process + Updates to advocacy drafts + Which of the advocated protocols should we choose? 4) Review of WG Milestones 5) Anything else If you have other items you'd like to see discussed, please advise the WG chairs, by email to ipfix-chairs@net.doit.wisc.edu ..................................................... As you can see, we need more detail on item (3) - so if *you* have any good ideas, controversial/provocative statements to make, *anything* which would help select a protocol, do please post them to the list! 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:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/