From majordomo@mil.doit.wisc.edu Fri Nov 1 20:54:35 2002 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 UAA12243 for ; Fri, 1 Nov 2002 20:54:34 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 187nIw-0000AY-00 for ipfix-list@mil.doit.wisc.edu; Fri, 01 Nov 2002 19:42:26 -0600 Received: from mailhub.xacct.com ([204.253.100.25] helo=xacct.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 187nIv-0000AR-00 for ipfix-eval@net.doit.wisc.edu; Fri, 01 Nov 2002 19:42:25 -0600 Received: (qmail 12341 invoked from network); 2 Nov 2002 01:42:11 -0000 Received: from usmail.xacct.com (204.253.100.12) by mailhub.xacct.com with SMTP; 2 Nov 2002 01:42:10 -0000 Received: from peter (inside.us.xacct.com [204.253.100.102]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id gA21j4a25094; Fri, 1 Nov 2002 17:45:10 -0800 From: "Peter Ludemann" To: "Carter Bullard" , Subject: RE: [ipfix-eval] RE: On template negotiation "complexity" in CRANE Date: Fri, 1 Nov 2002 17:41:29 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <5C8959A16A71B449AE793CF52FBBED6607A4A1@ptah.newyork.qosient.com> Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Carter: I think that this discussion is best taken offline. The "multicast" stuff has been thrashed around a fair bit and I think that the consensus is that we need to define a protocol that works over a wider distance than the constrained single-hop multicast network you're thinking of. Of course, it's nice if the chosen protocol can be adapted for such a constrained network ... my personal feeling is that the "control" stuff (templates, etc.) are best done with a fully reliable channel (based on TCP or SCTP, plus application-level acknowledgment), with the data containing "version" identification so that the receiver knows which version of templates are being used for a given record. This would allow the exporter to signal that the record formats are changing and to ensure that all the receivers have got the message but also allowing it to switch to the new format before everybody has sent in acknowledgment (at the risk of some receivers throwing away data they don't understand until they get the new format information). Although CRANE is designed to be fully reliable, it has this capability in its "configuration ID" which is a kind of version identification. - peter > -----Original Message----- > From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf > Of Carter Bullard > Sent: Thursday, October 31, 2002 4:45 PM > To: 'Peter Ludemann'; ipfix-eval@net.doit.wisc.edu > Subject: [ipfix-eval] RE: On template negotiation "complexity" in CRANE > > > Hey Peter, > Rather than thinking that reliability must be the driving > motivator of the protocol, think about how can the protocol > be developed to provide the most utility. Sure, if > reliability is the big thing, it needs to be there. If > high performance is the big thing, then other strategies > may be worth investigating. With architectural constraints, > I can build a reliable multicast network that is more reliable > than a TCP based strategy, at high rates. It's a good real > world example. > > Requiring the IPFIX protocol to have a bidirectional control > channel, and only support unicast transport, I think is really > "short sheeting" this modern transport protocol, IMHO. > > Carter > > > > > -----Original Message----- > > From: Peter Ludemann [mailto:peter.ludemann@xacct.com] > > Sent: Thursday, October 31, 2002 6:47 PM > > To: carter@qosient.com; ipfix-eval@net.doit.wisc.edu > > Subject: RE: On template negotiation "complexity" in CRANE > > > > > > Carter: > > > > Well, multicast (UDP) is hardly reliable, is it? > > > > I suppose that CRANE can be turned into an unreliable > > broadcast by doing as > > you say: assume an "OK" response when the templates are > > announced. But I > > wouldn't recommend this: what if the packet with the template > > information is > > lost? Confusion downstream ... > > > > Can broadcast of change of template could be made safe? I'd > > suggest instead > > using a reliable channel for handling such announcements. You > > could use > > CRANE's notion of a "configuration ID" to mark data records > > that are encoded > > with the old templates and those that are encoded under the > > new templates. > > > > - peter > > > > > -----Original Message----- > > > From: Carter Bullard [mailto:carter@qosient.com] > > > Sent: Thursday, October 31, 2002 1:27 PM > > > To: 'Peter Ludemann'; ipfix-eval@net.doit.wisc.edu > > > Subject: RE: On template negotiation "complexity" in CRANE > > > > > > > > > Hey Peter, > > > I'm still thinking "here are the fields", "here is the data". > > > Here is an example of how this might be used. > > > > > > Suppose I want to transmit flow records to a multicast address. > > > The sender really doesn't care if there are particular > > > receivers, it just needs to send data. Each of the receivers > > > however, may need to know something about the data that is > > > being received. One way is for the IPFIX protocol to periodically > > > announce its fields, for those receivers that have joined > > > the multicast group after the initial start of transmission. > > > I don't think I like receivers of a multicast IPFIX data stream > > > having to know the unicast address of the transmitter, in order > > > to discover what the output format is. > > > > > > Not currently in the IPFIX set of scenarios, but definitely a > > > real world possibility, and one the protocol should support, > > > IMHO. > > > > > > Carter > > > > > > Carter Bullard > > > QoSient, LLC > > > 300 E. 56th Street, Suite 18K > > > New York, New York 10022 > > > > > > carter@qosient.com > > > Phone +1 212 588-9133 > > > Fax +1 212 588-9134 > > > http://qosient.com > > > > > > > > > > -----Original Message----- > > > > From: Peter Ludemann [mailto:peter.ludemann@xacct.com] > > > > Sent: Thursday, October 31, 2002 3:47 PM > > > > To: carter@qosient.com; ipfix-eval@net.doit.wisc.edu > > > > Subject: RE: On template negotiation "complexity" in CRANE > > > > > > > > > > > > Carter: > > > > > > > > A minimal CRANE exporter could send only messages that say > > > > "here are the fields, no discussion"; and a minimal CRANE > > > > receiver can always reply with "I agree" to any template > > > > messages from the exporter. Does this meet your criteria? > > > > > > > > I image such a minimal implementation having a hard-coded > > > > template message on the exporter, which is sent in response > > > > to any template information request. On the receiver, there > > > > would also be hard-coded template, which should be the same; > > > > if there's a difference, that indicates the exporter isn't > > > > what was expected and the collector should report a > > > > configuration error (e.g., via SNMP); otherwise, the > > > > collector just replies to the exporter with "I agree" and > > > > then settles down to accept the actual data. > > > > > > > > - peter > > > > > > > > > -----Original Message----- > > > > > From: Carter Bullard [mailto:carter@qosient.com] > > > > > Sent: Thursday, October 31, 2002 12:27 PM > > > > > To: 'Peter Ludemann'; ipfix-eval@net.doit.wisc.edu > > > > > Subject: RE: On template negotiation "complexity" in CRANE > > > > > > > > > > > > > > > Hey Peter, > > > > > I have the same protocol strategy in the Argus protocol, > > > > > where an explicit response is required. I'm just thinking > > > > > of existing legacy flow transport strategies, where > > there currently > > > > > isn't even a request for data. While not a show stopper in > > > > any way, I > > > > > think it may need to be discussed. > > > > > > > > > > Regards, > > > > > > > > > > Carter > > > > > > > > > > Carter Bullard > > > > > QoSient, LLC > > > > > 300 E. 56th Street, Suite 18K > > > > > New York, New York 10022 > > > > > > > > > > carter@qosient.com > > > > > Phone +1 212 588-9133 > > > > > Fax +1 212 588-9134 > > > > > http://qosient.com > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Peter Ludemann [mailto:peter.ludemann@xacct.com] > > > > > > Sent: Thursday, October 31, 2002 3:17 PM > > > > > > To: carter@qosient.com; ipfix-eval@net.doit.wisc.edu > > > > > > Subject: RE: On template negotiation "complexity" in CRANE > > > > > > > > > > > > > > > > > > Carter Bullard [mailto:carter@qosient.com] wrote > > > > Thursday, October > > > > > > 31, 2002 11:58 AM: > > > > > > > > > > > > > There is one combination that is missing that I think > > > > > > > is important. > > > > > > > > > > > > > > Exporter says: "I am outputting fields a,b,c,d,e,." > > > > > > > Collector says: [no response] > > > > > > > Exporter sends data. > > > > > > > > > > > > > > While it may seem counter-intuitive to support this option, > > > > > > it is the > > > > > > > current state of the industry. Can Crane handle > > this type of > > > > > > > negotiation? > > > > > > > > > > > > Yes, but not with [no response]. [no response] is > > not allowed by > > > > > > the CRANE protocol. Instead, use a "I agree" response. > > > > The exporter > > > > > > makes the final decision as to what is exported, so > > there is no > > > > > > problem with a single collector just accepting whatever > > > > it is told. > > > > > > > > > > > > Our general philosophy is to require some kind of an > > > > acknowledgment > > > > > > to all messages. (Data messages are acknowledged in > > groups; all > > > > > > others are acknowledged > > > > > > individually.) For some messages, acknowledgment can be > > > > > > "asynchronous" (e.g., a request is sent with a request > > > > ID, which is > > > > > > used to identify the response). > > > > > > > > > > > > We think that it is a Bad Thing to allow silence to be > > > > equivalent to > > > > > > an acknowledgment. This is particularly the case for a compact > > > > > > binary protocol: if there is a mismatch between what the > > > > exporter is > > > > > > sending and what the collector is expecting, the only > > > > indication of > > > > > > a problem might be when somebody notices strange values > > > > showing up > > > > > > in the data. > > > > > > > > > > > > - peter > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > 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 Nov 6 19:29:48 2002 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 TAA18348 for ; Wed, 6 Nov 2002 19:29:47 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 189aI6-0002Hp-00 for ipfix-list@mil.doit.wisc.edu; Wed, 06 Nov 2002 18:12:58 -0600 Received: from mailhost2.auckland.ac.nz ([130.216.1.4]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 189aI3-0002Hi-00 for ipfix@net.doit.wisc.edu; Wed, 06 Nov 2002 18:12:55 -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 NAA24418 for ; Thu, 7 Nov 2002 13:12:53 +1300 (NZDT) Received: from postbox.auckland.ac.nz (postbox.auckland.ac.nz [130.216.191.126]) by mailhost.auckland.ac.nz (Mirapoint Messaging Server MOS 3.2.1.6-EA) with ESMTP id AJN05537; Thu, 7 Nov 2002 13:12:52 +1300 (NZDT) Received: from localhost (hotlava.auckland.ac.nz [130.216.191.123]) by postbox.auckland.ac.nz (8.11.6/8.11.6) with ESMTP id gA70Cqw01443 for ; Thu, 7 Nov 2002 13:12:52 +1300 Received: from nebbiolo.itss.auckland.ac.nz (nebbiolo.itss.auckland.ac.nz [130.216.4.167]) by hotlava.auckland.ac.nz (IMP) with HTTP for ; Thu, 7 Nov 2002 13:12:51 +1300 Message-ID: <1036627971.3dc9b003e98dd@hotlava.auckland.ac.nz> Date: Thu, 7 Nov 2002 13:12:51 +1300 From: Nevil Brownlee To: ipfix@net.doit.wisc.edu Subject: [ipfix] Agenda for IPFIX at Atlanta IETF MIME-Version: 1.0 Content-Type: text/plain 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: Our agenda for the IPFIX meeting in Atlanta is appended below. You'll note that the Evaluation Team's report, which reflects a rough consensus of the team members, is now available at www.auckland.ac.nz/net/ipfix The Evaluation Team members have managed to produce their drafts within a tight time frame; we're very grateful to them for all their hard work. See you in Atlanta! 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 IPFIX Agenda for Atlanta ------------------------ The IPFIX WG meeting is scheduled for Thursday 21 Nov 02, at 1530 (last session Thursday afternoon). 1) Agenda Review 2) Requirements Draft draft-ietf-ipfix-reqs-07.txt <<<< + Review of changes since Yokohama meeting + Open issues - We need to reach consensus on these; doing so should aid the protocol evaluation. 3) Evaluation Process + Report - Individual team member drafts draft-gopal-ipfix-eval-contrib-00.txt <<<< draft-leinen-ipfix-eval-contrib-00.txt <<<< - Rough Consensus report from the team draft-ietf-ipfix-protocol-eval-00.txt <<<< + Discussion: how to proceed - Could we eliminate some of the protocols as a first step? - Can we reach consensus on one of the candidates? - What changes are *required* in the chosen protocol? 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 NOTE: The drafts marked <<<< above missed the meeting draft deadline. Meantime, they are available at www.auckland.ac.nz/net/ipfix/ Revised Milestones Done Submit Revised Internet-Draft on IP Flow Export Requirements Done Submit Internet-Draft on IP Flow Export Architecture Done Submit Internet-Draft on IP Flow Export Data Model Done Submit Advocate Internet-Drafts for Candidate Protocols * Nov 02 Submit Internet-Draft on IPFIX Protocol Evaluation Report * Dec 02 Submit Internet-Draft on IP Flow Export Applicability Statement * Feb 03 Select IPFIX protocol, revise Architecture and Data Model drafts Apr 03 Submit IPFX-REQUIREMENTS to IESG for publication as Informational RFC * Apr 03 Submit IPFIX Protocol Evaluation Report to IESG for publication as Informational RFC Aug 03 Submit IPFX-ARCHITECTURE to IESG for publication as Proposed Standard RFC Aug 03 Submit IPFX-DATAMODEL to IESG for publication as Informational RFC * Aug 03 Submit IPFX-APPLICABILITY to IESG for publication as Informational RFC * indicates new milestones IPFIX WG: Document status, 7 Nov 02 Evaluation drafts: Advocate (individual) drafts (published) draft-calato-ipfix-lfap-eval-00.txt draft-claise-ipfix-eval-netflow-03.txt draft-kzhang-ipfix-eval-crane-00.txt draft-meyer-ipfix-ipdr-eval-00.txt draft-zander-ipfix-diameter-eval-00.txt Evaluation Review drafts draft-gopal-ipfix-eval-contrib-00.txt <<<< draft-leinen-ipfix-eval-contrib-00.txt <<<< draft-ietf-ipfix-protocol-eval-00.txt <<<< WG drafts: Under discussion draft-ietf-ipfix-reqs-07.txt <<<< On hold until evaluation complete: draft-ietf-ipfix-architecture-02.txt draft-ietf-ipfix-data-00.txt (EXPIRED) Proposed WG draft draft-zseby-ipfix-applicability-00.txt <<<< drafts are at www.auckland.ac.nz/net/ipfix/ ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ -- 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 Nov 7 10:01:54 2002 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 KAA26915 for ; Thu, 7 Nov 2002 10:01:54 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 189nxK-0000hN-00 for ipfix-list@mil.doit.wisc.edu; Thu, 07 Nov 2002 08:48:26 -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 189nxI-0000ga-00 for ipfix@net.doit.wisc.edu; Thu, 07 Nov 2002 08:48:24 -0600 Received: from riverstonenet.com ([134.141.180.78]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 7 Nov 2002 06:47:52 -0800 Message-ID: <3DCA7C9B.DE20AF97@riverstonenet.com> Date: Thu, 07 Nov 2002 09:45:47 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ipfixx Subject: [ipfix] Multiple levels of Reliability and Directionality Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Nov 2002 14:47:53.0475 (UTC) FILETIME=[A6EA2D30:01C2866C] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Does IPFIX need to support multiple levels of reliability and directionality? The applications IPFIX needs to support are quite varied and have differing needs in terms of reliability. Devices also have varying needs in terms of directionality. I would like the WG to consider requirements on the protocol to support a tiered approach meet these needs. Direction is either bi-directional or uni-directional. I've split reliability into 3 categories... High - Little to no data loss Medium - Minimal data loss is accepted Low - Data sent is best effort The six combinations are shown below... | Uni | Bi -------+------+--------- High | 1 | 4 -------+------+-------- Medium | 2 | 5 -------+------+-------- Low | 3 | 6 I think (IMHO) the most likely combinations are... 3. Low reliability and uni-directional. This will be used where the device and collector are in close proximity, there is high volume and some data loss is acceptable for the given application. Applications such as Attack/Intrusion Detection Traffic Profiling, etc... 5. Bi-directional medium reliability. This will be used where high volume and increased reliability are needed. Applications such as Usage-based Accounting where 95th percentile billing model is used. Or even Traffic Engineering where network policy decisions are based on the data collected. 4. Bi-directional high reliability would be used where the Usage-based Accounting application has strict requirements on data loss. Does IPFIX need to support multiple levels of reliability and directionality? Paul -- 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 Nov 7 12:00:42 2002 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 MAA02010 for ; Thu, 7 Nov 2002 12:00:42 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 189phg-0003M9-00 for ipfix-list@mil.doit.wisc.edu; Thu, 07 Nov 2002 10:40:24 -0600 Received: from pool-129-44-39-39.ny325.east.verizon.net ([129.44.39.39] helo=newyork.qosient.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 189phf-0003M2-00 for ipfix@net.doit.wisc.edu; Thu, 07 Nov 2002 10:40:23 -0600 Received: from SET (set [192.168.0.161]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id gA7GeFO32755; Thu, 7 Nov 2002 11:40:15 -0500 Reply-To: From: "Carter Bullard" To: , "'ipfixx'" Subject: RE: [ipfix] Multiple levels of Reliability and Directionality Date: Thu, 7 Nov 2002 11:40:06 -0500 Organization: QoSient, LLC Message-ID: <5C8959A16A71B449AE793CF52FBBED6607E6CA@ptah.newyork.qosient.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <5C8959A16A71B449AE793CF52FBBED660D294B@ptah.newyork.qosient.com> Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hey Paul, My 2 cents worth sez, absolutely yes! Carter > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of > calato@riverstonenet.com > Sent: Thursday, November 07, 2002 9:46 AM > To: ipfixx > Subject: [ipfix] Multiple levels of Reliability and Directionality > > > > Does IPFIX need to support multiple levels of reliability > and directionality? > > The applications IPFIX needs to support are quite varied > and have differing needs in terms of reliability. Devices > also have varying needs in terms of directionality. > > I would like the WG to consider requirements on the protocol > to support a tiered approach meet these needs. > > Direction is either bi-directional or uni-directional. I've split > reliability into 3 categories... > > High - Little to no data loss > Medium - Minimal data loss is accepted > Low - Data sent is best effort > > > The six combinations are shown below... > > > | Uni | Bi > -------+------+--------- > High | 1 | 4 > -------+------+-------- > Medium | 2 | 5 > -------+------+-------- > Low | 3 | 6 > > > > I think (IMHO) the most likely combinations are... > > 3. Low reliability and uni-directional. This will be used > where the device and collector are in close proximity, > there is high volume and some data loss is acceptable for > the given application. Applications such as > Attack/Intrusion Detection > Traffic Profiling, etc... > > 5. Bi-directional medium reliability. This will be used > where high volume and increased reliability are > needed. Applications > such as Usage-based Accounting where 95th > percentile billing > model is used. Or even Traffic Engineering where > network policy > decisions are based on the data collected. > > 4. Bi-directional high reliability would be used where the > Usage-based Accounting application has strict requirements > on data loss. > > Does IPFIX need to support multiple levels of reliability > and directionality? > > Paul > > -- > 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 Nov 7 12:37:56 2002 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 MAA03547 for ; Thu, 7 Nov 2002 12:37:55 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 189qTY-0004WZ-00 for ipfix-list@mil.doit.wisc.edu; Thu, 07 Nov 2002 11:29:52 -0600 Received: from usmail.xacct.com ([204.253.100.12]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 189qTW-0004WO-00 for ipfix@net.doit.wisc.edu; Thu, 07 Nov 2002 11:29:50 -0600 Received: from Givoly (inside.us.xacct.com [204.253.100.102]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id gA7HWv219286; Thu, 7 Nov 2002 09:33:03 -0800 From: "Tal Givoly" To: , , "'ipfixx'" Subject: RE: [ipfix] Multiple levels of Reliability and Directionality Date: Thu, 7 Nov 2002 09:29:12 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <5C8959A16A71B449AE793CF52FBBED6607E6CA@ptah.newyork.qosient.com> X-RBL-Warning: (dnsbl.njabl.org) relay tested -- 1016746205 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Paul, I agree completely - that captures the essense of the requirements. It allows balancing different application's need for different levels of reliability. Tal -----Original Message----- From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of Carter Bullard Sent: Thursday, November 07, 2002 8:40 AM To: calato@riverstonenet.com; 'ipfixx' Subject: RE: [ipfix] Multiple levels of Reliability and Directionality Hey Paul, My 2 cents worth sez, absolutely yes! Carter > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of > calato@riverstonenet.com > Sent: Thursday, November 07, 2002 9:46 AM > To: ipfixx > Subject: [ipfix] Multiple levels of Reliability and Directionality > > > > Does IPFIX need to support multiple levels of reliability > and directionality? > > The applications IPFIX needs to support are quite varied > and have differing needs in terms of reliability. Devices > also have varying needs in terms of directionality. > > I would like the WG to consider requirements on the protocol > to support a tiered approach meet these needs. > > Direction is either bi-directional or uni-directional. I've split > reliability into 3 categories... > > High - Little to no data loss > Medium - Minimal data loss is accepted > Low - Data sent is best effort > > > The six combinations are shown below... > > > | Uni | Bi > -------+------+--------- > High | 1 | 4 > -------+------+-------- > Medium | 2 | 5 > -------+------+-------- > Low | 3 | 6 > > > > I think (IMHO) the most likely combinations are... > > 3. Low reliability and uni-directional. This will be used > where the device and collector are in close proximity, > there is high volume and some data loss is acceptable for > the given application. Applications such as > Attack/Intrusion Detection > Traffic Profiling, etc... > > 5. Bi-directional medium reliability. This will be used > where high volume and increased reliability are > needed. Applications > such as Usage-based Accounting where 95th > percentile billing > model is used. Or even Traffic Engineering where > network policy > decisions are based on the data collected. > > 4. Bi-directional high reliability would be used where the > Usage-based Accounting application has strict requirements > on data loss. > > Does IPFIX need to support multiple levels of reliability > and directionality? > > Paul > > -- > 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 Nov 7 13:27:38 2002 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 NAA05302 for ; Thu, 7 Nov 2002 13:27:37 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 189rDO-0005ci-00 for ipfix-list@mil.doit.wisc.edu; Thu, 07 Nov 2002 12:17:14 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 189rDM-0005c1-00 for ipfix@net.doit.wisc.edu; Thu, 07 Nov 2002 12:17:12 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gA7IClj02346; Thu, 7 Nov 2002 12:12:48 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Nov 2002 10:12:33 -0800 Message-ID: <7B802811BE77D51189910002A55CFD2C047E1A1F@zsc3c032.us.nortel.com> From: "Reinaldo Penno" To: Tal Givoly , carter@qosient.com, calato@riverstonenet.com, "'ipfixx'" Subject: RE: [ipfix] Multiple levels of Reliability and Directionality Date: Thu, 7 Nov 2002 10:12:31 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C28689.3D47DBDA" 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_01C28689.3D47DBDA Content-Type: text/plain; charset="iso-8859-1" yep, good idea. > -----Original Message----- > From: Tal Givoly [mailto:givoly@xacct.com] > Sent: Thursday, November 07, 2002 12:29 PM > To: carter@qosient.com; calato@riverstonenet.com; 'ipfixx' > Subject: RE: [ipfix] Multiple levels of Reliability and Directionality > > > Paul, > > I agree completely - that captures the essense of the requirements. It > allows balancing different application's need for different levels of > reliability. > > Tal > > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu]On Behalf > Of Carter Bullard > Sent: Thursday, November 07, 2002 8:40 AM > To: calato@riverstonenet.com; 'ipfixx' > Subject: RE: [ipfix] Multiple levels of Reliability and Directionality > > > Hey Paul, > My 2 cents worth sez, absolutely yes! > Carter > > > -----Original Message----- > > From: majordomo listserver > > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of > > calato@riverstonenet.com > > Sent: Thursday, November 07, 2002 9:46 AM > > To: ipfixx > > Subject: [ipfix] Multiple levels of Reliability and Directionality > > > > > > > > Does IPFIX need to support multiple levels of reliability > > and directionality? > > > > The applications IPFIX needs to support are quite varied > > and have differing needs in terms of reliability. Devices > > also have varying needs in terms of directionality. > > > > I would like the WG to consider requirements on the protocol > > to support a tiered approach meet these needs. > > > > Direction is either bi-directional or uni-directional. I've split > > reliability into 3 categories... > > > > High - Little to no data loss > > Medium - Minimal data loss is accepted > > Low - Data sent is best effort > > > > > > The six combinations are shown below... > > > > > > | Uni | Bi > > -------+------+--------- > > High | 1 | 4 > > -------+------+-------- > > Medium | 2 | 5 > > -------+------+-------- > > Low | 3 | 6 > > > > > > > > I think (IMHO) the most likely combinations are... > > > > 3. Low reliability and uni-directional. This will be used > > where the device and collector are in close proximity, > > there is high volume and some data loss is acceptable for > > the given application. Applications such as > > Attack/Intrusion Detection > > Traffic Profiling, etc... > > > > 5. Bi-directional medium reliability. This will be used > > where high volume and increased reliability are > > needed. Applications > > such as Usage-based Accounting where 95th > > percentile billing > > model is used. Or even Traffic Engineering where > > network policy > > decisions are based on the data collected. > > > > 4. Bi-directional high reliability would be used where the > > Usage-based Accounting application has strict > requirements > > on data loss. > > > > Does IPFIX need to support multiple levels of reliability > > and directionality? > > > > Paul > > > > -- > > 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/ > ------_=_NextPart_001_01C28689.3D47DBDA Content-Type: text/html; charset="iso-8859-1" RE: [ipfix] Multiple levels of Reliability and Directionality

yep, good idea.

> -----Original Message-----
> From: Tal Givoly [mailto:givoly@xacct.com]
> Sent: Thursday, November 07, 2002 12:29 PM
> To: carter@qosient.com; calato@riverstonenet.com; 'ipfixx'
> Subject: RE: [ipfix] Multiple levels of Reliability and Directionality
>
>
> Paul,
>
> I agree completely - that captures the essense of the requirements. It
> allows balancing different application's need for different levels of
> reliability.
>
> Tal
>
> -----Original Message-----
> From: majordomo listserver
> [mailto:majordomo@mil.doit.wisc.edu]On Behalf
> Of Carter Bullard
> Sent: Thursday, November 07, 2002 8:40 AM
> To: calato@riverstonenet.com; 'ipfixx'
> Subject: RE: [ipfix] Multiple levels of Reliability and Directionality
>
>
> Hey Paul,
>   My 2 cents worth sez, absolutely yes!
> Carter
>
> > -----Original Message-----
> > From: majordomo listserver
> > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of
> > calato@riverstonenet.com
> > Sent: Thursday, November 07, 2002 9:46 AM
> > To: ipfixx
> > Subject: [ipfix] Multiple levels of Reliability and Directionality
> >
> >
> >
> > Does IPFIX need to support multiple levels of reliability
> > and directionality?
> >
> > The applications IPFIX needs to support are quite varied
> > and have differing needs in terms of reliability. Devices
> > also have varying needs in terms of directionality.
> >
> > I would like the WG to consider requirements on the protocol
> > to support a tiered approach meet these needs.
> >
> > Direction is either bi-directional or uni-directional. I've split
> > reliability into 3 categories...
> >
> >         High   - Little to no data loss
> >         Medium - Minimal data loss is accepted
> >         Low    - Data sent is best effort
> >
> >
> > The six combinations are shown below...
> >
> >
> >                | Uni  |  Bi
> >         -------+------+---------
> >         High   |  1   |    4
> >         -------+------+--------
> >         Medium |  2   |    5
> >         -------+------+--------
> >         Low    |  3   |    6
> >
> >
> >
> > I think (IMHO) the most likely combinations are...
> >
> >         3. Low reliability and uni-directional. This will be used
> >            where the device and collector are in close proximity,
> >            there is high volume and some data loss is acceptable for
> >            the given application. Applications such as
> > Attack/Intrusion Detection
> >            Traffic Profiling, etc...
> >
> >         5. Bi-directional medium reliability. This will be used
> >            where high volume and increased reliability are
> > needed. Applications
> >            such as Usage-based Accounting where 95th
> > percentile billing
> >            model is used. Or even Traffic Engineering where
> > network policy
> >            decisions are based on the data collected.
> >
> >         4. Bi-directional high reliability would be used where the
> >            Usage-based Accounting application has strict
> requirements
> >            on data loss.
> >
> > Does IPFIX need to support multiple levels of reliability
> > and directionality?
> >
> > Paul
> >
> > --
> > 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/
>

------_=_NextPart_001_01C28689.3D47DBDA-- -- 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 Nov 8 11:06:27 2002 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 LAA24825 for ; Fri, 8 Nov 2002 11:06:26 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18ABQQ-0000Vo-00 for ipfix-list@mil.doit.wisc.edu; Fri, 08 Nov 2002 09:52:02 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18ABQL-0000QU-00 for ipfix@net.doit.wisc.edu; Fri, 08 Nov 2002 09:51:57 -0600 Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gA8FpLY13375; Fri, 8 Nov 2002 16:51:21 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 728056504A; Fri, 8 Nov 2002 16:50:41 +0100 (CET) Date: Fri, 08 Nov 2002 16:50:41 +0100 From: Juergen Quittek To: ipfix@net.doit.wisc.edu, psamp@ops.ietf.org Subject: [ipfix] IPFIX and PSAMP harmonization Message-ID: <17266568.1036774241@[192.168.102.164]> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========17283487==========" Precedence: bulk Sender: majordomo listserver --==========17283487========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 7bit Dear all at PSAMP and IPFIX, As most of you know, there is some potential overlap of the work done in the two working groups. There also is a potential of mutual benefit between the groups. And certainly it would be desirable to harmonize the work in both groups (terminology, concepts, ...). I want to discuss these issues briefly in both WG sessions in Atlanta. The draft referenced below is intended to serve as a starting point for this discussion. Juergen ---------- Forwarded Message ---------- Date: 01 November 2002 08:42 -0500 From: Internet-Drafts@ietf.org To: IETF-Announce Subject: I-D ACTION:draft-quittek-psamp-ipfix-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : On the Relationship between PSAMP and IPFIX Author(s) : J. Quittek Filename : draft-quittek-psamp-ipfix-00.txt Pages : 10 Date : 2002-10-31 This memo discusses the relationship between the packet sampling (PSAMP) working group and the IP flow information export (IPFIX) working group. The goals of writing this memo are: avoiding duplication of work, increase mutual benefits between the groups, and harmonize the documents and standards developed by the groups. Therefore, potential overlap of both group's activities is analyzed, activities in both groups that potentially complement each other are pointed out, and common issues are listed that should be harmonized between the groups. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-quittek-psamp-ipfix-00.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-quittek-psamp-ipfix-00.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-quittek-psamp-ipfix-00.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. ---------- End Forwarded Message ---------- --==========17283487========== Content-Type: message/rfc822; name="I-D ACTION:draft-quittek-psamp-ipfix-00.txt" Return-Path: X-Sieve: cmu-sieve 2.0 Received: from tokyo.ccrle.nec.de (zipo.heidelberg.ccrle.nec.de [192.168.102.84]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 251DC72EC4; Fri, 1 Nov 2002 15:09:20 +0100 (CET) Received: from ran.ietf.org (ran.ietf.org [132.151.6.60]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gA1E9WY41219; Fri, 1 Nov 2002 15:09:32 +0100 (CET) (envelope-from owner-ietf-announce@ietf.org) Received: from majordomo by ran.ietf.org with local (Exim 4.10) id 187c4B-0000jn-00 for ietf-announce-list@ran.ietf.org; Fri, 01 Nov 2002 08:42:27 -0500 Received: from odin.ietf.org ([10.27.2.28] helo=ietf.org) by ran.ietf.org with esmtp (Exim 4.10) id 187c4A-0000jh-00 for all-ietf@ran.ietf.org; Fri, 01 Nov 2002 08:42:26 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06168; Fri, 1 Nov 2002 08:42:00 -0500 (EST) Message-Id: <200211011342.IAA06168@ietf.org> To: IETF-Announce: ; Cc: psamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-quittek-psamp-ipfix-00.txt Date: Fri, 01 Nov 2002 08:42:00 -0500 Sender: owner-ietf-announce@ietf.org Precedence: bulk MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========17272419==========" --==========17272419========== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : On the Relationship between PSAMP and IPFIX Author(s) : J. Quittek Filename : draft-quittek-psamp-ipfix-00.txt Pages : 10 Date : 2002-10-31 This memo discusses the relationship between the packet sampling (PSAMP) working group and the IP flow information export (IPFIX) working group. The goals of writing this memo are: avoiding duplication of work, increase mutual benefits between the groups, and harmonize the documents and standards developed by the groups. Therefore, potential overlap of both group's activities is analyzed, activities in both groups that potentially complement each other are pointed out, and common issues are listed that should be harmonized between the groups. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-quittek-psamp-ipfix-00.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-quittek-psamp-ipfix-00.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-quittek-psamp-ipfix-00.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. --==========17272419========== Content-Type: multipart/alternative; boundary="==========17276775==========" --==========17276775========== Content-Type: message/external-body; ACCESS-TYPE=mail-server; SERVER="mailserv@ietf.org" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2002-10-31150215.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-quittek-psamp-ipfix-00.txt --==========17276775========== Content-Type: message/external-body; name="draft-quittek-psamp-ipfix-00.txt"; SITE="ftp.ietf.org"; ACCESS-TYPE=anon-ftp; DIRECTORY=internet-drafts Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2002-10-31150215.I-D@ietf.org> --==========17276775==========-- --==========17272419==========-- --==========17283487==========-- -- 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 Nov 8 18:25:39 2002 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 SAA22108 for ; Fri, 8 Nov 2002 18:25:39 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18AILn-0004JL-00 for ipfix-list@mil.doit.wisc.edu; Fri, 08 Nov 2002 17:15:43 -0600 Received: from palrel11.hp.com ([156.153.255.246]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18AILk-0004JE-00 for ipfix@net.doit.wisc.edu; Fri, 08 Nov 2002 17:15:40 -0600 Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel11.hp.com (Postfix) with ESMTP id 4BE136006C3; Fri, 8 Nov 2002 15:15:37 -0800 (PST) Received: from simail.cup.hp.com (imail@sim.cup.hp.com [15.16.123.26]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id PAA00532; Fri, 8 Nov 2002 15:15:30 -0800 (PST) Received: from cup.hp.com ([15.16.124.96]) by simail.cup.hp.com (InterMail vM.5.01.03.01 201-253-122-118-101-20010319) with ESMTP id <20021108231530.WWD1825.simail.cup.hp.com@cup.hp.com>; Fri, 8 Nov 2002 15:15:30 -0800 Message-ID: <3DCC4621.2000707@cup.hp.com> Date: Fri, 08 Nov 2002 15:17:53 -0800 From: Jeff Meyer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: Tal Givoly Cc: carter@qosient.com, calato@riverstonenet.com, "'ipfixx'" Subject: Re: [ipfix] Multiple levels of Reliability and Directionality References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi, I agree with the aspect of varied reliability. I am less clear on the need for bi-directional behavior. The three scenarios you describe I agree with, but I'm not sure how the 2nd and 3rd scenario as described have any dependence on bi-directional aside from the some level of application layer ack. Regards, Jeff Meyer Tal Givoly wrote: > Paul, > > I agree completely - that captures the essense of the requirements. It > allows balancing different application's need for different levels of > reliability. > > Tal > > -----Original Message----- > From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf > Of Carter Bullard > Sent: Thursday, November 07, 2002 8:40 AM > To: calato@riverstonenet.com; 'ipfixx' > Subject: RE: [ipfix] Multiple levels of Reliability and Directionality > > > Hey Paul, > My 2 cents worth sez, absolutely yes! > Carter > > >>-----Original Message----- >>From: majordomo listserver >>[mailto:majordomo@mil.doit.wisc.edu] On Behalf Of >>calato@riverstonenet.com >>Sent: Thursday, November 07, 2002 9:46 AM >>To: ipfixx >>Subject: [ipfix] Multiple levels of Reliability and Directionality >> >> >> >>Does IPFIX need to support multiple levels of reliability >>and directionality? >> >>The applications IPFIX needs to support are quite varied >>and have differing needs in terms of reliability. Devices >>also have varying needs in terms of directionality. >> >>I would like the WG to consider requirements on the protocol >>to support a tiered approach meet these needs. >> >>Direction is either bi-directional or uni-directional. I've split >>reliability into 3 categories... >> >> High - Little to no data loss >> Medium - Minimal data loss is accepted >> Low - Data sent is best effort >> >> >>The six combinations are shown below... >> >> >> | Uni | Bi >> -------+------+--------- >> High | 1 | 4 >> -------+------+-------- >> Medium | 2 | 5 >> -------+------+-------- >> Low | 3 | 6 >> >> >> >>I think (IMHO) the most likely combinations are... >> >> 3. Low reliability and uni-directional. This will be used >> where the device and collector are in close proximity, >> there is high volume and some data loss is acceptable for >> the given application. Applications such as >>Attack/Intrusion Detection >> Traffic Profiling, etc... >> >> 5. Bi-directional medium reliability. This will be used >> where high volume and increased reliability are >>needed. Applications >> such as Usage-based Accounting where 95th >>percentile billing >> model is used. Or even Traffic Engineering where >>network policy >> decisions are based on the data collected. >> >> 4. Bi-directional high reliability would be used where the >> Usage-based Accounting application has strict requirements >> on data loss. >> >>Does IPFIX need to support multiple levels of reliability >>and directionality? >> >>Paul >> >>-- >>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 Sat Nov 9 20:19:52 2002 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 UAA28285 for ; Sat, 9 Nov 2002 20:19:52 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18AgNL-0001TB-00 for ipfix-list@mil.doit.wisc.edu; Sat, 09 Nov 2002 18:54:55 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18AgNJ-0001Se-00 for ipfix@net.doit.wisc.edu; Sat, 09 Nov 2002 18:54:53 -0600 Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gAA0sJY57672 for ; Sun, 10 Nov 2002 01:54:19 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.32] (unknown [192.168.102.32]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 6CFAE75F34 for ; Sun, 10 Nov 2002 01:53:33 +0100 (CET) Date: Sun, 10 Nov 2002 01:53:31 +0100 From: Juergen Quittek To: ipfix@net.doit.wisc.edu Subject: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt Message-ID: <5652968.1036893210@[192.168.102.32]> In-Reply-To: <200211081838.NAA06276@ietf.org> References: <200211081838.NAA06276@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 Hi all, There are still several requirements issues under dicussion on the list. We (the authors) only integrated changes into the document, for which we sensed rough consensus. If you disagree with our judgement, please speak up. Somehow, the requirements discussion suffers from a split: There are requirements resulting from the intention of standardzing a highly reliable metering standard for precise accounting (and billing). Differing from these are requirements for a simpler metering standard more oriented at what I would call "typical Internet reliability". Anyway, below please find the list of changes between versios -06 and -07 of draft-ietf-ipfix-reqs. Juergen 1. Replaced all occurrences of "sampling rate" by "sampling frequency". 2. Appended to Section 6.3.2.: "Flow information might get lost before it is processed properly by the collecting process. A means to gauge the amount of loss of flow information MUST be available from the exporting process and/or the collecting process. Possible reasons for flow information loss include resource shortage at the exporter, loss of packets between exporting process and collecting process, etc. If the exporting process is capable of detecting loss of connection to a collecting process, it SHOULD be able to perform failover to a specified backup collecting process." 3. Replaced in 6.1.: " 5. source TCP/UDP port number 6. destination TCP/UDP port number" by " 5. if protocol type is TCP or UDP: source TCP/UDP port number 6. if protocol type is TCP or UDP: destination TCP/UDP port number" 4. Inserted in 6.1.: " 7. if protocol type is ICMP: ICMP type and code" 5. Replaced text of Section 5.4.: "The metering process MUST be able to generate timestamps for the first and the last observed packet of a flow. The timestamp resolution MUST be at least the one of the sysUpTime [RFC1213], which is one centisecond." by "The metering process MUST be able to generate timestamps for the first and the last observation of a packet of a flow at the observation point. The timestamp resolution MUST be at least the one of the sysUpTime [RFC1213], which is one centisecond." 6. Replace in Section 8.1: "measurement and reporting" by "the metering process and the exporting process" -- Internet-Drafts@ietf.org wrote on 08 November 2002 13:38 -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-07.txt > Pages : 29 > Date : 2002-11-8 > > 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-07.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-07.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-07.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 Sat Nov 9 20:38:00 2002 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 UAA28689 for ; Sat, 9 Nov 2002 20:38:00 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18Agii-0001zY-00 for ipfix-list@mil.doit.wisc.edu; Sat, 09 Nov 2002 19:17:01 -0600 Received: from rip.psg.com ([147.28.0.39]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18Agih-0001zM-00 for ipfix@net.doit.wisc.edu; Sat, 09 Nov 2002 19:16:59 -0600 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18Agif-0009QK-00; Sat, 09 Nov 2002 17:16:57 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Juergen Quittek Cc: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt References: <200211081838.NAA06276@ietf.org> <5652968.1036893210@[192.168.102.32]> Message-Id: Date: Sat, 09 Nov 2002 17:16:57 -0800 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit > Somehow, the requirements discussion suffers from a split: > There are requirements resulting from the intention of > standardzing a highly reliable metering standard for precise > accounting (and billing). Differing from these are requirements > for a simpler metering standard more oriented at what I would > call "typical Internet reliability". the original goal, which the iesg thinks was chartered, is the latter. i do not understand how _flow_ measurements can be a _rigorous_ basis for billing. in my world, we use octet counting for that kind of application. randy -- 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 Nov 11 11:25:19 2002 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 LAA23685 for ; Mon, 11 Nov 2002 11:25:19 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18BH49-0003fD-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Nov 2002 10:05:33 -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 18BH47-0003e8-00 for ipfix@net.doit.wisc.edu; Mon, 11 Nov 2002 10:05:31 -0600 Received: from riverstonenet.com ([134.141.180.101]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 11 Nov 2002 08:04:58 -0800 Message-ID: <3DCFD4AB.492B2C4B@riverstonenet.com> Date: Mon, 11 Nov 2002 11:02:51 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jeff Meyer CC: Tal Givoly , carter@qosient.com, "'ipfixx'" Subject: Re: [ipfix] Multiple levels of Reliability and Directionality References: <3DCC4621.2000707@cup.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Nov 2002 16:04:59.0002 (UTC) FILETIME=[159895A0:01C2899C] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Jeff Meyer wrote: > > Hi, > > I agree with the aspect of varied reliability. > > I am less clear on the need for bi-directional > behavior. The three scenarios you describe I > agree with, but I'm not sure how the 2nd and > 3rd scenario as described have any dependence > on bi-directional aside from the some level of > application layer ack. > An application layer ACK all by itself makes the protocol bi-directional. Scenario #1 does not require the sender to also be a receiver. Scenarios #2 & #3 do require the sender to also be a receiver (even if only for ACK's). Whether or not we decide to add other features in scenarios #2 & #3 (such as field negotiation, capability negotiation, etc...) is up to the WG. But they could not be added to scenario #1. Paul > Regards, > > Jeff Meyer > > Tal Givoly wrote: > > > Paul, > > > > I agree completely - that captures the essense of the requirements. It > > allows balancing different application's need for different levels of > > reliability. > > > > Tal > > > > -----Original Message----- > > From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf > > Of Carter Bullard > > Sent: Thursday, November 07, 2002 8:40 AM > > To: calato@riverstonenet.com; 'ipfixx' > > Subject: RE: [ipfix] Multiple levels of Reliability and Directionality > > > > > > Hey Paul, > > My 2 cents worth sez, absolutely yes! > > Carter > > > > > >>-----Original Message----- > >>From: majordomo listserver > >>[mailto:majordomo@mil.doit.wisc.edu] On Behalf Of > >>calato@riverstonenet.com > >>Sent: Thursday, November 07, 2002 9:46 AM > >>To: ipfixx > >>Subject: [ipfix] Multiple levels of Reliability and Directionality > >> > >> > >> > >>Does IPFIX need to support multiple levels of reliability > >>and directionality? > >> > >>The applications IPFIX needs to support are quite varied > >>and have differing needs in terms of reliability. Devices > >>also have varying needs in terms of directionality. > >> > >>I would like the WG to consider requirements on the protocol > >>to support a tiered approach meet these needs. > >> > >>Direction is either bi-directional or uni-directional. I've split > >>reliability into 3 categories... > >> > >> High - Little to no data loss > >> Medium - Minimal data loss is accepted > >> Low - Data sent is best effort > >> > >> > >>The six combinations are shown below... > >> > >> > >> | Uni | Bi > >> -------+------+--------- > >> High | 1 | 4 > >> -------+------+-------- > >> Medium | 2 | 5 > >> -------+------+-------- > >> Low | 3 | 6 > >> > >> > >> > >>I think (IMHO) the most likely combinations are... > >> > >> 3. Low reliability and uni-directional. This will be used > >> where the device and collector are in close proximity, > >> there is high volume and some data loss is acceptable for > >> the given application. Applications such as > >>Attack/Intrusion Detection > >> Traffic Profiling, etc... > >> > >> 5. Bi-directional medium reliability. This will be used > >> where high volume and increased reliability are > >>needed. Applications > >> such as Usage-based Accounting where 95th > >>percentile billing > >> model is used. Or even Traffic Engineering where > >>network policy > >> decisions are based on the data collected. > >> > >> 4. Bi-directional high reliability would be used where the > >> Usage-based Accounting application has strict requirements > >> on data loss. > >> > >>Does IPFIX need to support multiple levels of reliability > >>and directionality? > >> > >>Paul > >> > >>-- > >>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 Nov 11 12:17:17 2002 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 MAA25101 for ; Mon, 11 Nov 2002 12:17:17 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18BI4A-0006AM-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Nov 2002 11:09:38 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18BI48-00069h-00 for ipfix@net.doit.wisc.edu; Mon, 11 Nov 2002 11:09:36 -0600 Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gABH92Y18920; Mon, 11 Nov 2002 18:09:03 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id A588128297; Mon, 11 Nov 2002 18:08:12 +0100 (CET) Date: Mon, 11 Nov 2002 18:08:13 +0100 From: Juergen Quittek To: Randy Bush Cc: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt Message-ID: <23010176.1037038093@[192.168.102.164]> In-Reply-To: References: 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 -- Randy Bush wrote on 09 November 2002 17:16 -0800: >> Somehow, the requirements discussion suffers from a split: >> There are requirements resulting from the intention of >> standardzing a highly reliable metering standard for precise >> accounting (and billing). Differing from these are requirements >> for a simpler metering standard more oriented at what I would >> call "typical Internet reliability". > > the original goal, which the iesg thinks was chartered, is the > latter. Thank you, Randy, for clarifying this (again). To all on the list: Do you think there is consensus on sticking to the original charter goal, or are there strong opinions on getting towards higher reliability of flow metering and export. My preference is going for "typical Internet reliability" and leaving high reliability out of the scope. Juergen > i do not understand how _flow_ measurements can be a > _rigorous_ basis for billing. in my world, we use octet counting > for that kind of application. > > randy > -- 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 Nov 11 12:17:31 2002 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 MAA25128 for ; Mon, 11 Nov 2002 12:17:31 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18BI5O-0006CD-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Nov 2002 11:10:54 -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 18BI5M-0006Bb-00 for ipfix@net.doit.wisc.edu; Mon, 11 Nov 2002 11:10:53 -0600 Received: from riverstonenet.com ([134.141.180.101]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 11 Nov 2002 09:10:20 -0800 Message-ID: <3DCFE3FE.5D957D82@riverstonenet.com> Date: Mon, 11 Nov 2002 12:08:14 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Quittek CC: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt References: <200211081838.NAA06276@ietf.org> <5652968.1036893210@[192.168.102.32]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Nov 2002 17:10:21.0005 (UTC) FILETIME=[374ABFD0:01C289A5] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Juergen Quittek wrote: > > Hi all, > > There are still several requirements issues under dicussion > on the list. We (the authors) only integrated changes into > the document, for which we sensed rough consensus. If you > disagree with our judgement, please speak up. > > Somehow, the requirements discussion suffers from a split: > There are requirements resulting from the intention of > standardzing a highly reliable metering standard for precise > accounting (and billing). Differing from these are requirements > for a simpler metering standard more oriented at what I would > call "typical Internet reliability". > > Anyway, below please find the list of changes between versios -06 > and -07 of draft-ietf-ipfix-reqs. > > Juergen > > 1. Replaced all occurrences of "sampling rate" by "sampling frequency". > > 2. Appended to Section 6.3.2.: > "Flow information might get lost before > it is processed properly by the collecting process. A means to > gauge the amount of loss of flow information MUST be available > from the exporting process and/or the collecting process. Possible > reasons for flow information loss include resource shortage at the > exporter, loss of packets between exporting process and collecting > process, etc. > > If the exporting process is capable of detecting loss of connection > to a collecting process, it SHOULD be able to perform failover to > a specified backup collecting process." > > 3. Replaced in 6.1.: > " 5. source TCP/UDP port number > 6. destination TCP/UDP port number" > by > " 5. if protocol type is TCP or UDP: source TCP/UDP port number > 6. if protocol type is TCP or UDP: destination TCP/UDP port number" > > 4. Inserted in 6.1.: > " 7. if protocol type is ICMP: ICMP type and code" Hopefully this is a SHOULD. Many platforms do not distinguish flow by ICMP type code. > > 5. Replaced text of Section 5.4.: > "The metering process MUST be able to generate timestamps for the > first and the last observed packet of a flow. The timestamp > resolution MUST be at least the one of the sysUpTime [RFC1213], > which is one centisecond." > by > "The metering process MUST be able to generate timestamps for the > first and the last observation of a packet of a flow at the > observation point. The timestamp resolution MUST be at least the > one of the sysUpTime [RFC1213], which is one centisecond." I'm speaking up on this one! Not all platforms timestamp each and every packet and thus cannot give the timestamp for the last observed packet. We need to allow for inactivity based platforms which means the last packet was seen within the window of the inactivity timer. > > 6. Replace in Section 8.1: > "measurement and reporting" by "the metering process and > the exporting process" > > -- Internet-Drafts@ietf.org wrote on 08 November 2002 13:38 -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-07.txt > > Pages : 29 > > Date : 2002-11-8 > > > > 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-07.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-07.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-07.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/ -- 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 Nov 11 12:47:32 2002 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 MAA25713 for ; Mon, 11 Nov 2002 12:47:32 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18BIUX-0006np-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Nov 2002 11:36:53 -0600 Received: from palrel12.hp.com ([156.153.255.237]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18BIUU-0006nj-00 for ipfix@net.doit.wisc.edu; Mon, 11 Nov 2002 11:36:50 -0600 Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel12.hp.com (Postfix) with ESMTP id E5B3FE00C11; Mon, 11 Nov 2002 09:36:47 -0800 (PST) Received: from simail.cup.hp.com (imail@sim.cup.hp.com [15.16.123.26]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id JAA14791; Mon, 11 Nov 2002 09:36:37 -0800 (PST) Received: from cup.hp.com ([15.16.124.96]) by simail.cup.hp.com (InterMail vM.5.01.03.01 201-253-122-118-101-20010319) with ESMTP id <20021111173641.YQV1825.simail.cup.hp.com@cup.hp.com>; Mon, 11 Nov 2002 09:36:41 -0800 Message-ID: <3DCFEB3C.6010602@cup.hp.com> Date: Mon, 11 Nov 2002 09:39:08 -0800 From: Jeff Meyer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: calato@riverstonenet.com Cc: Tal Givoly , carter@qosient.com, "'ipfixx'" Subject: Re: [ipfix] Multiple levels of Reliability and Directionality References: <3DCC4621.2000707@cup.hp.com> <3DCFD4AB.492B2C4B@riverstonenet.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit OK, then based on this minimal definition of bi-directional, I'm in complete agreement. It's the sliperry slope of other things one might want to exchange once this two way channel is open, which concerns me. There are lots of things one might want to exchange, but many of these are probably better addressed by reusing existing protocols, vs. stuffing into the IPFIX protocol. For example, controlling metering process is something which can be separated out from IPFIX. For example by using SNMP and a MeterMIB. Just trying to apply the KISS (Keep it simple stupid) principle. Regards, Jeff Meyer hp calato@riverstonenet.com wrote: > Jeff Meyer wrote: > >>Hi, >> >> I agree with the aspect of varied reliability. >> >> I am less clear on the need for bi-directional >>behavior. The three scenarios you describe I >>agree with, but I'm not sure how the 2nd and >>3rd scenario as described have any dependence >>on bi-directional aside from the some level of >>application layer ack. >> >> > > An application layer ACK all by itself makes the > protocol bi-directional. > > Scenario #1 does not require the sender to also be a receiver. > > Scenarios #2 & #3 do require the sender to also be a > receiver (even if only for ACK's). > > Whether or not we decide to add other features in > scenarios #2 & #3 (such as field negotiation, capability > negotiation, etc...) is up to the WG. But they could > not be added to scenario #1. > > Paul > > > >>Regards, >> >> Jeff Meyer >> >>Tal Givoly wrote: >> >> >>>Paul, >>> >>>I agree completely - that captures the essense of the requirements. It >>>allows balancing different application's need for different levels of >>>reliability. >>> >>>Tal >>> >>>-----Original Message----- >>>From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf >>>Of Carter Bullard >>>Sent: Thursday, November 07, 2002 8:40 AM >>>To: calato@riverstonenet.com; 'ipfixx' >>>Subject: RE: [ipfix] Multiple levels of Reliability and Directionality >>> >>> >>>Hey Paul, >>> My 2 cents worth sez, absolutely yes! >>>Carter >>> >>> >>> >>>>-----Original Message----- >>>>From: majordomo listserver >>>>[mailto:majordomo@mil.doit.wisc.edu] On Behalf Of >>>>calato@riverstonenet.com >>>>Sent: Thursday, November 07, 2002 9:46 AM >>>>To: ipfixx >>>>Subject: [ipfix] Multiple levels of Reliability and Directionality >>>> >>>> >>>> >>>>Does IPFIX need to support multiple levels of reliability >>>>and directionality? >>>> >>>>The applications IPFIX needs to support are quite varied >>>>and have differing needs in terms of reliability. Devices >>>>also have varying needs in terms of directionality. >>>> >>>>I would like the WG to consider requirements on the protocol >>>>to support a tiered approach meet these needs. >>>> >>>>Direction is either bi-directional or uni-directional. I've split >>>>reliability into 3 categories... >>>> >>>> High - Little to no data loss >>>> Medium - Minimal data loss is accepted >>>> Low - Data sent is best effort >>>> >>>> >>>>The six combinations are shown below... >>>> >>>> >>>> | Uni | Bi >>>> -------+------+--------- >>>> High | 1 | 4 >>>> -------+------+-------- >>>> Medium | 2 | 5 >>>> -------+------+-------- >>>> Low | 3 | 6 >>>> >>>> >>>> >>>>I think (IMHO) the most likely combinations are... >>>> >>>> 3. Low reliability and uni-directional. This will be used >>>> where the device and collector are in close proximity, >>>> there is high volume and some data loss is acceptable for >>>> the given application. Applications such as >>>>Attack/Intrusion Detection >>>> Traffic Profiling, etc... >>>> >>>> 5. Bi-directional medium reliability. This will be used >>>> where high volume and increased reliability are >>>>needed. Applications >>>> such as Usage-based Accounting where 95th >>>>percentile billing >>>> model is used. Or even Traffic Engineering where >>>>network policy >>>> decisions are based on the data collected. >>>> >>>> 4. Bi-directional high reliability would be used where the >>>> Usage-based Accounting application has strict requirements >>>> on data loss. >>>> >>>>Does IPFIX need to support multiple levels of reliability >>>>and directionality? >>>> >>>>Paul >>>> >>>>-- >>>>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 Nov 11 12:50:01 2002 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 MAA25834 for ; Mon, 11 Nov 2002 12:50:01 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18BIc8-00071u-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Nov 2002 11:44:44 -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 18BIc6-00071N-00 for ipfix@net.doit.wisc.edu; Mon, 11 Nov 2002 11:44:42 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gABHhU012552; Mon, 11 Nov 2002 09:43:30 -0800 (PST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Nov 2002 09:43:30 -0800 Message-ID: <0A11633F61BD9F40B43ABCC694004F930DACD7@zsc3c026.us.nortel.com> From: "Reinaldo Penno" To: Juergen Quittek , Randy Bush Cc: ipfix@net.doit.wisc.edu Subject: RE: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt Date: Mon, 11 Nov 2002 09:43:23 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C289A9.D4B1B1EE" 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_01C289A9.D4B1B1EE Content-Type: text/plain; charset="iso-8859-1" I would second Paul's proposal about several models of operation. The charter talks about billing and accounting. Some people will also use IPfix for security/intrusion detection, usage-based billing and other related tasks as stated on the requirements draft. I sent an email about this before. We are claiming the protocol will be used for a lot of different purposes but seem to be afraid of taking the necessary steps to uphold that. If we do not have a highly reliable protocol (at least as one model of operation), then usage based billing, intrusion detection and to a certain extent QoS Monitoring should be taken out of the requirements draft (see Appendix section). But as said, I also understand that if somebody just want to do some traffic profiling, a higher reliability might be too much, that's why I said I second Paul's proposal. regards, Reinaldo ps: What is the definition of a "typical" Internet reliability? > -----Original Message----- > From: Juergen Quittek [mailto:quittek@ccrle.nec.de] > Sent: Monday, November 11, 2002 12:08 PM > To: Randy Bush > Cc: ipfix@net.doit.wisc.edu > Subject: Re: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt > > > -- Randy Bush wrote on 09 November 2002 17:16 -0800: > > >> Somehow, the requirements discussion suffers from a split: > >> There are requirements resulting from the intention of > >> standardzing a highly reliable metering standard for precise > >> accounting (and billing). Differing from these are requirements > >> for a simpler metering standard more oriented at what I would > >> call "typical Internet reliability". > > > > the original goal, which the iesg thinks was chartered, is the > > latter. > > Thank you, Randy, for clarifying this (again). > > To all on the list: > Do you think there is consensus on sticking to the original charter > goal, or are there strong opinions on getting towards higher > reliability > of flow metering and export. > > My preference is going for "typical Internet reliability" and leaving > high reliability out of the scope. > > Juergen > > > i do not understand how _flow_ measurements can be a > > _rigorous_ basis for billing. in my world, we use octet counting > > for that kind of application. > > > > randy > > > > > > -- > 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/ > ------_=_NextPart_001_01C289A9.D4B1B1EE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt

I would second Paul's proposal about several models = of operation.

The charter talks about billing and accounting. Some = people will also use IPfix for security/intrusion detection, = usage-based billing and other related tasks as stated on the = requirements draft.

I sent an email about this before. We are claiming = the protocol will be used for a lot of different purposes but seem to = be afraid of taking the necessary steps to uphold that. If we do not = have a highly reliable protocol (at least as one model of operation), = then usage based billing, intrusion detection and to a certain extent = QoS Monitoring should be taken out of the requirements draft (see = Appendix section).

But as said, I also understand that if somebody just = want to do some traffic profiling, a higher reliability might be too = much, that's why I said I second Paul's proposal.

regards,

Reinaldo

ps: What is the definition of a "typical" = Internet reliability?

> -----Original Message-----
> From: Juergen Quittek [mailto:quittek@ccrle.nec.de]
> Sent: Monday, November 11, 2002 12:08 PM
> To: Randy Bush
> Cc: ipfix@net.doit.wisc.edu
> Subject: Re: [ipfix] Re: I-D = ACTION:draft-ietf-ipfix-reqs-07.txt
>
>
> -- Randy Bush wrote on 09 November 2002 17:16 = -0800:
>
> >> Somehow, the requirements discussion = suffers from a split:
> >> There are requirements resulting from = the intention of
> >> standardzing a highly reliable = metering standard for precise
> >> accounting (and billing). Differing = from these are requirements
> >> for a simpler metering standard more = oriented at what I would
> >> call "typical Internet = reliability".
> >
> > <ad> the original goal, which the = iesg thinks was chartered, is the
> > latter.  </ad>
>
> Thank you, Randy, for clarifying this = (again).
>
> To all on the list:
> Do you think there is consensus on sticking to = the original charter
> goal, or are there strong opinions on getting = towards higher
> reliability
> of flow metering and export.
>
> My preference is going for "typical = Internet reliability" and leaving
> high reliability out of the scope.
>
>     Juergen
>
> > <operator> i do not understand how = _flow_ measurements can be a
> > _rigorous_ basis for billing.  in my = world, we use octet counting
> > for that kind of application.  = </operator>
> >
> > randy
> >
>
>
>
> --
> Help        = mailto:majordomo@net.doit.wi= sc.edu and say "help"
> in message body
> Unsubscribe mailto:majordomo@net.doit.wi= sc.edu and say
> "unsubscribe ipfix" in message = body
> Archive     http://ipfix.doit.wisc.edu/archive/
>

------_=_NextPart_001_01C289A9.D4B1B1EE-- -- 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 Nov 11 12:50:06 2002 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 MAA25848 for ; Mon, 11 Nov 2002 12:50:05 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18BIZ3-0006yC-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Nov 2002 11:41:33 -0600 Received: from usmail.xacct.com ([204.253.100.12]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18BIZ1-0006y3-00 for ipfix@net.doit.wisc.edu; Mon, 11 Nov 2002 11:41:31 -0600 Received: from Givoly ([192.168.0.2]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id gABHis205810; Mon, 11 Nov 2002 09:44:55 -0800 From: "Tal Givoly" To: "Juergen Quittek" , "Randy Bush" Cc: Subject: RE: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt Date: Mon, 11 Nov 2002 09:41:05 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <23010176.1037038093@[192.168.102.164]> X-RBL-Warning: (dnsbl.njabl.org) relay tested -- 1016746205 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi, I feel strongly that "typical Internet reliability" is insufficient to make this standard of value for a large set of applications. Although there are many applications that can work in "typical Internet reliability", accounting for usage (whether for billing, interconnect, peering, settlements, charge-back or other uses), which our company has been involved in the past 5 years, is suffering from unreliable methods leading to cost-ineffective deployments to afford any sort of reliable mechanisms. The ability to support carrier-grade requirements is left as an "excercise" for the carriers - one which they struggle with. If we limit the protocol by considering protocols that cannot be (even optionally) reliable, we lose a significant portion of the value of such a protocol altogether. Adopting one of the existing techniques yielding "typical Internet reliability" would merely leave the state of affairs as is today - yet another protocol that needs to be implemented in the network/service elements. The evolution of the Internet has clearly focused, first and foremost, on offering ability to launch services, then on making them secure and scalable enough to actually be used, and finally, it is time to make them business aware. In order to launch services of value, it must be possible to scalably, reliably, account for these services. Protocols exposing the service usage should, at least optionally, have reliability mechanisms - so that carriers interested in such applications would not need to deploy ineffective and ultimately poorly designed systems. Tal -----Original Message----- From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of Juergen Quittek Sent: Monday, November 11, 2002 9:08 AM To: Randy Bush Cc: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt -- Randy Bush wrote on 09 November 2002 17:16 -0800: >> Somehow, the requirements discussion suffers from a split: >> There are requirements resulting from the intention of >> standardzing a highly reliable metering standard for precise >> accounting (and billing). Differing from these are requirements >> for a simpler metering standard more oriented at what I would >> call "typical Internet reliability". > > the original goal, which the iesg thinks was chartered, is the > latter. Thank you, Randy, for clarifying this (again). To all on the list: Do you think there is consensus on sticking to the original charter goal, or are there strong opinions on getting towards higher reliability of flow metering and export. My preference is going for "typical Internet reliability" and leaving high reliability out of the scope. Juergen > i do not understand how _flow_ measurements can be a > _rigorous_ basis for billing. in my world, we use octet counting > for that kind of application. > > randy > -- 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 Nov 11 12:53:19 2002 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 MAA25945 for ; Mon, 11 Nov 2002 12:53:19 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18BIfh-00076q-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Nov 2002 11:48:25 -0600 Received: from rip.psg.com ([147.28.0.39]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18BIff-00076j-00 for ipfix@net.doit.wisc.edu; Mon, 11 Nov 2002 11:48:23 -0600 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18BIfd-000IRf-00; Mon, 11 Nov 2002 09:48:21 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Tal Givoly" Cc: "Juergen Quittek" , Subject: RE: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt References: <23010176.1037038093@[192.168.102.164]> Message-Id: Date: Mon, 11 Nov 2002 09:48:21 -0800 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit > I feel strongly that "typical Internet reliability" is > insufficient to make this standard of value for a large set of > applications. this is trivially true. the question is whether such applications are, or should be, in the charter of this wg. currently they are not. if you wish to change that, then a change to the charter will be needed. in this case, as it would seriously affect many parties, that will be a rather inclusive process and success is far from sure. it would be nice if the wg could abjure mission creep. randy -- 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 Nov 11 12:56:17 2002 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 MAA26011 for ; Mon, 11 Nov 2002 12:56:17 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18BIiN-00079E-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Nov 2002 11:51:11 -0600 Received: from usmail.xacct.com ([204.253.100.12]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18BIiL-000798-00 for ipfix@net.doit.wisc.edu; Mon, 11 Nov 2002 11:51:09 -0600 Received: from peter (inside.us.xacct.com [204.253.100.102]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id gABHsS206016; Mon, 11 Nov 2002 09:54:28 -0800 From: "Peter Ludemann" To: "Randy Bush" , "Juergen Quittek" Cc: Subject: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt Date: Mon, 11 Nov 2002 09:50:37 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: X-RBL-Warning: (dnsbl.njabl.org) relay tested -- 1016746205 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Randy Bush wrote Saturday, November 09, 2002 5:17 PM > i do not understand how _flow_ measurements can be a > _rigorous_ basis for billing. in my world, we use octet counting > for that kind of application. Au contraire, octet counting is so 20th century & dot-com. Because of a need for _rigorous_ billing, and for flexibility in billing/business models, I am currently working on projects that use (amongst other things) for billing: - dynamic IP addresses (which we dynamically map to customer ID) - protocol classification (including dynamically assigned ports such as for FTP and H.323) - octets, adjusted for resends, IP, TCP, application header overhead (don't want to charge end-users more when network quality gets worse) - content type (MIME type, etc.) - QoS (response time, packet loss, etc.) The octet values are just one part of what we get from "flows". Service providers who work with just octet counts are in danger of commoditizing their business; far better to work with the detailed information that flows provide. Anyway, if all you wanted was dreary old octets, you could easily get them by just summing over flows. By the way, the data we collect for billing is also used for network engineering. Of course, for network engineering, the reliability requirements would be lower; but it's nice to be able to get all the data from a single source (well, actually it's not, but you don't want to be bored with issues of redundancy, fail-over, etc.). [As these projects pay the bills, I have zero time to contribute to the other IPFIX documents, unfortunately.] - peter -- 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 Nov 11 13:11:46 2002 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 NAA26428 for ; Mon, 11 Nov 2002 13:11:45 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18BIun-0007Xx-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Nov 2002 12:04:01 -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 18BIul-0007XM-00 for ipfix@net.doit.wisc.edu; Mon, 11 Nov 2002 12:03:59 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gABI2k013031; Mon, 11 Nov 2002 10:02:46 -0800 (PST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Nov 2002 10:02:46 -0800 Message-ID: <0A11633F61BD9F40B43ABCC694004F930DAD32@zsc3c026.us.nortel.com> From: "Reinaldo Penno" To: Randy Bush , Tal Givoly Cc: Juergen Quittek , ipfix@net.doit.wisc.edu Subject: RE: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt Date: Mon, 11 Nov 2002 10:02:44 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C289AC.88D33B00" 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_01C289AC.88D33B00 Content-Type: text/plain; charset="iso-8859-1" I'm kind of confused The charter talks about billing and accounting... http://www.ietf.org/html.charters/ipfix-charter.html "As such, there is a need in industry and the Internet research community for IP devices such as routers to export flow information in a standard way to external systems such as mediation systems, accounting/billing systems, and network management systems to facilitate services such as Internet research, measurement, accounting, and billing. " > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Monday, November 11, 2002 12:48 PM > To: Tal Givoly > Cc: Juergen Quittek; ipfix@net.doit.wisc.edu > Subject: RE: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt > > > > > > I feel strongly that "typical Internet reliability" is > > insufficient to make this standard of value for a large set of > > applications. > > this is trivially true. the question is whether such applications > are, or should be, in the charter of this wg. currently they are > not. if you wish to change that, then a change to the charter will > be needed. in this case, as it would seriously affect many > parties, that will be a rather inclusive process and success is far > from sure. > > it would be nice if the wg could abjure mission creep. > > > > randy > > > -- > 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/ > ------_=_NextPart_001_01C289AC.88D33B00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt

I'm kind of confused

The charter talks about billing and accounting... http://www.ietf.org/html.charters/ipfix-charter.html

"As such, there is a need in industry and the = Internet research community for IP devices such as routers to export = flow information in a standard way to external systems such as = mediation systems, accounting/billing systems, and network management = systems to facilitate services such as Internet research, measurement, = accounting, and billing. "


> -----Original Message-----
> From: Randy Bush [mailto:randy@psg.com]
> Sent: Monday, November 11, 2002 12:48 PM
> To: Tal Givoly
> Cc: Juergen Quittek; = ipfix@net.doit.wisc.edu
> Subject: RE: [ipfix] Re: I-D = ACTION:draft-ietf-ipfix-reqs-07.txt
>
>
> <ad>
>
> > I feel strongly that "typical = Internet reliability" is
> > insufficient to make this standard of = value for a large set of
> > applications.
>
> this is trivially true.  the question is = whether such applications
> are, or should be, in the charter of this = wg.  currently they are
> not.  if you wish to change that, then a = change to the charter will
> be needed.  in this case, as it would = seriously affect many
> parties, that will be a rather inclusive = process and success is far
> from sure.
>
> it would be nice if the wg could abjure mission = creep.
>
> </ad>
>
> randy
>
>
> --
> Help        = mailto:majordomo@net.doit.wi= sc.edu and say "help"
> in message body
> Unsubscribe mailto:majordomo@net.doit.wi= sc.edu and say
> "unsubscribe ipfix" in message = body
> Archive     http://ipfix.doit.wisc.edu/archive/
>

------_=_NextPart_001_01C289AC.88D33B00-- -- 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 Nov 11 13:21:12 2002 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 NAA26709 for ; Mon, 11 Nov 2002 13:21:11 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18BJ4O-00002C-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Nov 2002 12:13:56 -0600 Received: from usmail.xacct.com ([204.253.100.12]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18BJ4N-000025-00 for ipfix@net.doit.wisc.edu; Mon, 11 Nov 2002 12:13:55 -0600 Received: from Givoly ([192.168.0.2]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id gABIAN206321; Mon, 11 Nov 2002 10:10:36 -0800 From: "Tal Givoly" To: "Jeff Meyer" , Cc: , "'ipfixx'" Subject: RE: [ipfix] Multiple levels of Reliability and Directionality Date: Mon, 11 Nov 2002 10:06:34 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3DCFEB3C.6010602@cup.hp.com> X-RBL-Warning: (dnsbl.njabl.org) relay tested -- 1016746205 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Jeff, I agree with you completely here - the protocol should focus on a primarily uni-directional feed from network/service elements (metering+exporting process) to collection process. Adding capabilities (such as parameter configuration, provisioning of other sorts, etc.) here is a slippery slope. I would add, however, that the bi-directionality is needed both for assurance that messages are delivered as well as, IMHO, version, capability and template negotiation (which can be simplified as needed by device). Version and capability negotiation allows for forward/backward interoperability and compatibility. Template negotiation allows for more efficient application-aware communication. As Peter explained earlier (http://ipfix.doit.wisc.edu/archive/1381.html - scenario #1 or #2), it is possible to have all these capabilities and have no impact on the metering/export processes complexity - the complexity can be, optionally, added to the collection process (off the device) in order to allow for interoperability with multiple concurrent versions/capabilities/templates in the devices. Essentially, I believe we achieved consensus regarding the need for template capabilities to allow separation of the data model from the protocol. Version/capability negotiation are very useful for any protocol in order to increase its applicability and useful lifespan. Tal -----Original Message----- From: Jeff Meyer [mailto:jeffm@cup.hp.com] Sent: Monday, November 11, 2002 9:39 AM To: calato@riverstonenet.com Cc: Tal Givoly; carter@qosient.com; 'ipfixx' Subject: Re: [ipfix] Multiple levels of Reliability and Directionality OK, then based on this minimal definition of bi-directional, I'm in complete agreement. It's the sliperry slope of other things one might want to exchange once this two way channel is open, which concerns me. There are lots of things one might want to exchange, but many of these are probably better addressed by reusing existing protocols, vs. stuffing into the IPFIX protocol. For example, controlling metering process is something which can be separated out from IPFIX. For example by using SNMP and a MeterMIB. Just trying to apply the KISS (Keep it simple stupid) principle. Regards, Jeff Meyer hp calato@riverstonenet.com wrote: > Jeff Meyer wrote: > >>Hi, >> >> I agree with the aspect of varied reliability. >> >> I am less clear on the need for bi-directional >>behavior. The three scenarios you describe I >>agree with, but I'm not sure how the 2nd and >>3rd scenario as described have any dependence >>on bi-directional aside from the some level of >>application layer ack. >> >> > > An application layer ACK all by itself makes the > protocol bi-directional. > > Scenario #1 does not require the sender to also be a receiver. > > Scenarios #2 & #3 do require the sender to also be a > receiver (even if only for ACK's). > > Whether or not we decide to add other features in > scenarios #2 & #3 (such as field negotiation, capability > negotiation, etc...) is up to the WG. But they could > not be added to scenario #1. > > Paul > > > >>Regards, >> >> Jeff Meyer >> >>Tal Givoly wrote: >> >> >>>Paul, >>> >>>I agree completely - that captures the essense of the requirements. It >>>allows balancing different application's need for different levels of >>>reliability. >>> >>>Tal >>> >>>-----Original Message----- >>>From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf >>>Of Carter Bullard >>>Sent: Thursday, November 07, 2002 8:40 AM >>>To: calato@riverstonenet.com; 'ipfixx' >>>Subject: RE: [ipfix] Multiple levels of Reliability and Directionality >>> >>> >>>Hey Paul, >>> My 2 cents worth sez, absolutely yes! >>>Carter >>> >>> >>> >>>>-----Original Message----- >>>>From: majordomo listserver >>>>[mailto:majordomo@mil.doit.wisc.edu] On Behalf Of >>>>calato@riverstonenet.com >>>>Sent: Thursday, November 07, 2002 9:46 AM >>>>To: ipfixx >>>>Subject: [ipfix] Multiple levels of Reliability and Directionality >>>> >>>> >>>> >>>>Does IPFIX need to support multiple levels of reliability >>>>and directionality? >>>> >>>>The applications IPFIX needs to support are quite varied >>>>and have differing needs in terms of reliability. Devices >>>>also have varying needs in terms of directionality. >>>> >>>>I would like the WG to consider requirements on the protocol >>>>to support a tiered approach meet these needs. >>>> >>>>Direction is either bi-directional or uni-directional. I've split >>>>reliability into 3 categories... >>>> >>>> High - Little to no data loss >>>> Medium - Minimal data loss is accepted >>>> Low - Data sent is best effort >>>> >>>> >>>>The six combinations are shown below... >>>> >>>> >>>> | Uni | Bi >>>> -------+------+--------- >>>> High | 1 | 4 >>>> -------+------+-------- >>>> Medium | 2 | 5 >>>> -------+------+-------- >>>> Low | 3 | 6 >>>> >>>> >>>> >>>>I think (IMHO) the most likely combinations are... >>>> >>>> 3. Low reliability and uni-directional. This will be used >>>> where the device and collector are in close proximity, >>>> there is high volume and some data loss is acceptable for >>>> the given application. Applications such as >>>>Attack/Intrusion Detection >>>> Traffic Profiling, etc... >>>> >>>> 5. Bi-directional medium reliability. This will be used >>>> where high volume and increased reliability are >>>>needed. Applications >>>> such as Usage-based Accounting where 95th >>>>percentile billing >>>> model is used. Or even Traffic Engineering where >>>>network policy >>>> decisions are based on the data collected. >>>> >>>> 4. Bi-directional high reliability would be used where the >>>> Usage-based Accounting application has strict requirements >>>> on data loss. >>>> >>>>Does IPFIX need to support multiple levels of reliability >>>>and directionality? >>>> >>>>Paul >>>> >>>>-- >>>>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 Nov 11 13:25:13 2002 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 NAA26818 for ; Mon, 11 Nov 2002 13:25:12 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18BJ84-00007F-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Nov 2002 12:17:44 -0600 Received: from usmail.xacct.com ([204.253.100.12]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18BJ83-000074-00 for ipfix@net.doit.wisc.edu; Mon, 11 Nov 2002 12:17:43 -0600 Received: from Givoly ([192.168.0.2]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id gABIK7206492; Mon, 11 Nov 2002 10:20:16 -0800 From: "Tal Givoly" To: "Reinaldo Penno" , "Randy Bush" Cc: "Juergen Quittek" , Subject: RE: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt Date: Mon, 11 Nov 2002 10:16:18 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03DC_01C2896B.5FFDCDD0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <0A11633F61BD9F40B43ABCC694004F930DAD32@zsc3c026.us.nortel.com> X-RBL-Warning: (dnsbl.njabl.org) relay tested -- 1016746205 Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. ------=_NextPart_000_03DC_01C2896B.5FFDCDD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txtReinaldo, I couldn't have put it better myself. Our involvement in this working group is based on this charter, explicitly stating the support for billing and accounting as possible applications of the protocol. If this is the case, the requirements may need to be clarified, but the working group charter already addresses the applications requiring a reliable protocol (at least in part of its operational modes). Tal -----Original Message----- From: Reinaldo Penno [mailto:rpenno@nortelnetworks.com] Sent: Monday, November 11, 2002 10:03 AM To: Randy Bush; Tal Givoly Cc: Juergen Quittek; ipfix@net.doit.wisc.edu Subject: RE: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt I'm kind of confused The charter talks about billing and accounting... http://www.ietf.org/html.charters/ipfix-charter.html "As such, there is a need in industry and the Internet research community for IP devices such as routers to export flow information in a standard way to external systems such as mediation systems, accounting/billing systems, and network management systems to facilitate services such as Internet research, measurement, accounting, and billing. " > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Monday, November 11, 2002 12:48 PM > To: Tal Givoly > Cc: Juergen Quittek; ipfix@net.doit.wisc.edu > Subject: RE: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt > > > > > > I feel strongly that "typical Internet reliability" is > > insufficient to make this standard of value for a large set of > > applications. > > this is trivially true. the question is whether such applications > are, or should be, in the charter of this wg. currently they are > not. if you wish to change that, then a change to the charter will > be needed. in this case, as it would seriously affect many > parties, that will be a rather inclusive process and success is far > from sure. > > it would be nice if the wg could abjure mission creep. > > > > randy > > > -- > 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/ > ------=_NextPart_000_03DC_01C2896B.5FFDCDD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ipfix] Re: I-D = ACTION:draft-ietf-ipfix-reqs-07.txt
Reinaldo,
 
I=20 couldn't have put it better myself. Our involvement in this working = group is=20 based on this charter, explicitly stating the support for billing and = accounting=20 as possible applications of the protocol. If this is the case, the = requirements=20 may need to be clarified, but the working group charter already = addresses=20 the applications requiring a reliable protocol (at least in part of its=20 operational modes).
 
Tal
-----Original Message-----
From: Reinaldo Penno=20 [mailto:rpenno@nortelnetworks.com]
Sent: Monday, November = 11, 2002=20 10:03 AM
To: Randy Bush; Tal Givoly
Cc: Juergen = Quittek;=20 ipfix@net.doit.wisc.edu
Subject: RE: [ipfix] Re: I-D=20 ACTION:draft-ietf-ipfix-reqs-07.txt

I'm kind of confused

The charter talks about billing and accounting... http://www.ietf.org/html.charters/ipfix-charter.html<= /FONT>=20

"As such, there is a need in industry and the = Internet=20 research community for IP devices such as routers to export flow = information=20 in a standard way to external systems such as mediation systems,=20 accounting/billing systems, and network management systems to = facilitate=20 services such as Internet research, measurement, accounting, and = billing.=20 "


> -----Original Message-----
>=20 From: Randy Bush [mailto:randy@psg.com] =
> Sent: Monday, November 11, 2002 12:48 PM =
> To: Tal Givoly
> Cc: = Juergen Quittek;=20 ipfix@net.doit.wisc.edu
> Subject: RE: = [ipfix] Re:=20 I-D ACTION:draft-ietf-ipfix-reqs-07.txt
> =
>
> = <ad>=20
>
> > I feel = strongly that=20 "typical Internet reliability" is
> >=20 insufficient to make this standard of value for a large set of=20
> > applications.
>=20
> this is trivially true.  the = question is=20 whether such applications
> are, or = should be, in=20 the charter of this wg.  currently they are
>=20 not.  if you wish to change that, then a change to the charter=20 will
> be needed.  in this case, as = it would=20 seriously affect many
> parties, that = will be a=20 rather inclusive process and success is far
> from=20 sure.
>
> it = would be=20 nice if the wg could abjure mission creep.
>=20
> </ad>
>=20
> randy
>=20
>
> = --
> Help        mailto:majordomo@net.doit.wis= c.edu=20 and say "help"
> in message body =
> Unsubscribe mailto:majordomo@net.doit.wis= c.edu=20 and say
> "unsubscribe ipfix" in message=20 body
> Archive     http://ipfix.doit.wisc.edu/archive/ =
>

------=_NextPart_000_03DC_01C2896B.5FFDCDD0-- -- 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 Nov 11 13:49:10 2002 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 NAA27306 for ; Mon, 11 Nov 2002 13:49:09 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18BJXO-0000qv-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Nov 2002 12:43:54 -0600 Received: from rip.psg.com ([147.28.0.39]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18BJXN-0000qp-00 for ipfix@net.doit.wisc.edu; Mon, 11 Nov 2002 12:43:53 -0600 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18BJXF-000JwT-00; Mon, 11 Nov 2002 10:43:45 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Reinaldo Penno" Cc: Tal Givoly , Juergen Quittek , ipfix@net.doit.wisc.edu Subject: RE: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt References: <0A11633F61BD9F40B43ABCC694004F930DAD32@zsc3c026.us.nortel.com> Message-Id: Date: Mon, 11 Nov 2002 10:43:45 -0800 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit > The charter talks about billing and accounting... yup. use of the current style stuff to do those kinds of things is reasonable. bending the current stuff in order to boil the ocean can be done in experimental drafts. but the primary goal of this wg is to reconcile some _current_ inter-vendor incompatibilities, fix congestion control, etc. perhaps we should have two wgs, ipwork and ipfix? randy -- 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 Nov 11 14:20:49 2002 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 OAA28464 for ; Mon, 11 Nov 2002 14:20:49 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18BK1G-0001bG-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Nov 2002 13:14:46 -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 18BK1E-0001aW-00 for ipfix@net.doit.wisc.edu; Mon, 11 Nov 2002 13:14:44 -0600 Received: from riverstonenet.com ([134.141.180.81]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 11 Nov 2002 11:14:11 -0800 Message-ID: <3DD00105.C1F767EA@riverstonenet.com> Date: Mon, 11 Nov 2002 14:12:05 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Tal Givoly CC: Jeff Meyer , carter@qosient.com, "'ipfixx'" Subject: Re: [ipfix] Multiple levels of Reliability and Directionality References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Nov 2002 19:14:12.0288 (UTC) FILETIME=[84AE8C00:01C289B6] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Let me see if we all agree on a couple things... 1. There is no such thing as partially uni-directional. 2. IPFIX ought to support a uni-directional mode of operation. Paul Tal Givoly wrote: > > Jeff, > > I agree with you completely here - the protocol should focus on a primarily > uni-directional feed from network/service elements (metering+exporting > process) to collection process. Adding capabilities (such as parameter > configuration, provisioning of other sorts, etc.) here is a slippery slope. > > I would add, however, that the bi-directionality is needed both for > assurance that messages are delivered as well as, IMHO, version, capability > and template negotiation (which can be simplified as needed by device). > Version and capability negotiation allows for forward/backward > interoperability and compatibility. Template negotiation allows for more > efficient application-aware communication. As Peter explained earlier > (http://ipfix.doit.wisc.edu/archive/1381.html - scenario #1 or #2), it is > possible to have all these capabilities and have no impact on the > metering/export processes complexity - the complexity can be, optionally, > added to the collection process (off the device) in order to allow for > interoperability with multiple concurrent versions/capabilities/templates in > the devices. > > Essentially, I believe we achieved consensus regarding the need for template > capabilities to allow separation of the data model from the protocol. > Version/capability negotiation are very useful for any protocol in order to > increase its applicability and useful lifespan. > > Tal > > -----Original Message----- > From: Jeff Meyer [mailto:jeffm@cup.hp.com] > Sent: Monday, November 11, 2002 9:39 AM > To: calato@riverstonenet.com > Cc: Tal Givoly; carter@qosient.com; 'ipfixx' > Subject: Re: [ipfix] Multiple levels of Reliability and Directionality > > OK, then based on this minimal definition of > bi-directional, I'm in complete agreement. > > It's the sliperry slope of other things one might > want to exchange once this two way channel is open, > which concerns me. There are lots of things one > might want to exchange, but many of these are probably > better addressed by reusing existing protocols, > vs. stuffing into the IPFIX protocol. > > For example, controlling metering process is something > which can be separated out from IPFIX. For example > by using SNMP and a MeterMIB. > > Just trying to apply the KISS (Keep it simple stupid) > principle. > > Regards, > > Jeff Meyer > hp > > calato@riverstonenet.com wrote: > > > Jeff Meyer wrote: > > > >>Hi, > >> > >> I agree with the aspect of varied reliability. > >> > >> I am less clear on the need for bi-directional > >>behavior. The three scenarios you describe I > >>agree with, but I'm not sure how the 2nd and > >>3rd scenario as described have any dependence > >>on bi-directional aside from the some level of > >>application layer ack. > >> > >> > > > > An application layer ACK all by itself makes the > > protocol bi-directional. > > > > Scenario #1 does not require the sender to also be a receiver. > > > > Scenarios #2 & #3 do require the sender to also be a > > receiver (even if only for ACK's). > > > > Whether or not we decide to add other features in > > scenarios #2 & #3 (such as field negotiation, capability > > negotiation, etc...) is up to the WG. But they could > > not be added to scenario #1. > > > > Paul > > > > > > > >>Regards, > >> > >> Jeff Meyer > >> > >>Tal Givoly wrote: > >> > >> > >>>Paul, > >>> > >>>I agree completely - that captures the essense of the requirements. It > >>>allows balancing different application's need for different levels of > >>>reliability. > >>> > >>>Tal > >>> > >>>-----Original Message----- > >>>From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf > >>>Of Carter Bullard > >>>Sent: Thursday, November 07, 2002 8:40 AM > >>>To: calato@riverstonenet.com; 'ipfixx' > >>>Subject: RE: [ipfix] Multiple levels of Reliability and Directionality > >>> > >>> > >>>Hey Paul, > >>> My 2 cents worth sez, absolutely yes! > >>>Carter > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: majordomo listserver > >>>>[mailto:majordomo@mil.doit.wisc.edu] On Behalf Of > >>>>calato@riverstonenet.com > >>>>Sent: Thursday, November 07, 2002 9:46 AM > >>>>To: ipfixx > >>>>Subject: [ipfix] Multiple levels of Reliability and Directionality > >>>> > >>>> > >>>> > >>>>Does IPFIX need to support multiple levels of reliability > >>>>and directionality? > >>>> > >>>>The applications IPFIX needs to support are quite varied > >>>>and have differing needs in terms of reliability. Devices > >>>>also have varying needs in terms of directionality. > >>>> > >>>>I would like the WG to consider requirements on the protocol > >>>>to support a tiered approach meet these needs. > >>>> > >>>>Direction is either bi-directional or uni-directional. I've split > >>>>reliability into 3 categories... > >>>> > >>>> High - Little to no data loss > >>>> Medium - Minimal data loss is accepted > >>>> Low - Data sent is best effort > >>>> > >>>> > >>>>The six combinations are shown below... > >>>> > >>>> > >>>> | Uni | Bi > >>>> -------+------+--------- > >>>> High | 1 | 4 > >>>> -------+------+-------- > >>>> Medium | 2 | 5 > >>>> -------+------+-------- > >>>> Low | 3 | 6 > >>>> > >>>> > >>>> > >>>>I think (IMHO) the most likely combinations are... > >>>> > >>>> 3. Low reliability and uni-directional. This will be used > >>>> where the device and collector are in close proximity, > >>>> there is high volume and some data loss is acceptable for > >>>> the given application. Applications such as > >>>>Attack/Intrusion Detection > >>>> Traffic Profiling, etc... > >>>> > >>>> 5. Bi-directional medium reliability. This will be used > >>>> where high volume and increased reliability are > >>>>needed. Applications > >>>> such as Usage-based Accounting where 95th > >>>>percentile billing > >>>> model is used. Or even Traffic Engineering where > >>>>network policy > >>>> decisions are based on the data collected. > >>>> > >>>> 4. Bi-directional high reliability would be used where the > >>>> Usage-based Accounting application has strict requirements > >>>> on data loss. > >>>> > >>>>Does IPFIX need to support multiple levels of reliability > >>>>and directionality? > >>>> > >>>>Paul > >>>> > >>>>-- > >>>>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 Nov 11 14:33:10 2002 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 OAA28758 for ; Mon, 11 Nov 2002 14:33:10 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18BKE3-0001x7-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Nov 2002 13:27:59 -0600 Received: from palrel10.hp.com ([156.153.255.245]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18BKE0-0001x0-00 for ipfix@net.doit.wisc.edu; Mon, 11 Nov 2002 13:27:57 -0600 Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel10.hp.com (Postfix) with ESMTP id 16390C00AE8; Mon, 11 Nov 2002 11:27:54 -0800 (PST) Received: from simail.cup.hp.com (imail@sim.cup.hp.com [15.16.123.26]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id LAA22262; Mon, 11 Nov 2002 11:27:44 -0800 (PST) Received: from cup.hp.com ([15.16.124.96]) by simail.cup.hp.com (InterMail vM.5.01.03.01 201-253-122-118-101-20010319) with ESMTP id <20021111192747.YUN1825.simail.cup.hp.com@cup.hp.com>; Mon, 11 Nov 2002 11:27:47 -0800 Message-ID: <3DD00546.9070108@cup.hp.com> Date: Mon, 11 Nov 2002 11:30:14 -0800 From: Jeff Meyer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: Tal Givoly Cc: Juergen Quittek , Randy Bush , ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi, I completely agree w/ Tal's response here. The charter states that the IPFIX protocol is meant to address the following use case: export flow information in a standard way to external systems such as mediation systems, accounting/billing systems, and network management systems to facilitate services such as Internet research, measurement, accounting, and billing. Accounting and billing are not activities which respond well to unreliable delivery of information. IP Flows are a very good source of information for billing, since it provides identity information for both the consumer and the target service (IP addresses and ports) as well as metrics on the usage of that flow (duration, pkts, bytes, etc.) In a deployment where accounting is to be done via flows, it is imperative that the metering process and the exporting process provide a reliable delivery stream. It may be the case that an unreliable stream is "good enough" (apparently so given the popularity of NetFlow), but many many customers I see don't think it is "good enough" for their applications. In some cases, given the lack of alternatives they'll go with this anyway. So, I think the idea of different profiles, potentially addressed by different protocols may be the best solution to addressing the charter. In particular, NFv9 and IPDR seem like they may fit the bill jointly. NFv9 for UDP based unreliable delivery and IPDR for TCP/SCTP based reliable delivery. Regards, Jeff Meyer Tal Givoly wrote: > Hi, > > I feel strongly that "typical Internet reliability" is insufficient to make > this standard of value for a large set of applications. > > Although there are many applications that can work in "typical Internet > reliability", accounting for usage (whether for billing, interconnect, > peering, settlements, charge-back or other uses), which our company has been > involved in the past 5 years, is suffering from unreliable methods leading > to cost-ineffective deployments to afford any sort of reliable mechanisms. > The ability to support carrier-grade requirements is left as an "excercise" > for the carriers - one which they struggle with. > > If we limit the protocol by considering protocols that cannot be (even > optionally) reliable, we lose a significant portion of the value of such a > protocol altogether. Adopting one of the existing techniques yielding > "typical Internet reliability" would merely leave the state of affairs as is > today - yet another protocol that needs to be implemented in the > network/service elements. > > The evolution of the Internet has clearly focused, first and foremost, on > offering ability to launch services, then on making them secure and scalable > enough to actually be used, and finally, it is time to make them business > aware. In order to launch services of value, it must be possible to > scalably, reliably, account for these services. Protocols exposing the > service usage should, at least optionally, have reliability mechanisms - so > that carriers interested in such applications would not need to deploy > ineffective and ultimately poorly designed systems. > > Tal > -----Original Message----- > From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf > Of Juergen Quittek > Sent: Monday, November 11, 2002 9:08 AM > To: Randy Bush > Cc: ipfix@net.doit.wisc.edu > Subject: Re: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt > > > -- Randy Bush wrote on 09 November 2002 17:16 -0800: > > >>>Somehow, the requirements discussion suffers from a split: >>>There are requirements resulting from the intention of >>>standardzing a highly reliable metering standard for precise >>>accounting (and billing). Differing from these are requirements >>>for a simpler metering standard more oriented at what I would >>>call "typical Internet reliability". >>> >> the original goal, which the iesg thinks was chartered, is the >>latter. >> > > Thank you, Randy, for clarifying this (again). > > To all on the list: > Do you think there is consensus on sticking to the original charter > goal, or are there strong opinions on getting towards higher reliability > of flow metering and export. > > My preference is going for "typical Internet reliability" and leaving > high reliability out of the scope. > > Juergen > > >> i do not understand how _flow_ measurements can be a >>_rigorous_ basis for billing. in my world, we use octet counting >>for that kind of application. >> >>randy >> >> > > > > -- > 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 Nov 11 14:42:33 2002 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 OAA28979 for ; Mon, 11 Nov 2002 14:42:33 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18BKMw-0002CQ-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Nov 2002 13:37:10 -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 18BKMu-0002BP-00 for ipfix@net.doit.wisc.edu; Mon, 11 Nov 2002 13:37:08 -0600 Received: from riverstonenet.com ([134.141.180.81]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 11 Nov 2002 11:36:34 -0800 Message-ID: <3DD00643.E62AF044@riverstonenet.com> Date: Mon, 11 Nov 2002 14:34:27 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Randy Bush CC: Reinaldo Penno , Tal Givoly , Juergen Quittek , ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt References: <0A11633F61BD9F40B43ABCC694004F930DAD32@zsc3c026.us.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Nov 2002 19:36:34.0805 (UTC) FILETIME=[A4E26250:01C289B9] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Randy Bush wrote: > > > The charter talks about billing and accounting... > > yup. use of the current style stuff to do those kinds of things is > reasonable. bending the current stuff in order to boil the ocean > can be done in experimental drafts. but the primary goal of this > wg is to reconcile some _current_ inter-vendor incompatibilities, > fix congestion control, etc. > This thread started with a question on reliability... > Somehow, the requirements discussion suffers from a split: > There are requirements resulting from the intention of > standardzing a highly reliable metering standard for precise > accounting (and billing). Differing from these are requirements > for a simpler metering standard more oriented at what I would > call "typical Internet reliability". the original goal, which the iesg thinks was chartered, is the latter. To the charter once again... "o Ensure that the flow export system is reliable in that it will minimize the likelihood of flow data being lost due to resource constraints in the exporter or receiver and to accurately report such loss if it occurs. " I see mention of reliability but nothing about to what level. The guiding principal has been to try and standardize what is "out there" today. Right now we have Netflow with none, LFAP with a reliable transport and CRANE with application level (not an exhaustive list, just the ones that come to mind). It would seem that coming to agreement on reliability is within the charter. Paul > perhaps we should have two wgs, ipwork and ipfix? > > randy > > -- > 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 Nov 11 17:29:41 2002 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 RAA04571 for ; Mon, 11 Nov 2002 17:29:41 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18BMdR-000620-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Nov 2002 16:02:21 -0600 Received: from mailhost2.auckland.ac.nz ([130.216.191.4]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18BMdP-00061q-00 for ipfix@net.doit.wisc.edu; Mon, 11 Nov 2002 16:02:19 -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 LAA13972 for ; Tue, 12 Nov 2002 11:02:12 +1300 (NZDT) Received: from postbox.auckland.ac.nz (postbox.auckland.ac.nz [130.216.191.126]) by mailhost.auckland.ac.nz (Mirapoint Messaging Server MOS 3.2.1.6-EA) with ESMTP id AJR36304; Tue, 12 Nov 2002 11:02:11 +1300 (NZDT) Received: from localhost (hotlava.auckland.ac.nz [130.216.191.123]) by postbox.auckland.ac.nz (8.11.6/8.11.6) with ESMTP id gABM2Bw22616 for ; Tue, 12 Nov 2002 11:02:11 +1300 Received: from nebbiolo.itss.auckland.ac.nz (nebbiolo.itss.auckland.ac.nz [130.216.4.167]) by hotlava.auckland.ac.nz (IMP) with HTTP for ; Tue, 12 Nov 2002 11:02:11 +1300 Message-ID: <1037052131.3dd028e3c8fe3@hotlava.auckland.ac.nz> Date: Tue, 12 Nov 2002 11:02:11 +1300 From: Nevil Brownlee To: ipfix@net.doit.wisc.edu Subject: [ipfix] Agenda for Atlanta MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_923500563655976026b8b681" 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 This message is in MIME format. --=_923500563655976026b8b681 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Hello all: Attached herewith is the latest version of the agenda for our WG session at the Atlanta IETF. At that meeting, let's focus on reaching consensus on the IPFIX requirements. As far as I can see, there aren't many issues remaining, and it's *very* important that we finish the requirements and get them submitted as an RFC. Also, we need to get as far as we can towards consensus on selecting the IPFIX protocol. As you'll see from our current list of milestones, our goal is to select the protocol, and produce revised versions of the Architecture and Data Model drafts in time for the next IETF meeting, i.e. March next year. Don't forget that reaching consensus is a process of negotiation; we need to standardise something which will be useful (and therefore widely used) real soon now. If we agree there's good reason to extend/develop the IPFIX model further, we mustn't let such development delay our immediate goals. See you in Atlanta, 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 IMP: http://horde.org/imp/ --=_923500563655976026b8b681 Content-Type: text/plain; name="ipfix-agenda.txt" Content-Disposition: attachment; filename="ipfix-agenda.txt" Content-Transfer-Encoding: base64 SVBGSVggQWdlbmRhIGZvciBBdGxhbnRhCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQoKVGhlIElQ RklYIFdHIG1lZXRpbmcgaXMgc2NoZWR1bGVkIGZvciBUaHVyc2RheSAyMSBOb3YgMDIsCmF0IDE1 MzAgKGxhc3Qgc2Vzc2lvbiBUaHVyc2RheSBhZnRlcm5vb24pLgoKbWludXRlcwoKIDIgIDEpIEFn ZW5kYSBSZXZpZXcKCiAzICAyKSBJbnRlcm5ldCBNZWFzdXJlbWVudHMgUmVzZWFyY2ggR3JvdXAg KGltcmcpICAgCiAgICAgICAgICBPdmVydmlldy4gIE1hcmsgQWxsbWFuCgoxMCAgMykgUmVsYXRp b25zaGlwIGJldHdlZW4gUFNBTVAgYW5kIElQRklYCiAgICAgICAgICAgSi4gUXVpdHRlaywgIGRy YWZ0LXF1aXR0ZWstcHNhbXAtaXBmaXgtMDAudHh0Cgo0MCAgNCkgUmVxdWlyZW1lbnRzIERyYWZ0 ICBkcmFmdC1pZXRmLWlwZml4LXJlcXMtMDcudHh0IDw8PDwKICAgICAgICsgUmV2aWV3IG9mIGNo YW5nZXMgc2luY2UgWW9rb2hhbWEgbWVldGluZwogICAgICAgKyBPcGVuIGlzc3VlcwogICAgICAg ICAtIFdlIG5lZWQgdG8gcmVhY2ggY29uc2Vuc3VzIG9uIHRoZXNlOyBkb2luZyBzbwogICAgICAg ICAgIHNob3VsZCBhaWQgdGhlIHByb3RvY29sIGV2YWx1YXRpb24uCiAgIAo1MCAzKSBFdmFsdWF0 aW9uIFByb2Nlc3MKICAgICAgKyBSZXBvcnQKICAgICAgICAtIEluZGl2aWR1YWwgdGVhbSBtZW1i ZXIgZHJhZnRzCiAgICAgICAgICAgIGRyYWZ0LWdvcGFsLWlwZml4LWV2YWwtY29udHJpYi0wMC50 eHQgPDw8PAogICAgICAgICAgICBkcmFmdC1sZWluZW4taXBmaXgtZXZhbC1jb250cmliLTAwLnR4 dCA8PDw8CiAgICAgICAgLSBSb3VnaCBDb25zZW5zdXMgcmVwb3J0IGZyb20gdGhlIHRlYW0KICAg ICAgICAgICAgZHJhZnQtaWV0Zi1pcGZpeC1wcm90b2NvbC1ldmFsLTAwLnR4dCA8PDw8CgogICAg ICArIERpc2N1c3Npb246IGhvdyB0byBwcm9jZWVkCiAgICAgICAgLSBDb3VsZCB3ZSBlbGltaW5h dGUgc29tZSBvZiB0aGUgcHJvdG9jb2xzIGFzIGEgZmlyc3Qgc3RlcD8KICAgICAgICAtIENhbiB3 ZSByZWFjaCBjb25zZW5zdXMgb24gb25lIG9mIHRoZSBjYW5kaWRhdGVzPyAKICAgICAgICAtIFdo YXQgY2hhbmdlcyBhcmUgKnJlcXVpcmVkKiBpbiB0aGUgY2hvc2VuIHByb3RvY29sPwoKMTAgNCkg UmV2aWV3IG9mIFdHIE1pbGVzdG9uZXMKCiA1IDUpIEFueXRoaW5nIGVsc2UKCklmIHlvdSBoYXZl IG90aGVyIGl0ZW1zIHlvdSdkIGxpa2UgdG8gc2VlIGRpc2N1c3NlZCwgcGxlYXNlIGFkdmlzZQp0 aGUgV0cgY2hhaXJzLCBieSBlbWFpbCB0byBpcGZpeC1jaGFpcnNAbmV0LmRvaXQud2lzYy5lZHUK CgpOT1RFOiBUaGUgZHJhZnRzIG1hcmtlZCA8PDw8IGFib3ZlIG1pc3NlZCB0aGUgbWVldGluZyBk cmFmdCBkZWFkbGluZS4KICAgICAgTWVhbnRpbWUsIHRoZXkgYXJlIGF2YWlsYWJsZSBhdAogICAg ICAgICAgICAgd3d3LmF1Y2tsYW5kLmFjLm56L25ldC9pcGZpeC8KICAgICAgCgoKUmV2aXNlZCBN aWxlc3RvbmVzCgogIERvbmUgICAgICAgIFN1Ym1pdCBSZXZpc2VkIEludGVybmV0LURyYWZ0IG9u IElQIEZsb3cgRXhwb3J0IFJlcXVpcmVtZW50cyAKICBEb25lICAgICAgICBTdWJtaXQgSW50ZXJu ZXQtRHJhZnQgb24gSVAgRmxvdyBFeHBvcnQgQXJjaGl0ZWN0dXJlIAogIERvbmUgICAgICAgIFN1 Ym1pdCBJbnRlcm5ldC1EcmFmdCBvbiBJUCBGbG93IEV4cG9ydCBEYXRhIE1vZGVsIAogIERvbmUg ICAgICAgIFN1Ym1pdCBBZHZvY2F0ZSBJbnRlcm5ldC1EcmFmdHMgZm9yIENhbmRpZGF0ZSBQcm90 b2NvbHMKCiogTm92IDAyICAgICAgU3VibWl0IEludGVybmV0LURyYWZ0IG9uIElQRklYIFByb3Rv Y29sIEV2YWx1YXRpb24gUmVwb3J0CgoqIERlYyAwMiAgICAgIFN1Ym1pdCBJbnRlcm5ldC1EcmFm dCBvbiBJUCBGbG93IEV4cG9ydCBBcHBsaWNhYmlsaXR5IFN0YXRlbWVudAoKCiogRmViIDAzICAg ICAgU2VsZWN0IElQRklYIHByb3RvY29sLCByZXZpc2UgQXJjaGl0ZWN0dXJlIGFuZCBEYXRhIE1v ZGVsIGRyYWZ0cwoKCiAgQXByIDAzICAgICAgU3VibWl0IElQRlgtUkVRVUlSRU1FTlRTIHRvIElF U0cgZm9yIHB1YmxpY2F0aW9uIAogICAgICAgICAgICAgICAgYXMgSW5mb3JtYXRpb25hbCBSRkMg CgoqIEFwciAwMyAgICAgIFN1Ym1pdCBJUEZJWCBQcm90b2NvbCBFdmFsdWF0aW9uIFJlcG9ydCB0 byBJRVNHIGZvciBwdWJsaWNhdGlvbgogICAgICAgICAgICAgICAgYXMgSW5mb3JtYXRpb25hbCBS RkMKCgogIEF1ZyAwMyAgICAgIFN1Ym1pdCBJUEZYLUFSQ0hJVEVDVFVSRSB0byBJRVNHIGZvciBw dWJsaWNhdGlvbgogICAgICAgICAgICAgICAgYXMgUHJvcG9zZWQgU3RhbmRhcmQgUkZDCiAgQXVn IDAzICAgICAgU3VibWl0IElQRlgtREFUQU1PREVMIHRvIElFU0cgZm9yIHB1YmxpY2F0aW9uIAog ICAgICAgICAgICAgICAgYXMgSW5mb3JtYXRpb25hbCBSRkMgCiogQXVnIDAzICAgICAgU3VibWl0 IElQRlgtQVBQTElDQUJJTElUWSB0byBJRVNHIGZvciBwdWJsaWNhdGlvbiAKICAgICAgICAgICAg ICAgIGFzIEluZm9ybWF0aW9uYWwgUkZDIAoKKiBpbmRpY2F0ZXMgbmV3IG1pbGVzdG9uZXMKCgpJ UEZJWCBXRzogRG9jdW1lbnQgc3RhdHVzLCA3IE5vdiAwMgoKRXZhbHVhdGlvbiBkcmFmdHM6CiAg QWR2b2NhdGUgKGluZGl2aWR1YWwpIGRyYWZ0cyAgKHB1Ymxpc2hlZCkKICAgIGRyYWZ0LWNhbGF0 by1pcGZpeC1sZmFwLWV2YWwtMDAudHh0CiAgICBkcmFmdC1jbGFpc2UtaXBmaXgtZXZhbC1uZXRm bG93LTAzLnR4dAogICAgZHJhZnQta3poYW5nLWlwZml4LWV2YWwtY3JhbmUtMDAudHh0CiAgICBk cmFmdC1tZXllci1pcGZpeC1pcGRyLWV2YWwtMDAudHh0CiAgICBkcmFmdC16YW5kZXItaXBmaXgt ZGlhbWV0ZXItZXZhbC0wMC50eHQKCiAgRXZhbHVhdGlvbiBSZXZpZXcgZHJhZnRzCiAgICBkcmFm dC1nb3BhbC1pcGZpeC1ldmFsLWNvbnRyaWItMDAudHh0ICA8PDw8CiAgICBkcmFmdC1sZWluZW4t aXBmaXgtZXZhbC1jb250cmliLTAwLnR4dCA8PDw8CgogICAgZHJhZnQtaWV0Zi1pcGZpeC1wcm90 b2NvbC1ldmFsLTAwLnR4dCAgPDw8PAoKV0cgZHJhZnRzOgogIFVuZGVyIGRpc2N1c3Npb24KICAg IGRyYWZ0LWlldGYtaXBmaXgtcmVxcy0wNy50eHQgPDw8PAoKICBPbiBob2xkIHVudGlsIGV2YWx1 YXRpb24gY29tcGxldGU6CiAgICBkcmFmdC1pZXRmLWlwZml4LWFyY2hpdGVjdHVyZS0wMi50eHQK ICAgIGRyYWZ0LWlldGYtaXBmaXgtZGF0YS0wMC50eHQgIChFWFBJUkVEKQoKICBQcm9wb3NlZCBX RyBkcmFmdAogICAgZHJhZnQtenNlYnktaXBmaXgtYXBwbGljYWJpbGl0eS0wMC50eHQKCjw8PDwg ZHJhZnRzIGFyZSBhdCB3d3cuYXVja2xhbmQuYWMubnovbmV0L2lwZml4LwogICAgIGFuZCBhbHNv IGF0IGh0dHA6Ly9pcGZpeC5kb2l0Lndpc2MuZWR1L2V2YWwvCiAgICAgb3IgaHR0cDovL3d3dy5p ZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1pcGZpeC1yZXFzLTA3LnR4dAoK --=_923500563655976026b8b681 Content-Type: application/octet-stream; name="Note_Well_Statement" Content-Disposition: attachment; filename="Note_Well_Statement" Content-Transfer-Encoding: base64 Cgo+RnJvbSB0aW1lIHRvIHRpbWUsIGVzcGVjaWFsbHkganVzdCBiZWZvcmUgYSBtZWV0aW5nLCB0 aGlzIHN0YXRlbWVudCBpcyB0bwpiZSBzZW50IHRvIGVhY2ggYW5kIGV2ZXJ5IElFVEYgd29ya2lu ZyBncm91cCBtYWlsaW5nIGxpc3QuCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQoKCQkJCU5PVEUgV0VMTAoK QWxsIHN0YXRlbWVudHMgcmVsYXRlZCB0byB0aGUgYWN0aXZpdGllcyBvZiB0aGUgSUVURiBhbmQg YWRkcmVzc2VkIHRvIHRoZQpJRVRGIGFyZSBzdWJqZWN0IHRvIGFsbCBwcm92aXNpb25zIG9mIFNl Y3Rpb24gMTAgb2YgUkZDIDIwMjYsIHdoaWNoIGdyYW50cwp0byB0aGUgSUVURiBhbmQgaXRzIHBh cnRpY2lwYW50cyBjZXJ0YWluIGxpY2Vuc2VzIGFuZCByaWdodHMgaW4gc3VjaApzdGF0ZW1lbnRz LgoKU3VjaCBzdGF0ZW1lbnRzIGluY2x1ZGUgdmVyYmFsIHN0YXRlbWVudHMgaW4gSUVURiBtZWV0 aW5ncywgYXMgd2VsbCBhcwp3cml0dGVuIGFuZCBlbGVjdHJvbmljIGNvbW11bmljYXRpb25zIG1h ZGUgYXQgYW55IHRpbWUgb3IgcGxhY2UsIHdoaWNoIGFyZQphZGRyZXNzZWQgdG8KCiAgICAtIHRo ZSBJRVRGIHBsZW5hcnkgc2Vzc2lvbiwKICAgIC0gYW55IElFVEYgd29ya2luZyBncm91cCBvciBw b3J0aW9uIHRoZXJlb2YsCiAgICAtIHRoZSBJRVNHLCBvciBhbnkgbWVtYmVyIHRoZXJlb2Ygb24g YmVoYWxmIG9mIHRoZSBJRVNHLAogICAgLSB0aGUgSUFCIG9yIGFueSBtZW1iZXIgdGhlcmVvZiBv biBiZWhhbGYgb2YgdGhlIElBQiwKICAgIC0gYW55IElFVEYgbWFpbGluZyBsaXN0LCBpbmNsdWRp bmcgdGhlIElFVEYgbGlzdCBpdHNlbGYsCiAgICAgIGFueSB3b3JraW5nIGdyb3VwIG9yIGRlc2ln biB0ZWFtIGxpc3QsIG9yIGFueSBvdGhlciBsaXN0CiAgICAgIGZ1bmN0aW9uaW5nIHVuZGVyIElF VEYgYXVzcGljZXMsCiAgICAtIHRoZSBSRkMgRWRpdG9yIG9yIHRoZSBJbnRlcm5ldC1EcmFmdHMg ZnVuY3Rpb24KClN0YXRlbWVudHMgbWFkZSBvdXRzaWRlIG9mIGFuIElFVEYgbWVldGluZywgbWFp bGluZyBsaXN0IG9yIG90aGVyIGZ1bmN0aW9uLAp0aGF0IGFyZSBjbGVhcmx5IG5vdCBpbnRlbmRl ZCB0byBiZSBpbnB1dCB0byBhbiBJRVRGIGFjdGl2aXR5LCBncm91cCBvcgpmdW5jdGlvbiwgYXJl IG5vdCBzdWJqZWN0IHRvIHRoZXNlIHByb3Zpc2lvbnMuCg== --=_923500563655976026b8b681-- -- 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 Nov 11 20:38:08 2002 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 UAA08077 for ; Mon, 11 Nov 2002 20:38:08 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18BPp0-0003FB-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Nov 2002 19:26:30 -0600 Received: from mailhost2.auckland.ac.nz ([130.216.1.4]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18BPoy-0003F3-00 for ipfix@net.doit.wisc.edu; Mon, 11 Nov 2002 19:26:28 -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 OAA10616; Tue, 12 Nov 2002 14:26:11 +1300 (NZDT) Received: from postbox.auckland.ac.nz (postbox.auckland.ac.nz [130.216.191.126]) by mailhost.auckland.ac.nz (Mirapoint Messaging Server MOS 3.2.1.6-EA) with ESMTP id AJR52908; Tue, 12 Nov 2002 14:26:11 +1300 (NZDT) Received: from localhost (hotlava.auckland.ac.nz [130.216.191.123]) by postbox.auckland.ac.nz (8.11.6/8.11.6) with ESMTP id gAC1QBw21108; Tue, 12 Nov 2002 14:26:11 +1300 Received: from nebbiolo.itss.auckland.ac.nz (nebbiolo.itss.auckland.ac.nz [130.216.4.167]) by hotlava.auckland.ac.nz (IMP) with HTTP for ; Tue, 12 Nov 2002 14:26:11 +1300 Message-ID: <1037064371.3dd058b338ace@hotlava.auckland.ac.nz> Date: Tue, 12 Nov 2002 14:26:11 +1300 From: Nevil Brownlee To: Juergen Quittek Cc: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Agenda for Atlanta References: <1037052131.3dd028e3c8fe3@hotlava.auckland.ac.nz> <14070882.1037063899@[192.168.102.31]> In-Reply-To: <14070882.1037063899@[192.168.102.31]> MIME-Version: 1.0 Content-Type: text/plain 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: Juergen Quittek has pointed out to me that in the IPFIX agenda I'd marked draft-ietf-ipfix-reqs-07.txt as "missed the meeting draft deadline". But actually, it was in time and is available at the IETF I-D repository. I guess I got the deadline date confused with the one for -00 drafts. Sorry about that, Juergen. 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 IMP: http://horde.org/imp/ -- 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 Nov 12 03:30:25 2002 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 DAA24896 for ; Tue, 12 Nov 2002 03:30:25 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18BW67-0004Rk-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Nov 2002 02:08:36 -0600 Received: from usmail.xacct.com ([204.253.100.12]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18BW65-0004Ra-00 for ipfix@net.doit.wisc.edu; Tue, 12 Nov 2002 02:08:34 -0600 Received: from peter ([192.168.254.132]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id gAC8C2216807; Tue, 12 Nov 2002 00:12:03 -0800 From: "Peter Ludemann" To: Cc: "Randy Bush" Subject: [ipfix] RE: I-D ACTION:draft-ietf-ipfix-reqs-07.txt Date: Tue, 12 Nov 2002 00:08:18 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: X-RBL-Warning: (dnsbl.njabl.org) relay tested -- 1016746205 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Randy Bush reminded me in the attached that I had forgotten to identify myself as a , while he was representing an . Octet counting may well be sufficient for Randy and his (I don't know his business model), but many of the s I deal with demand far more in terms of detailed flow reporting (these s are worldwide, including US, Japan, Europe). We would have lost business if we could provide nothing more than octet counting. Some (not all) s want more flexibility in their billing models. And because IPFIX proposes its data be used for (amongst other things) billing, I must disagree with Randy and say that IPFIX should provide flow data. The flows can always be summed or otherwise aggregated to provide just octet counts. I hope that Randy and I do not disagree about reliability. (Some s want even more -- fully redundant probes, data collection, deduplication, persistency, etc.) As one who remembers with fondness the days when the Internet was free of commercialism (and undergraduates) I feel a bit uneasy in representing a vendor, who might seem to be pushing something upon the IETF. But we are not marketers trying to create demand that isn't there -- we are reacting to requests. Someone must pay for the Internet; and we're just trying to process the data that will allow a wide variety of usage models, so that natural selection can take us to better systems (which I hope will be more pervasive and less expensive; and will still allow undergraduates). Unfortunately, the stickiest part often is data collection -- which we're hoping that IPFIX will help solve by choosing a useful standard. - peter > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Monday, November 11, 2002 9:54 AM > To: Peter Ludemann > Subject: Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt > > > >> i do not understand how _flow_ measurements can be a > >> _rigorous_ basis for billing. in my world, we use octet counting > >> for that kind of application. > > > > Au contraire, octet counting is so 20th century & dot-com. > > > > Because of a need for _rigorous_ billing, and for flexibility in > > billing/business models, I am currently working on projects that > > use (amongst other things) for billing: > > - dynamic IP addresses (which we dynamically map to customer ID) > > - protocol classification (including dynamically assigned ports > > such as for FTP and H.323) > > - octets, adjusted for resends, IP, TCP, application header overhead > > (don't want to charge end-users more when network quality > > gets worse) > > - content type (MIME type, etc.) > > - QoS (response time, packet loss, etc.) > > you forgot the tag. > > randy -- 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 Nov 12 03:34:37 2002 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 DAA24996 for ; Tue, 12 Nov 2002 03:34:36 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18BWEA-0004ZW-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Nov 2002 02:16:54 -0600 Received: from usmail.xacct.com ([204.253.100.12]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18BWE8-0004ZQ-00 for ipfix@net.doit.wisc.edu; Tue, 12 Nov 2002 02:16:52 -0600 Received: from peter ([192.168.254.132]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id gAC8KY216876 for ; Tue, 12 Nov 2002 00:20:34 -0800 From: "Peter Ludemann" To: "ipfixx" Subject: [ipfix] RE: Multiple levels of Reliability and Directionality Date: Tue, 12 Nov 2002 00:16:49 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <3DCA7C9B.DE20AF97@riverstonenet.com> X-RBL-Warning: (dnsbl.njabl.org) relay tested -- 1016746205 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Jeff Meyer suggested (message #1415) that: NFv9 and IPDR seem like they may fit the bill jointly. NFv9 for UDP based unreliable delivery and IPDR for TCP/SCTP based reliable delivery. I disagree: two is too complicated and unnecessary (tedious details follow in the rest of this note). Also, I think that Jeff does IPDR a disservice here, in that IPDR-streaming also provides application-level ACK (as does CRANE). Jeff, please correct me if I mis-read the document. [By the way, is there an official version for the IPFIX WG? I could only find protocol documents on the IPDR website.] I'll discuss how to remove reliability from the point of view of CRANE; others might wish to point out where there are differences with their protocols. The protocol document doesn't discuss behaviour for fail-over as being outside the scope of the document, so there might be some misunderstanding of what application-level ACK provides. At minimum, it should provide: - persistency on the receiver and subsequent ACK is done by a combination of timer and #records (ACK for slow data rates, #records for high rates) - sender times out on ACK, whether because of slow network, slow receiver, or slow downstream persistency processing - fail-over to one or more secondary receivers when application-level ACK not received within timeout - multiple "streams" to allow N-to-1 redundancy (CRANE provides this within its protocol; presumably IPDR would use multiple TCP connections to provide similar capability) - ability to absorb bursts of data, with fail-over/fail-back if one receiver is overwhelmed and then recovers But I digress ... it isn't necessary to have the complication of two protocols just to support unreliability. I have already shown how template negotiation does not lead to a complex implementation for a *minimal* conforming implementation (#1382, #1386, #1381). In a similar spirit, the bi-directional protocols can be made unreliable as follows: Step 1 (for protocols that have application-level reliability): Remove the template negotiation. Remove any multiplexed stream in the protocol (e.g., CRANE's "sessions"), replacing by separate transport channels. Remove the application-level ACK. For the implementation, the effects are: (a) receiver doesn't need to provide persistency on the received data. (b) exporter does not need to maintain a queue of data waiting to be ACKed. At this point, we have "partial uni-directionality" - there is still transport-level ACK and flow control (TCP or SCTP). Step 2: Change from TCP/SCTP to UDP, ensuring that all records can be put into a single packet. For efficiency, multiple records can be packed into a single packet but they must not span records because of the possibility of packet loss. If there is no data record number, add one (application-level protocols already have record numbers). Step 1(b) is a little subtle, if the implementation on the exporter does non-blocking I/O (which is what we did in our CRANE implementation: we didn't want to slow down the main processing on the network element). Most TCP/SCTP stacks have relatively small buffers (typically no bigger than 256K), so the application must still keep its own buffer and make its own decisions on discarding records when the application buffer fills up. Step 2 has its own subtlety: how to deal with template changes. I don't see how this could be done without some kind of acknowledgment, whether by a reliable TCP channel, or by something like RADIUS's acknowledgments -- after all, packet losses occur occasionally even in the best families -- and it's pointless to broadcast packets when the receiver doesn't know their format. So, one must have either a predetermined set of record definitions or some bi-directionality for acknowledging format changes. References: http://ipfix.doit.wisc.edu/archive/1382.html http://ipfix.doit.wisc.edu/archive/1386.html http://ipfix.doit.wisc.edu/archive/1381.html http://ipfix.doit.wisc.edu/archive/1221.html http://ipfix.doit.wisc.edu/archive/1415.html - peter > -----Original Message----- > From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf > Of calato@riverstonenet.com > Sent: Thursday, November 07, 2002 6:46 AM > To: ipfixx > Subject: [ipfix] Multiple levels of Reliability and Directionality > > > > Does IPFIX need to support multiple levels of reliability > and directionality? > > The applications IPFIX needs to support are quite varied > and have differing needs in terms of reliability. Devices > also have varying needs in terms of directionality. > > I would like the WG to consider requirements on the protocol > to support a tiered approach meet these needs. > > Direction is either bi-directional or uni-directional. I've split > reliability into 3 categories... > > High - Little to no data loss > Medium - Minimal data loss is accepted > Low - Data sent is best effort > > > The six combinations are shown below... > > > | Uni | Bi > -------+------+--------- > High | 1 | 4 > -------+------+-------- > Medium | 2 | 5 > -------+------+-------- > Low | 3 | 6 > > > > I think (IMHO) the most likely combinations are... > > 3. Low reliability and uni-directional. This will be used > where the device and collector are in close proximity, > there is high volume and some data loss is acceptable for > the given application. Applications such as Attack/Intrusion > Detection > Traffic Profiling, etc... > > 5. Bi-directional medium reliability. This will be used > where high volume and increased reliability are needed. > Applications > such as Usage-based Accounting where 95th percentile billing > model is used. Or even Traffic Engineering where network > policy > decisions are based on the data collected. > > 4. Bi-directional high reliability would be used where the > Usage-based Accounting application has strict requirements > on data loss. > > Does IPFIX need to support multiple levels of reliability > and directionality? > > Paul -- 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 Nov 12 05:19:19 2002 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 FAA26451 for ; Tue, 12 Nov 2002 05:19:19 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18BXv5-00078y-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Nov 2002 04:05:19 -0600 Received: from mailhub.fokus.gmd.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18BXv3-00077R-00 for ipfix@net.doit.wisc.edu; Tue, 12 Nov 2002 04:05:17 -0600 Received: from fokus.gmd.de (dhcp209 [195.37.78.209]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id gACA3bl08375; Tue, 12 Nov 2002 11:03:37 +0100 (MET) Message-ID: <3DD0D112.2090905@fokus.gmd.de> Date: Tue, 12 Nov 2002 10:59:46 +0100 From: Sebastian Zander Organization: Fraunhofer FOKUS User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: de-DE MIME-Version: 1.0 To: calato@riverstonenet.com CC: Randy Bush , Reinaldo Penno , Tal Givoly , Juergen Quittek , ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt References: <0A11633F61BD9F40B43ABCC694004F930DAD32@zsc3c026.us.nortel.com> <3DD00643.E62AF044@riverstonenet.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit calato@riverstonenet.com wrote: > Randy Bush wrote: > >>>The charter talks about billing and accounting... >>> >>yup. use of the current style stuff to do those kinds of things is >>reasonable. bending the current stuff in order to boil the ocean >>can be done in experimental drafts. but the primary goal of this >>wg is to reconcile some _current_ inter-vendor incompatibilities, >>fix congestion control, etc. >> >> > > This thread started with a question on reliability... > > > Somehow, the requirements discussion suffers from a split: > > There are requirements resulting from the intention of > > standardzing a highly reliable metering standard for precise > > accounting (and billing). Differing from these are requirements > > for a simpler metering standard more oriented at what I would > > call "typical Internet reliability". > > the original goal, which the iesg thinks was chartered, is the > latter. Maybe someone can explain to me what "typical Internet reliability" is? > To the charter once again... > > "o Ensure that the flow export system is reliable in that it will > minimize the likelihood of flow data being lost due to resource > constraints in the exporter or receiver and to accurately report > such loss if it occurs. " > > I see mention of reliability but nothing about to what level. The > guiding > principal has been to try and standardize what is "out there" today. > Right now > we have Netflow with none, LFAP with a reliable transport and CRANE > with application level (not an exhaustive list, just the ones that come > to mind). > > It would seem that coming to agreement on reliability is within the > charter. Paul, you are completly right. We should not try to boil the ocean but we should boil enough water to make nice coffee for everyone. Or are we trying to make coffee with cold water? :-) Sebastian > > Paul > > >>perhaps we should have two wgs, ipwork and ipfix? >> >>randy >> >>-- >>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/ > > -- Sebastian Zander E-mail: zander@fokus.fhg.de FhI FOKUS / Global Networking (GloNe) Tel: +49-30-3463-7287 Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 D-10589 Berlin, Germany www.fokus.fhg.de/usr/sebastian.zander -- 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 Nov 12 22:40:51 2002 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 WAA25820 for ; Tue, 12 Nov 2002 22:40:51 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18BoDD-0002Ac-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Nov 2002 21:29:07 -0600 Received: from usmail.xacct.com ([204.253.100.12]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18BoDC-0002AV-00 for ipfix@net.doit.wisc.edu; Tue, 12 Nov 2002 21:29:06 -0600 Received: from peter (inside.us.xacct.com [204.253.100.102]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id gAD3Wj231533 for ; Tue, 12 Nov 2002 19:32:46 -0800 From: "Peter Ludemann" To: Subject: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt Date: Tue, 12 Nov 2002 19:28:59 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <3DD0D112.2090905@fokus.gmd.de> X-RBL-Warning: (dnsbl.njabl.org) relay tested -- 1016746205 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Sebastian Zander wrote Tuesday, November 12, 2002 2:00 AM: > Paul, you are completly right. We should not try to boil the ocean but we > should boil enough water to make nice coffee for everyone. Or are > we trying to make coffee with cold water? :-) I have a friend who does make coffee with cold water. It takes overnight "soaking" of the coffee, though. Seriously, I was hoping to convince people that a minimal conforming implementation of a protocol with template negotiation and application reliability is only a little more difficult to implement than the much less useful protocols which don't have these features. (And I've even described how to remove reliability for those who don't need/want it.) [If my explanations are incomprehensible, please send me a private note with a hint about what needs re-explaining and I'll do a rewrite.] So, I don't think we need to boil the ocean but it is worthwhile to start with fresh cold water, clean equipment and decent beans because for about the same amount of effort, these give much better coffee. And then we can turn our focus to the real stuff: what data are exported (I foresee many opinions on customer use cases). - peter -- 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 Nov 13 10:59:38 2002 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 KAA05831 for ; Wed, 13 Nov 2002 10:59:38 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18BzaQ-0005Iw-00 for ipfix-list@mil.doit.wisc.edu; Wed, 13 Nov 2002 09:37:50 -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 18BzaO-0005E5-00 for ipfix@net.doit.wisc.edu; Wed, 13 Nov 2002 09:37:48 -0600 Received: from riverstonenet.com ([134.141.180.82]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 13 Nov 2002 07:37:16 -0800 Message-ID: <3DD2712E.E656D12@riverstonenet.com> Date: Wed, 13 Nov 2002 10:35:10 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 CC: ipfix@net.doit.wisc.edu Subject: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Nov 2002 15:37:17.0637 (UTC) FILETIME=[8C2BE750:01C28B2A] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit I'm left wondering what level of reliability is in scope? It seems we a few people that agree a highly reliable protocol is out of scope and several agreeing it is in scope. Since one person from the former was wearing an AD hat I'm left still uncertain of the outcome. Is high reliability in scope or out of scope. If out of scope, to what level is in scope? 1. Transport level reliability 2. Redundancy reliability (e.g. sending all data to multiple collectors or multicasting) 3. Failover (i.e. detecting a collector is down and switching to another) 4. Congestion awareness only (i.e. send and forget) What level of reliability is in scope? Paul -- 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 Nov 13 12:08:55 2002 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 MAA08793 for ; Wed, 13 Nov 2002 12:08:55 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18C0iI-0006yD-00 for ipfix-list@mil.doit.wisc.edu; Wed, 13 Nov 2002 10:50:02 -0600 Received: from pool-129-44-39-39.ny325.east.verizon.net ([129.44.39.39] helo=newyork.qosient.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18C0iG-0006xg-00 for ipfix@net.doit.wisc.edu; Wed, 13 Nov 2002 10:50:00 -0600 Received: from sphynx (sphynx [192.168.0.64]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id gADGnuO03979; Wed, 13 Nov 2002 11:49:56 -0500 From: "Carter Bullard" To: Cc: Subject: RE: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt Date: Wed, 13 Nov 2002 11:49:48 -0500 Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A4B6@ptah.newyork.qosient.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <5C8959A16A71B449AE793CF52FBBED660D6617@ptah.newyork.qosient.com> Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hey Paul, I believe that your list of 4 items is missing the critical reliability support mechanism that IPFIX has in its list of requirements. IMHO, the only reliability mechanism that IPFIX needs. Receiver detection of IPFIX message loss. If the protocol supports this basic property, vendors can then build reliable systems; as reliable as any customer can afford. Supplementing this with data stream integrity mechanisms so that the receiver can realize the nature of any loss, would be a dream solution. What does this mean for the protocol? Sequence numbers and periodic stream integrity reports. Anything else can be vendor improvements. IMHO. Carter > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of > calato@riverstonenet.com > Sent: Wednesday, November 13, 2002 10:35 AM > Cc: ipfix@net.doit.wisc.edu > Subject: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt > > > > I'm left wondering what level of reliability is in scope? > > It seems we a few people that agree a highly reliable > protocol is out of scope and several agreeing it is in > scope. Since one person from the former was wearing an AD > hat I'm left still uncertain of the outcome. > > Is high reliability in scope or out of scope. If out > of scope, to what level is in scope? > > 1. Transport level reliability > 2. Redundancy reliability (e.g. sending all data > to multiple collectors or multicasting) > 3. Failover (i.e. detecting a collector is > down and switching to another) > 4. Congestion awareness only (i.e. send and forget) > > What level of reliability is in scope? > > Paul > > -- > 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 Nov 14 10:50:53 2002 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 KAA22197 for ; Thu, 14 Nov 2002 10:50:53 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18CM1f-0001kf-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Nov 2002 09:35:27 -0600 Received: from dplonka by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18CM1e-0001ka-00 for ipfix@net.doit.wisc.edu; Thu, 14 Nov 2002 09:35:26 -0600 Date: Thu, 14 Nov 2002 09:35:26 -0600 From: Dave Plonka To: ipfix@net.doit.wisc.edu Subject: [ipfix] IPFIX web resources for Atlanta meeting Message-ID: <20021114093526.B4910@doit.wisc.edu> Reply-To: plonka@doit.wisc.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Organization: UW-Madison, DoIT, Network Services X-VMS-Error: %SYSTEM-W-TOOMANYAJL, too many security audit journals encountered X-Shakespearean-Insult: Thou ruttish spur-galled lewdster Precedence: bulk Sender: majordomo listserver IPFIXers, FYI: I've recently updated the IPFIX web site so that the evaluation documents are mirrored or linked here: http://ipfix.doit.wisc.edu/eval/ Please see the "README.html" info at the bottom of that page. Those are the items to be reviewed if you need to catch-up in preparation for our upcoming meeting scheduled for 1530 on Thursday, Nov 21, in Atlanta. Also, some previously broken or out-of-date links to documents from the main page have hopefully been fixed: http://ipfix.doit.wisc.edu/#IPFIX_related_Internet_Drafts_an See you in Atlanta, Dave P.S. As some of you thankfully have been, please do let me know if you see a problem on the IPFIX page. Thanks to Nevil for putting up the documents on the temporary site while I was on vacation last week. -- plonka@doit.wisc.edu http://net.doit.wisc.edu/~plonka ARS:N9HZF Madison, WI -- 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 Nov 14 11:03:25 2002 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 LAA22538 for ; Thu, 14 Nov 2002 11:03:25 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18CMIw-0002F3-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Nov 2002 09:53:18 -0600 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18CMIu-0002At-00 for ipfix-eval@net.doit.wisc.edu; Thu, 14 Nov 2002 09:53:16 -0600 Received: from cisco.com (bclaise-isdn-home.cisco.com [10.49.4.218]) by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id gAEFqb707329 for ; Thu, 14 Nov 2002 16:52:37 +0100 (CET) Message-ID: <3DD3C6C3.30408@cisco.com> Date: Thu, 14 Nov 2002 16:52:35 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020815 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-eval@net.doit.wisc.edu Subject: [ipfix-eval] Some comments on the evaluation team draft Content-Type: multipart/alternative; boundary="------------070604040905000206080005" Precedence: bulk Sender: majordomo listserver --------------070604040905000206080005 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit All, I have 2 coments regarding the following draft http://www2.auckland.ac.nz/net//ipfix/draft-ietf-ipfix-protocol-eval-00.txt 4.5 Time Synchronization (5.5) LFAP: T CRANE: T IPDR: T NetFlow: P Diameter: T In my draft http://www.ietf.org/internet-drafts/draft-claise-ipfix-eval-netflow-03.txt, I wrote 3.4.5 Time Synchronization (5.5) _ Total Compliance. _ The export packet header contains the UTC time of the export packet generation. This header also contains the router sysUpTime at the time of the export packet generation. The UTC time the router booted can therefore be deduced. The flow records contain the flow start and flow end sysUpTime, so that the NetFlow collector can deduce the flow start and flow end UTC time. 5.7 Anonymization (6.7) LFAP: E CRANE: E IPDR: E NetFlow: E Diameter: E In my draft http://www.ietf.org/internet-drafts/draft-claise-ipfix-eval-netflow-03.txt, I wrote 3.5.7 Anonymization (6.6) "The exporting process MAY be capable of anonymizing source and destination IP addresses in flow data before exporting them." _Total Compliance. _ You can export the prefix is you want to and not the specific source and destination IP addresses. I would appreciate if those two points above could be changed. BTW, maybe I misunderstood the idea of the evaluation team, but from http://ipfix.doit.wisc.edu/archive/1000.html 3) Evaluation Team met by teleconference for an hour on Wed 26 June The team was strongly influenced by the MIDCOM WG's recent evaluation effort; the IPFIX process will be similar. a) The team will publish a 'Protocol Advocacy' draft, to be used by the Protocol Advocates in making their submissions to the Evaluation team. b) They will also publish a 'call for IPFIX protocol submissions,' most probably via the IPFIX list, referring to a web page on the IPFIX web site. The call for submissions will set out preconditions (e.g. 'must be documented in an Internet Draft or RFC'), as discussed previously. c) Once all the submissions are in, the team will publish them, and call for comments about them on the IPFIX list. In addition, the team will read all the drafts and form their own opionions of them. d) The team will publish an 'Evaluation' draft, using the same outline as the Protocol Advocacy drafts; this will conclude with a recommendation on which protocol most nearly meets the IPFIX requirements. e) The Evaluation draft will be discussed on the IPFIX list, until we reach WG consensus. From above, you can read "this will conclude with a recommendation on which protocol most nearly meets the IPFIX requirements." And it seems that we miss that part in http://www2.auckland.ac.nz/net//ipfix/draft-ietf-ipfix-protocol-eval-00.txt. The only exception was in the initial draft from Simon Leinen. But the "conclusion" section was removed in the second version of his draft. Regards, Benoit. --------------070604040905000206080005 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 
All,

I have 2 coments regarding the following draft

http://www2.auckland.ac.nz/net//ipfix/draft-ietf-ipfix-protocol-eval-00.txt


4.5 Time Synchronization  (5.5) 

LFAP: T     CRANE: T     IPDR: T     NetFlow: P     Diameter: T

In my draft http://www.ietf.org/internet-drafts/draft-claise-ipfix-eval-netflow-03.txt, I wrote
3.4.5 Time Synchronization (5.5)

Total Compliance.
The export packet header contains the UTC time of the export packet
generation. This header also contains the router sysUpTime at the
time of the export packet generation. The UTC time the router booted
can therefore be deduced. The flow records contain the flow start
and flow end sysUpTime, so that the NetFlow collector can deduce the
flow start and flow end UTC time. 

5.7 Anonymization  (6.7) 
    
LFAP: E     CRANE: E     IPDR: E     NetFlow: E     Diameter: E
In my draft http://www.ietf.org/internet-drafts/draft-claise-ipfix-eval-netflow-03.txt, I wrote

3.5.7 Anonymization (6.6)
   
   "The exporting process MAY be capable of anonymizing source and
   destination IP addresses in flow data before exporting them."
   Total Compliance.
You can export the prefix is you want to and not the specific source and destination IP addresses.

I would appreciate if those two points above could be changed.


BTW, maybe I misunderstood the idea of the evaluation team, but from http://ipfix.doit.wisc.edu/archive/1000.html
3) Evaluation Team met by teleconference for an hour on Wed 26 June

   The team was strongly influenced by the MIDCOM WG's recent
   evaluation effort; the IPFIX process will be similar.

   a) The team will publish a 'Protocol Advocacy' draft, to be used
      by the Protocol Advocates in making their submissions to the
      Evaluation team.

   b) They will also publish a 'call for IPFIX protocol submissions,'
      most probably via the IPFIX list, referring to a web page on
      the IPFIX web site.  The call for submissions will set out
      preconditions (e.g. 'must be documented in an Internet Draft
      or RFC'), as discussed previously.

   c) Once all the submissions are in, the team will publish them,
      and call for comments about them on the IPFIX list.
      In addition, the team will read all the drafts and form their
      own opionions of them.

   d) The team will publish an 'Evaluation' draft, using the same
      outline as the Protocol Advocacy drafts; this will conclude
      with a recommendation on which protocol most nearly meets the
      IPFIX requirements.

   e) The Evaluation draft will be discussed on the IPFIX list, 
      until we reach WG consensus.
From above, you can read "this will conclude with a recommendation on which protocol most nearly meets the IPFIX requirements."
And it seems that we miss that part in http://www2.auckland.ac.nz/net//ipfix/draft-ietf-ipfix-protocol-eval-00.txt.
The only exception was  in the initial draft from Simon Leinen. But the "conclusion" section was removed in the second version of his draft.

Regards, Benoit.





--------------070604040905000206080005--


--
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 Nov 14 11:30:36 2002
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 LAA23572
	for ; Thu, 14 Nov 2002 11:30:36 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18CMkI-0002sc-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 14 Nov 2002 10:21:34 -0600
Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18CMkH-0002rp-00
	for ipfix-eval@net.doit.wisc.edu; Thu, 14 Nov 2002 10:21:33 -0600
Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gAEGL7l16808;
	Thu, 14 Nov 2002 10:21:07 -0600 (CST)
Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 14 Nov 2002 08:20:52 -0800
Message-ID: <0A11633F61BD9F40B43ABCC694004F931821C6@zsc3c026.us.nortel.com>
From: "Reinaldo Penno" 
To: Benoit Claise , ipfix-eval@net.doit.wisc.edu
Subject: RE: [ipfix-eval] Some comments on the evaluation team draft
Date: Thu, 14 Nov 2002 08:20:51 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C28BF9.CCA71FDC"
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_01C28BF9.CCA71FDC
Content-Type: text/plain;
	charset="iso-8859-1"

Hello Benoit,
 
some answers...

-----Original Message-----
From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Thursday, November 14, 2002 10:53 AM
To: ipfix-eval@net.doit.wisc.edu
Subject: [ipfix-eval] Some comments on the evaluation team draft


All,



I have 2 coments regarding the following draft
http://www2.auckland.ac.nz/net//ipfix/draft-ietf-ipfix-protocol-eval-00.txt
 





4.5 Time Synchronization  (5.5) 



LFAP: T     CRANE: T     IPDR: T     NetFlow: P     Diameter: T



In my draft
http://www.ietf.org/internet-drafts/draft-claise-ipfix-eval-netflow-03.txt

, I wrote

3.4.5 Time Synchronization (5.5) 

Total Compliance. 
The export packet header contains the UTC time of the export packet 
generation. This header also contains the router sysUpTime at the 
time of the export packet generation. The UTC time the router booted 
can therefore be deduced. The flow records contain the flow start 
and flow end sysUpTime, so that the NetFlow collector can deduce the 
flow start and flow end UTC time. 



5.7 Anonymization  (6.7) 

    

LFAP: E     CRANE: E     IPDR: E     NetFlow: E     Diameter: E
In my draft
http://www.ietf.org/internet-drafts/draft-claise-ipfix-eval-netflow-03.txt

, I wrote


3.5.7 Anonymization (6.6) 
    
   "The exporting process MAY be capable of anonymizing source and 
   destination IP addresses in flow data before exporting them."
   Total Compliance. 


You can export the prefix is you want to and not the specific source and
destination IP addresses. 
 
From my point of view exporting only the prefix is not considered
anonymization. I'm not sure this got into the recent requirements draft, but
was the conclusion of some discussions that I actually think (but not
posisitive) you were copied.  I should put that as a open item....

I would appreciate if those two points above could be changed.


BTW, maybe I misunderstood the idea of the evaluation team, but from
http://ipfix.doit.wisc.edu/archive/1000.html
 


3) Evaluation Team met by teleconference for an hour on Wed 26 June



   The team was strongly influenced by the MIDCOM WG's recent

   evaluation effort; the IPFIX process will be similar.



   a) The team will publish a 'Protocol Advocacy' draft, to be used

      by the Protocol Advocates in making their submissions to the

      Evaluation team.



   b) They will also publish a 'call for IPFIX protocol submissions,'

      most probably via the IPFIX list, referring to a web page on

      the IPFIX web site.  The call for submissions will set out

      preconditions (e.g. 'must be documented in an Internet Draft

      or RFC'), as discussed previously.



   c) Once all the submissions are in, the team will publish them,

      and call for comments about them on the IPFIX list.

      In addition, the team will read all the drafts and form their

      own opionions of them.



   d) The team will publish an 'Evaluation' draft, using the same

      outline as the Protocol Advocacy drafts; this will conclude

      with a recommendation on which protocol most nearly meets the

      IPFIX requirements.



   e) The Evaluation draft will be discussed on the IPFIX list, 

      until we reach WG consensus.

From above, you can read "this will conclude with a recommendation on which
protocol most nearly meets the IPFIX requirements."
And it seems that we miss that part in
http://www2.auckland.ac.nz/net//ipfix/draft-ietf-ipfix-protocol-eval-00.txt
 . 
 
that's because the draft will still got through revisions after the
advocates have a chance to comment on the items they find relevant (just
like you did), and also after the open requirements that are relevant to the
evaluation are closed (e.g. reliability). Only after that we will issue a
final recommendation
 
regards,
 
Reinaldo
 
The only exception was  in the initial draft from Simon Leinen. But the
"conclusion" section was removed in the second version of his draft.

Regards, Benoit.





------_=_NextPart_001_01C28BF9.CCA71FDC
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









Hello=20
Benoit,


 


some=20
answers...



  
-----Original Message-----
From: Benoit Claise=20
  [mailto:bclaise@cisco.com]
Sent: Thursday, November 14, =
2002 10:53=20
  AM
To: ipfix-eval@net.doit.wisc.edu
Subject: =
[ipfix-eval]=20
  Some comments on the evaluation team =
draft

All,

I have 2 coments regarding the following draft

http://www2.auckland.ac.nz/net//ipfix/draft-ietf-ipfix-prot=
ocol-eval-00.txt


4.5 Time Synchronization  (5.5)=20

LFAP: T     CRANE: T     IPDR: T     NetFlow: P     Diameter: T

In my draft http://www.ietf.org/internet-drafts/draft-claise-ipfix-eval-=
netflow-03.txt, I wrote


  
3.4.5 Time Synchronization (5.5) 

Total =
Compliance.=20
    
The export packet header contains the UTC time of the =
export packet=20
    
generation. This header also contains the router sysUpTime at =
the=20
    
time of the export packet generation. The UTC time the router =
booted=20
    
can therefore be deduced. The flow records contain the flow =
start=20
    
and flow end sysUpTime, so that the NetFlow collector can =
deduce the=20
    
flow start and flow end UTC time. 

5.7 =
Anonymization  (6.7)=20
   =20
LFAP: E     CRANE: E     IPDR: E     NetFlow: E     Diameter: =
E
In my draft http://www.ietf.org/internet-drafts/draft-claise-ipfix-eval-=
netflow-03.txt, I wrote

  

3.5.7 Anonymization (6.6) 
   =20
    
   "The exporting process MAY be capable of =
anonymizing source=20
    and 
   destination IP addresses in flow data before =
exporting=20
    them."
   Total Compliance. 

  
You can export the prefix is you want to and not the specific =
source and=20
  destination IP addresses. 

  
 

  
From=20
  my point of view exporting only the prefix is not considered =
anonymization.=20
  I'm not sure this got into the recent requirements draft, but =
was the=20
  conclusion of some =
discussions=20
  that I actually think (but not posisitive) you were copied.  I =
should put=20
  that as a open item....

I would appreciate if =
those two=20
  points above could be changed.


BTW, maybe I misunderstood =
the idea=20
  of the evaluation team, but from http://ipfix.doit.=
wisc.edu/archive/1000.html

  
3) Evaluation Team met by teleconference for an hour =
on Wed 26 June

   The team was strongly influenced by the MIDCOM WG's recent
   evaluation effort; the IPFIX process will be similar.

   a) The team will publish a 'Protocol Advocacy' draft, to be used
      by the Protocol Advocates in making their submissions to the
      Evaluation team.

   b) They will also publish a 'call for IPFIX protocol submissions,'
      most probably via the IPFIX list, referring to a web page on
      the IPFIX web site.  The call for submissions will set out
      preconditions (e.g. 'must be documented in an Internet Draft
      or RFC'), as discussed previously.

   c) Once all the submissions are in, the team will publish them,
      and call for comments about them on the IPFIX list.
      In addition, the team will read all the drafts and form their
      own opionions of them.

   d) The team will publish an 'Evaluation' draft, using the same
      outline as the Protocol Advocacy drafts; this will conclude
      with a recommendation on which protocol most nearly meets the
      IPFIX requirements.

   e) The Evaluation draft will be discussed on the IPFIX list,=20
      until we reach WG consensus.

  
From above, you can read "this will conclude with a =
recommendation on=20
  which protocol most nearly meets the IPFIX requirements."
And it =
seems that=20
  we miss that part in http://www2.auckland.ac.nz/net//ipfix/draft-ietf-ipfix-prot=
ocol-eval-00.txt. 

  
 

  
that's because the draft will still got through revisions =
after the=20
  advocates have a chance to comment on the items they find relevant =
(just like=20
  you did), and also after the open requirements that are relevant to =
the=20
  evaluation are closed (e.g. reliability). Only after that we will =
issue a=20
  final recommendation

  
 

  
regards,

  
 

  
Reinaldo

  
 
The only =
exception=20
  was  in the initial draft from Simon Leinen. But the =
"conclusion" section=20
  was removed in the second version of his draft.

Regards,=20
  Benoit.



------_=_NextPart_001_01C28BF9.CCA71FDC--

--
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 Nov 14 14:32:33 2002
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 OAA27932
	for ; Thu, 14 Nov 2002 14:32:28 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18CPXq-00075f-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 14 Nov 2002 13:20:55 -0600
Received: from usmail.xacct.com ([204.253.100.12])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18CPXo-00075X-00
	for ipfix-req@net.doit.wisc.edu; Thu, 14 Nov 2002 13:20:52 -0600
Received: from Givoly ([192.168.0.2])
	by usmail.xacct.com (8.11.2/8.11.2) with SMTP id gAEJOM226111;
	Thu, 14 Nov 2002 11:24:24 -0800
From: "Tal Givoly" 
To: "Nevil Brownlee" ,
        
Subject: [ipfix-req] IPFIX Reliability Requirement
Date: Thu, 14 Nov 2002 11:20:30 -0800
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-RBL-Warning: (dnsbl.njabl.org) relay tested -- 1016746205
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

Nevil and all,

We still do not have consensus on 'reliability' in the IPFIX protocol.

I would like us to achieve consensus regarding two points:
1. Standardizing NetFlow is not the charter of the working group (although
NetFlow is a perfectly viable candidate protocol and may be selected after
evaluation).
2. Addressing the issue of reliability of the protocol (to whatever degree
is agreed upon), is in scope of the effort of the working group.

Once we agree regarding these two points, we can dedicate some effort to
finally bring to conclusion the discussion regarding reliability and how it
relates to the requirements of the protocol.

I am not proposing 'carrier-grade' reliability for all. But I believe that
it can be demonstrated (see below) that some kind of reliability IS part of
the IPFIX charter and that the various kinds of reliability MUST be
addressed properly if IPFIX is to standardise on a widely-useful protocol.

The rest of this submission includes justification for the above two points
as well as a proposal on how to move forward to resolve the ambiguity and
lack of agreement regarding the reliability requirement.



Below is an attempt to summarize the debate regarding the reliability
requirement.

The views presented thus far includes the entire spectrum from "no
reliability, let's just standardize NetFlow" to carrier-grade billing-level
reliability, and a large number of possible variations to achieve some
middle ground. It seems that that middle ground is being sought in order to
provide greater applicability to the IPFIX protocol.

My initial thoughts are that this debate will not settle in the mailing
list. However, in attempt to help bring this issue to conclusion, I put
forth a presentation of the various views presented and potential method to
resolve the issue at hand.

As one of the people that have an interest in resolving this issue (as we
should all if we are to achieve consensus), I have tried to objectively
round up the views presented - stemming from the charter of the WG, the
requirements document, and individual views of users presented on many
threads:

----------------------------
Extract from Charter, regarding reliability
(http://www.ietf.org/html.charters/ipfix-charter.html):

"As such, there is a need in industry and the Internet research community
for IP devices such as routers to export flow information in a standard way
to external systems such as mediation systems, accounting/billing systems,
and network management systems to facilitate services such as Internet
research, measurement, accounting, and billing."

and

"The protocol must run over an IETF approved congestion-aware transport
protocol such as TCP or SCTP."

One of the specific goals:

"Ensure that the flow export system is reliable in that it will minimize the
likelihood of flow data being lost due to resource constraints in the
exporter or receiver and to accurately report such loss if it occurs. "

----------------------------
Extract from Requirements draft, regarding reliability
(http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reqs-07.txt):

5.1.  Reliability

   The metering process MUST either be reliable or missing reliability
   MUST be known and indicated. The metering process is reliable if each
   packet passing the observation point is metered according to the
   configuration of the metering process. If, e.g. due to some overload,
   not all passing packets can be included into the metering process,
   then the metering process MUST be able to detect this failure and to
   report about it.

6.3.  Data Transfer

   Requirements for the data transfer include reliability, congestion
   awareness, and security requirements. For meeting these requirements
   the exporting process can utilize existing security features provided
   by the device hosting the process and/or provided by the transport
   network. For example it can use existing security technologies for
   authentication and encryption or it can rely on physical protection
   of a separated network for transferring flow information.

6.3.1.  Congestion Awareness

   For the data transfer, a congestion aware protocol MUST be supported.

6.3.2.  Reliability

   Absence of reliability of the data transfer, for example caused by
   loss or reordering of packets containing flow information, MUST be
   indicated.

   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.

   Flow information might get lost before it is processed properly by
   the collecting process. A means to gauge the amount of loss of flow
   information MUST be available from the exporting process and/or the
   collecting process. Possible reasons for flow information loss
   include resource shortage at the exporter, loss of packets between
   exporting process and collecting process, etc.

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

Appendix: Derivation of Requirements from Applications

   The following table documents, how the requirements stated in
   sections 3-7 are derived from requirements of the applications listed
   in section 2.

   Used abbreviations:
      M = MUST
      S = SHOULD
      O = MAY (OPTIONAL)
      - = DONT CARE

   -----------------------------------------------------------------------.
      IPFIX                                                               |
   ----------------------------------------------------------------.      |
   E: QoS Monitoring                                               |      |
   ----------------------------------------------------------.     |      |
   D: Attack/Intrusion Detection                             |     |      |
   ----------------------------------------------------.     |     |      |
   C: Traffic Engineering                              |     |     |      |
   ----------------------------------------------.     |     |     |      |
   B: Traffic Profiling                          |     |     |     |      |
   ----------------------------------------.     |     |     |     |      |
   A: Usage-based Accounting               |     |     |     |     |      |
   ----------------------------------.     |     |     |     |     |      |
                                     |     |     |     |     |     |      |
   | Sect. |    Requirement          |  A  |  B  |  C  |  D  |  E  | IPFIX|
   |-------+-------------------------+-----+-----+-----+-----+-----+------|
   | 5.    | METERING PROCESS                                             |
   |-------+-------------------------+-----+-----+-----+-----+-----+------|
   | 5.1.  | Reliability             |  M  |  S  |  S  |  S  |  S  |      |
   |-------+-------------------------+-----+-----+-----+-----+-----+  M   |
   | 5.1.  | Indication of           |  -  |  M  |  M  |  M  |  M  |      |
   |       | missing reliability     |     |     |     |     |     |      |
   |-------+-------------------------+-----+-----+-----+-----+-----+------|
   | 6.3.  | DATA TRANSFER                                                |
   |-------+-------------------------+-----+-----+-----+-----+-----+------|
   | 6.3.1.| Congestion aware        |  M  |  M  |  M  |  M  |  M  |  M   |
   |-------+-------------------------+-----+-----+-----+-----+-----+------|
   | 6.3.2.| Reliability             |  M  |  S  |  S  |  S  |  S  |  M   |




From the above alone, my understanding (supported by many other opinions I
found in the archives), is that addressing the potential issue of
reliability is definitely within the scope of the working group - by
definition of the charter, from the the requirements and from the attention
this matter has received. A whopping 319 messages have some reference to
"reliability". One cannot claim there has not been much discussion on the
topic. This is largely due to many interested participants with varying
views of the subject.

Much of the discussion may be due to ambiguity regarding the definition of
what does "reliability" really means. Further, people are still debating
whether addressing the issue is even in scope to be addressed by the working
group, including distinguished senior IETF members.

The history of this debate is very old. For instance, you can look at
http://ipfix.doit.wisc.edu/archive/0817.html where Nevil summarizes:

> >    ** Need to reach consensus on two major points:
> >        a. We know we need reliable transport.  Do we
> >           also need unreliable?

vs.

Randy Bush wrote (http://ipfix.doit.wisc.edu/archive/0006.html)

"I assume this is standardisation of "NetFlow".
If yes, some non-proprietary way of indicating that
they are standardising existing practice would be
nice and help avoid confusion such as Brian's."

More recently Randy wrote:

In http://ipfix.doit.wisc.edu/archive/1401.html
"
> Somehow, the requirements discussion suffers from a split:
> There are requirements resulting from the intention of
> standardzing a highly reliable metering standard for precise
> accounting (and billing). Differing from these are requirements
> for a simpler metering standard more oriented at what I would
> call "typical Internet reliability".

 the original goal, which the iesg thinks was chartered, is the
latter.  "

In http://ipfix.doit.wisc.edu/archive/1413.html:
"...but the primary goal of this wg is to reconcile some _current_
inter-vendor incompatibilities,
fix congestion control, etc."

The examples just serve to demonstrate the extremes that this debate has
gone through.

If this was the case (we are merely trying to standardize NetFlow), we
shouldn't have gone to all the trouble and gotten to a protocol evaluation
phase to begin with. As we are going through that process (based on the
charter and the agreed-upon requirements), we should conclude, FIRST, that
the standardization of "NetFlow" is not the objective of the working group.

Also, 4 of the protocols proposed currently propose to use congestion-aware
protocol as underlying technology (while the NetFlow proposes to be extended
to use such a protocol).

I propose we that the SECOND conclusion is that we achieve consensus on
whether or not reliability needs or need not be addressed. I propose is that
that consensus is that the matter at least needs to be addressed and is
covered by the WG charter and requirements draft.

If both of the above are maintained as the consensus, we should arrive at a
common definition of levels and modes of reliability and refine the
requirements document to have several well-defined (unambiguous) levels of
reliability. For each of those, we would then try to achieve consensus on
which are MUST, SHOULD or MAY levels of compliance. Only then would we be
able to get to the business of comparing the protocols against less
ambiguous, agreed-upon requirements in this area.

If it can be determined that we arrive at consensus regarding these first
two points, I volunteer to document the (potentially) desired levels of
reliability so that a debate regarding the level of conformity be launched.

Nevil, perhaps this item is worthy of discussion as part of the agenda in
the IETF WG meeting itself.

Tal
____________________________________________

Tal Givoly
Chief Scientist
XACCT Technologies, Inc.
2900 Lakeside Drive
Santa Clara, CA 95054
http://www.xacct.com

Direct:  408-330-5747
Tel:     408-654-9900 x 5747
Fax:     408-654-9904
E-mail:  mailto:givoly@xacct.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  Thu Nov 14 15:32:22 2002
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 PAA29949
	for ; Thu, 14 Nov 2002 15:32:22 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18CQYK-0000v1-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 14 Nov 2002 14:25:28 -0600
Received: from pool-68-160-192-59.ny325.east.verizon.net ([68.160.192.59] helo=newyork.qosient.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18CQYI-0000uu-00
	for ipfix-eval@net.doit.wisc.edu; Thu, 14 Nov 2002 14:25:26 -0600
Received: from SET (set [192.168.0.161])
	by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id gAEKPOO14900
	for ; Thu, 14 Nov 2002 15:25:24 -0500
Reply-To: 
From: "Carter Bullard" 
To: 
Subject: [ipfix-eval] RE: [ipfix-req] IPFIX Reliability Requirement
Date: Thu, 14 Nov 2002 15:25:15 -0500
Organization: QoSient, LLC
Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A4B9@ptah.newyork.qosient.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

Gentle people,
Here is an excerpt of some mail that I sent to Peter, that
didn't make it to the list.  Understanding the nature of
an IPFIX transport failure helps to put my concerns
regarding reliability in perspective.  The failure scenario
below is but one of them, but IMHO the important one.

Carter

> Here is a scenario that I imagine.  If IPFIX is using TCP,
> for instance, what will be the nature of IPFIX record loss?
> There will be none, as long as the TCP is healthy.  When
> the TCP fails, and the receiver finally reconnects, possibly
> seconds/minutes later, the client can discover the
> number of records that were missed, possibly even the number
> of flows, bytes, packets, etc ...., through the use of the
> reliability mechanisms inherent in the IPFIX protocol, ie
> sequence numbers and integrity reports.   But there is nothing
> in the IPFIX WG's charter to specify that the IPFIX device must
> have any of these lost records to retransmit.   Routers
> definitely won't have them around.  Some expensive probes
> will, but IPFIX must support both of these devices.
> 
> To require that IPFIX support reliability through single
> channel receiver ACK'ing puts far too many constraints on
> the design and function of IPFIX devices, something that
> is out of scope of the WG.
> 
> Now if IPFIX were designed such that the receiver could
> declare what records it was interested in, then you could
> implement a selective retransmission mechanism through
> the use of multiple IPFIX sessions.  After you reconnect
> and start getting the current stream, you discover you missed
> 27,356 records.  Get another IPFIX session with the device
> and ask just for those 27,356 records, if the device supports
> it.  That sounds reasonable to me, given the nature of IPFIX
> record loss characteristics.
> 
> Carter
> 
> 



--
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 Nov 14 16:48:54 2002
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 QAA02110
	for ; Thu, 14 Nov 2002 16:48:54 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18CRaa-0002Ud-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 14 Nov 2002 15:31:52 -0600
Received: from usmail.xacct.com ([204.253.100.12])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18CRaY-0002UV-00
	for ipfix-req@net.doit.wisc.edu; Thu, 14 Nov 2002 15:31:50 -0600
Received: from Givoly ([192.168.0.2])
	by usmail.xacct.com (8.11.2/8.11.2) with SMTP id gAELZC228374;
	Thu, 14 Nov 2002 13:35:18 -0800
From: "Tal Givoly" 
To: "Juergen Quittek" 
Cc: 
Subject: RE: [ipfix-req] list of issues
Date: Thu, 14 Nov 2002 13:31:21 -0800
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <7605466.1035285886@[192.168.102.164]>
X-RBL-Warning: (dnsbl.njabl.org) relay tested -- 1016746205
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

Juergen,

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

-----Original Message-----
From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf
Of Juergen Quittek
Sent: Tuesday, October 22, 2002 2:25 AM
To: ipfix-req@net.doit.wisc.edu
Subject: [ipfix-req] list of issues


Dear all,

Since the posting of the last requirements I-D, I took some
'vacation' from the ipfix list. Now I find that I missed
participating in some very interesting discussions.

Below I try to summarize raised requriements issues.
It might be incomplete. Please add issues I missed.

My intention is to check all issues and identify an already
existing consensus, or to trigger completion of the discussion
on these issues in order to get consesus soon.

If you want to contribute to the further discussion of these
issues, please use separate emails per issues and please state
the issue in the subject field. ("Re: list of issues" is not
really helpful for continuing the MPLS label discussion).

    Juergen


Reinaldo-1a: adding a VPN-ID attribute in section 6.1

    I think this is a good point. Still I have three questions:
    - Would it be a MUST, a SHOULD, or a MAY?
    - Shall we ask it to be required only where applicable (on devices
      supporting VPN-IDs?
    - Is it required too much for an IP meter? (see MPLS label discussion)

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

Reinaldo-1b: export NATed flows (before and after)

    We already discussed this issue earlier this year and decided to not
    stating a requirement. However, it is already considered by the
    information model I-D.

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

Reinaldo-2a: Add failover requirements, for example on the ability
             to detect loss of connectivity with the collector and
             trigger the appropriate action (eg. a switch over to
             an alternate collector.)

    I haven't seen many responses on that. Is this a nice-to-have
    or a MUST?
    What would be appropriate actions?
    Is the requirement just "do something senseful in case of
    loosing a connection (or something like this) to the collector?

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

Reinaldo-2b: Add optional export of flow records to multiple collectors

    This is already covered.

Reinaldo-2c: Add optional re-transmission of lost flow records.

    This should be part of the requirements discussion (see Reinaldo-3).

Reinaldo-2d: Add: Exchange control information from the collector, monitor
             export process and detect any overload in the process of
             exporting.

    I do not think, an exchange of control information from the collector
    is required.

    Monitoring the exporter and detecting overload is not explicitly
    discussed, but implied in the reliability requirement ("indicate
    missing reliability"). Is a clarification needed that for indicating
    missing reliability a detection of overload is required?

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

Reinaldo-3: Rephrase or modify Section 6.3.2. "Reliability"

    There was an extended discussion on this. Can one of the participants
    tell me what he considers to be the consensus concerning the new
    phrasing.

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

Reinaldo-4: Add MUST requirement for exporting ICMP codes in Section 6.1

    There were not many responses on this suggestion. Personally, I do
    not consider it a MUST, but a nice-to-have.

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

Reinaldo-5: Remove Section 5.8. "Ignore Port Copy"?

    This is not a strong requirement. It's a nice-to-have.
    Is there a consesus on either keeping or removing it?

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

Reinaldo-6: Section 6.6. "Anonymization"

    As far as I understood the discussion, there was a request to more
    clearly state what kind/level of anonymization is required. I find
    this hard to decide. Therefore, I suggest keeping the more vague
    current version.

Tal> Concur.

Simon-1: Drop MPLS label

   This covers two sections:
       - Requiring the metering process to be able to separate flows by the
MPLS label
       - requiring the ability to export the MPLS label or FEC

   It has been discussed controversially for a long time. I still do not see
   a clear consensus on this issue. Fortunaltely, I do not see a
considerable
   impact on the protocol evaluation.

Tal> No strong opinion.

Tal
--
Help        mailto: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 Nov 14 17:54:19 2002
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 RAA05042
	for ; Thu, 14 Nov 2002 17:54:19 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18CSms-0004Pl-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 14 Nov 2002 16:48:39 -0600
Received: from babar.switch.ch ([130.59.4.2])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18CSmq-0004Ov-00
	for ipfix-eval@net.doit.wisc.edu; Thu, 14 Nov 2002 16:48:36 -0600
Received: from babar.switch.ch (localhost [IPv6:::1])
	by babar.switch.ch (8.12.2+Sun/8.12.2) with ESMTP id gAEMlsKt013814;
	Thu, 14 Nov 2002 23:47:54 +0100 (MET)
Received: (from leinen@localhost)
	by babar.switch.ch (8.12.2+Sun/8.12.2/Submit) id gAEMlrLE013811;
	Thu, 14 Nov 2002 23:47:53 +0100 (MET)
X-Authentication-Warning: babar.switch.ch: leinen set sender to simon@limmat.switch.ch using -f
To: Benoit Claise 
Cc: ipfix-eval@net.doit.wisc.edu
Subject: Re: [ipfix-eval] Some comments on the evaluation team draft
References: <3DD3C6C3.30408@cisco.com>
X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7,F
   7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR`
From: Simon Leinen 
In-Reply-To: <3DD3C6C3.30408@cisco.com>
Date: 14 Nov 2002 23:47:53 +0100
Message-ID: 
Lines: 27
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.90
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Precedence: bulk
Sender: majordomo listserver 

On Thu, 14 Nov 2002 16:52:35 +0100, Benoit Claise  said:
> 4.5 Time Synchronization  (5.5) LFAP: T     CRANE: T     IPDR: T
> NetFlow: P     Diameter: T

> In my draft
> http://www.ietf.org/internet-drafts/draft-claise-ipfix-eval-netflow-03.txt,
> I wrote

>     3.4.5 Time Synchronization (5.5)

>     _ Total Compliance. _
>     The export packet header contains the UTC time of the export packet
>     generation. This header also contains the router sysUpTime at the
>     time of the export packet generation. The UTC time the router booted
>     can therefore be deduced. The flow records contain the flow start
>     and flow end sysUpTime, so that the NetFlow collector can deduce the
>     flow start and flow end UTC time.

Yes, but the problem is (Mark Fullmer pointed this out) that the UTC
time field in the header only has 1-second resolution, so a collector
cannot convert flow timestamps to UTC times with the required
precision (centiseconds or better).

It could be fixed by making the UTC time field in the header more
precise.  I think earlier versions of NetFlow had this.
-- 
Simon.

--
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 Nov 14 18:00:46 2002
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 SAA07438
	for ; Thu, 14 Nov 2002 18:00:46 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18CStJ-0004dr-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 14 Nov 2002 16:55:17 -0600
Received: from babar.switch.ch ([130.59.4.2])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18CStG-0004cp-00; Thu, 14 Nov 2002 16:55:14 -0600
Received: from babar.switch.ch (localhost [IPv6:::1])
	by babar.switch.ch (8.12.2+Sun/8.12.2) with ESMTP id gAEMsYKt013830;
	Thu, 14 Nov 2002 23:54:34 +0100 (MET)
Received: (from leinen@localhost)
	by babar.switch.ch (8.12.2+Sun/8.12.2/Submit) id gAEMsXZT013827;
	Thu, 14 Nov 2002 23:54:33 +0100 (MET)
X-Authentication-Warning: babar.switch.ch: leinen set sender to simon@limmat.switch.ch using -f
To: Benoit Claise 
Cc: ipfix-eval@net.doit.wisc.edu, ipfix-req@net.doit.wisc.edu
Subject: Re: [ipfix-eval] Some comments on the evaluation team draft
References: <3DD3C6C3.30408@cisco.com>
X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7,F
   7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR`
From: Simon Leinen 
In-Reply-To: <3DD3C6C3.30408@cisco.com>
Date: 14 Nov 2002 23:54:33 +0100
Message-ID: 
Lines: 28
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.90
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Precedence: bulk
Sender: majordomo listserver 

On Thu, 14 Nov 2002 16:52:35 +0100, Benoit Claise  said:
> 5.7 Anonymization  (6.7)   LFAP: E     CRANE: E     IPDR: E
> NetFlow: E     Diameter: E

> In my draft http://www.ietf.org/internet-drafts/draft-claise-ipfix-eval-netflow-03.txt, I wrote


>     3.5.7 Anonymization (6.6)
>             "The exporting process MAY be capable of anonymizing
> source and
>        destination IP addresses in flow data before exporting them."
>        _Total Compliance. _

> You can export the prefix is you want to and not the specific source
> and destination IP addresses.

I would call that "(router-based) aggregation" rather than
"anonymization".  With anonymization you somehow expect to maintain
granularity, but want some kind of (non-reversible?) scrambling to
cover up privacy-sensitive parts of the traffic data, such as IP
addresses.

Don't take this requirement too seriously.  None of the candidates has
addressed this, and I think as a requirement it hasn't been thought
through too well.  It doesn't really reflect current practice, and
personally I think this is better done on the collector side.
-- 
Simon.

--
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 Nov 14 18:35:01 2002
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 SAA08364
	for ; Thu, 14 Nov 2002 18:35:01 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18CTLm-0005Qh-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 14 Nov 2002 17:24:42 -0600
Received: from babar.switch.ch ([130.59.4.2])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18CStG-0004cp-00; Thu, 14 Nov 2002 16:55:14 -0600
Received: from babar.switch.ch (localhost [IPv6:::1])
	by babar.switch.ch (8.12.2+Sun/8.12.2) with ESMTP id gAEMsYKt013830;
	Thu, 14 Nov 2002 23:54:34 +0100 (MET)
Received: (from leinen@localhost)
	by babar.switch.ch (8.12.2+Sun/8.12.2/Submit) id gAEMsXZT013827;
	Thu, 14 Nov 2002 23:54:33 +0100 (MET)
X-Authentication-Warning: babar.switch.ch: leinen set sender to simon@limmat.switch.ch using -f
To: Benoit Claise 
Cc: ipfix-eval@net.doit.wisc.edu, ipfix-req@net.doit.wisc.edu
Subject: [ipfix-req] Re: [ipfix-eval] Some comments on the evaluation team draft
References: <3DD3C6C3.30408@cisco.com>
X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7,F
   7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR`
From: Simon Leinen 
In-Reply-To: <3DD3C6C3.30408@cisco.com>
Date: 14 Nov 2002 23:54:33 +0100
Message-ID: 
Lines: 28
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.90
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Precedence: bulk
Sender: majordomo listserver 

On Thu, 14 Nov 2002 16:52:35 +0100, Benoit Claise  said:
> 5.7 Anonymization  (6.7)   LFAP: E     CRANE: E     IPDR: E
> NetFlow: E     Diameter: E

> In my draft http://www.ietf.org/internet-drafts/draft-claise-ipfix-eval-netflow-03.txt, I wrote


>     3.5.7 Anonymization (6.6)
>             "The exporting process MAY be capable of anonymizing
> source and
>        destination IP addresses in flow data before exporting them."
>        _Total Compliance. _

> You can export the prefix is you want to and not the specific source
> and destination IP addresses.

I would call that "(router-based) aggregation" rather than
"anonymization".  With anonymization you somehow expect to maintain
granularity, but want some kind of (non-reversible?) scrambling to
cover up privacy-sensitive parts of the traffic data, such as IP
addresses.

Don't take this requirement too seriously.  None of the candidates has
addressed this, and I think as a requirement it hasn't been thought
through too well.  It doesn't really reflect current practice, and
personally I think this is better done on the collector side.
-- 
Simon.

--
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 Nov 14 18:37:05 2002
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 SAA08429
	for ; Thu, 14 Nov 2002 18:37:05 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18CTRT-0005Xx-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 14 Nov 2002 17:30:35 -0600
Received: from sj-msg-core-1.cisco.com ([171.71.163.11])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18CTRR-0005XZ-00
	for ipfix-eval@net.doit.wisc.edu; Thu, 14 Nov 2002 17:30:33 -0600
Received: from vvalluri-u10.cisco.com (vvalluri-u10.cisco.com [128.107.162.119])
	by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAENU0Ng004447;
	Thu, 14 Nov 2002 15:30:00 -0800 (PST)
Date: Thu, 14 Nov 2002 15:30:00 -0800 (PST)
From: Vamsidhar Valluri 
To: Simon Leinen 
cc: Benoit Claise , 
Subject: Re: [ipfix-eval] Some comments on the evaluation team draft
In-Reply-To: 
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk
Sender: majordomo listserver 



On 14 Nov 2002, Simon Leinen wrote:

> On Thu, 14 Nov 2002 16:52:35 +0100, Benoit Claise  said:
> > 4.5 Time Synchronization  (5.5) LFAP: T     CRANE: T     IPDR: T
> > NetFlow: P     Diameter: T
>
> > In my draft
> > http://www.ietf.org/internet-drafts/draft-claise-ipfix-eval-netflow-03.txt,
> > I wrote
>
> >     3.4.5 Time Synchronization (5.5)
>
> >     _ Total Compliance. _
> >     The export packet header contains the UTC time of the export packet
> >     generation. This header also contains the router sysUpTime at the
> >     time of the export packet generation. The UTC time the router booted
> >     can therefore be deduced. The flow records contain the flow start
> >     and flow end sysUpTime, so that the NetFlow collector can deduce the
> >     flow start and flow end UTC time.
>
> Yes, but the problem is (Mark Fullmer pointed this out) that the UTC
> time field in the header only has 1-second resolution, so a collector
> cannot convert flow timestamps to UTC times with the required
> precision (centiseconds or better).
>
> It could be fixed by making the UTC time field in the header more
> precise.  I think earlier versions of NetFlow had this.

We are considering the suggestion made by Mark Fullmer to change this to
more precise value.

-vamsi

> --
> Simon.
>
> --
> 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 Nov 14 18:46:04 2002
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 SAA08720
	for ; Thu, 14 Nov 2002 18:46:04 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18CTXB-0005dU-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 14 Nov 2002 17:36:30 -0600
Received: from usmail.xacct.com ([204.253.100.12])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18CTXA-0005dM-00; Thu, 14 Nov 2002 17:36:28 -0600
Received: from Givoly ([192.168.0.2])
	by usmail.xacct.com (8.11.2/8.11.2) with SMTP id gAENdq230383;
	Thu, 14 Nov 2002 15:39:52 -0800
From: "Tal Givoly" 
To: "Simon Leinen" 
Cc: , ,
        "Benoit Claise" 
Subject: RE: [ipfix-eval] Some comments on the evaluation team draft
Date: Thu, 14 Nov 2002 15:36:01 -0800
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: 
X-RBL-Warning: (dnsbl.njabl.org) relay tested -- 1016746205
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

Simon,

I fully support your conclusion.

Tal

-----Original Message-----
From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf
Of Simon Leinen
Sent: Thursday, November 14, 2002 2:55 PM
To: Benoit Claise
Cc: ipfix-eval@net.doit.wisc.edu; ipfix-req@net.doit.wisc.edu
Subject: Re: [ipfix-eval] Some comments on the evaluation team draft


On Thu, 14 Nov 2002 16:52:35 +0100, Benoit Claise  said:
> 5.7 Anonymization  (6.7)   LFAP: E     CRANE: E     IPDR: E
> NetFlow: E     Diameter: E

> In my draft
http://www.ietf.org/internet-drafts/draft-claise-ipfix-eval-netflow-03.txt,
I wrote


>     3.5.7 Anonymization (6.6)
>             "The exporting process MAY be capable of anonymizing
> source and
>        destination IP addresses in flow data before exporting them."
>        _Total Compliance. _

> You can export the prefix is you want to and not the specific source
> and destination IP addresses.

I would call that "(router-based) aggregation" rather than
"anonymization".  With anonymization you somehow expect to maintain
granularity, but want some kind of (non-reversible?) scrambling to
cover up privacy-sensitive parts of the traffic data, such as IP
addresses.

Don't take this requirement too seriously.  None of the candidates has
addressed this, and I think as a requirement it hasn't been thought
through too well.  It doesn't really reflect current practice, and
personally I think this is better done on the collector side.
--
Simon.

--
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 Nov 14 19:05:18 2002
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 TAA09311
	for ; Thu, 14 Nov 2002 19:05:17 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18CTrL-0006G0-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 14 Nov 2002 17:57:19 -0600
Received: from usmail.xacct.com ([204.253.100.12])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18CTXA-0005dM-00; Thu, 14 Nov 2002 17:36:28 -0600
Received: from Givoly ([192.168.0.2])
	by usmail.xacct.com (8.11.2/8.11.2) with SMTP id gAENdq230383;
	Thu, 14 Nov 2002 15:39:52 -0800
From: "Tal Givoly" 
To: "Simon Leinen" 
Cc: , ,
        "Benoit Claise" 
Subject: [ipfix-req] RE: [ipfix-eval] Some comments on the evaluation team draft
Date: Thu, 14 Nov 2002 15:36:01 -0800
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: 
X-RBL-Warning: (dnsbl.njabl.org) relay tested -- 1016746205
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

Simon,

I fully support your conclusion.

Tal

-----Original Message-----
From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf
Of Simon Leinen
Sent: Thursday, November 14, 2002 2:55 PM
To: Benoit Claise
Cc: ipfix-eval@net.doit.wisc.edu; ipfix-req@net.doit.wisc.edu
Subject: Re: [ipfix-eval] Some comments on the evaluation team draft


On Thu, 14 Nov 2002 16:52:35 +0100, Benoit Claise  said:
> 5.7 Anonymization  (6.7)   LFAP: E     CRANE: E     IPDR: E
> NetFlow: E     Diameter: E

> In my draft
http://www.ietf.org/internet-drafts/draft-claise-ipfix-eval-netflow-03.txt,
I wrote


>     3.5.7 Anonymization (6.6)
>             "The exporting process MAY be capable of anonymizing
> source and
>        destination IP addresses in flow data before exporting them."
>        _Total Compliance. _

> You can export the prefix is you want to and not the specific source
> and destination IP addresses.

I would call that "(router-based) aggregation" rather than
"anonymization".  With anonymization you somehow expect to maintain
granularity, but want some kind of (non-reversible?) scrambling to
cover up privacy-sensitive parts of the traffic data, such as IP
addresses.

Don't take this requirement too seriously.  None of the candidates has
addressed this, and I think as a requirement it hasn't been thought
through too well.  It doesn't really reflect current practice, and
personally I think this is better done on the collector side.
--
Simon.

--
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 Nov 14 19:50:29 2002
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 TAA10918
	for ; Thu, 14 Nov 2002 19:50:28 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18CUYf-0007JX-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 14 Nov 2002 18:42:06 -0600
Received: from tokyo.ccrle.nec.de ([195.37.70.2])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18CUYd-0007IW-00
	for ipfix-req@net.doit.wisc.edu; Thu, 14 Nov 2002 18:42:04 -0600
Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11])
	by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gAF0fUY95460;
	Fri, 15 Nov 2002 01:41:30 +0100 (CET)
	(envelope-from quittek@ccrle.nec.de)
Received: from [192.168.102.31] (unknown [192.168.102.31])
	by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP
	id 91EC46E808; Fri, 15 Nov 2002 01:40:25 +0100 (CET)
Date: Fri, 15 Nov 2002 01:40:23 +0100
From: Juergen Quittek 
To: Tal Givoly 
Cc: ipfix-req@net.doit.wisc.edu
Subject: VPN-IDs, was: RE: [ipfix-req] list of issues
Message-ID: <43062480.1037324422@[192.168.102.31]>
In-Reply-To: 
References:  
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

Tal,

-- Tal Givoly wrote on 14 November 2002 13:31 -0800:

> Reinaldo-1a: adding a VPN-ID attribute in section 6.1
>
>     I think this is a good point. Still I have three questions:
>     - Would it be a MUST, a SHOULD, or a MAY?
>     - Shall we ask it to be required only where applicable (on devices
>       supporting VPN-IDs?
>     - Is it required too much for an IP meter? (see MPLS label discussion)
>
> Tal> Should not be mandatory (i.e. remove) - would inflate data structure

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

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

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

> Reinaldo-1b: export NATed flows (before and after)
>
>     We already discussed this issue earlier this year and decided to not
>     stating a requirement. However, it is already considered by the
>     information model I-D.
>
> Tal> Should not be mandatory (i.e. remove) - same reason as above.

Same ocmment as above.

    Juergen


--
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 Nov 14 19:58:22 2002
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 TAA11385
	for ; Thu, 14 Nov 2002 19:58:17 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18CUhj-0007U8-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 14 Nov 2002 18:51:27 -0600
Received: from tokyo.ccrle.nec.de ([195.37.70.2])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18CUhh-0007Ta-00
	for ipfix-req@net.doit.wisc.edu; Thu, 14 Nov 2002 18:51:25 -0600
Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11])
	by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gAF0osY95565;
	Fri, 15 Nov 2002 01:50:54 +0100 (CET)
	(envelope-from quittek@ccrle.nec.de)
Received: from [192.168.102.31] (unknown [192.168.102.31])
	by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP
	id C87AA6E804; Fri, 15 Nov 2002 01:49:53 +0100 (CET)
Date: Fri, 15 Nov 2002 01:49:51 +0100
From: Juergen Quittek 
To: Tal Givoly 
Cc: ipfix-req@net.doit.wisc.edu
Subject: failover requirements, was: RE: [ipfix-req] list of issues
Message-ID: <43631098.1037324991@[192.168.102.31]>
In-Reply-To: 
References:  
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

Tal,

-- Tal Givoly wrote on 14 November 2002 13:31 -0800:

> Reinaldo-2a: Add failover requirements, for example on the ability
>              to detect loss of connectivity with the collector and
>              trigger the appropriate action (eg. a switch over to
>              an alternate collector.)
>
>     I haven't seen many responses on that. Is this a nice-to-have
>     or a MUST?
>     What would be appropriate actions?
>     Is the requirement just "do something senseful in case of
>     loosing a connection (or something like this) to the collector?
>
> Tal> I strongly believe that the protocol MUST support a mode in which it
> operates fail-over. It should be noted that failover implicitly requires
> bi-directional communication (minimally offered by transport protocol).
> Therefore the way I see it, protocol MUST have a MODE in which it can fail
> over to a backup collector in one of several cases. These cases may include
> (but are not limited to), failure of the collector, failure of the link to
> the collector, overload of the collector, lack of acknowledgement from
> collector, signal from collector, and negative acknowledge from collector.
> I'm sure there would be a debate whether that mode must exist in each
> implementation or it merely be optional to support that mode. The protocol
> itself must have such a mode, IMHO.

What about the following change:

in draft-ietf-ipfix-reqs-07 replace

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

by

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


    Juergen

--
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 Nov 14 20:06:44 2002
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 UAA11766
	for ; Thu, 14 Nov 2002 20:06:44 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18CUpC-0007lo-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 14 Nov 2002 18:59:10 -0600
Received: from tokyo.ccrle.nec.de ([195.37.70.2])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18CUpA-0007l3-00
	for ipfix-req@net.doit.wisc.edu; Thu, 14 Nov 2002 18:59:08 -0600
Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11])
	by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gAF0wcY95672;
	Fri, 15 Nov 2002 01:58:38 +0100 (CET)
	(envelope-from quittek@ccrle.nec.de)
Received: from [192.168.102.31] (unknown [192.168.102.31])
	by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP
	id 0BA706E816; Fri, 15 Nov 2002 01:57:37 +0100 (CET)
Date: Fri, 15 Nov 2002 01:57:35 +0100
From: Juergen Quittek 
To: Tal Givoly 
Cc: ipfix-req@net.doit.wisc.edu
Subject: RE: [ipfix-req] list of issues
Message-ID: <44094925.1037325455@[192.168.102.31]>
In-Reply-To: 
References:  
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

Tal,

-- Tal Givoly wrote on 14 November 2002 13:31 -0800:

> Reinaldo-2d: Add: Exchange control information from the collector, monitor
>              export process and detect any overload in the process of
>              exporting.
>
>     I do not think, an exchange of control information from the collector
>     is required.
>
>     Monitoring the exporter and detecting overload is not explicitly
>     discussed, but implied in the reliability requirement ("indicate
>     missing reliability"). Is a clarification needed that for indicating
>     missing reliability a detection of overload is required?
>
> Tal> I believe that overload in the collector or in the network needs to be
> handled and be included as part of overload behavior.

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

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

    Juergen

--
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 Nov 14 20:14:09 2002
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 UAA12032
	for ; Thu, 14 Nov 2002 20:14:09 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18CUy0-0000EG-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 14 Nov 2002 19:08:16 -0600
Received: from tokyo.ccrle.nec.de ([195.37.70.2])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18CUxy-0000A1-00
	for ipfix-req@net.doit.wisc.edu; Thu, 14 Nov 2002 19:08:14 -0600
Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11])
	by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gAF17hY95804;
	Fri, 15 Nov 2002 02:07:43 +0100 (CET)
	(envelope-from quittek@ccrle.nec.de)
Received: from [192.168.102.31] (unknown [192.168.102.31])
	by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP
	id CFA8A6E0C5; Fri, 15 Nov 2002 02:06:41 +0100 (CET)
Date: Fri, 15 Nov 2002 02:06:40 +0100
From: Juergen Quittek 
To: Tal Givoly 
Cc: ipfix-req@net.doit.wisc.edu
Subject: improve reliability section, was: RE: [ipfix-req] list of issues
Message-ID: <44640739.1037326000@[192.168.102.31]>
In-Reply-To: 
References:  
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

Tal,

-- Tal Givoly wrote on 14 November 2002 13:31 -0800:

> Reinaldo-3: Rephrase or modify Section 6.3.2. "Reliability"
>
>     There was an extended discussion on this. Can one of the participants
>     tell me what he considers to be the consensus concerning the new
>     phrasing.
>
> Tal> I don't believe we have arrived at consensus. I would welcome the
> opportunity to take a stab at phrasing the consensus or even the options for
> consensus once we, first, achieve consensus on at least two principles:
> - We are not here to standardize NetFlow

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

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

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

    Juergen



--
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 Nov 14 20:19:55 2002
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 UAA12293
	for ; Thu, 14 Nov 2002 20:19:55 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18CV3O-0000M6-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 14 Nov 2002 19:13:50 -0600
Received: from tokyo.ccrle.nec.de ([195.37.70.2])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18CV3M-0000LK-00
	for ipfix-req@net.doit.wisc.edu; Thu, 14 Nov 2002 19:13:48 -0600
Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11])
	by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gAF1DHY95870;
	Fri, 15 Nov 2002 02:13:17 +0100 (CET)
	(envelope-from quittek@ccrle.nec.de)
Received: from [192.168.102.31] (unknown [192.168.102.31])
	by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP
	id CFC1B6E82C; Fri, 15 Nov 2002 02:12:15 +0100 (CET)
Date: Fri, 15 Nov 2002 02:12:15 +0100
From: Juergen Quittek 
To: Tal Givoly 
Cc: ipfix-req@net.doit.wisc.edu
Subject: MUST or SHOULD be able to export ICMP codes? was:RE: [ipfix-req] list of issues
Message-ID: <44974980.1037326335@[192.168.102.31]>
In-Reply-To: 
References:  
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

Tal,

-- Tal Givoly wrote on 14 November 2002 13:31 -0800:

> Reinaldo-4: Add MUST requirement for exporting ICMP codes in Section 6.1
>
>     There were not many responses on this suggestion. Personally, I do
>     not consider it a MUST, but a nice-to-have.
>
> Tal> I believe this should be classified as a SHOULD.

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

    Juergen

--
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 Nov 14 20:22:53 2002
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 UAA12380
	for ; Thu, 14 Nov 2002 20:22:53 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18CV5p-0000Pe-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 14 Nov 2002 19:16:21 -0600
Received: from tokyo.ccrle.nec.de ([195.37.70.2])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18CV5n-0000Or-00
	for ipfix-req@net.doit.wisc.edu; Thu, 14 Nov 2002 19:16:19 -0600
Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11])
	by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gAF1FmY95895;
	Fri, 15 Nov 2002 02:15:48 +0100 (CET)
	(envelope-from quittek@ccrle.nec.de)
Received: from [192.168.102.31] (unknown [192.168.102.31])
	by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP
	id 614976E82C; Fri, 15 Nov 2002 02:14:47 +0100 (CET)
Date: Fri, 15 Nov 2002 02:14:46 +0100
From: Juergen Quittek 
To: Tal Givoly 
Cc: ipfix-req@net.doit.wisc.edu
Subject: RE: [ipfix-req] list of issues
Message-ID: <45126057.1037326486@[192.168.102.31]>
In-Reply-To: 
References:  
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

Tal,

-- Tal Givoly wrote on 14 November 2002 13:31 -0800:

> Reinaldo-5: Remove Section 5.8. "Ignore Port Copy"?
>
>     This is not a strong requirement. It's a nice-to-have.
>     Is there a consesus on either keeping or removing it?
>
> Tal> I believe it can be removed for reasons described above regarding VPN.

I don't understand at all. Regarding VPN-IDs you said:

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

How does this relate to ignoring port copy?

    Juergen


--
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 Nov 14 21:21:15 2002
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 VAA13861
	for ; Thu, 14 Nov 2002 21:21:14 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18CW1t-0001qB-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 14 Nov 2002 20:16:21 -0600
Received: from usmail.xacct.com ([204.253.100.12])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18CW1q-0001q0-00
	for ipfix-req@net.doit.wisc.edu; Thu, 14 Nov 2002 20:16:18 -0600
Received: from Givoly ([192.168.0.2])
	by usmail.xacct.com (8.11.2/8.11.2) with SMTP id gAF2Ji232615;
	Thu, 14 Nov 2002 18:19:50 -0800
From: "Tal Givoly" 
To: "Juergen Quittek" 
Cc: 
Subject: RE: improve reliability section, was: RE: [ipfix-req] list of issues
Date: Thu, 14 Nov 2002 18:15:54 -0800
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <44640739.1037326000@[192.168.102.31]>
X-RBL-Warning: (dnsbl.njabl.org) relay tested -- 1016746205
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

Jurgen,

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

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

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

Tal

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


Tal,

-- Tal Givoly wrote on 14 November 2002 13:31 -0800:

> Reinaldo-3: Rephrase or modify Section 6.3.2. "Reliability"
>
>     There was an extended discussion on this. Can one of the participants
>     tell me what he considers to be the consensus concerning the new
>     phrasing.
>
> Tal> I don't believe we have arrived at consensus. I would welcome the
> opportunity to take a stab at phrasing the consensus or even the options
for
> consensus once we, first, achieve consensus on at least two principles:
> - We are not here to standardize NetFlow

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

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

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

    Juergen



--
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 Nov 14 21:21:27 2002
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 VAA13874
	for ; Thu, 14 Nov 2002 21:21:27 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18CW2C-0001qV-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 14 Nov 2002 20:16:40 -0600
Received: from usmail.xacct.com ([204.253.100.12])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18CW2A-0001qL-00
	for ipfix-req@net.doit.wisc.edu; Thu, 14 Nov 2002 20:16:38 -0600
Received: from Givoly ([192.168.0.2])
	by usmail.xacct.com (8.11.2/8.11.2) with SMTP id gAF2Jo232619;
	Thu, 14 Nov 2002 18:19:54 -0800
From: "Tal Givoly" 
To: "Juergen Quittek" 
Cc: 
Subject: RE: [ipfix-req] list of issues
Date: Thu, 14 Nov 2002 18:16:00 -0800
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <44094925.1037325455@[192.168.102.31]>
X-RBL-Warning: (dnsbl.njabl.org) relay tested -- 1016746205
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

Juergen,

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

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

Tal

-----Original Message-----
From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf
Of Juergen Quittek
Sent: Thursday, November 14, 2002 4:58 PM
To: Tal Givoly
Cc: ipfix-req@net.doit.wisc.edu
Subject: RE: [ipfix-req] list of issues


Tal,

-- Tal Givoly wrote on 14 November 2002 13:31 -0800:

> Reinaldo-2d: Add: Exchange control information from the collector, monitor
>              export process and detect any overload in the process of
>              exporting.
>
>     I do not think, an exchange of control information from the collector
>     is required.
>
>     Monitoring the exporter and detecting overload is not explicitly
>     discussed, but implied in the reliability requirement ("indicate
>     missing reliability"). Is a clarification needed that for indicating
>     missing reliability a detection of overload is required?
>
> Tal> I believe that overload in the collector or in the network needs to
be
> handled and be included as part of overload behavior.

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

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

    Juergen

--
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 Nov 14 21:21:28 2002
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 VAA13881
	for ; Thu, 14 Nov 2002 21:21:28 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18CW2O-0001rA-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 14 Nov 2002 20:16:52 -0600
Received: from usmail.xacct.com ([204.253.100.12])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18CW2L-0001qk-00
	for ipfix-req@net.doit.wisc.edu; Thu, 14 Nov 2002 20:16:49 -0600
Received: from Givoly ([192.168.0.2])
	by usmail.xacct.com (8.11.2/8.11.2) with SMTP id gAF2K1232628;
	Thu, 14 Nov 2002 18:20:09 -0800
From: "Tal Givoly" 
To: "Juergen Quittek" 
Cc: 
Subject: RE: VPN-IDs, was: RE: [ipfix-req] list of issues
Date: Thu, 14 Nov 2002 18:16:10 -0800
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <43062480.1037324422@[192.168.102.31]>
X-RBL-Warning: (dnsbl.njabl.org) relay tested -- 1016746205
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

Juergen,

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

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

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

Tal

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


Tal,

-- Tal Givoly wrote on 14 November 2002 13:31 -0800:

> Reinaldo-1a: adding a VPN-ID attribute in section 6.1
>
>     I think this is a good point. Still I have three questions:
>     - Would it be a MUST, a SHOULD, or a MAY?
>     - Shall we ask it to be required only where applicable (on devices
>       supporting VPN-IDs?
>     - Is it required too much for an IP meter? (see MPLS label discussion)
>
> Tal> Should not be mandatory (i.e. remove) - would inflate data structure

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

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

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

> Reinaldo-1b: export NATed flows (before and after)
>
>     We already discussed this issue earlier this year and decided to not
>     stating a requirement. However, it is already considered by the
>     information model I-D.
>
> Tal> Should not be mandatory (i.e. remove) - same reason as above.

Same ocmment as above.

    Juergen


--
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 Nov 14 23:25:30 2002
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 XAA17720
	for ; Thu, 14 Nov 2002 23:25:30 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18CXvg-0004hY-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 14 Nov 2002 22:18:04 -0600
Received: from usmail.xacct.com ([204.253.100.12])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18CXvf-0004hO-00
	for ipfix@net.doit.wisc.edu; Thu, 14 Nov 2002 22:18:03 -0600
Received: from peter ([192.168.254.172])
	by usmail.xacct.com (8.11.2/8.11.2) with SMTP id gAF4La201597;
	Thu, 14 Nov 2002 20:21:37 -0800
From: "Peter Ludemann" 
To: "Carter Bullard" 
Cc: 
Subject: RE: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt
Date: Thu, 14 Nov 2002 20:17:48 -0800
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <5C8959A16A71B449AE793CF52FBBED6607A4B6@ptah.newyork.qosient.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-RBL-Warning: (dnsbl.njabl.org) relay tested -- 1016746205
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

Carter:

Your statement could be true for one definition of reliability, but not for
full reliability with fail-over. For that, one needs *exporter" detection of
message loss (this could be caused by link failure or by collector failure -
that is, failure to acknowledge); the exporter can then fail-over to another
collector and retransmit unacknowledged records.

Probably we need multiple "levels" of reliability (I tried to define some in
a note a few days ago); reliability isn't a one-size-fits-all item and we
should have a protocol which can support the various kinds of reliability.

- peter

> -----Original Message-----
> From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf
> Of Carter Bullard
> Sent: Wednesday, November 13, 2002 8:50 AM
> To: calato@riverstonenet.com
> Cc: ipfix@net.doit.wisc.edu
> Subject: RE: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt
>
>
> Hey Paul,
>    I believe that your list of 4 items is missing
> the critical reliability support mechanism that IPFIX
> has in its list of requirements.   IMHO, the only
> reliability mechanism that IPFIX needs.
>
>    Receiver detection of IPFIX message loss.
>
>    If the protocol supports this basic property, vendors
> can then build reliable systems; as reliable as any
> customer can afford.  Supplementing this with data
> stream integrity mechanisms so that the receiver can
> realize the nature of any loss, would be a dream
> solution.
>
>    What does this mean for the protocol?  Sequence
> numbers and periodic stream integrity reports. Anything
> else can be vendor improvements.   IMHO.
>
> Carter
>
>
> > -----Original Message-----
> > From: majordomo listserver
> > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of
> > calato@riverstonenet.com
> > Sent: Wednesday, November 13, 2002 10:35 AM
> > Cc: ipfix@net.doit.wisc.edu
> > Subject: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt
> >
> >
> >
> > I'm left wondering what level of reliability is in scope?
> >
> > It seems we a few people that agree a highly reliable
> > protocol is out of scope and several agreeing it is in
> > scope. Since one person from the former was wearing an AD
> > hat I'm left still uncertain of the outcome.
> >
> > Is high reliability in scope or out of scope. If out
> > of scope, to what level is in scope?
> >
> > 	1. Transport level reliability
> > 	2. Redundancy reliability (e.g. sending all data
> > 	   to multiple collectors or multicasting)
> > 	3. Failover (i.e. detecting a collector is
> > 	   down and switching to another)
> > 	4. Congestion awareness only (i.e. send and forget)
> >
> > What level of reliability is in scope?
> >
> > Paul
> >
> > --
> > 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 Nov 15 01:47:34 2002
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 BAA21131
	for ; Fri, 15 Nov 2002 01:47:33 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18Ca5c-00001L-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 15 Nov 2002 00:36:28 -0600
Received: from pool-68-160-192-59.ny325.east.verizon.net ([68.160.192.59] helo=newyork.qosient.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18Ca5a-00001F-00
	for ipfix@net.doit.wisc.edu; Fri, 15 Nov 2002 00:36:26 -0600
Received: from SET (set [192.168.0.161])
	by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id gAF6aPO06801;
	Fri, 15 Nov 2002 01:36:25 -0500
Reply-To: 
From: "Carter Bullard" 
To: "'Peter Ludemann'" 
Cc: 
Subject: RE: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt
Date: Fri, 15 Nov 2002 01:36:02 -0500
Organization: QoSient, LLC
Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A4BA@ptah.newyork.qosient.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
In-Reply-To: <5C8959A16A71B449AE793CF52FBBED660D7D67@ptah.newyork.qosient.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

Hey Peter,
   This is of course the problem with discussions of reliability.
Your goal of full reliability (is that 100% reliability ?) is
difficult to achieve, and your described strategy for achieving
it doesn't necessarily get you closer to your goal.  At 20-50K
records per second, source initiated failover to a secondary
receiver isn't going to get you full reliability.  The only
way an IPFIX device can support operational reliability at
the performance levels discussed (> 20-50K records per second)
is for it to have enough storage to ride through at the least
a 120 second outage, assuming TCP is the transport protocol
of choice.  That would be about 250MB-1GB of high performance
storage, depending on your flow model and deployment.  This
generally means a disk.

The idea of a transport protocol requiring a local disk on
a router is not a strategy that will be successful in the IETF.
Lets not go there, so to speak.

A successful IPFIX strategy will result in a transport protocol
that can support vendors building reliable architectures.  Minimally
that means to me receiver loss detection and stream integrity
checking. With those simple mechanisms, I can build as
reliable an IPFIX architecture that can be built.  The cheapest
one would use source multicasting.  With source multicasting,
there is no need for transport fault detection at the source or
any type of failover.

The most expensive architecture would involve fully redundant
probes, with multiple tap points and lots of local storage,
fully redundant data streams feeding fully redundant collectors
that populate fully redundant IPFIX record data stores.  The IPFIX
devices would be designed to allow multiple concurrent connections
initiated by the collectors, so that the redundant collection
architecture can completely control the flow of IPFIX records.
All that is additionally needed here is for the IPFIX data model
to support duplicate record rejection.

Carter



> -----Original Message-----
> From: Peter Ludemann [mailto:peter.ludemann@xacct.com] 
> Sent: Thursday, November 14, 2002 11:18 PM
> To: Carter Bullard
> Cc: ipfix@net.doit.wisc.edu
> Subject: RE: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt
> 
> 
> Carter:
> 
> Your statement could be true for one definition of 
> reliability, but not for full reliability with fail-over. For 
> that, one needs *exporter" detection of message loss (this 
> could be caused by link failure or by collector failure - 
> that is, failure to acknowledge); the exporter can then 
> fail-over to another collector and retransmit unacknowledged records.
> 
> Probably we need multiple "levels" of reliability (I tried to 
> define some in a note a few days ago); reliability isn't a 
> one-size-fits-all item and we should have a protocol which 
> can support the various kinds of reliability.
> 
> - peter
> 
> > -----Original Message-----
> > From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On 
> > Behalf Of Carter Bullard
> > Sent: Wednesday, November 13, 2002 8:50 AM
> > To: calato@riverstonenet.com
> > Cc: ipfix@net.doit.wisc.edu
> > Subject: RE: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt
> >
> >
> > Hey Paul,
> >    I believe that your list of 4 items is missing
> > the critical reliability support mechanism that IPFIX
> > has in its list of requirements.   IMHO, the only
> > reliability mechanism that IPFIX needs.
> >
> >    Receiver detection of IPFIX message loss.
> >
> >    If the protocol supports this basic property, vendors
> > can then build reliable systems; as reliable as any
> > customer can afford.  Supplementing this with data
> > stream integrity mechanisms so that the receiver can
> > realize the nature of any loss, would be a dream
> > solution.
> >
> >    What does this mean for the protocol?  Sequence
> > numbers and periodic stream integrity reports. Anything
> > else can be vendor improvements.   IMHO.
> >
> > Carter
> >
> >
> > > -----Original Message-----
> > > From: majordomo listserver 
> [mailto:majordomo@mil.doit.wisc.edu] On 
> > > Behalf Of calato@riverstonenet.com
> > > Sent: Wednesday, November 13, 2002 10:35 AM
> > > Cc: ipfix@net.doit.wisc.edu
> > > Subject: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt
> > >
> > >
> > >
> > > I'm left wondering what level of reliability is in scope?
> > >
> > > It seems we a few people that agree a highly reliable protocol is 
> > > out of scope and several agreeing it is in scope. Since 
> one person 
> > > from the former was wearing an AD hat I'm left still uncertain of 
> > > the outcome.
> > >
> > > Is high reliability in scope or out of scope. If out
> > > of scope, to what level is in scope?
> > >
> > > 	1. Transport level reliability
> > > 	2. Redundancy reliability (e.g. sending all data
> > > 	   to multiple collectors or multicasting)
> > > 	3. Failover (i.e. detecting a collector is
> > > 	   down and switching to another)
> > > 	4. Congestion awareness only (i.e. send and forget)
> > >
> > > What level of reliability is in scope?
> > >
> > > Paul
> > >
> > > --
> > > 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 Nov 15 03:03:21 2002
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 DAA02284
	for ; Fri, 15 Nov 2002 03:03:21 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18Cb36-0001cm-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 15 Nov 2002 01:37:56 -0600
Received: from usmail.xacct.com ([204.253.100.12])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18Cb34-0001cg-00
	for ipfix@net.doit.wisc.edu; Fri, 15 Nov 2002 01:37:54 -0600
Received: from peter ([192.168.254.172])
	by usmail.xacct.com (8.11.2/8.11.2) with SMTP id gAF7fZ203021;
	Thu, 14 Nov 2002 23:41:36 -0800
From: "Peter Ludemann" 
To: 
Cc: 
Subject: RE: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt
Date: Thu, 14 Nov 2002 23:37:33 -0800
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <5C8959A16A71B449AE793CF52FBBED6607A4BA@ptah.newyork.qosient.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-RBL-Warning: (dnsbl.njabl.org) relay tested -- 1016746205
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

Carter:

I think we're in violent agreement ... there are a number of kinds of
"reliability". In the scenario you give, clearly 100% reliability would be
expensive and perhaps not desired. At lower data rates (e.g., with more
aggregation on the device), the highest level of reliability might be the
best choice. The important thing is that there be a choice.

I've tried to describe how a high-reliability protocol can also function in
lower reliability modes (I didn't describe the multicast design that you
favour; but it would be a variant of simple broadcast). There's nothing
preventing CRANE, for example, being "downgraded" to the broadcast style you
describe. The inverse - taking an unreliable protocol and trying to make it
reliable - is more, ahem, "challenging".

The situation is similar to when I buy disk: I make a choice of performance
and reliability by choosing amongst options such as RAID level and
journaling. As far as my programs are concerned, it's all just disk.
Similarly, with the IPFIX protocol, I would want the exporter and receiver
to always be the same, with the protocol being put into an appropriate
reliability mode. (It happens that most of *my* users want high reliability
and are prepared to pay for it; *your* users might be different. I think
that CRANE - put into appropriate reliability mode - can satisfy both kinds
of users.)

- peter

> -----Original Message-----
> From: Carter Bullard [mailto:carter@qosient.com]
> Sent: Thursday, November 14, 2002 10:36 PM
> To: 'Peter Ludemann'
> Cc: ipfix@net.doit.wisc.edu
> Subject: RE: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt
>
>
> Hey Peter,
>    This is of course the problem with discussions of reliability.
> Your goal of full reliability (is that 100% reliability ?) is
> difficult to achieve, and your described strategy for achieving
> it doesn't necessarily get you closer to your goal.  At 20-50K
> records per second, source initiated failover to a secondary
> receiver isn't going to get you full reliability.  The only
> way an IPFIX device can support operational reliability at
> the performance levels discussed (> 20-50K records per second)
> is for it to have enough storage to ride through at the least
> a 120 second outage, assuming TCP is the transport protocol
> of choice.  That would be about 250MB-1GB of high performance
> storage, depending on your flow model and deployment.  This
> generally means a disk.
>
> The idea of a transport protocol requiring a local disk on
> a router is not a strategy that will be successful in the IETF.
> Lets not go there, so to speak.
>
> A successful IPFIX strategy will result in a transport protocol
> that can support vendors building reliable architectures.  Minimally
> that means to me receiver loss detection and stream integrity
> checking. With those simple mechanisms, I can build as
> reliable an IPFIX architecture that can be built.  The cheapest
> one would use source multicasting.  With source multicasting,
> there is no need for transport fault detection at the source or
> any type of failover.
>
> The most expensive architecture would involve fully redundant
> probes, with multiple tap points and lots of local storage,
> fully redundant data streams feeding fully redundant collectors
> that populate fully redundant IPFIX record data stores.  The IPFIX
> devices would be designed to allow multiple concurrent connections
> initiated by the collectors, so that the redundant collection
> architecture can completely control the flow of IPFIX records.
> All that is additionally needed here is for the IPFIX data model
> to support duplicate record rejection.
>
> Carter
>
>
>
> > -----Original Message-----
> > From: Peter Ludemann [mailto:peter.ludemann@xacct.com]
> > Sent: Thursday, November 14, 2002 11:18 PM
> > To: Carter Bullard
> > Cc: ipfix@net.doit.wisc.edu
> > Subject: RE: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt
> >
> >
> > Carter:
> >
> > Your statement could be true for one definition of
> > reliability, but not for full reliability with fail-over. For
> > that, one needs *exporter" detection of message loss (this
> > could be caused by link failure or by collector failure -
> > that is, failure to acknowledge); the exporter can then
> > fail-over to another collector and retransmit unacknowledged records.
> >
> > Probably we need multiple "levels" of reliability (I tried to
> > define some in a note a few days ago); reliability isn't a
> > one-size-fits-all item and we should have a protocol which
> > can support the various kinds of reliability.
> >
> > - peter
> >
> > > -----Original Message-----
> > > From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On
> > > Behalf Of Carter Bullard
> > > Sent: Wednesday, November 13, 2002 8:50 AM
> > > To: calato@riverstonenet.com
> > > Cc: ipfix@net.doit.wisc.edu
> > > Subject: RE: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt
> > >
> > >
> > > Hey Paul,
> > >    I believe that your list of 4 items is missing
> > > the critical reliability support mechanism that IPFIX
> > > has in its list of requirements.   IMHO, the only
> > > reliability mechanism that IPFIX needs.
> > >
> > >    Receiver detection of IPFIX message loss.
> > >
> > >    If the protocol supports this basic property, vendors
> > > can then build reliable systems; as reliable as any
> > > customer can afford.  Supplementing this with data
> > > stream integrity mechanisms so that the receiver can
> > > realize the nature of any loss, would be a dream
> > > solution.
> > >
> > >    What does this mean for the protocol?  Sequence
> > > numbers and periodic stream integrity reports. Anything
> > > else can be vendor improvements.   IMHO.
> > >
> > > Carter
> > >
> > >
> > > > -----Original Message-----
> > > > From: majordomo listserver
> > [mailto:majordomo@mil.doit.wisc.edu] On
> > > > Behalf Of calato@riverstonenet.com
> > > > Sent: Wednesday, November 13, 2002 10:35 AM
> > > > Cc: ipfix@net.doit.wisc.edu
> > > > Subject: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt
> > > >
> > > >
> > > >
> > > > I'm left wondering what level of reliability is in scope?
> > > >
> > > > It seems we a few people that agree a highly reliable protocol is
> > > > out of scope and several agreeing it is in scope. Since
> > one person
> > > > from the former was wearing an AD hat I'm left still uncertain of
> > > > the outcome.
> > > >
> > > > Is high reliability in scope or out of scope. If out
> > > > of scope, to what level is in scope?
> > > >
> > > > 	1. Transport level reliability
> > > > 	2. Redundancy reliability (e.g. sending all data
> > > > 	   to multiple collectors or multicasting)
> > > > 	3. Failover (i.e. detecting a collector is
> > > > 	   down and switching to another)
> > > > 	4. Congestion awareness only (i.e. send and forget)
> > > >
> > > > What level of reliability is in scope?
> > > >
> > > > Paul
> > > >
> > > > --
> > > > 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 Nov 15 06:59:20 2002
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 GAA05951
	for ; Fri, 15 Nov 2002 06:59:20 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18Cf1M-0001NS-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 15 Nov 2002 05:52:24 -0600
Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18Cf1K-0001ME-00
	for ipfix@net.doit.wisc.edu; Fri, 15 Nov 2002 05:52:22 -0600
Received: from cisco.com (bclaise-isdn-home.cisco.com [10.49.4.218])
	by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id gAFBah726855;
	Fri, 15 Nov 2002 12:36:43 +0100 (CET)
Message-ID: <3DD4DC4B.6050103@cisco.com>
Date: Fri, 15 Nov 2002 12:36:43 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020815
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jeff Meyer 
CC: calato@riverstonenet.com, Tal Givoly ,
        carter@qosient.com, "'ipfixx'" 
Subject: Re: [ipfix] Multiple levels of Reliability and Directionality
References:  <3DCC4621.2000707@cup.hp.com> <3DCFD4AB.492B2C4B@riverstonenet.com> <3DCFEB3C.6010602@cup.hp.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

Jeff,

> It's the sliperry slope of other things one might
> want to exchange once this two way channel is open,
> which concerns me.  There are lots of things one
> might want to exchange, but many of these are probably
> better addressed by reusing existing protocols,
> vs. stuffing into the IPFIX protocol.
>
> For example, controlling metering process is something
> which can be separated out from IPFIX.  For example
> by using SNMP and a MeterMIB.
>
> Just trying to apply the KISS (Keep it simple stupid)
> principle. 

I could not agree more with your comments.

Regards, Benoit.

>
>
>
> Regards,
>
>   Jeff Meyer
>   hp
>
>
> calato@riverstonenet.com wrote:
>
>> Jeff Meyer wrote:
>>
>>> Hi,
>>>
>>>   I agree with the aspect of varied reliability.
>>>
>>>   I am less clear on the need for bi-directional
>>> behavior.  The three scenarios you describe I
>>> agree with, but I'm not sure how the 2nd and
>>> 3rd scenario as described have any dependence
>>> on bi-directional aside from the some level of
>>> application layer ack.
>>>
>>>
>>
>>     An application layer ACK all by itself makes the
>>     protocol bi-directional.
>>
>>     Scenario #1 does not require the sender to also be a receiver.
>>     Scenarios #2 & #3 do require the sender to also be a
>>     receiver (even if only for ACK's).
>>
>>     Whether or not we decide to add other features in
>>     scenarios #2 & #3 (such as field negotiation, capability
>>     negotiation, etc...) is up to the WG. But they could
>>     not be added to scenario #1.
>>
>>     Paul
>>     
>>
>>> Regards,
>>>
>>>   Jeff Meyer
>>>
>>> Tal Givoly wrote:
>>>
>>>
>>>> Paul,
>>>>
>>>> I agree completely - that captures the essense of the requirements. It
>>>> allows balancing different application's need for different levels of
>>>> reliability.
>>>>
>>>> Tal
>>>>
>>>> -----Original Message-----
>>>> From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On 
>>>> Behalf
>>>> Of Carter Bullard
>>>> Sent: Thursday, November 07, 2002 8:40 AM
>>>> To: calato@riverstonenet.com; 'ipfixx'
>>>> Subject: RE: [ipfix] Multiple levels of Reliability and Directionality
>>>>
>>>>
>>>> Hey Paul,
>>>>  My 2 cents worth sez, absolutely yes!
>>>> Carter
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: majordomo listserver
>>>>> [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of
>>>>> calato@riverstonenet.com
>>>>> Sent: Thursday, November 07, 2002 9:46 AM
>>>>> To: ipfixx
>>>>> Subject: [ipfix] Multiple levels of Reliability and Directionality
>>>>>
>>>>>
>>>>>
>>>>> Does IPFIX need to support multiple levels of reliability
>>>>> and directionality?
>>>>>
>>>>> The applications IPFIX needs to support are quite varied
>>>>> and have differing needs in terms of reliability. Devices
>>>>> also have varying needs in terms of directionality.
>>>>>
>>>>> I would like the WG to consider requirements on the protocol
>>>>> to support a tiered approach meet these needs.
>>>>>
>>>>> Direction is either bi-directional or uni-directional. I've split
>>>>> reliability into 3 categories...
>>>>>
>>>>>       High   - Little to no data loss
>>>>>       Medium - Minimal data loss is accepted
>>>>>       Low    - Data sent is best effort
>>>>>
>>>>>
>>>>> The six combinations are shown below...
>>>>>
>>>>>
>>>>>              | Uni  |  Bi
>>>>>       -------+------+---------
>>>>>       High   |  1   |    4
>>>>>       -------+------+--------
>>>>>       Medium |  2   |    5
>>>>>       -------+------+--------
>>>>>       Low    |  3   |    6
>>>>>
>>>>>
>>>>>
>>>>> I think (IMHO) the most likely combinations are...
>>>>>
>>>>>       3. Low reliability and uni-directional. This will be used
>>>>>          where the device and collector are in close proximity,
>>>>>          there is high volume and some data loss is acceptable for
>>>>>          the given application. Applications such as
>>>>> Attack/Intrusion Detection
>>>>>          Traffic Profiling, etc...
>>>>>
>>>>>       5. Bi-directional medium reliability. This will be used
>>>>>          where high volume and increased reliability are
>>>>> needed. Applications
>>>>>          such as Usage-based Accounting where 95th
>>>>> percentile billing
>>>>>          model is used. Or even Traffic Engineering where
>>>>> network policy
>>>>>          decisions are based on the data collected.
>>>>>
>>>>>       4. Bi-directional high reliability would be used where the
>>>>>          Usage-based Accounting application has strict requirements
>>>>>          on data loss.
>>>>>
>>>>> Does IPFIX need to support multiple levels of reliability
>>>>> and directionality?
>>>>>
>>>>> Paul
>>>>>
>>>>> -- 
>>>>> 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/





--
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 Nov 15 07:00:33 2002
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 HAA05985
	for ; Fri, 15 Nov 2002 07:00:32 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18Cf1x-0001ST-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 15 Nov 2002 05:53:01 -0600
Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18Cf1v-0001NX-00
	for ipfix@net.doit.wisc.edu; Fri, 15 Nov 2002 05:52:59 -0600
Received: from cisco.com (bclaise-isdn-home.cisco.com [10.49.4.218])
	by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id gAFBbJ727275;
	Fri, 15 Nov 2002 12:37:19 +0100 (CET)
Message-ID: <3DD4DC6F.2000100@cisco.com>
Date: Fri, 15 Nov 2002 12:37:19 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020815
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tal Givoly 
CC: Jeff Meyer , calato@riverstonenet.com,
        carter@qosient.com, "'ipfixx'" 
Subject: Re: [ipfix] Multiple levels of Reliability and Directionality
References: 
Content-Type: multipart/alternative;
 boundary="------------060802080200080208090405"
Precedence: bulk
Sender: majordomo listserver 


--------------060802080200080208090405
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Tal,

>Jeff,
>
>I agree with you completely here - the protocol should focus on a primarily
>uni-directional feed from network/service elements (metering+exporting
>process) to collection process. Adding capabilities (such as parameter
>configuration, provisioning of other sorts, etc.) here is a slippery slope.
>
>I would add, however, that the bi-directionality is needed both for
>assurance that messages are delivered as well as, 
>
The application level ACK are not always possible, too much memory 
involved in the router.
If the memory was not an issue, NetFlow would have been proposed on TCP 
as well.
And using the transport protocol ACK is an easier task than development 
a new ACK system at the application level.

>IMHO, version, capability
>and template negotiation (which can be simplified as needed by device).
>Version and capability negotiation allows for forward/backward
>interoperability and compatibility. Template negotiation allows for more
>efficient application-aware communication. As Peter explained earlier
>(http://ipfix.doit.wisc.edu/archive/1381.html - scenario #1 or #2), it is
>possible to have all these capabilities and have no impact on the
>metering/export processes complexity - the complexity can be, optionally,
>added to the collection process (off the device) in order to allow for
>interoperability with multiple concurrent versions/capabilities/templates in
>the devices.
>
>Essentially, I believe we achieved consensus regarding the need for template
>capabilities to allow separation of the data model from the protocol.
>
>Version/capability negotiation are very useful for any protocol in order to
>increase its applicability and useful lifespan.
>
Yes, but capability negotiations have been discussed several times and 
somehow agreed on by a hum during the meeting in Minneapolis.
http://ipfix.doit.wisc.edu/IETF53/minutes.txt

   "Regarding capability negotiation, consensus amongst attendees (by a
   hum) was that neither exporter configuration nor capabilities
   negotiation between collectors and exporters should be addressed by
   IPFIX.  The chairs will follow-up with a call on the mailing list on
   this topic."

Note that, if you want my opinion again on this, you can read Juergen's email at:
http://ipfx.doit.wisc.edu/list/ipfix/archive/0461.html

Regards, Benoit.

>
>Tal
>
>-----Original Message-----
>From: Jeff Meyer [mailto:jeffm@cup.hp.com]
>Sent: Monday, November 11, 2002 9:39 AM
>To: calato@riverstonenet.com
>Cc: Tal Givoly; carter@qosient.com; 'ipfixx'
>Subject: Re: [ipfix] Multiple levels of Reliability and Directionality
>
>
>OK, then based on this minimal definition of
>bi-directional, I'm in complete agreement.
>
>It's the sliperry slope of other things one might
>want to exchange once this two way channel is open,
>which concerns me.  There are lots of things one
>might want to exchange, but many of these are probably
>better addressed by reusing existing protocols,
>vs. stuffing into the IPFIX protocol.
>
>For example, controlling metering process is something
>which can be separated out from IPFIX.  For example
>by using SNMP and a MeterMIB.
>
>Just trying to apply the KISS (Keep it simple stupid)
>principle.
>
>
>Regards,
>
>   Jeff Meyer
>   hp
>
>
>calato@riverstonenet.com wrote:
>
>  
>
>>Jeff Meyer wrote:
>>
>>    
>>
>>>Hi,
>>>
>>>  I agree with the aspect of varied reliability.
>>>
>>>  I am less clear on the need for bi-directional
>>>behavior.  The three scenarios you describe I
>>>agree with, but I'm not sure how the 2nd and
>>>3rd scenario as described have any dependence
>>>on bi-directional aside from the some level of
>>>application layer ack.
>>>
>>>
>>>      
>>>
>>	An application layer ACK all by itself makes the
>>	protocol bi-directional.
>>
>>	Scenario #1 does not require the sender to also be a receiver.
>>
>>	Scenarios #2 & #3 do require the sender to also be a
>>	receiver (even if only for ACK's).
>>
>>	Whether or not we decide to add other features in
>>	scenarios #2 & #3 (such as field negotiation, capability
>>	negotiation, etc...) is up to the WG. But they could
>>	not be added to scenario #1.
>>
>>	Paul
>>
>>
>>
>>    
>>
>>>Regards,
>>>
>>>  Jeff Meyer
>>>
>>>Tal Givoly wrote:
>>>
>>>
>>>      
>>>
>>>>Paul,
>>>>
>>>>I agree completely - that captures the essense of the requirements. It
>>>>allows balancing different application's need for different levels of
>>>>reliability.
>>>>
>>>>Tal
>>>>
>>>>-----Original Message-----
>>>>From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf
>>>>Of Carter Bullard
>>>>Sent: Thursday, November 07, 2002 8:40 AM
>>>>To: calato@riverstonenet.com; 'ipfixx'
>>>>Subject: RE: [ipfix] Multiple levels of Reliability and Directionality
>>>>
>>>>
>>>>Hey Paul,
>>>> My 2 cents worth sez, absolutely yes!
>>>>Carter
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>>>-----Original Message-----
>>>>>From: majordomo listserver
>>>>>[mailto:majordomo@mil.doit.wisc.edu] On Behalf Of
>>>>>calato@riverstonenet.com
>>>>>Sent: Thursday, November 07, 2002 9:46 AM
>>>>>To: ipfixx
>>>>>Subject: [ipfix] Multiple levels of Reliability and Directionality
>>>>>
>>>>>
>>>>>
>>>>>Does IPFIX need to support multiple levels of reliability
>>>>>and directionality?
>>>>>
>>>>>The applications IPFIX needs to support are quite varied
>>>>>and have differing needs in terms of reliability. Devices
>>>>>also have varying needs in terms of directionality.
>>>>>
>>>>>I would like the WG to consider requirements on the protocol
>>>>>to support a tiered approach meet these needs.
>>>>>
>>>>>Direction is either bi-directional or uni-directional. I've split
>>>>>reliability into 3 categories...
>>>>>
>>>>>      High   - Little to no data loss
>>>>>      Medium - Minimal data loss is accepted
>>>>>      Low    - Data sent is best effort
>>>>>
>>>>>
>>>>>The six combinations are shown below...
>>>>>
>>>>>
>>>>>             | Uni  |  Bi
>>>>>      -------+------+---------
>>>>>      High   |  1   |    4
>>>>>      -------+------+--------
>>>>>      Medium |  2   |    5
>>>>>      -------+------+--------
>>>>>      Low    |  3   |    6
>>>>>
>>>>>
>>>>>
>>>>>I think (IMHO) the most likely combinations are...
>>>>>
>>>>>      3. Low reliability and uni-directional. This will be used
>>>>>         where the device and collector are in close proximity,
>>>>>         there is high volume and some data loss is acceptable for
>>>>>         the given application. Applications such as
>>>>>Attack/Intrusion Detection
>>>>>         Traffic Profiling, etc...
>>>>>
>>>>>      5. Bi-directional medium reliability. This will be used
>>>>>         where high volume and increased reliability are
>>>>>needed. Applications
>>>>>         such as Usage-based Accounting where 95th
>>>>>percentile billing
>>>>>         model is used. Or even Traffic Engineering where
>>>>>network policy
>>>>>         decisions are based on the data collected.
>>>>>
>>>>>      4. Bi-directional high reliability would be used where the
>>>>>         Usage-based Accounting application has strict requirements
>>>>>         on data loss.
>>>>>
>>>>>Does IPFIX need to support multiple levels of reliability
>>>>>and directionality?
>>>>>
>>>>>Paul
>>>>>
>>>>>--
>>>>>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/
>  
>



--------------060802080200080208090405
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit




  


Tal, 



  
Jeff,

I agree with you completely here - the protocol should focus on a primarily
uni-directional feed from network/service elements (metering+exporting
process) to collection process. Adding capabilities (such as parameter
configuration, provisioning of other sorts, etc.) here is a slippery slope.

I would add, however, that the bi-directionality is needed both for
assurance that messages are delivered as well as, 



The application level ACK are not always possible, too much memory involved
in the router.

If the memory was not an issue, NetFlow would have been proposed on TCP as
well.

And using the transport protocol ACK is an easier task than development a
new ACK system at the application level.



  
IMHO, version, capability
and template negotiation (which can be simplified as needed by device).
Version and capability negotiation allows for forward/backward
interoperability and compatibility. Template negotiation allows for more
efficient application-aware communication. As Peter explained earlier
(http://ipfix.doit.wisc.edu/archive/1381.html - scenario #1 or #2), it is
possible to have all these capabilities and have no impact on the
metering/export processes complexity - the complexity can be, optionally,
added to the collection process (off the device) in order to allow for
interoperability with multiple concurrent versions/capabilities/templates in
the devices.

Essentially, I believe we achieved consensus regarding the need for template
capabilities to allow separation of the data model from the protocol.





  
Version/capability negotiation are very useful for any protocol in order to
increase its applicability and useful lifespan.



Yes, but capability negotiations have been discussed several times and somehow
agreed on by a hum during the meeting in Minneapolis.

http://ipfix.doit.wisc.edu/IETF53/minutes.txt


   "Regarding capability negotiation, consensus amongst attendees (by a
   hum) was that neither exporter configuration nor capabilities
   negotiation between collectors and exporters should be addressed by
   IPFIX.  The chairs will follow-up with a call on the mailing list on
   this topic."

Note that, if you want my opinion again on this, you can read Juergen's email at:
http://ipfx.doit.wisc.edu/list/ipfix/archive/0461.html


Regards, Benoit.





  

Tal

-----Original Message-----
From: Jeff Meyer [mailto:jeffm@cup.hp.com]
Sent: Monday, November 11, 2002 9:39 AM
To: calato@riverstonenet.com
Cc: Tal Givoly; carter@qosient.com; 'ipfixx'
Subject: Re: [ipfix] Multiple levels of Reliability and Directionality


OK, then based on this minimal definition of
bi-directional, I'm in complete agreement.

It's the sliperry slope of other things one might
want to exchange once this two way channel is open,
which concerns me.  There are lots of things one
might want to exchange, but many of these are probably
better addressed by reusing existing protocols,
vs. stuffing into the IPFIX protocol.

For example, controlling metering process is something
which can be separated out from IPFIX.  For example
by using SNMP and a MeterMIB.

Just trying to apply the KISS (Keep it simple stupid)
principle.


Regards,

   Jeff Meyer
   hp


calato@riverstonenet.com wrote:

  

  

    
Jeff Meyer wrote:

    

    

      
Hi,

  I agree with the aspect of varied reliability.

  I am less clear on the need for bi-directional
behavior.  The three scenarios you describe I
agree with, but I'm not sure how the 2nd and
3rd scenario as described have any dependence
on bi-directional aside from the some level of
application layer ack.


      

    

    
	An application layer ACK all by itself makes the
	protocol bi-directional.

	Scenario #1 does not require the sender to also be a receiver.

	Scenarios #2 & #3 do require the sender to also be a
	receiver (even if only for ACK's).

	Whether or not we decide to add other features in
	scenarios #2 & #3 (such as field negotiation, capability
	negotiation, etc...) is up to the WG. But they could
	not be added to scenario #1.

	Paul



    

    

      
Regards,

  Jeff Meyer

Tal Givoly wrote:


      

      

        
Paul,

I agree completely - that captures the essense of the requirements. It
allows balancing different application's need for different levels of
reliability.

Tal

-----Original Message-----
From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf
Of Carter Bullard
Sent: Thursday, November 07, 2002 8:40 AM
To: calato@riverstonenet.com; 'ipfixx'
Subject: RE: [ipfix] Multiple levels of Reliability and Directionality


Hey Paul,
 My 2 cents worth sez, absolutely yes!
Carter



        

        

          
-----Original Message-----
From: majordomo listserver
[mailto:majordomo@mil.doit.wisc.edu] On Behalf Of
calato@riverstonenet.com
Sent: Thursday, November 07, 2002 9:46 AM
To: ipfixx
Subject: [ipfix] Multiple levels of Reliability and Directionality



Does IPFIX need to support multiple levels of reliability
and directionality?

The applications IPFIX needs to support are quite varied
and have differing needs in terms of reliability. Devices
also have varying needs in terms of directionality.

I would like the WG to consider requirements on the protocol
to support a tiered approach meet these needs.

Direction is either bi-directional or uni-directional. I've split
reliability into 3 categories...

      High   - Little to no data loss
      Medium - Minimal data loss is accepted
      Low    - Data sent is best effort


The six combinations are shown below...


             | Uni  |  Bi
      -------+------+---------
      High   |  1   |    4
      -------+------+--------
      Medium |  2   |    5
      -------+------+--------
      Low    |  3   |    6



I think (IMHO) the most likely combinations are...

      3. Low reliability and uni-directional. This will be used
         where the device and collector are in close proximity,
         there is high volume and some data loss is acceptable for
         the given application. Applications such as
Attack/Intrusion Detection
         Traffic Profiling, etc...

      5. Bi-directional medium reliability. This will be used
         where high volume and increased reliability are
needed. Applications
         such as Usage-based Accounting where 95th
percentile billing
         model is used. Or even Traffic Engineering where
network policy
         decisions are based on the data collected.

      4. Bi-directional high reliability would be used where the
         Usage-based Accounting application has strict requirements
         on data loss.

Does IPFIX need to support multiple levels of reliability
and directionality?

Paul

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










--------------060802080200080208090405--


--
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 Nov 15 07:06:20 2002
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 HAA06071
	for ; Fri, 15 Nov 2002 07:06:19 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18Ceyo-0001J2-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 15 Nov 2002 05:49:46 -0600
Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18Ceyl-0001IL-00
	for ipfix@net.doit.wisc.edu; Fri, 15 Nov 2002 05:49:43 -0600
Received: from cisco.com (bclaise-isdn-home.cisco.com [10.49.4.218])
	by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id gAFBXh724920;
	Fri, 15 Nov 2002 12:33:44 +0100 (CET)
Message-ID: <3DD4DB97.4080204@cisco.com>
Date: Fri, 15 Nov 2002 12:33:43 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020815
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: calato@riverstonenet.com
CC: Tal Givoly , Jeff Meyer ,
        carter@qosient.com, "'ipfixx'" 
Subject: Re: [ipfix] Multiple levels of Reliability and Directionality
References:  <3DD00105.C1F767EA@riverstonenet.com>
Content-Type: multipart/alternative;
 boundary="------------000808020801020607070409"
Precedence: bulk
Sender: majordomo listserver 


--------------000808020801020607070409
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Paul,

First of all, let me take back your initial email, for clarity purposes

        High   - Little to no data loss
        Medium - Minimal data loss is accepted
        Low    - Data sent is best effort


The six combinations are shown below...


               | Uni  |  Bi
        -------+------+---------
        High   |  1   |    4
        -------+------+--------
        Medium |  2   |    5
        -------+------+--------
        Low    |  3   |    6



I think (IMHO) the most likely combinations are...

        3. Low reliability and uni-directional. This will be used
           where the device and collector are in close proximity,
           there is high volume and some data loss is acceptable for
           the given application. Applications such as Attack/Intrusion
           Detection Traffic Profiling, etc...

        5. Bi-directional medium reliability. This will be used
           where high volume and increased reliability are needed.
           Applications
           such as Usage-based Accounting where 95th percentile billing
           model is used. Or even Traffic Engineering where network
           policy decisions are based on the data collected.

        4. Bi-directional high reliability would be used where the
           Usage-based Accounting application has strict requirements
           on data loss.

I agree on 3, this is the minimum.

I agree on 5 but I fear that the application level ACK will not always be a possible solution from a router point of view. What if the router exports so much flow records that it can't cache them while waiting for the ACK.
So basically, resending the flow records is not always possible.
So, if you conclude that the requirement for 5 is the bidirectionality with application level ACK, then this requirement is not always possible! 
IMHO, 5 could alos be 
	2 with best-effort
	or 2 with a carefully designed network

Regarding 4, Randy replied already

     > Somehow, the requirements discussion suffers from a split:
>  There are requirements resulting from the intention of
>  standardzing a highly reliable metering standard for precise
>  accounting (and billing). Differing from these are requirements
>  for a simpler metering standard more oriented at what I would
>  call "typical Internet reliability".

     the original goal, which the iesg thinks was chartered, is the
    latter.  

>Let me see if we all agree on a couple things...
>
>	1. There is no such thing as partially uni-directional.
>	2. IPFIX ought to support a uni-directional mode of operation.
>
Agreed.

Regards, Benoit.

>
>Paul
>
>Tal Givoly wrote:
>  
>
>>Jeff,
>>
>>I agree with you completely here - the protocol should focus on a primarily
>>uni-directional feed from network/service elements (metering+exporting
>>process) to collection process. Adding capabilities (such as parameter
>>configuration, provisioning of other sorts, etc.) here is a slippery slope.
>>
>>I would add, however, that the bi-directionality is needed both for
>>assurance that messages are delivered as well as, IMHO, version, capability
>>and template negotiation (which can be simplified as needed by device).
>>Version and capability negotiation allows for forward/backward
>>interoperability and compatibility. Template negotiation allows for more
>>efficient application-aware communication. As Peter explained earlier
>>(http://ipfix.doit.wisc.edu/archive/1381.html - scenario #1 or #2), it is
>>possible to have all these capabilities and have no impact on the
>>metering/export processes complexity - the complexity can be, optionally,
>>added to the collection process (off the device) in order to allow for
>>interoperability with multiple concurrent versions/capabilities/templates in
>>the devices.
>>
>>Essentially, I believe we achieved consensus regarding the need for template
>>capabilities to allow separation of the data model from the protocol.
>>Version/capability negotiation are very useful for any protocol in order to
>>increase its applicability and useful lifespan.
>>
>>Tal
>>
>>-----Original Message-----
>>From: Jeff Meyer [mailto:jeffm@cup.hp.com]
>>Sent: Monday, November 11, 2002 9:39 AM
>>To: calato@riverstonenet.com
>>Cc: Tal Givoly; carter@qosient.com; 'ipfixx'
>>Subject: Re: [ipfix] Multiple levels of Reliability and Directionality
>>
>>OK, then based on this minimal definition of
>>bi-directional, I'm in complete agreement.
>>
>>It's the sliperry slope of other things one might
>>want to exchange once this two way channel is open,
>>which concerns me.  There are lots of things one
>>might want to exchange, but many of these are probably
>>better addressed by reusing existing protocols,
>>vs. stuffing into the IPFIX protocol.
>>
>>For example, controlling metering process is something
>>which can be separated out from IPFIX.  For example
>>by using SNMP and a MeterMIB.
>>
>>Just trying to apply the KISS (Keep it simple stupid)
>>principle.
>>
>>Regards,
>>
>>   Jeff Meyer
>>   hp
>>
>>calato@riverstonenet.com wrote:
>>
>>    
>>
>>>Jeff Meyer wrote:
>>>
>>>      
>>>
>>>>Hi,
>>>>
>>>>  I agree with the aspect of varied reliability.
>>>>
>>>>  I am less clear on the need for bi-directional
>>>>behavior.  The three scenarios you describe I
>>>>agree with, but I'm not sure how the 2nd and
>>>>3rd scenario as described have any dependence
>>>>on bi-directional aside from the some level of
>>>>application layer ack.
>>>>
>>>>
>>>>        
>>>>
>>>      An application layer ACK all by itself makes the
>>>      protocol bi-directional.
>>>
>>>      Scenario #1 does not require the sender to also be a receiver.
>>>
>>>      Scenarios #2 & #3 do require the sender to also be a
>>>      receiver (even if only for ACK's).
>>>
>>>      Whether or not we decide to add other features in
>>>      scenarios #2 & #3 (such as field negotiation, capability
>>>      negotiation, etc...) is up to the WG. But they could
>>>      not be added to scenario #1.
>>>
>>>      Paul
>>>
>>>
>>>
>>>      
>>>
>>>>Regards,
>>>>
>>>>  Jeff Meyer
>>>>
>>>>Tal Givoly wrote:
>>>>
>>>>
>>>>        
>>>>
>>>>>Paul,
>>>>>
>>>>>I agree completely - that captures the essense of the requirements. It
>>>>>allows balancing different application's need for different levels of
>>>>>reliability.
>>>>>
>>>>>Tal
>>>>>
>>>>>-----Original Message-----
>>>>>From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf
>>>>>Of Carter Bullard
>>>>>Sent: Thursday, November 07, 2002 8:40 AM
>>>>>To: calato@riverstonenet.com; 'ipfixx'
>>>>>Subject: RE: [ipfix] Multiple levels of Reliability and Directionality
>>>>>
>>>>>
>>>>>Hey Paul,
>>>>> My 2 cents worth sez, absolutely yes!
>>>>>Carter
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>-----Original Message-----
>>>>>>From: majordomo listserver
>>>>>>[mailto:majordomo@mil.doit.wisc.edu] On Behalf Of
>>>>>>calato@riverstonenet.com
>>>>>>Sent: Thursday, November 07, 2002 9:46 AM
>>>>>>To: ipfixx
>>>>>>Subject: [ipfix] Multiple levels of Reliability and Directionality
>>>>>>
>>>>>>
>>>>>>
>>>>>>Does IPFIX need to support multiple levels of reliability
>>>>>>and directionality?
>>>>>>
>>>>>>The applications IPFIX needs to support are quite varied
>>>>>>and have differing needs in terms of reliability. Devices
>>>>>>also have varying needs in terms of directionality.
>>>>>>
>>>>>>I would like the WG to consider requirements on the protocol
>>>>>>to support a tiered approach meet these needs.
>>>>>>
>>>>>>Direction is either bi-directional or uni-directional. I've split
>>>>>>reliability into 3 categories...
>>>>>>
>>>>>>      High   - Little to no data loss
>>>>>>      Medium - Minimal data loss is accepted
>>>>>>      Low    - Data sent is best effort
>>>>>>
>>>>>>
>>>>>>The six combinations are shown below...
>>>>>>
>>>>>>
>>>>>>             | Uni  |  Bi
>>>>>>      -------+------+---------
>>>>>>      High   |  1   |    4
>>>>>>      -------+------+--------
>>>>>>      Medium |  2   |    5
>>>>>>      -------+------+--------
>>>>>>      Low    |  3   |    6
>>>>>>
>>>>>>
>>>>>>
>>>>>>I think (IMHO) the most likely combinations are...
>>>>>>
>>>>>>      3. Low reliability and uni-directional. This will be used
>>>>>>         where the device and collector are in close proximity,
>>>>>>         there is high volume and some data loss is acceptable for
>>>>>>         the given application. Applications such as
>>>>>>Attack/Intrusion Detection
>>>>>>         Traffic Profiling, etc...
>>>>>>
>>>>>>      5. Bi-directional medium reliability. This will be used
>>>>>>         where high volume and increased reliability are
>>>>>>needed. Applications
>>>>>>         such as Usage-based Accounting where 95th
>>>>>>percentile billing
>>>>>>         model is used. Or even Traffic Engineering where
>>>>>>network policy
>>>>>>         decisions are based on the data collected.
>>>>>>
>>>>>>      4. Bi-directional high reliability would be used where the
>>>>>>         Usage-based Accounting application has strict requirements
>>>>>>         on data loss.
>>>>>>
>>>>>>Does IPFIX need to support multiple levels of reliability
>>>>>>and directionality?
>>>>>>
>>>>>>Paul
>>>>>>
>>>>>>--
>>>>>>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/
>  
>



--------------000808020801020607070409
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit




  


Paul,



First of all, let me take back your initial email, for clarity purposes

 

        High   - Little to no data loss
        Medium - Minimal data loss is accepted
        Low    - Data sent is best effort


The six combinations are shown below...


               | Uni  |  Bi
        -------+------+---------
        High   |  1   |    4
        -------+------+--------
        Medium |  2   |    5
        -------+------+--------
        Low    |  3   |    6



I think (IMHO) the most likely combinations are...

        3. Low reliability and uni-directional. This will be used
           where the device and collector are in close proximity,
           there is high volume and some data loss is acceptable for
           the given application. Applications such as Attack/Intrusion
           Detection Traffic Profiling, etc...

        5. Bi-directional medium reliability. This will be used
           where high volume and increased reliability are needed.
           Applications
           such as Usage-based Accounting where 95th percentile billing
           model is used. Or even Traffic Engineering where network
           policy decisions are based on the data collected.

        4. Bi-directional high reliability would be used where the
           Usage-based Accounting application has strict requirements
           on data loss.

I agree on 3, this is the minimum.

I agree on 5 but I fear that the application level ACK will not always be a possible solution from a router point of view. What if the router exports so much flow records that it can't cache them while waiting for the ACK.
So basically, resending the flow records is not always possible.
So, if you conclude that the requirement for 5 is the bidirectionality with application level ACK, then this requirement is not always possible! 
IMHO, 5 could alos be 
	2 with best-effort
	or 2 with a carefully designed network

Regarding 4, Randy replied already


 

> Somehow, the requirements discussion suffers from a split:

   > There are requirements resulting
from the intention of

   > standardzing a highly reliable
metering standard for precise

   > accounting (and billing). Differing
from these are requirements

   > for a simpler metering standard
more oriented at what I would

   > call "typical Internet reliability".

   

 <ad> the original goal, which the iesg thinks was chartered, is the

 latter.   

 



  
Let me see if we all agree on a couple things...

	1. There is no such thing as partially uni-directional.
	2. IPFIX ought to support a uni-directional mode of operation.



Agreed.



Regards, Benoit.





  

Paul

Tal Givoly wrote:
  

  

    
Jeff,

I agree with you completely here - the protocol should focus on a primarily
uni-directional feed from network/service elements (metering+exporting
process) to collection process. Adding capabilities (such as parameter
configuration, provisioning of other sorts, etc.) here is a slippery slope.

I would add, however, that the bi-directionality is needed both for
assurance that messages are delivered as well as, IMHO, version, capability
and template negotiation (which can be simplified as needed by device).
Version and capability negotiation allows for forward/backward
interoperability and compatibility. Template negotiation allows for more
efficient application-aware communication. As Peter explained earlier
(http://ipfix.doit.wisc.edu/archive/1381.html - scenario #1 or #2), it is
possible to have all these capabilities and have no impact on the
metering/export processes complexity - the complexity can be, optionally,
added to the collection process (off the device) in order to allow for
interoperability with multiple concurrent versions/capabilities/templates in
the devices.

Essentially, I believe we achieved consensus regarding the need for template
capabilities to allow separation of the data model from the protocol.
Version/capability negotiation are very useful for any protocol in order to
increase its applicability and useful lifespan.

Tal

-----Original Message-----
From: Jeff Meyer [mailto:jeffm@cup.hp.com]
Sent: Monday, November 11, 2002 9:39 AM
To: calato@riverstonenet.com
Cc: Tal Givoly; carter@qosient.com; 'ipfixx'
Subject: Re: [ipfix] Multiple levels of Reliability and Directionality

OK, then based on this minimal definition of
bi-directional, I'm in complete agreement.

It's the sliperry slope of other things one might
want to exchange once this two way channel is open,
which concerns me.  There are lots of things one
might want to exchange, but many of these are probably
better addressed by reusing existing protocols,
vs. stuffing into the IPFIX protocol.

For example, controlling metering process is something
which can be separated out from IPFIX.  For example
by using SNMP and a MeterMIB.

Just trying to apply the KISS (Keep it simple stupid)
principle.

Regards,

   Jeff Meyer
   hp

calato@riverstonenet.com wrote:

    

    

      
Jeff Meyer wrote:

      

      

        
Hi,

  I agree with the aspect of varied reliability.

  I am less clear on the need for bi-directional
behavior.  The three scenarios you describe I
agree with, but I'm not sure how the 2nd and
3rd scenario as described have any dependence
on bi-directional aside from the some level of
application layer ack.


        

      

      
      An application layer ACK all by itself makes the
      protocol bi-directional.

      Scenario #1 does not require the sender to also be a receiver.

      Scenarios #2 & #3 do require the sender to also be a
      receiver (even if only for ACK's).

      Whether or not we decide to add other features in
      scenarios #2 & #3 (such as field negotiation, capability
      negotiation, etc...) is up to the WG. But they could
      not be added to scenario #1.

      Paul



      

      

        
Regards,

  Jeff Meyer

Tal Givoly wrote:


        

        

          
Paul,

I agree completely - that captures the essense of the requirements. It
allows balancing different application's need for different levels of
reliability.

Tal

-----Original Message-----
From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf
Of Carter Bullard
Sent: Thursday, November 07, 2002 8:40 AM
To: calato@riverstonenet.com; 'ipfixx'
Subject: RE: [ipfix] Multiple levels of Reliability and Directionality


Hey Paul,
 My 2 cents worth sez, absolutely yes!
Carter



          

          

            
-----Original Message-----
From: majordomo listserver
[mailto:majordomo@mil.doit.wisc.edu] On Behalf Of
calato@riverstonenet.com
Sent: Thursday, November 07, 2002 9:46 AM
To: ipfixx
Subject: [ipfix] Multiple levels of Reliability and Directionality



Does IPFIX need to support multiple levels of reliability
and directionality?

The applications IPFIX needs to support are quite varied
and have differing needs in terms of reliability. Devices
also have varying needs in terms of directionality.

I would like the WG to consider requirements on the protocol
to support a tiered approach meet these needs.

Direction is either bi-directional or uni-directional. I've split
reliability into 3 categories...

      High   - Little to no data loss
      Medium - Minimal data loss is accepted
      Low    - Data sent is best effort


The six combinations are shown below...


             | Uni  |  Bi
      -------+------+---------
      High   |  1   |    4
      -------+------+--------
      Medium |  2   |    5
      -------+------+--------
      Low    |  3   |    6



I think (IMHO) the most likely combinations are...

      3. Low reliability and uni-directional. This will be used
         where the device and collector are in close proximity,
         there is high volume and some data loss is acceptable for
         the given application. Applications such as
Attack/Intrusion Detection
         Traffic Profiling, etc...

      5. Bi-directional medium reliability. This will be used
         where high volume and increased reliability are
needed. Applications
         such as Usage-based Accounting where 95th
percentile billing
         model is used. Or even Traffic Engineering where
network policy
         decisions are based on the data collected.

      4. Bi-directional high reliability would be used where the
         Usage-based Accounting application has strict requirements
         on data loss.

Does IPFIX need to support multiple levels of reliability
and directionality?

Paul

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










--------------000808020801020607070409--


--
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 Nov 15 07:16:40 2002
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 HAA06236
	for ; Fri, 15 Nov 2002 07:16:39 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18CfIY-00027m-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 15 Nov 2002 06:10:10 -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 18CfIW-00026S-00
	for ipfix-req@net.doit.wisc.edu; Fri, 15 Nov 2002 06:10:08 -0600
Received: from riverstonenet.com ([134.141.180.74]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Fri, 15 Nov 2002 04:09:36 -0800
Message-ID: <3DD4E380.B8642B7C@riverstonenet.com>
Date: Fri, 15 Nov 2002 07:07:28 -0500
From: calato@riverstonenet.com
X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Juergen Quittek 
CC: Tal Givoly , ipfix-req@net.doit.wisc.edu
Subject: Re: MUST or SHOULD be able to export ICMP codes? was:RE: [ipfix-req] 
 list of issues
References:  <44974980.1037326335@[192.168.102.31]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 15 Nov 2002 12:09:37.0180 (UTC) FILETIME=[DDFC8DC0:01C28C9F]
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

Juergen Quittek wrote:
> 
> Tal,
> 
> -- Tal Givoly wrote on 14 November 2002 13:31 -0800:
> 
> > Reinaldo-4: Add MUST requirement for exporting ICMP codes in Section 6.1
> >
> >     There were not many responses on this suggestion. Personally, I do
> >     not consider it a MUST, but a nice-to-have.
> >
> > Tal> I believe this should be classified as a SHOULD.
> 
> I agree. In the current draft it is listed in section 6.1 as a MUST
> attribute. We should move it to SHOULD. But I changed my opinion
> on this issue already two times. Are there other people having a more
> firm opinion?
> 
	SHOULD. Many platforms do not distinguish on this field and
	it does not make sense to report it if not part of the key.

>     Juergen
> 
> --
> 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 Nov 15 07:25:58 2002
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 HAA06440
	for ; Fri, 15 Nov 2002 07:25:57 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18CfSD-0002OE-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 15 Nov 2002 06:20:09 -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 18CfSA-0002Mn-00
	for ipfix@net.doit.wisc.edu; Fri, 15 Nov 2002 06:20:06 -0600
Received: from riverstonenet.com ([134.141.180.74]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Fri, 15 Nov 2002 04:19:33 -0800
Message-ID: <3DD4E5D5.DDF48D7@riverstonenet.com>
Date: Fri, 15 Nov 2002 07:17:25 -0500
From: calato@riverstonenet.com
X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Ludemann 
CC: carter@qosient.com, ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 15 Nov 2002 12:19:33.0953 (UTC) FILETIME=[41B0E310:01C28CA1]
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

Peter Ludemann wrote:
> 
> Carter:
> 
> I think we're in violent agreement ... there are a number of kinds of
> "reliability". In the scenario you give, clearly 100% reliability would be
> expensive and perhaps not desired. At lower data rates (e.g., with more
> aggregation on the device), the highest level of reliability might be the
> best choice. The important thing is that there be a choice.

	In fact, when aggregation is in place, reliability is even
	more important since the data represents much larger chunks
	of data.

	Paul

> 
> I've tried to describe how a high-reliability protocol can also function in
> lower reliability modes (I didn't describe the multicast design that you
> favour; but it would be a variant of simple broadcast). There's nothing
> preventing CRANE, for example, being "downgraded" to the broadcast style you
> describe. The inverse - taking an unreliable protocol and trying to make it
> reliable - is more, ahem, "challenging".
> 
> The situation is similar to when I buy disk: I make a choice of performance
> and reliability by choosing amongst options such as RAID level and
> journaling. As far as my programs are concerned, it's all just disk.
> Similarly, with the IPFIX protocol, I would want the exporter and receiver
> to always be the same, with the protocol being put into an appropriate
> reliability mode. (It happens that most of *my* users want high reliability
> and are prepared to pay for it; *your* users might be different. I think
> that CRANE - put into appropriate reliability mode - can satisfy both kinds
> of users.)
> 
> - peter
> 
> > -----Original Message-----
> > From: Carter Bullard [mailto:carter@qosient.com]
> > Sent: Thursday, November 14, 2002 10:36 PM
> > To: 'Peter Ludemann'
> > Cc: ipfix@net.doit.wisc.edu
> > Subject: RE: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt
> >
> >
> > Hey Peter,
> >    This is of course the problem with discussions of reliability.
> > Your goal of full reliability (is that 100% reliability ?) is
> > difficult to achieve, and your described strategy for achieving
> > it doesn't necessarily get you closer to your goal.  At 20-50K
> > records per second, source initiated failover to a secondary
> > receiver isn't going to get you full reliability.  The only
> > way an IPFIX device can support operational reliability at
> > the performance levels discussed (> 20-50K records per second)
> > is for it to have enough storage to ride through at the least
> > a 120 second outage, assuming TCP is the transport protocol
> > of choice.  That would be about 250MB-1GB of high performance
> > storage, depending on your flow model and deployment.  This
> > generally means a disk.
> >
> > The idea of a transport protocol requiring a local disk on
> > a router is not a strategy that will be successful in the IETF.
> > Lets not go there, so to speak.
> >
> > A successful IPFIX strategy will result in a transport protocol
> > that can support vendors building reliable architectures.  Minimally
> > that means to me receiver loss detection and stream integrity
> > checking. With those simple mechanisms, I can build as
> > reliable an IPFIX architecture that can be built.  The cheapest
> > one would use source multicasting.  With source multicasting,
> > there is no need for transport fault detection at the source or
> > any type of failover.
> >
> > The most expensive architecture would involve fully redundant
> > probes, with multiple tap points and lots of local storage,
> > fully redundant data streams feeding fully redundant collectors
> > that populate fully redundant IPFIX record data stores.  The IPFIX
> > devices would be designed to allow multiple concurrent connections
> > initiated by the collectors, so that the redundant collection
> > architecture can completely control the flow of IPFIX records.
> > All that is additionally needed here is for the IPFIX data model
> > to support duplicate record rejection.
> >
> > Carter
> >
> >
> >
> > > -----Original Message-----
> > > From: Peter Ludemann [mailto:peter.ludemann@xacct.com]
> > > Sent: Thursday, November 14, 2002 11:18 PM
> > > To: Carter Bullard
> > > Cc: ipfix@net.doit.wisc.edu
> > > Subject: RE: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt
> > >
> > >
> > > Carter:
> > >
> > > Your statement could be true for one definition of
> > > reliability, but not for full reliability with fail-over. For
> > > that, one needs *exporter" detection of message loss (this
> > > could be caused by link failure or by collector failure -
> > > that is, failure to acknowledge); the exporter can then
> > > fail-over to another collector and retransmit unacknowledged records.
> > >
> > > Probably we need multiple "levels" of reliability (I tried to
> > > define some in a note a few days ago); reliability isn't a
> > > one-size-fits-all item and we should have a protocol which
> > > can support the various kinds of reliability.
> > >
> > > - peter
> > >
> > > > -----Original Message-----
> > > > From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On
> > > > Behalf Of Carter Bullard
> > > > Sent: Wednesday, November 13, 2002 8:50 AM
> > > > To: calato@riverstonenet.com
> > > > Cc: ipfix@net.doit.wisc.edu
> > > > Subject: RE: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt
> > > >
> > > >
> > > > Hey Paul,
> > > >    I believe that your list of 4 items is missing
> > > > the critical reliability support mechanism that IPFIX
> > > > has in its list of requirements.   IMHO, the only
> > > > reliability mechanism that IPFIX needs.
> > > >
> > > >    Receiver detection of IPFIX message loss.
> > > >
> > > >    If the protocol supports this basic property, vendors
> > > > can then build reliable systems; as reliable as any
> > > > customer can afford.  Supplementing this with data
> > > > stream integrity mechanisms so that the receiver can
> > > > realize the nature of any loss, would be a dream
> > > > solution.
> > > >
> > > >    What does this mean for the protocol?  Sequence
> > > > numbers and periodic stream integrity reports. Anything
> > > > else can be vendor improvements.   IMHO.
> > > >
> > > > Carter
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: majordomo listserver
> > > [mailto:majordomo@mil.doit.wisc.edu] On
> > > > > Behalf Of calato@riverstonenet.com
> > > > > Sent: Wednesday, November 13, 2002 10:35 AM
> > > > > Cc: ipfix@net.doit.wisc.edu
> > > > > Subject: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt
> > > > >
> > > > >
> > > > >
> > > > > I'm left wondering what level of reliability is in scope?
> > > > >
> > > > > It seems we a few people that agree a highly reliable protocol is
> > > > > out of scope and several agreeing it is in scope. Since
> > > one person
> > > > > from the former was wearing an AD hat I'm left still uncertain of
> > > > > the outcome.
> > > > >
> > > > > Is high reliability in scope or out of scope. If out
> > > > > of scope, to what level is in scope?
> > > > >
> > > > >         1. Transport level reliability
> > > > >         2. Redundancy reliability (e.g. sending all data
> > > > >            to multiple collectors or multicasting)
> > > > >         3. Failover (i.e. detecting a collector is
> > > > >            down and switching to another)
> > > > >         4. Congestion awareness only (i.e. send and forget)
> > > > >
> > > > > What level of reliability is in scope?
> > > > >
> > > > > Paul
> > > > >
> > > > > --
> > > > > 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  Fri Nov 15 08:27:48 2002
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 IAA07767
	for ; Fri, 15 Nov 2002 08:27:48 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18CgHN-00040i-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 15 Nov 2002 07:13:01 -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 18CgHL-000401-00
	for ipfix@net.doit.wisc.edu; Fri, 15 Nov 2002 07:12:59 -0600
Received: from riverstonenet.com ([134.141.180.74]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Fri, 15 Nov 2002 05:12:26 -0800
Message-ID: <3DD4F23A.2E67805@riverstonenet.com>
Date: Fri, 15 Nov 2002 08:10:18 -0500
From: calato@riverstonenet.com
X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Benoit Claise 
CC: Tal Givoly , Jeff Meyer ,
        carter@qosient.com, "'ipfixx'" 
Subject: Re: [ipfix] Multiple levels of Reliability and Directionality
References:  <3DD00105.C1F767EA@riverstonenet.com> <3DD4DB97.4080204@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 15 Nov 2002 13:12:26.0962 (UTC) FILETIME=[A4F3A320:01C28CA8]
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

Benoit Claise wrote:
> 
> Paul,
> 
> First of all, let me take back your initial email, for clarity
> purposes
> 
>         High   - Little to no data loss
>         Medium - Minimal data loss is accepted
>         Low    - Data sent is best effort
> 
> The six combinations are shown below...
> 
>                | Uni  |  Bi
>         -------+------+---------
>         High   |  1   |    4
>         -------+------+--------
>         Medium |  2   |    5
>         -------+------+--------
>         Low    |  3   |    6
> 
> I think (IMHO) the most likely combinations are...
> 
>         3. Low reliability and uni-directional. This will be used
>            where the device and collector are in close proximity,
>            there is high volume and some data loss is acceptable for
>            the given application. Applications such as
> Attack/Intrusion
>            Detection Traffic Profiling, etc...
> 
>         5. Bi-directional medium reliability. This will be used
>            where high volume and increased reliability are needed.
>            Applications
>            such as Usage-based Accounting where 95th percentile
> billing
>            model is used. Or even Traffic Engineering where network
>            policy decisions are based on the data collected.
> 
>         4. Bi-directional high reliability would be used where the
>            Usage-based Accounting application has strict requirements
>            on data loss.
> 
> I agree on 3, this is the minimum.
> 
> I agree on 5 but I fear that the application level ACK will not always
> be a possible solution from a router point of view. What if the router
> exports so much flow records that it can't cache them while waiting
> for the ACK.
> So basically, resending the flow records is not always possible.
> So, if you conclude that the requirement for 5 is the bidirectionality
> with application level ACK, then this requirement is not always
> possible!

	Agreed. In very high volume deployments I would 
	use option #3.
	
> IMHO, 5 could alos be
>         2 with best-effort
>         or 2 with a carefully designed network

	If the customer can design their accounting network
	in such away. But I'm not sure we want to require that.
	
	Lets assume that aggregation is happening at
	a reasonably high level (which drops the flow rate
	to a manageable level). But the consequence is that
	one lost record can be a huge chunk of missing data.

	In this case reliability is the issue not the data
	rate. I'm advocating a reliability option (note I said option)
	as a way to solve this.	
	

> 
> Regarding 4, Randy replied already
> 
>      > Somehow, the requirements discussion suffers from a split:
>      > There are requirements resulting from the intention of
>      > standardzing a highly reliable metering standard for
>      precise
>      > accounting (and billing). Differing from these are
>      requirements
>      > for a simpler metering standard more oriented at what I
>      would
>      > call "typical Internet reliability".
> 
>       the original goal, which the iesg thinks was chartered,
>      is the
>      latter.
> 

	There was a lot of push back by the group on that statement.
	I asked for clarification but have not received any.

	Paul

> > Let me see if we all agree on a couple things...
> >
> >         1. There is no such thing as partially uni-directional.
> >         2. IPFIX ought to support a uni-directional mode of
> > operation.
> >
> Agreed.
> 
> Regards, Benoit.
> 
> >
> > Paul
> >
> > Tal Givoly wrote:
> >
> >
> >> Jeff,
> >>
> >> I agree with you completely here - the protocol should focus on a
> >> primarily
> >> uni-directional feed from network/service elements
> >> (metering+exporting
> >> process) to collection process. Adding capabilities (such as
> >> parameter
> >> configuration, provisioning of other sorts, etc.) here is a
> >> slippery slope.
> >>
> >> I would add, however, that the bi-directionality is needed both
> >> for
> >> assurance that messages are delivered as well as, IMHO, version,
> >> capability
> >> and template negotiation (which can be simplified as needed by
> >> device).
> >> Version and capability negotiation allows for forward/backward
> >> interoperability and compatibility. Template negotiation allows
> >> for more
> >> efficient application-aware communication. As Peter explained
> >> earlier
> >> (http://ipfix.doit.wisc.edu/archive/1381.html - scenario #1 or
> >> #2), it is
> >> possible to have all these capabilities and have no impact on the
> >> metering/export processes complexity - the complexity can be,
> >> optionally,
> >> added to the collection process (off the device) in order to allow
> >> for
> >> interoperability with multiple concurrent
> >> versions/capabilities/templates in
> >> the devices.
> >>
> >> Essentially, I believe we achieved consensus regarding the need
> >> for template
> >> capabilities to allow separation of the data model from the
> >> protocol.
> >> Version/capability negotiation are very useful for any protocol in
> >> order to
> >> increase its applicability and useful lifespan.
> >>
> >> Tal
> >>
> >> -----Original Message-----
> >> From: Jeff Meyer [mailto:jeffm@cup.hp.com]
> >> Sent: Monday, November 11, 2002 9:39 AM
> >> To: calato@riverstonenet.com
> >> Cc: Tal Givoly; carter@qosient.com; 'ipfixx'
> >> Subject: Re: [ipfix] Multiple levels of Reliability and
> >> Directionality
> >>
> >> OK, then based on this minimal definition of
> >> bi-directional, I'm in complete agreement.
> >>
> >> It's the sliperry slope of other things one might
> >> want to exchange once this two way channel is open,
> >> which concerns me.  There are lots of things one
> >> might want to exchange, but many of these are probably
> >> better addressed by reusing existing protocols,
> >> vs. stuffing into the IPFIX protocol.
> >>
> >> For example, controlling metering process is something
> >> which can be separated out from IPFIX.  For example
> >> by using SNMP and a MeterMIB.
> >>
> >> Just trying to apply the KISS (Keep it simple stupid)
> >> principle.
> >>
> >> Regards,
> >>
> >>    Jeff Meyer
> >>    hp
> >>
> >> calato@riverstonenet.com wrote:
> >>
> >>
> >>
> >> > Jeff Meyer wrote:
> >> >
> >> >
> >> >
> >> >>  Hi,
> >> >>
> >> >>    I agree with the aspect of varied reliability.
> >> >>
> >> >>    I am less clear on the need for bi-directional
> >> >>  behavior.  The three scenarios you describe I
> >> >>  agree with, but I'm not sure how the 2nd and
> >> >>  3rd scenario as described have any dependence
> >> >>  on bi-directional aside from the some level of
> >> >>  application layer ack.
> >> >>
> >> >>
> >> >>
> >> >>
> >> >       An application layer ACK all by itself makes the
> >> >       protocol bi-directional.
> >> >
> >> >       Scenario #1 does not require the sender to also be a
> >> > receiver.
> >> >
> >> >       Scenarios #2 & #3 do require the sender to also be a
> >> >       receiver (even if only for ACK's).
> >> >
> >> >       Whether or not we decide to add other features in
> >> >       scenarios #2 & #3 (such as field negotiation, capability
> >> >       negotiation, etc...) is up to the WG. But they could
> >> >       not be added to scenario #1.
> >> >
> >> >       Paul
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >>  Regards,
> >> >>
> >> >>    Jeff Meyer
> >> >>
> >> >>  Tal Givoly wrote:
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> > Paul,
> >> >> >
> >> >> > I agree completely - that captures the essense of the
> >> >> > requirements. It
> >> >> > allows balancing different application's need for different
> >> >> > levels of
> >> >> > reliability.
> >> >> >
> >> >> > Tal
> >> >> >
> >> >> > -----Original Message-----
> >> >> > From: majordomo listserver [
> >> >> > mailto:majordomo@mil.doit.wisc.edu]On Behalf
> >> >> > Of Carter Bullard
> >> >> > Sent: Thursday, November 07, 2002 8:40 AM
> >> >> > To: calato@riverstonenet.com; 'ipfixx'
> >> >> > Subject: RE: [ipfix] Multiple levels of Reliability and
> >> >> > Directionality
> >> >> >
> >> >> >
> >> >> > Hey Paul,
> >> >> >  My 2 cents worth sez, absolutely yes!
> >> >> > Carter
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >>  -----Original Message-----
> >> >> >>  From: majordomo listserver
> >> >> >>  [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of
> >> >> >>  calato@riverstonenet.com
> >> >> >>  Sent: Thursday, November 07, 2002 9:46 AM
> >> >> >>  To: ipfixx
> >> >> >>  Subject: [ipfix] Multiple levels of Reliability and
> >> >> >>  Directionality
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>  Does IPFIX need to support multiple levels of reliability
> >> >> >>  and directionality?
> >> >> >>
> >> >> >>  The applications IPFIX needs to support are quite varied
> >> >> >>  and have differing needs in terms of reliability. Devices
> >> >> >>  also have varying needs in terms of directionality.
> >> >> >>
> >> >> >>  I would like the WG to consider requirements on the protocol
> >> >> >>  to support a tiered approach meet these needs.
> >> >> >>
> >> >> >>  Direction is either bi-directional or uni-directional. I've
> >> >> >>  split
> >> >> >>  reliability into 3 categories...
> >> >> >>
> >> >> >>        High   - Little to no data loss
> >> >> >>        Medium - Minimal data loss is accepted
> >> >> >>        Low    - Data sent is best effort
> >> >> >>
> >> >> >>
> >> >> >>  The six combinations are shown below...
> >> >> >>
> >> >> >>
> >> >> >>               | Uni  |  Bi
> >> >> >>        -------+------+---------
> >> >> >>        High   |  1   |    4
> >> >> >>        -------+------+--------
> >> >> >>        Medium |  2   |    5
> >> >> >>        -------+------+--------
> >> >> >>        Low    |  3   |    6
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>  I think (IMHO) the most likely combinations are...
> >> >> >>
> >> >> >>        3. Low reliability and uni-directional. This will be
> >> >> >>  used
> >> >> >>           where the device and collector are in close
> >> >> >>  proximity,
> >> >> >>           there is high volume and some data loss is
> >> >> >>  acceptable for
> >> >> >>           the given application. Applications such as
> >> >> >>  Attack/Intrusion Detection
> >> >> >>           Traffic Profiling, etc...
> >> >> >>
> >> >> >>        5. Bi-directional medium reliability. This will be
> >> >> >>  used
> >> >> >>           where high volume and increased reliability are
> >> >> >>  needed. Applications
> >> >> >>           such as Usage-based Accounting where 95th
> >> >> >>  percentile billing
> >> >> >>           model is used. Or even Traffic Engineering where
> >> >> >>  network policy
> >> >> >>           decisions are based on the data collected.
> >> >> >>
> >> >> >>        4. Bi-directional high reliability would be used where
> >> >> >>  the
> >> >> >>           Usage-based Accounting application has strict
> >> >> >>  requirements
> >> >> >>           on data loss.
> >> >> >>
> >> >> >>  Does IPFIX need to support multiple levels of reliability
> >> >> >>  and directionality?
> >> >> >>
> >> >> >>  Paul
> >> >> >>
> >> >> >>  --
> >> >> >>  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/
> >
> >

--
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 Nov 15 08:35:50 2002
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 IAA07908
	for ; Fri, 15 Nov 2002 08:35:50 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18CgQr-0004Bj-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 15 Nov 2002 07:22:49 -0600
Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18CgQp-0004Ab-00
	for ipfix@net.doit.wisc.edu; Fri, 15 Nov 2002 07:22:48 -0600
Received: from cisco.com (bclaise-isdn-home.cisco.com [10.49.4.218])
	by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id gAFDME722342;
	Fri, 15 Nov 2002 14:22:14 +0100 (CET)
Message-ID: <3DD4F505.5020404@cisco.com>
Date: Fri, 15 Nov 2002 14:22:13 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020815
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: calato@riverstonenet.com
CC: ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] Re: I-D ACTION:draft-ietf-ipfix-reqs-07.txt
References:  <3DD2712E.E656D12@riverstonenet.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

Paul,

Taking into account all the feedback sent so far to the mailing list

>I'm left wondering what level of reliability is in scope?
>
>It seems we a few people that agree a highly reliable 
>protocol is out of scope and several agreeing it is in 
>scope. Since one person from the former was wearing an AD 
>hat I'm left still uncertain of the outcome.
>
>Is high reliability in scope or out of scope. If out
>of scope, to what level is in scope?
>
>	1. Transport level reliability
>	2. Redundancy reliability (e.g. sending all data 
>	   to multiple collectors or multicasting)
>	3. Failover (i.e. detecting a collector is 
>	   down and switching to another)
>	4. Congestion awareness only (i.e. send and forget)
>
Maybe we can add some more options. Let me also attempt to classify them.

	1. Congestion awareness only (i.e. send and forget)
        2. Receiver detection of IPFIX message loss
	3. Redundancy reliability (e.g. sending all data
	   to multiple collectors or multicasting)
	4. exporter detection of message loss caused by a broken link to collector
	5. Failover (i.e. detecting a collector is
	   down and switching to another)
        6. exporter detection of message loss caused by application level ACK not received
	7. Transport level reliability

1. and 2. are the minimum for IPFIX. 
   Taken into account by the req-07 as MUST(section 6.3.1 and section 6.3.2)

3. an easy solution.
   Taken into account by the req-07 as a MAY (section 8.3)

4. Taken into account by the req-07 as a SHOULD (section 6.3.2)

5. Taken into account by the req-07 as a MAY (section 6.3.2)

IMHO, this is as far as we should go in IPFIX.

Regards, Benoit.

>	
>What level of reliability is in scope?
>
>Paul
>
>--
>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 Nov 15 08:59:47 2002
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 IAA08400
	for ; Fri, 15 Nov 2002 08:59:47 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18Cgsf-0004ut-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 15 Nov 2002 07:51:33 -0600
Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18Cgsc-0004tk-00; Fri, 15 Nov 2002 07:51:30 -0600
Received: from cisco.com (bclaise-isdn-home.cisco.com [10.49.4.218])
	by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id gAFDou718450;
	Fri, 15 Nov 2002 14:50:56 +0100 (CET)
Message-ID: <3DD4FBC0.10701@cisco.com>
Date: Fri, 15 Nov 2002 14:50:56 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020815
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Simon Leinen 
CC: ipfix-eval@net.doit.wisc.edu, ipfix-req@net.doit.wisc.edu
Subject: Re: [ipfix-eval] Some comments on the evaluation team draft
References: <3DD3C6C3.30408@cisco.com> 
Content-Type: multipart/alternative;
 boundary="------------070108070903030709070101"
Precedence: bulk
Sender: majordomo listserver 


--------------070108070903030709070101
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Simon,

>On Thu, 14 Nov 2002 16:52:35 +0100, Benoit Claise  said:
>  
>
>>5.7 Anonymization  (6.7)   LFAP: E     CRANE: E     IPDR: E
>>NetFlow: E     Diameter: E
>>    
>>
>
>  
>
>>In my draft http://www.ietf.org/internet-drafts/draft-claise-ipfix-eval-netflow-03.txt, I wrote
>>    
>>
>
>
>  
>
>>    3.5.7 Anonymization (6.6)
>>            "The exporting process MAY be capable of anonymizing
>>source and
>>       destination IP addresses in flow data before exporting them."
>>       _Total Compliance. _
>>    
>>
>
>  
>
>>You can export the prefix is you want to and not the specific source
>>and destination IP addresses.
>>    
>>
>
>I would call that "(router-based) aggregation" rather than
>"anonymization".  With anonymization you somehow expect to maintain
>granularity, but want some kind of (non-reversible?) scrambling to
>cover up privacy-sensitive parts of the traffic data, such as IP
>addresses.
>
So what's the point to export something that you can't use?

Benoit.

>
>Don't take this requirement too seriously.  None of the candidates has
>addressed this, and I think as a requirement it hasn't been thought
>through too well.  It doesn't really reflect current practice, and
>personally I think this is better done on the collector side.
>  
>



--------------070108070903030709070101
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit




  
  


Simon,



  
On Thu, 14 Nov 2002 16:52:35 +0100, Benoit Claise <bclaise@cisco.com> said:
  

  

    
5.7 Anonymization  (6.7)   LFAP: E     CRANE: E     IPDR: E
NetFlow: E     Diameter: E
    

  

  

  

  

    
In my draft http://www.ietf.org/internet-drafts/draft-claise-ipfix-eval-netflow-03.txt, I wrote
    

  

  


  

  

    
    3.5.7 Anonymization (6.6)
            "The exporting process MAY be capable of anonymizing
source and
       destination IP addresses in flow data before exporting them."
       _Total Compliance. _
    

  

  

  

  

    
You can export the prefix is you want to and not the specific source
and destination IP addresses.
    

  

  

I would call that "(router-based) aggregation" rather than
"anonymization".  With anonymization you somehow expect to maintain
granularity, but want some kind of (non-reversible?) scrambling to
cover up privacy-sensitive parts of the traffic data, such as IP
addresses.



So what's the point to export something that you can't use?



Benoit.



  

Don't take this requirement too seriously.  None of the candidates has
addressed this, and I think as a requirement it hasn't been thought
through too well.  It doesn't really reflect current practice, and
personally I think this is better done on the collector side.
  










--------------070108070903030709070101--


--
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 Nov 15 09:12:24 2002
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 JAA08731
	for ; Fri, 15 Nov 2002 09:12:23 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18Ch1C-0005Aj-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 15 Nov 2002 08:00:22 -0600
Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18Ch1B-000571-00
	for ipfix-req@net.doit.wisc.edu; Fri, 15 Nov 2002 08:00:21 -0600
Received: from cisco.com (bclaise-isdn-home.cisco.com [10.49.4.218])
	by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id gAFDxQ725223;
	Fri, 15 Nov 2002 14:59:26 +0100 (CET)
Message-ID: <3DD4FDBE.9080708@cisco.com>
Date: Fri, 15 Nov 2002 14:59:26 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020815
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Juergen Quittek 
CC: Tal Givoly , ipfix-req@net.doit.wisc.edu
Subject: Re: failover requirements, was: RE: [ipfix-req] list of issues
References:  <43631098.1037324991@[192.168.102.31]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

Juergen,

> Tal,
>
> -- Tal Givoly wrote on 14 November 2002 13:31 -0800:
>
>> Reinaldo-2a: Add failover requirements, for example on the ability
>>              to detect loss of connectivity with the collector and
>>              trigger the appropriate action (eg. a switch over to
>>              an alternate collector.)
>>
>>     I haven't seen many responses on that. Is this a nice-to-have
>>     or a MUST?
>>     What would be appropriate actions?
>>     Is the requirement just "do something senseful in case of
>>     loosing a connection (or something like this) to the collector?
>>
>> Tal> I strongly believe that the protocol MUST support a mode in 
>> which it
>> operates fail-over. It should be noted that failover implicitly requires
>> bi-directional communication (minimally offered by transport protocol).
>> Therefore the way I see it, protocol MUST have a MODE in which it can 
>> fail
>> over to a backup collector in one of several cases. These cases may 
>> include
>> (but are not limited to), failure of the collector, failure of the 
>> link to
>> the collector, overload of the collector, lack of acknowledgement from
>> collector, signal from collector, and negative acknowledge from 
>> collector.
>> I'm sure there would be a debate whether that mode must exist in each
>> implementation or it merely be optional to support that mode. The 
>> protocol
>> itself must have such a mode, IMHO.
>
>
> What about the following change:
>
> in draft-ietf-ipfix-reqs-07 replace
>
>   If the exporting process is capable of detecting loss of connection
>   to a collecting process, it SHOULD be able to perform failover to a
>   specified backup collecting process.
>
> by
>
>   The exporting process MUST support a mode in which it can detect
>   loss of connection to one or more of the collecting processes.
>   If the exporting process detects loss of connection it MUST be
>   able to perform failover to one or more specified backup
>   collecting processes. 

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

Or

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

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

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

Regards, Benoit.

>
>
>
>    Juergen
>
> -- 
> 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 Nov 15 09:29:39 2002
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 JAA09229
	for ; Fri, 15 Nov 2002 09:29:39 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18ChIo-0005gS-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 15 Nov 2002 08:18:34 -0600
Received: from [67.17.241.195] (helo=kayla.dl.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18ChIm-0005ff-00
	for ipfix-eval@net.doit.wisc.edu; Fri, 15 Nov 2002 08:18:32 -0600
Received: from Athena.dl.com (ns100dmz.dl.com [67.17.241.200])
	by kayla.dl.com (8.11.6+Sun/8.11.6) with SMTP id gAFEI0l05162
	for ; Fri, 15 Nov 2002 06:18:00 -0800 (PST)
Received: by Athena.dl.com(Lotus SMTP MTA v4.6.6  (890.1 7-16-1999))  id 88256C72.004E85B8 ; Fri, 15 Nov 2002 06:17:40 -0800
X-Lotus-FromDomain: DLNOTES
From: "Malcolm Gillespie" 
To: ipfix-eval@net.doit.wisc.edu
Message-ID: <88256C72.004E83C3.00@Athena.dl.com>
Date: Fri, 15 Nov 2002 09:16:48 -0500
Subject: [ipfix-eval] IPFIX protocol: Suitability Matrix for CPE - CSU/DSUs
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Precedence: bulk
Sender: majordomo listserver 

Being a player in a fiercely competitive CPE market, QuickEagle would like
to share its views, requirements and real-world experience to help the
IPFIX group to evaluate the various proposed protocols.

Some critical attributes of a CSU/DSU are:
1.   Reliability
2.   Low cost of ownership over product lifetime

We are using CRANE to deliver QoS and other metrics from our CSU/DSUs.
Despite the low initial cost of such devices, one thing everyone takes for
granted from their CSU/DSUs is reliability, and hence low recurring cost of
ownership over the life of the product. As a result, our choice of technology
was driven by these factors.  CRANE also ensures us a level of flexibility
and scalability in an ever-changing IP community that allows us to adapt
quickly.

Many carriers have expressed a need to standardize on flow collection from
multi-vendor CPE, such as the CSU/DSUs, without compromising reliability or
being locked into expensive proprietary/closed solutions.

From our point of view, CRANE was a good choice because it offers:

1. Reliability - meets the carrier's requirements (congestion
   handling, zero data loss, minimal bandwidth). Our data is
   multiplexed onto the same network as regular traffic but
   with lower priority, so it is important that the protocol
   be able to handle this situation.

2. Low cost to integrate into our devices - this was achieved
   in a manner of a few engineering weeks and tested successfully
   by both us and a major carrier.

3. Small footprint - very important for us because of the
   highly competitive pricing in our market, and the need for
   feature richness without inordinate overhead.

4. Ease of adding new record types for export - just by adding
   a few new definitions in our code, CRANE's template
   negotiation takes care of everything else.
   Also, we can perform rolling version upgrades in the field
   without disrupting service enabled by its version and
   capability negotiation features.

5. Data push - CRANE data is much easier to process and scales
   better than SNMP (SNMP would have required keeping history
   data in case of missed polls, increasing our development cost
   and time)

In summary, for what we needed, CRANE was the best solution on the market
that meets our and our customers' requirements. So far we haven't found
anything better for our purposes.

Malcolm Gillespie
Director of Software Development
Quick Eagle Networks



--
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 Nov 15 09:29:42 2002
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 JAA09242
	for ; Fri, 15 Nov 2002 09:29:42 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18ChKd-0005jJ-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 15 Nov 2002 08:20:27 -0600
Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18Cgsc-0004tk-00; Fri, 15 Nov 2002 07:51:30 -0600
Received: from cisco.com (bclaise-isdn-home.cisco.com [10.49.4.218])
	by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id gAFDou718450;
	Fri, 15 Nov 2002 14:50:56 +0100 (CET)
Message-ID: <3DD4FBC0.10701@cisco.com>
Date: Fri, 15 Nov 2002 14:50:56 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020815
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Simon Leinen 
CC: ipfix-eval@net.doit.wisc.edu, ipfix-req@net.doit.wisc.edu
Subject: [ipfix-req] Re: [ipfix-eval] Some comments on the evaluation team draft
References: <3DD3C6C3.30408@cisco.com> 
Content-Type: multipart/alternative;
 boundary="------------070108070903030709070101"
Precedence: bulk
Sender: majordomo listserver 


--------------070108070903030709070101
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Simon,

>On Thu, 14 Nov 2002 16:52:35 +0100, Benoit Claise  said:
>  
>
>>5.7 Anonymization  (6.7)   LFAP: E     CRANE: E     IPDR: E
>>NetFlow: E     Diameter: E
>>    
>>
>
>  
>
>>In my draft http://www.ietf.org/internet-drafts/draft-claise-ipfix-eval-netflow-03.txt, I wrote
>>    
>>
>
>
>  
>
>>    3.5.7 Anonymization (6.6)
>>            "The exporting process MAY be capable of anonymizing
>>source and
>>       destination IP addresses in flow data before exporting them."
>>       _Total Compliance. _
>>    
>>
>
>  
>
>>You can export the prefix is you want to and not the specific source
>>and destination IP addresses.
>>    
>>
>
>I would call that "(router-based) aggregation" rather than
>"anonymization".  With anonymization you somehow expect to maintain
>granularity, but want some kind of (non-reversible?) scrambling to
>cover up privacy-sensitive parts of the traffic data, such as IP
>addresses.
>
So what's the point to export something that you can't use?

Benoit.

>
>Don't take this requirement too seriously.  None of the candidates has
>addressed this, and I think as a requirement it hasn't been thought
>through too well.  It doesn't really reflect current practice, and
>personally I think this is better done on the collector side.
>  
>



--------------070108070903030709070101
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit




  
  


Simon,



  
On Thu, 14 Nov 2002 16:52:35 +0100, Benoit Claise <bclaise@cisco.com> said:
  

  

    
5.7 Anonymization  (6.7)   LFAP: E     CRANE: E     IPDR: E
NetFlow: E     Diameter: E
    

  

  

  

  

    
In my draft http://www.ietf.org/internet-drafts/draft-claise-ipfix-eval-netflow-03.txt, I wrote
    

  

  


  

  

    
    3.5.7 Anonymization (6.6)
            "The exporting process MAY be capable of anonymizing
source and
       destination IP addresses in flow data before exporting them."
       _Total Compliance. _
    

  

  

  

  

    
You can export the prefix is you want to and not the specific source
and destination IP addresses.
    

  

  

I would call that "(router-based) aggregation" rather than
"anonymization".  With anonymization you somehow expect to maintain
granularity, but want some kind of (non-reversible?) scrambling to
cover up privacy-sensitive parts of the traffic data, such as IP
addresses.



So what's the point to export something that you can't use?



Benoit.



  

Don't take this requirement too seriously.  None of the candidates has
addressed this, and I think as a requirement it hasn't been thought
through too well.  It doesn't really reflect current practice, and
personally I think this is better done on the collector side.
  










--------------070108070903030709070101--


--
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 Nov 15 10:20:26 2002
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 KAA10235
	for ; Fri, 15 Nov 2002 10:20:26 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18Ci5G-0006yI-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 15 Nov 2002 09:08:38 -0600
Received: from mail.verilink.com ([192.94.46.36] helo=vrlkmail.verilink.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18Ci5F-0006xI-00
	for ipfix-eval@net.doit.wisc.edu; Fri, 15 Nov 2002 09:08:37 -0600
Subject: [ipfix-eval] Industry Perspective Regarding IPFIX Protocol
To: ipfix-eval@net.doit.wisc.edu
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: 
From: DScarlett@verilink.com
Date: Fri, 15 Nov 2002 09:01:48 -0600
X-MIMETrack: Serialize by Router on VRLKMAIL/VRLK(Release 5.0.11  |July 24, 2002) at 11/15/2002
 09:02:20 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Precedence: bulk
Sender: majordomo listserver 

Sir/Madam:

Verilink is a leading provider of business-to-business broadband access
solutions.  We recently had the opportunity integrate CRANE client software
into a number of our WANsuite access devices.  Implementation of the CRANE
client on our devices required a relatively small footprint. The
integration
required minimal development effort to integrate within the device and
between the access devices and the CRANE server (the data collection
point).

This opportunity came to us as one of our larger carrier customers had
selected the CRANE server firmware for use in its network and service
offerings.  The CRANE solution certainly seems to meet that carrier's needs
and requirements quite satisfactorily.

We appreciated the fact that the protocol offered reliability and
scalability while working over a wide area network that is potentially
subject to discontinuity.

I understand that as part of your evaluation you are considering the CRANE
protocol and perhaps this information may shed some light as to the
maturity
of this protocol and the ease with which it can be implemented.

Regards,

David Scarlett
Product Manager
Verilink Corporation


NOTICE: This communication may contain privileged or other confidential
information. If you are not the intended recipient, or believe that you
have received this communication in error, please do not print, copy,
retransmit,disseminate, or otherwise use the information. Also, please
indicate to the sender that you have received this communication in error,
and delete the copy you received. Thank you.



--
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 Nov 15 10:56:33 2002
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 KAA11091
	for ; Fri, 15 Nov 2002 10:56:32 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18CigC-00009M-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 15 Nov 2002 09:46:48 -0600
Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18CigA-00008d-00; Fri, 15 Nov 2002 09:46:46 -0600
Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gAFFkHC23152;
	Fri, 15 Nov 2002 09:46:17 -0600 (CST)
Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 15 Nov 2002 07:46:03 -0800
Message-ID: <0A11633F61BD9F40B43ABCC694004F9320258F@zsc3c026.us.nortel.com>
From: "Reinaldo Penno" 
To: Benoit Claise , Simon Leinen
	 
Cc: ipfix-eval@net.doit.wisc.edu, ipfix-req@net.doit.wisc.edu
Subject: RE: [ipfix-eval] Some comments on the evaluation team draft
Date: Fri, 15 Nov 2002 07:45:55 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C28CBE.158FA308"
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_01C28CBE.158FA308
Content-Type: text/plain;
	charset="iso-8859-1"

Benoit,
 
you can use other fields, such as IP Proto, TCP Ports, packet size, etc,
etc..There are several sites where you can download public data from
probes/exporters where the IP addresses are maked by a one-way function but
the other fields can be seen. See for instance
http://tracer.csl.sony.co.jp/mawi/guideline.txt
 
 
"Protecting User Privacy

There are 2 issues regarding user privacy.

1. Removing user data:
Leave only protocol headers and remove protocol
payload which could contain user data.
2. Providing anonymity:
Scramble addresses which could be used to identify a
user.
"
 
regards,
 
Reinaldo

-----Original Message-----
From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Friday, November 15, 2002 8:51 AM
To: Simon Leinen
Cc: ipfix-eval@net.doit.wisc.edu; ipfix-req@net.doit.wisc.edu
Subject: Re: [ipfix-eval] Some comments on the evaluation team draft


Simon,


On Thu, 14 Nov 2002 16:52:35 +0100, Benoit Claise
  said:

  

5.7 Anonymization  (6.7)   LFAP: E     CRANE: E     IPDR: E

NetFlow: E     Diameter: E

    



  

In my draft
http://www.ietf.org/internet-drafts/draft-claise-ipfix-eval-netflow-03.txt

, I wrote

    





  

    3.5.7 Anonymization (6.6)

            "The exporting process MAY be capable of anonymizing

source and

       destination IP addresses in flow data before exporting them."

       _Total Compliance. _

    



  

You can export the prefix is you want to and not the specific source

and destination IP addresses.

    



I would call that "(router-based) aggregation" rather than

"anonymization".  With anonymization you somehow expect to maintain

granularity, but want some kind of (non-reversible?) scrambling to

cover up privacy-sensitive parts of the traffic data, such as IP

addresses.

So what's the point to export something that you can't use?

Benoit.




Don't take this requirement too seriously.  None of the candidates has

addressed this, and I think as a requirement it hasn't been thought

through too well.  It doesn't really reflect current practice, and

personally I think this is better done on the collector side.

  




------_=_NextPart_001_01C28CBE.158FA308
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









Benoit,


 


you=20
can use other fields, such as IP Proto, TCP Ports, packet size, etc, =
etc..There=20
are several sites where you can download public data from =
probes/exporters where=20
the IP addresses are maked by a one-way function but the other =
fields can=20
be seen. See for instance http://tracer.c=
sl.sony.co.jp/mawi/guideline.txt


 


"Protecting User =
Privacy

	There=20
are 2 issues regarding user privacy.

	1. Removing user data:
	=
	Leave=20
only protocol headers and remove protocol
		payload which could =
contain user=20
data.
	2. Providing anonymity:
		Scramble addresses which could =
be used to=20
identify a
		user.
"


 


regards,


 


Reinaldo


  
-----Original Message-----
From: Benoit Claise=20
  [mailto:bclaise@cisco.com]
Sent: Friday, November 15, 2002 =
8:51=20
  AM
To: Simon Leinen
Cc: =
ipfix-eval@net.doit.wisc.edu;=20
  ipfix-req@net.doit.wisc.edu
Subject: Re: [ipfix-eval] Some =
comments=20
  on the evaluation team draft

Simon,

  
On Thu, 14 Nov 2002 16:52:35 +0100, Benoit =
Claise <bclaise@cisco.com> said:
  

    
5.7 Anonymization  (6.7)   =
LFAP: E     CRANE: E     IPDR: E
NetFlow: E     Diameter: E
    

  

    
In my draft http://www.ietf.org/internet-drafts/draft-claise-ipfix-eval-=
netflow-03.txt, I wrote
    


  

    
    3.5.7 Anonymization =
(6.6)
            "The exporting process MAY be capable of anonymizing
source and
       destination IP addresses in flow data before exporting them."
       _Total Compliance. _
    

  

    
You can export the prefix =
is you want to and not the specific source
and destination IP addresses.
    

I would call that "(router-based) aggregation" rather than
"anonymization".  With anonymization you somehow expect to maintain
granularity, but want some kind of (non-reversible?) scrambling to
cover up privacy-sensitive parts of the traffic data, such as IP
addresses.
So what's the point to export something =
that you=20
  can't use?

Benoit.

  
Don't take this requirement too seriously.  None of the candidates has
addressed this, and I think as a requirement it hasn't been thought
through too well.  It doesn't really reflect current practice, and
personally I think this is better done on the collector side.
  




------_=_NextPart_001_01C28CBE.158FA308--

--
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 Nov 15 11:02:46 2002
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 LAA11203
	for ; Fri, 15 Nov 2002 11:02:45 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18CieY-00007T-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 15 Nov 2002 09:45:06 -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 18CieX-00006i-00
	for ipfix-req@net.doit.wisc.edu; Fri, 15 Nov 2002 09:45:05 -0600
Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47])
	by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gAFFeWC01310;
	Fri, 15 Nov 2002 07:40:33 -0800 (PST)
Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 15 Nov 2002 07:40:32 -0800
Message-ID: <0A11633F61BD9F40B43ABCC694004F93202582@zsc3c026.us.nortel.com>
From: "Reinaldo Penno" 
To: calato@riverstonenet.com, Juergen Quittek 
Cc: Tal Givoly , ipfix-req@net.doit.wisc.edu
Subject: [ipfix-req] RE: MUST or SHOULD be able to export ICMP codes? was:RE: [ipfix-r
	eq]  list of issues
Date: Fri, 15 Nov 2002 07:40:30 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C28CBD.53C31D5E"
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_01C28CBD.53C31D5E
Content-Type: text/plain;
	charset="iso-8859-1"

Many platforms do not distinguish a lot of fields...Should we make them all
SHOULD?

Because today we have two requirements (on a quick glance) that go against
this reasoning

"4.4.  MPLS Label

   If the observation point is located at a device supporting
   Multiprotocol Label Switching (MPLS, see [RFC3031]) then the metering
   process MUST be able to separate flows by the MPLS label.

4.5.  DiffServ Code Point

   If the observation point is located at a device supporting
   Differentiated Services (DiffServ) then the metering process MUST be
   able to separate flows by the DiffServ Code Point (DSCP, see
   [RFC2474])."

So, if that's the reasoning I would propose (as before) dropping these two
requirements or making them a SHOULD. Otherwise I propose something like

"
   If the observation point is located at a device supporting
   ICMP ([XXXX]) then the metering  process MUST be able to separate flows
by ICMP Type and Code."

I'm just trying to be consistent, otherwise we are having double standards. 

regards,

Reinaldo 


ps: Detecting the ICMP type and code is Very important for security
purposes.


> -----Original Message-----
> From: calato@riverstonenet.com [mailto:calato@riverstonenet.com]
> Sent: Friday, November 15, 2002 7:07 AM
> To: Juergen Quittek
> Cc: Tal Givoly; ipfix-req@net.doit.wisc.edu
> Subject: Re: MUST or SHOULD be able to export ICMP codes? was:RE:
> [ipfix-req] list of issues
> 
> 
> Juergen Quittek wrote:
> > 
> > Tal,
> > 
> > -- Tal Givoly wrote on 14 November 2002 13:31 -0800:
> > 
> > > Reinaldo-4: Add MUST requirement for exporting ICMP codes 
> in Section 6.1
> > >
> > >     There were not many responses on this suggestion. 
> Personally, I do
> > >     not consider it a MUST, but a nice-to-have.
> > >
> > > Tal> I believe this should be classified as a SHOULD.
> > 
> > I agree. In the current draft it is listed in section 6.1 as a MUST
> > attribute. We should move it to SHOULD. But I changed my opinion
> > on this issue already two times. Are there other people 
> having a more
> > firm opinion?
> > 
> 	SHOULD. Many platforms do not distinguish on this field and
> 	it does not make sense to report it if not part of the key.
> 
> >     Juergen
> > 
> > --
> > 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/
> 

------_=_NextPart_001_01C28CBD.53C31D5E
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: MUST or SHOULD be able to export ICMP codes? was:RE: =
[ipfix-req]  list of issues




Many platforms do not distinguish a lot of =
fields...Should we make them all SHOULD?




Because today we have two requirements (on a quick =
glance) that go against this reasoning




"4.4.  MPLS Label




   If the observation point is located at a =
device supporting

   Multiprotocol Label Switching (MPLS, =
see [RFC3031]) then the metering

   process MUST be able to separate flows =
by the MPLS label.




4.5.  DiffServ Code Point




   If the observation point is located at a =
device supporting

   Differentiated Services (DiffServ) then =
the metering process MUST be

   able to separate flows by the DiffServ =
Code Point (DSCP, see

   [RFC2474])."




So, if that's the reasoning I would propose (as =
before) dropping these two requirements or making them a SHOULD. =
Otherwise I propose something like



"

   If the observation point is located at =
a device supporting

   ICMP ([XXXX]) then the metering  =
process MUST be able to separate flows by ICMP Type and =
Code."




I'm just trying to be consistent, otherwise we are =
having double standards. 




regards,




Reinaldo 






ps: Detecting the ICMP type and code is Very =
important for security purposes.






> -----Original Message-----

> From: calato@riverstonenet.com [mailto:calato@riverstonenet.com=
]

> Sent: Friday, November 15, 2002 7:07 AM

> To: Juergen Quittek

> Cc: Tal Givoly; =
ipfix-req@net.doit.wisc.edu

> Subject: Re: MUST or SHOULD be able to export =
ICMP codes? was:RE:

> [ipfix-req] list of issues

> 

> 

> Juergen Quittek wrote:

> > 

> > Tal,

> > 

> > -- Tal Givoly wrote on 14 November 2002 =
13:31 -0800:

> > 

> > > Reinaldo-4: Add MUST requirement for =
exporting ICMP codes 

> in Section 6.1

> > >

> > >     There were =
not many responses on this suggestion. 

> Personally, I do

> > >     not consider =
it a MUST, but a nice-to-have.

> > >

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

> > 

> > I agree. In the current draft it is listed =
in section 6.1 as a MUST

> > attribute. We should move it to SHOULD. =
But I changed my opinion

> > on this issue already two times. Are there =
other people 

> having a more

> > firm opinion?

> > 

>       SHOULD. Many =
platforms do not distinguish on this field and

>       it does not make =
sense to report it if not part of the key.

> 

> >     Juergen

> > 

> > --

> > =
Help        mailto:majordomo@net.doit.wi=
sc.edu and say 

> "help" in message body

> > Unsubscribe mailto:majordomo@net.doit.wi=
sc.edu and say

> > "unsubscribe ipfix" in message =
body

> > Archive     http://ipfix.doit.wisc.edu/archive/

> 

> --

> Help        =
mailto:majordomo@net.doit.wi=
sc.edu and say "help" 

> in message body

> Unsubscribe mailto:majordomo@net.doit.wi=
sc.edu and say

> "unsubscribe ipfix" in message =
body

> Archive     http://ipfix.doit.wisc.edu/archive/

> 





------_=_NextPart_001_01C28CBD.53C31D5E--

--
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 Nov 15 11:16:14 2002
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 LAA11484
	for ; Fri, 15 Nov 2002 11:16:13 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18Cj0u-0000u6-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 15 Nov 2002 10:08:12 -0600
Received: from pool-68-160-192-59.ny325.east.verizon.net ([68.160.192.59] helo=newyork.qosient.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18Cj0t-0000tz-00
	for ipfix-req@net.doit.wisc.edu; Fri, 15 Nov 2002 10:08:11 -0600
Received: from sphynx (sphynx [192.168.0.64])
	by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id gAFG86O07594;
	Fri, 15 Nov 2002 11:08:06 -0500
From: "Carter Bullard" 
To: "'Reinaldo Penno'" , ,
        "'Juergen Quittek'" 
Cc: "'Tal Givoly'" , 
Subject: RE: [ipfix-req] RE: MUST or SHOULD be able to export ICMP codes? was:RE: [ipfix-req]  list of issues
Date: Fri, 15 Nov 2002 11:07:57 -0500
Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A4BB@ptah.newyork.qosient.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <5C8959A16A71B449AE793CF52FBBED660D8038@ptah.newyork.qosient.com>
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

Hey Reinaldo,
  I agree that a MUST is too strong for any data element
in the flow model. It pre-supposes that all IPFIX devices
will generate the same type of flow information.  ICMP
packets can be viewed as belonging to its own flow, in
the case of ICMP request/response types, or they can be
viewed as belonging to Type-P1-P2 flows, in the case
of unreachables.

  I do not want IPFIX to dictate how a flow monitor will
count these packets, since it doesn't have a well defined
flow model that explains the methodology.

Carter

Carter Bullard
QoSient, LLC
300 E. 56th Street
Suite 18K
New York, New York 10022

+1 212 588-9133 Phone
+1 212 588-9134 Fax
   
-----Original Message-----
From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] On
Behalf Of Reinaldo Penno
Sent: Friday, November 15, 2002 10:41 AM
To: calato@riverstonenet.com; Juergen Quittek
Cc: Tal Givoly; ipfix-req@net.doit.wisc.edu
Subject: [ipfix-req] RE: MUST or SHOULD be able to export ICMP codes?
was:RE: [ipfix-req] list of issues


Many platforms do not distinguish a lot of fields...Should we make them
all SHOULD? 
Because today we have two requirements (on a quick glance) that go
against this reasoning 
"4.4.  MPLS Label 
   If the observation point is located at a device supporting 
   Multiprotocol Label Switching (MPLS, see [RFC3031]) then the metering

   process MUST be able to separate flows by the MPLS label. 
4.5.  DiffServ Code Point 
   If the observation point is located at a device supporting 
   Differentiated Services (DiffServ) then the metering process MUST be 
   able to separate flows by the DiffServ Code Point (DSCP, see 
   [RFC2474])." 
So, if that's the reasoning I would propose (as before) dropping these
two requirements or making them a SHOULD. Otherwise I propose something
like
" 
   If the observation point is located at a device supporting 
   ICMP ([XXXX]) then the metering  process MUST be able to separate
flows by ICMP Type and Code." 
I'm just trying to be consistent, otherwise we are having double
standards. 
regards, 
Reinaldo 


ps: Detecting the ICMP type and code is Very important for security
purposes. 


> -----Original Message----- 
> From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] 
> Sent: Friday, November 15, 2002 7:07 AM 
> To: Juergen Quittek 
> Cc: Tal Givoly; ipfix-req@net.doit.wisc.edu 
> Subject: Re: MUST or SHOULD be able to export ICMP codes? was:RE: 
> [ipfix-req] list of issues 
> 
> 
> Juergen Quittek wrote: 
> > 
> > Tal, 
> > 
> > -- Tal Givoly wrote on 14 November 2002 13:31 -0800: 
> > 
> > > Reinaldo-4: Add MUST requirement for exporting ICMP codes 
> in Section 6.1 
> > > 
> > >     There were not many responses on this suggestion. 
> Personally, I do 
> > >     not consider it a MUST, but a nice-to-have. 
> > > 
> > > Tal> I believe this should be classified as a SHOULD. 
> > 
> > I agree. In the current draft it is listed in section 6.1 as a MUST 
> > attribute. We should move it to SHOULD. But I changed my opinion 
> > on this issue already two times. Are there other people 
> having a more 
> > firm opinion? 
> > 
>       SHOULD. Many platforms do not distinguish on this field and 
>       it does not make sense to report it if not part of the key. 
> 
> >     Juergen 
> > 
> > -- 
> > 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 Nov 15 11:17:40 2002
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 LAA11527
	for ; Fri, 15 Nov 2002 11:17:39 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18Ciym-0000qU-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 15 Nov 2002 10:06:00 -0600
Received: from host195-89-159-99.uk.regusnet.com ([195.89.159.99] helo=cygnus.degree2.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18Ciyk-0000qH-00
	for ipfix-eval@net.doit.wisc.edu; Fri, 15 Nov 2002 10:05:58 -0600
Received: from calypso (calypso.degree2.com [172.30.40.49])
	by cygnus.degree2.com (8.11.6/8.11.6) with ESMTP id gAFG5uY07562;
	Fri, 15 Nov 2002 16:05:56 GMT
From: "Alistair Munro" 
To: 
Cc: 
Subject: [ipfix-eval] Support for CRANE
Date: Fri, 15 Nov 2002 16:09:01 -0000
Message-ID: <005201c28cc1$500c10e0$31281eac@degree2.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: 
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

Dear IPFIX-EVALers,

Degree2 Innovations develops QoS solutions for packet networks which we
market to enterprise users or license to vendors of IADs (or similar
middlebox/access router devices). Our customers have expressed a strong
requirement for billing based on delivered QoS against agreed SLAs. They
also need to understand the traffic mixes flowing across their LAN/WAN
boundaries as the first step in enforcing the SLAs and related policies.
For our own purposes, we sought a protocol that would be implementable
on both low-end and high-end devices, with a high degree of flexibility
on the information to be collected, and reliability (of the collection
process as well as the transport protocol).

We selected CRANE as the protocol to communicate the individual IP flow
and aggregated (metered) data between exporter and collector. 

We have implemented, independently of XACCT, our own exporter and
collector processes. We intend to do interoperability testing with XACCT
some time early next year. On the basis of recently published interim
evaluation documents, (drafts from Gopal and Leinen), it appears to be a
good fit to IPFIX requirements.

We encourage the IPFIX group to adopt CRANE as its preferred protocol.

Best regards,

Alistair Munro

--
Dr. Alistair Munro,
Chief Systems Engineer, Degree2 Innovations Ltd.
Regus House, 1 Friary, Temple Quay, Bristol, BS1 6EA, U.K.
E-mail: Alistair.Munro@degree2.com
Tel: (work) +44-117-900-8114, (home) +44-1275-462707, (mobile)
+44-7974-922-442;
Fax: +44-117-900-8151
Web: http://www.u4eagroup.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  Fri Nov 15 11:17:41 2002
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 LAA11540
	for ; Fri, 15 Nov 2002 11:17:41 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18CiyF-0000op-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 15 Nov 2002 10:05:27 -0600
Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18CigA-00008d-00; Fri, 15 Nov 2002 09:46:46 -0600
Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gAFFkHC23152;
	Fri, 15 Nov 2002 09:46:17 -0600 (CST)
Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 15 Nov 2002 07:46:03 -0800
Message-ID: <0A11633F61BD9F40B43ABCC694004F9320258F@zsc3c026.us.nortel.com>
From: "Reinaldo Penno" 
To: Benoit Claise , Simon Leinen
	 
Cc: ipfix-eval@net.doit.wisc.edu, ipfix-req@net.doit.wisc.edu
Subject: [ipfix-req] RE: [ipfix-eval] Some comments on the evaluation team draft
Date: Fri, 15 Nov 2002 07:45:55 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C28CBE.158FA308"
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_01C28CBE.158FA308
Content-Type: text/plain;
	charset="iso-8859-1"

Benoit,
 
you can use other fields, such as IP Proto, TCP Ports, packet size, etc,
etc..There are several sites where you can download public data from
probes/exporters where the IP addresses are maked by a one-way function but
the other fields can be seen. See for instance
http://tracer.csl.sony.co.jp/mawi/guideline.txt
 
 
"Protecting User Privacy

There are 2 issues regarding user privacy.

1. Removing user data:
Leave only protocol headers and remove protocol
payload which could contain user data.
2. Providing anonymity:
Scramble addresses which could be used to identify a
user.
"
 
regards,
 
Reinaldo

-----Original Message-----
From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Friday, November 15, 2002 8:51 AM
To: Simon Leinen
Cc: ipfix-eval@net.doit.wisc.edu; ipfix-req@net.doit.wisc.edu
Subject: Re: [ipfix-eval] Some comments on the evaluation team draft


Simon,


On Thu, 14 Nov 2002 16:52:35 +0100, Benoit Claise
  said:

  

5.7 Anonymization  (6.7)   LFAP: E     CRANE: E     IPDR: E

NetFlow: E     Diameter: E

    



  

In my draft
http://www.ietf.org/internet-drafts/draft-claise-ipfix-eval-netflow-03.txt

, I wrote

    





  

    3.5.7 Anonymization (6.6)

            "The exporting process MAY be capable of anonymizing

source and

       destination IP addresses in flow data before exporting them."

       _Total Compliance. _

    



  

You can export the prefix is you want to and not the specific source

and destination IP addresses.

    



I would call that "(router-based) aggregation" rather than

"anonymization".  With anonymization you somehow expect to maintain

granularity, but want some kind of (non-reversible?) scrambling to

cover up privacy-sensitive parts of the traffic data, such as IP

addresses.

So what's the point to export something that you can't use?

Benoit.




Don't take this requirement too seriously.  None of the candidates has

addressed this, and I think as a requirement it hasn't been thought

through too well.  It doesn't really reflect current practice, and

personally I think this is better done on the collector side.

  




------_=_NextPart_001_01C28CBE.158FA308
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









Benoit,


 


you=20
can use other fields, such as IP Proto, TCP Ports, packet size, etc, =
etc..There=20
are several sites where you can download public data from =
probes/exporters where=20
the IP addresses are maked by a one-way function but the other =
fields can=20
be seen. See for instance http://tracer.c=
sl.sony.co.jp/mawi/guideline.txt


 


"Protecting User =
Privacy

	There=20
are 2 issues regarding user privacy.

	1. Removing user data:
	=
	Leave=20
only protocol headers and remove protocol
		payload which could =
contain user=20
data.
	2. Providing anonymity:
		Scramble addresses which could =
be used to=20
identify a
		user.
"


 


regards,


 


Reinaldo


  
-----Original Message-----
From: Benoit Claise=20
  [mailto:bclaise@cisco.com]
Sent: Friday, November 15, 2002 =
8:51=20
  AM
To: Simon Leinen
Cc: =
ipfix-eval@net.doit.wisc.edu;=20
  ipfix-req@net.doit.wisc.edu
Subject: Re: [ipfix-eval] Some =
comments=20
  on the evaluation team draft

Simon,

  
On Thu, 14 Nov 2002 16:52:35 +0100, Benoit =
Claise <bclaise@cisco.com> said:
  

    
5.7 Anonymization  (6.7)   =
LFAP: E     CRANE: E     IPDR: E
NetFlow: E     Diameter: E
    

  

    
In my draft http://www.ietf.org/internet-drafts/draft-claise-ipfix-eval-=
netflow-03.txt, I wrote
    


  

    
    3.5.7 Anonymization =
(6.6)
            "The exporting process MAY be capable of anonymizing
source and
       destination IP addresses in flow data before exporting them."
       _Total Compliance. _
    

  

    
You can export the prefix =
is you want to and not the specific source
and destination IP addresses.
    

I would call that "(router-based) aggregation" rather than
"anonymization".  With anonymization you somehow expect to maintain
granularity, but want some kind of (non-reversible?) scrambling to
cover up privacy-sensitive parts of the traffic data, such as IP
addresses.
So what's the point to export something =
that you=20
  can't use?

Benoit.

  
Don't take this requirement too seriously.  None of the candidates has
addressed this, and I think as a requirement it hasn't been thought
through too well.  It doesn't really reflect current practice, and
personally I think this is better done on the collector side.
  




------_=_NextPart_001_01C28CBE.158FA308--

--
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 Nov 15 11:23:38 2002
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 LAA11713
	for ; Fri, 15 Nov 2002 11:23:38 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18Cj9R-00018O-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 15 Nov 2002 10:17:01 -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 18Cj9O-00017e-00
	for ipfix-req@net.doit.wisc.edu; Fri, 15 Nov 2002 10:16:58 -0600
Received: from riverstonenet.com ([134.141.180.74]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Fri, 15 Nov 2002 08:16:26 -0800
Message-ID: <3DD51D5A.E8D84A8D@riverstonenet.com>
Date: Fri, 15 Nov 2002 11:14:18 -0500
From: calato@riverstonenet.com
X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Reinaldo Penno 
CC: Juergen Quittek , Tal Givoly ,
        ipfix-req@net.doit.wisc.edu
Subject: Re: MUST or SHOULD be able to export ICMP codes? was:RE: [ipfix-req]  
 list of issues
References: <0A11633F61BD9F40B43ABCC694004F93202582@zsc3c026.us.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 15 Nov 2002 16:16:27.0409 (UTC) FILETIME=[59922810:01C28CC2]
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

> Reinaldo Penno wrote:
> 
> Many platforms do not distinguish a lot of fields...Should we make
> them all SHOULD?

	Of course. Who is going to go change their hardware to
	meet this IPFIX requirement?
	
> 
> Because today we have two requirements (on a quick glance) that go
> against this reasoning
> 
> "4.4.  MPLS Label
> 
>    If the observation point is located at a device supporting
>    Multiprotocol Label Switching (MPLS, see [RFC3031]) then the
> metering
>    process MUST be able to separate flows by the MPLS label.

	This is reasonable because it says IF the device
	supports MPLS. If the device supports MPLS, it will 
	by definition, distinguish by label. What other attributes 
	(e.g. src ip, dst-ip) can be reported is less clear to me.

> 
> 4.5.  DiffServ Code Point
> 
>    If the observation point is located at a device supporting
>    Differentiated Services (DiffServ) then the metering process MUST
> be
>    able to separate flows by the DiffServ Code Point (DSCP, see
>    [RFC2474])."

	I didn't object to this one because I could not
	point to any devices that don't already distinguish
	based on this. Someone else is free to object on that
	basis.

> 
> So, if that's the reasoning I would propose (as before) dropping these
> two requirements or making them a SHOULD. Otherwise I propose
> something like
> 
> "
>    If the observation point is located at a device supporting
>    ICMP ([XXXX]) then the metering  process MUST be able to separate
> flows by ICMP Type and Code."
> 

	I would word it like this...

	If the observation point is located at a device which
	distinguishes flows by ICMP type code, then the metering  
	process MUST be able to export the type code.

	However, I thought we were trying to take the state
	of the industry in terms of distinguishing flows and
	make those MUSTs and the others SHOULD. 
	

> I'm just trying to be consistent, otherwise we are having double
> standards.
> 
> regards,
> 
> Reinaldo
> 
> ps: Detecting the ICMP type and code is Very important for security
> purposes.
> 

	I'm not questioning that aspect.

	Paul

> > -----Original Message-----
> > From: calato@riverstonenet.com [mailto:calato@riverstonenet.com]
> > Sent: Friday, November 15, 2002 7:07 AM
> > To: Juergen Quittek
> > Cc: Tal Givoly; ipfix-req@net.doit.wisc.edu
> > Subject: Re: MUST or SHOULD be able to export ICMP codes? was:RE:
> > [ipfix-req] list of issues
> >
> >
> > Juergen Quittek wrote:
> > >
> > > Tal,
> > >
> > > -- Tal Givoly wrote on 14 November 2002 13:31 -0800:
> > >
> > > > Reinaldo-4: Add MUST requirement for exporting ICMP codes
> > in Section 6.1
> > > >
> > > >     There were not many responses on this suggestion.
> > Personally, I do
> > > >     not consider it a MUST, but a nice-to-have.
> > > >
> > > > Tal> I believe this should be classified as a SHOULD.
> > >
> > > I agree. In the current draft it is listed in section 6.1 as a
> MUST
> > > attribute. We should move it to SHOULD. But I changed my opinion
> > > on this issue already two times. Are there other people
> > having a more
> > > firm opinion?
> > >
> >       SHOULD. Many platforms do not distinguish on this field and
> >       it does not make sense to report it if not part of the key.
> >
> > >     Juergen
> > >
> > > --
> > > 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 Nov 15 11:36:50 2002
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 LAA11896
	for ; Fri, 15 Nov 2002 11:36:49 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18CjHU-0001Ls-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 15 Nov 2002 10:25:20 -0600
Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18CjHS-0001Ke-00
	for ipfix@net.doit.wisc.edu; Fri, 15 Nov 2002 10:25:18 -0600
Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gAFGCvC07048;
	Fri, 15 Nov 2002 10:12:58 -0600 (CST)
Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 15 Nov 2002 08:12:43 -0800
Message-ID: <0A11633F61BD9F40B43ABCC694004F932025D8@zsc3c026.us.nortel.com>
From: "Reinaldo Penno" 
To: calato@riverstonenet.com, Benoit Claise 
Cc: Tal Givoly , Jeff Meyer ,
        carter@qosient.com, "'ipfixx'" 
Subject: RE: [ipfix] Multiple levels of Reliability and Directionality
Date: Fri, 15 Nov 2002 08:12:42 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C28CC1.D3744C4A"
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_01C28CC1.D3744C4A
Content-Type: text/plain;
	charset="iso-8859-1"

comments inline...

> -----Original Message-----
> From: calato@riverstonenet.com [mailto:calato@riverstonenet.com]
> Sent: Friday, November 15, 2002 8:10 AM
> To: Benoit Claise
> Cc: Tal Givoly; Jeff Meyer; carter@qosient.com; 'ipfixx'
> Subject: Re: [ipfix] Multiple levels of Reliability and Directionality
> 
> 
> Benoit Claise wrote:
> > 
> > Paul,
> > 
> > First of all, let me take back your initial email, for clarity
> > purposes
> > 
> >         High   - Little to no data loss
> >         Medium - Minimal data loss is accepted
> >         Low    - Data sent is best effort
> > 
> > The six combinations are shown below...
> > 
> >                | Uni  |  Bi
> >         -------+------+---------
> >         High   |  1   |    4
> >         -------+------+--------
> >         Medium |  2   |    5
> >         -------+------+--------
> >         Low    |  3   |    6
> > 
> > I think (IMHO) the most likely combinations are...
> > 
> >         3. Low reliability and uni-directional. This will be used
> >            where the device and collector are in close proximity,
> >            there is high volume and some data loss is acceptable for
> >            the given application. Applications such as
> > Attack/Intrusion
> >            Detection Traffic Profiling, etc...
> > 
> >         5. Bi-directional medium reliability. This will be used
> >            where high volume and increased reliability are needed.
> >            Applications
> >            such as Usage-based Accounting where 95th percentile
> > billing
> >            model is used. Or even Traffic Engineering where network
> >            policy decisions are based on the data collected.
> > 
> >         4. Bi-directional high reliability would be used where the
> >            Usage-based Accounting application has strict 
> requirements
> >            on data loss.
> > 
> > I agree on 3, this is the minimum.
> > 
> > I agree on 5 but I fear that the application level ACK will 
> not always
> > be a possible solution from a router point of view. What if 
> the router
> > exports so much flow records that it can't cache them while waiting
> > for the ACK.
> > So basically, resending the flow records is not always possible.
> > So, if you conclude that the requirement for 5 is the 
> bidirectionality
> > with application level ACK, then this requirement is not always
> > possible!
> 
> 	Agreed. In very high volume deployments I would 
> 	use option #3.
> 	
> > IMHO, 5 could alos be
> >         2 with best-effort
> >         or 2 with a carefully designed network
> 
> 	If the customer can design their accounting network
> 	in such away. But I'm not sure we want to require that.
> 	
> 	Lets assume that aggregation is happening at
> 	a reasonably high level (which drops the flow rate
> 	to a manageable level). But the consequence is that
> 	one lost record can be a huge chunk of missing data.
> 
> 	In this case reliability is the issue not the data
> 	rate. I'm advocating a reliability option (note I said option)
> 	as a way to solve this.	
> 	
> 
> > 
> > Regarding 4, Randy replied already
> > 
> >      > Somehow, the requirements discussion suffers from a split:
> >      > There are requirements resulting from the intention of
> >      > standardzing a highly reliable metering standard for
> >      precise
> >      > accounting (and billing). Differing from these are
> >      requirements
> >      > for a simpler metering standard more oriented at what I
> >      would
> >      > call "typical Internet reliability".
> > 
> >       the original goal, which the iesg thinks was chartered,
> >      is the
> >      latter.
> > 
> 
> 	There was a lot of push back by the group on that statement.
> 	I asked for clarification but have not received any.


IMO the statement included generalizations such as  "in my world, we use
octet counting for that kind of application" and "typical Internet
reliability" that several people questioned.

and then in a following email

"some _current_ inter-vendor incompatibilities,
fix congestion control, etc"

and this might go more into the core of problem. We have several "current"
vendors with somewhat distinct protocols. I should also say different
providers (based on some emails to the list) with different needs. What kind
of compromise can be achieved knowing that there are people that want
relible billing accounting (per flows, applications, etc) and some people
that just want traffic profiling and we still end up with standard widely
adopted? 

-RP



> 
> 	Paul
> 
> > > Let me see if we all agree on a couple things...
> > >
> > >         1. There is no such thing as partially uni-directional.
> > >         2. IPFIX ought to support a uni-directional mode of
> > > operation.
> > >
> > Agreed.
> > 
> > Regards, Benoit.
> > 
> > >
> > > Paul
> > >
> > > Tal Givoly wrote:
> > >
> > >
> > >> Jeff,
> > >>
> > >> I agree with you completely here - the protocol should focus on a
> > >> primarily
> > >> uni-directional feed from network/service elements
> > >> (metering+exporting
> > >> process) to collection process. Adding capabilities (such as
> > >> parameter
> > >> configuration, provisioning of other sorts, etc.) here is a
> > >> slippery slope.
> > >>
> > >> I would add, however, that the bi-directionality is needed both
> > >> for
> > >> assurance that messages are delivered as well as, IMHO, version,
> > >> capability
> > >> and template negotiation (which can be simplified as needed by
> > >> device).
> > >> Version and capability negotiation allows for forward/backward
> > >> interoperability and compatibility. Template negotiation allows
> > >> for more
> > >> efficient application-aware communication. As Peter explained
> > >> earlier
> > >> (http://ipfix.doit.wisc.edu/archive/1381.html - scenario #1 or
> > >> #2), it is
> > >> possible to have all these capabilities and have no impact on the
> > >> metering/export processes complexity - the complexity can be,
> > >> optionally,
> > >> added to the collection process (off the device) in 
> order to allow
> > >> for
> > >> interoperability with multiple concurrent
> > >> versions/capabilities/templates in
> > >> the devices.
> > >>
> > >> Essentially, I believe we achieved consensus regarding the need
> > >> for template
> > >> capabilities to allow separation of the data model from the
> > >> protocol.
> > >> Version/capability negotiation are very useful for any 
> protocol in
> > >> order to
> > >> increase its applicability and useful lifespan.
> > >>
> > >> Tal
> > >>
> > >> -----Original Message-----
> > >> From: Jeff Meyer [mailto:jeffm@cup.hp.com]
> > >> Sent: Monday, November 11, 2002 9:39 AM
> > >> To: calato@riverstonenet.com
> > >> Cc: Tal Givoly; carter@qosient.com; 'ipfixx'
> > >> Subject: Re: [ipfix] Multiple levels of Reliability and
> > >> Directionality
> > >>
> > >> OK, then based on this minimal definition of
> > >> bi-directional, I'm in complete agreement.
> > >>
> > >> It's the sliperry slope of other things one might
> > >> want to exchange once this two way channel is open,
> > >> which concerns me.  There are lots of things one
> > >> might want to exchange, but many of these are probably
> > >> better addressed by reusing existing protocols,
> > >> vs. stuffing into the IPFIX protocol.
> > >>
> > >> For example, controlling metering process is something
> > >> which can be separated out from IPFIX.  For example
> > >> by using SNMP and a MeterMIB.
> > >>
> > >> Just trying to apply the KISS (Keep it simple stupid)
> > >> principle.
> > >>
> > >> Regards,
> > >>
> > >>    Jeff Meyer
> > >>    hp
> > >>
> > >> calato@riverstonenet.com wrote:
> > >>
> > >>
> > >>
> > >> > Jeff Meyer wrote:
> > >> >
> > >> >
> > >> >
> > >> >>  Hi,
> > >> >>
> > >> >>    I agree with the aspect of varied reliability.
> > >> >>
> > >> >>    I am less clear on the need for bi-directional
> > >> >>  behavior.  The three scenarios you describe I
> > >> >>  agree with, but I'm not sure how the 2nd and
> > >> >>  3rd scenario as described have any dependence
> > >> >>  on bi-directional aside from the some level of
> > >> >>  application layer ack.
> > >> >>
> > >> >>
> > >> >>
> > >> >>
> > >> >       An application layer ACK all by itself makes the
> > >> >       protocol bi-directional.
> > >> >
> > >> >       Scenario #1 does not require the sender to also be a
> > >> > receiver.
> > >> >
> > >> >       Scenarios #2 & #3 do require the sender to also be a
> > >> >       receiver (even if only for ACK's).
> > >> >
> > >> >       Whether or not we decide to add other features in
> > >> >       scenarios #2 & #3 (such as field negotiation, capability
> > >> >       negotiation, etc...) is up to the WG. But they could
> > >> >       not be added to scenario #1.
> > >> >
> > >> >       Paul
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >>  Regards,
> > >> >>
> > >> >>    Jeff Meyer
> > >> >>
> > >> >>  Tal Givoly wrote:
> > >> >>
> > >> >>
> > >> >>
> > >> >>
> > >> >> > Paul,
> > >> >> >
> > >> >> > I agree completely - that captures the essense of the
> > >> >> > requirements. It
> > >> >> > allows balancing different application's need for different
> > >> >> > levels of
> > >> >> > reliability.
> > >> >> >
> > >> >> > Tal
> > >> >> >
> > >> >> > -----Original Message-----
> > >> >> > From: majordomo listserver [
> > >> >> > mailto:majordomo@mil.doit.wisc.edu]On Behalf
> > >> >> > Of Carter Bullard
> > >> >> > Sent: Thursday, November 07, 2002 8:40 AM
> > >> >> > To: calato@riverstonenet.com; 'ipfixx'
> > >> >> > Subject: RE: [ipfix] Multiple levels of Reliability and
> > >> >> > Directionality
> > >> >> >
> > >> >> >
> > >> >> > Hey Paul,
> > >> >> >  My 2 cents worth sez, absolutely yes!
> > >> >> > Carter
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> >>  -----Original Message-----
> > >> >> >>  From: majordomo listserver
> > >> >> >>  [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of
> > >> >> >>  calato@riverstonenet.com
> > >> >> >>  Sent: Thursday, November 07, 2002 9:46 AM
> > >> >> >>  To: ipfixx
> > >> >> >>  Subject: [ipfix] Multiple levels of Reliability and
> > >> >> >>  Directionality
> > >> >> >>
> > >> >> >>
> > >> >> >>
> > >> >> >>  Does IPFIX need to support multiple levels of reliability
> > >> >> >>  and directionality?
> > >> >> >>
> > >> >> >>  The applications IPFIX needs to support are quite varied
> > >> >> >>  and have differing needs in terms of reliability. Devices
> > >> >> >>  also have varying needs in terms of directionality.
> > >> >> >>
> > >> >> >>  I would like the WG to consider requirements on 
> the protocol
> > >> >> >>  to support a tiered approach meet these needs.
> > >> >> >>
> > >> >> >>  Direction is either bi-directional or 
> uni-directional. I've
> > >> >> >>  split
> > >> >> >>  reliability into 3 categories...
> > >> >> >>
> > >> >> >>        High   - Little to no data loss
> > >> >> >>        Medium - Minimal data loss is accepted
> > >> >> >>        Low    - Data sent is best effort
> > >> >> >>
> > >> >> >>
> > >> >> >>  The six combinations are shown below...
> > >> >> >>
> > >> >> >>
> > >> >> >>               | Uni  |  Bi
> > >> >> >>        -------+------+---------
> > >> >> >>        High   |  1   |    4
> > >> >> >>        -------+------+--------
> > >> >> >>        Medium |  2   |    5
> > >> >> >>        -------+------+--------
> > >> >> >>        Low    |  3   |    6
> > >> >> >>
> > >> >> >>
> > >> >> >>
> > >> >> >>  I think (IMHO) the most likely combinations are...
> > >> >> >>
> > >> >> >>        3. Low reliability and uni-directional. This will be
> > >> >> >>  used
> > >> >> >>           where the device and collector are in close
> > >> >> >>  proximity,
> > >> >> >>           there is high volume and some data loss is
> > >> >> >>  acceptable for
> > >> >> >>           the given application. Applications such as
> > >> >> >>  Attack/Intrusion Detection
> > >> >> >>           Traffic Profiling, etc...
> > >> >> >>
> > >> >> >>        5. Bi-directional medium reliability. This will be
> > >> >> >>  used
> > >> >> >>           where high volume and increased reliability are
> > >> >> >>  needed. Applications
> > >> >> >>           such as Usage-based Accounting where 95th
> > >> >> >>  percentile billing
> > >> >> >>           model is used. Or even Traffic Engineering where
> > >> >> >>  network policy
> > >> >> >>           decisions are based on the data collected.
> > >> >> >>
> > >> >> >>        4. Bi-directional high reliability would be 
> used where
> > >> >> >>  the
> > >> >> >>           Usage-based Accounting application has strict
> > >> >> >>  requirements
> > >> >> >>           on data loss.
> > >> >> >>
> > >> >> >>  Does IPFIX need to support multiple levels of reliability
> > >> >> >>  and directionality?
> > >> >> >>
> > >> >> >>  Paul
> > >> >> >>
> > >> >> >>  --
> > >> >> >>  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/
> > >
> > >
> 
> --
> 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/
> 

------_=_NextPart_001_01C28CC1.D3744C4A
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [ipfix] Multiple levels of Reliability and =
Directionality




comments inline...




> -----Original Message-----

> From: calato@riverstonenet.com [mailto:calato@riverstonenet.com=
]

> Sent: Friday, November 15, 2002 8:10 AM

> To: Benoit Claise

> Cc: Tal Givoly; Jeff Meyer; carter@qosient.com; =
'ipfixx'

> Subject: Re: [ipfix] Multiple levels of =
Reliability and Directionality

> 

> 

> Benoit Claise wrote:

> > 

> > Paul,

> > 

> > First of all, let me take back your =
initial email, for clarity

> > purposes

> > 

> =
>         High   - =
Little to no data loss

> =
>         Medium - Minimal =
data loss is accepted

> =
>         =
Low    - Data sent is best effort

> > 

> > The six combinations are shown =
below...

> > 

> =
>           &n=
bsp;    | Uni  |  Bi

> =
>         =
-------+------+---------

> =
>         High   =
|  1   |    4

> =
>         =
-------+------+--------

> =
>         Medium |  =
2   |    5

> =
>         =
-------+------+--------

> =
>         =
Low    |  3   |    =
6

> > 

> > I think (IMHO) the most likely =
combinations are...

> > 

> =
>         3. Low reliability =
and uni-directional. This will be used

> =
>            =
where the device and collector are in close proximity,

> =
>            =
there is high volume and some data loss is acceptable for

> =
>            =
the given application. Applications such as

> > Attack/Intrusion

> =
>            =
Detection Traffic Profiling, etc...

> > 

> =
>         5. Bi-directional =
medium reliability. This will be used

> >       &n=
bsp;    where high volume and increased reliability are =
needed.

> =
>            =
Applications

> =
>            =
such as Usage-based Accounting where 95th percentile

> > billing

> =
>            =
model is used. Or even Traffic Engineering where network

> =
>            =
policy decisions are based on the data collected.

> > 

> =
>         4. Bi-directional =
high reliability would be used where the

> =
>            =
Usage-based Accounting application has strict 

> requirements

> =
>            =
on data loss.

> > 

> > I agree on 3, this is the minimum.

> > 

> > I agree on 5 but I fear that the =
application level ACK will 

> not always

> > be a possible solution from a router point =
of view. What if 

> the router

> > exports so much flow records that it can't =
cache them while waiting

> > for the ACK.

> > So basically, resending the flow records =
is not always possible.

> > So, if you conclude that the requirement =
for 5 is the 

> bidirectionality

> > with application level ACK, then this =
requirement is not always

> > possible!

> 

>       Agreed. In very =
high volume deployments I would 

>       use option =
#3.

>       

> > IMHO, 5 could alos be

> =
>         2 with =
best-effort

> =
>         or 2 with a =
carefully designed network

> 

>       If the customer =
can design their accounting network

>       in such away. =
But I'm not sure we want to require that.

>       

>       Lets assume that =
aggregation is happening at

>       a reasonably =
high level (which drops the flow rate

>       to a manageable =
level). But the consequence is that

>       one lost record =
can be a huge chunk of missing data.

> 

>       In this case =
reliability is the issue not the data

>       rate. I'm =
advocating a reliability option (note I said option)

>       as a way to =
solve this. 

>       

> 

> > 

> > Regarding 4, Randy replied already

> > 

> >      > =
Somehow, the requirements discussion suffers from a split:

> >      > There =
are requirements resulting from the intention of

> >      > =
standardzing a highly reliable metering standard for

> >      =
precise

> >      > =
accounting (and billing). Differing from these are

> >      =
requirements

> >      > for a =
simpler metering standard more oriented at what I

> >      would

> >      > call =
"typical Internet reliability".

> > 

> >      <ad> =
the original goal, which the iesg thinks was chartered,

> >      is =
the

> >      =
latter.

> > 

> 

>       There was a lot =
of push back by the group on that statement.

>       I asked for =
clarification but have not received any.






IMO the statement included generalizations such =
as  "in my world, we use octet counting for that kind of =
application" and "typical Internet reliability" that =
several people questioned.



and then in a following email




"some _current_ inter-vendor =
incompatibilities,

fix congestion control, etc"




and this might go more into the core of problem. We =
have several "current" vendors with somewhat distinct =
protocols. I should also say different providers (based on some emails =
to the list) with different needs. What kind of compromise can be =
achieved knowing that there are people that want relible billing =
accounting (per flows, applications, etc) and some people that just =
want traffic profiling and we still end up with standard widely =
adopted? 



-RP








> 

>       Paul

> 

> > > Let me see if we all agree on a =
couple things...

> > >

> > =
>         1. There is no =
such thing as partially uni-directional.

> > =
>         2. IPFIX ought to =
support a uni-directional mode of

> > > operation.

> > >

> > Agreed.

> > 

> > Regards, Benoit.

> > 

> > >

> > > Paul

> > >

> > > Tal Givoly wrote:

> > >

> > >

> > >> Jeff,

> > >>

> > >> I agree with you completely here =
- the protocol should focus on a

> > >> primarily

> > >> uni-directional feed from =
network/service elements

> > >> (metering+exporting

> > >> process) to collection process. =
Adding capabilities (such as

> > >> parameter

> > >> configuration, provisioning of =
other sorts, etc.) here is a

> > >> slippery slope.

> > >>

> > >> I would add, however, that the =
bi-directionality is needed both

> > >> for

> > >> assurance that messages are =
delivered as well as, IMHO, version,

> > >> capability

> > >> and template negotiation (which =
can be simplified as needed by

> > >> device).

> > >> Version and capability =
negotiation allows for forward/backward

> > >> interoperability and =
compatibility. Template negotiation allows

> > >> for more

> > >> efficient application-aware =
communication. As Peter explained

> > >> earlier

> > >> (http://ipfix.doit.wisc.edu/archive/1381.html - =
scenario #1 or

> > >> #2), it is

> > >> possible to have all these =
capabilities and have no impact on the

> > >> metering/export processes =
complexity - the complexity can be,

> > >> optionally,

> > >> added to the collection process =
(off the device) in 

> order to allow

> > >> for

> > >> interoperability with multiple =
concurrent

> > >> versions/capabilities/templates =
in

> > >> the devices.

> > >>

> > >> Essentially, I believe we =
achieved consensus regarding the need

> > >> for template

> > >> capabilities to allow separation =
of the data model from the

> > >> protocol.

> > >> Version/capability negotiation =
are very useful for any 

> protocol in

> > >> order to

> > >> increase its applicability and =
useful lifespan.

> > >>

> > >> Tal

> > >>

> > >> -----Original Message-----

> > >> From: Jeff Meyer [mailto:jeffm@cup.hp.com]

> > >> Sent: Monday, November 11, 2002 =
9:39 AM

> > >> To: =
calato@riverstonenet.com

> > >> Cc: Tal Givoly; =
carter@qosient.com; 'ipfixx'

> > >> Subject: Re: [ipfix] Multiple =
levels of Reliability and

> > >> Directionality

> > >>

> > >> OK, then based on this minimal =
definition of

> > >> bi-directional, I'm in complete =
agreement.

> > >>

> > >> It's the sliperry slope of other =
things one might

> > >> want to exchange once this two =
way channel is open,

> > >> which concerns me.  There =
are lots of things one

> > >> might want to exchange, but many =
of these are probably

> > >> better addressed by reusing =
existing protocols,

> > >> vs. stuffing into the IPFIX =
protocol.

> > >>

> > >> For example, controlling metering =
process is something

> > >> which can be separated out from =
IPFIX.  For example

> > >> by using SNMP and a =
MeterMIB.

> > >>

> > >> Just trying to apply the KISS =
(Keep it simple stupid)

> > >> principle.

> > >>

> > >> Regards,

> > >>

> > >>    Jeff =
Meyer

> > >>    hp

> > >>

> > >> calato@riverstonenet.com =
wrote:

> > >>

> > >>

> > >>

> > >> > Jeff Meyer wrote:

> > >> >

> > >> >

> > >> >

> > >> >>  Hi,

> > >> >>

> > >> >>    I =
agree with the aspect of varied reliability.

> > >> >>

> > >> >>    I am =
less clear on the need for bi-directional

> > >> >>  behavior.  =
The three scenarios you describe I

> > >> >>  agree with, but =
I'm not sure how the 2nd and

> > >> >>  3rd scenario as =
described have any dependence

> > >> >>  on bi-directional =
aside from the some level of

> > >> >>  application layer =
ack.

> > >> >>

> > >> >>

> > >> >>

> > >> >>

> > >> =
>       An application layer ACK all =
by itself makes the

> > >> =
>       protocol =
bi-directional.

> > >> >

> > >> =
>       Scenario #1 does not require =
the sender to also be a

> > >> > receiver.

> > >> >

> > >> =
>       Scenarios #2 & #3 do =
require the sender to also be a

> > >> =
>       receiver (even if only for =
ACK's).

> > >> >

> > >> =
>       Whether or not we decide to =
add other features in

> > >> =
>       scenarios #2 & #3 (such as =
field negotiation, capability

> > >> =
>       negotiation, etc...) is up to =
the WG. But they could

> > >> =
>       not be added to scenario =
#1.

> > >> >

> > >> =
>       Paul

> > >> >

> > >> >

> > >> >

> > >> >

> > >> >

> > >> >>  Regards,

> > >> >>

> > >> >>    Jeff =
Meyer

> > >> >>

> > >> >>  Tal Givoly =
wrote:

> > >> >>

> > >> >>

> > >> >>

> > >> >>

> > >> >> > Paul,

> > >> >> >

> > >> >> > I agree completely =
- that captures the essense of the

> > >> >> > requirements. =
It

> > >> >> > allows balancing =
different application's need for different

> > >> >> > levels of

> > >> >> > reliability.

> > >> >> >

> > >> >> > Tal

> > >> >> >

> > >> >> > -----Original =
Message-----

> > >> >> > From: majordomo =
listserver [

> > >> >> > mailto:majordomo@mil.doit.wi=
sc.edu]On Behalf

> > >> >> > Of Carter =
Bullard

> > >> >> > Sent: Thursday, =
November 07, 2002 8:40 AM

> > >> >> > To: =
calato@riverstonenet.com; 'ipfixx'

> > >> >> > Subject: RE: =
[ipfix] Multiple levels of Reliability and

> > >> >> > =
Directionality

> > >> >> >

> > >> >> >

> > >> >> > Hey Paul,

> > >> >> >  My 2 cents =
worth sez, absolutely yes!

> > >> >> > Carter

> > >> >> >

> > >> >> >

> > >> >> >

> > >> >> >

> > >> >> >

> > >> >> >>  =
-----Original Message-----

> > >> >> >>  From: =
majordomo listserver

> > >> >> >>  [mailto:majordomo@mil.doit.wi=
sc.edu] On Behalf Of

> > >> >> >>  =
calato@riverstonenet.com

> > >> >> >>  Sent: =
Thursday, November 07, 2002 9:46 AM

> > >> >> >>  To: =
ipfixx

> > >> >> >>  Subject: =
[ipfix] Multiple levels of Reliability and

> > >> >> >>  Directiona=
lity

> > >> >> >>

> > >> >> >>

> > >> >> >>

> > >> >> >>  Does =
IPFIX need to support multiple levels of reliability

> > >> >> >>  and =
directionality?

> > >> >> >>

> > >> >> >>  The =
applications IPFIX needs to support are quite varied

> > >> >> >>  and have =
differing needs in terms of reliability. Devices

> > >> >> >>  also have =
varying needs in terms of directionality.

> > >> >> >>

> > >> >> >>  I would =
like the WG to consider requirements on 

> the protocol

> > >> >> >>  to =
support a tiered approach meet these needs.

> > >> >> >>

> > >> >> >>  Direction =
is either bi-directional or 

> uni-directional. I've

> > >> >> >>  =
split

> > >> >> >>  =
reliability into 3 categories...

> > >> >> >>

> > >> >> =
>>        High   - =
Little to no data loss

> > >> >> =
>>        Medium - Minimal =
data loss is accepted

> > >> >> =
>>        =
Low    - Data sent is best effort

> > >> >> >>

> > >> >> >>

> > >> >> >>  The six =
combinations are shown below...

> > >> >> >>

> > >> >> >>

> > >> >> =
>>          &nbs=
p;    | Uni  |  Bi

> > >> >> =
>>        =
-------+------+---------

> > >> >> =
>>        High   =
|  1   |    4

> > >> >> =
>>        =
-------+------+--------

> > >> >> =
>>        Medium |  =
2   |    5

> > >> >> =
>>        =
-------+------+--------

> > >> >> =
>>        =
Low    |  3   |    =
6

> > >> >> >>

> > >> >> >>

> > >> >> >>

> > >> >> >>  I think =
(IMHO) the most likely combinations are...

> > >> >> >>

> > >> >> =
>>        3. Low reliability =
and uni-directional. This will be

> > >> >> >>  =
used

> > >> >> =
>>           =
where the device and collector are in close

> > >> >> >>  =
proximity,

> > >> >> =
>>           =
there is high volume and some data loss is

> > >> >> >>  =
acceptable for

> > >> >> =
>>           =
the given application. Applications such as

> > >> >> >>  =
Attack/Intrusion Detection

> > >> >> =
>>           =
Traffic Profiling, etc...

> > >> >> >>

> > >> >> =
>>        5. Bi-directional =
medium reliability. This will be

> > >> >> >>  =
used

> > >> >> =
>>           =
where high volume and increased reliability are

> > >> >> >>  needed. =
Applications

> > >> >> =
>>           =
such as Usage-based Accounting where 95th

> > >> >> >>  =
percentile billing

> > >> >> =
>>           =
model is used. Or even Traffic Engineering where

> > >> >> >>  network =
policy

> > >> >> =
>>           =
decisions are based on the data collected.

> > >> >> >>

> > >> >> =
>>        4. Bi-directional =
high reliability would be 

> used where

> > >> >> >>  =
the

> > >> >> =
>>           =
Usage-based Accounting application has strict

> > >> >> >>  =
requirements

> > >> >> =
>>           on =
data loss.

> > >> >> >>

> > >> >> >>  Does =
IPFIX need to support multiple levels of reliability

> > >> >> >>  and =
directionality?

> > >> >> >>

> > >> >> >>  =
Paul

> > >> >> >>

> > >> >> >>  --

> > >> >> >>  =
Help        mailto:majordomo@net.doit.wi=
sc.edu and say

> > >> >> >>  =
"help"

> > >> >> >>  in =
message body

> > >> >> >>  =
Unsubscribe mailto:majordomo@net.doit.wi=
sc.edu and say

> > >> >> >>  =
"unsubscribe ipfix" in message body

> > >> >> >>  =
Archive     http://ipfix.doit.wisc.edu/archive/

> > >> >> >>

> > >> >> >>

> > >> >> >>

> > >> >> >>

> > >> >> >>

> > >> >> > --

> > >> >> > =
Help        mailto:majordomo@net.doit.wi=
sc.edu and 

> say "help"

> > >> >> > in message

> > >> >> > body

> > >> >> > Unsubscribe mailto:majordomo@net.doit.wi=
sc.edu and say

> > >> >> > "unsubscribe =
ipfix" in message body

> > >> >> > =
Archive     http://ipfix.doit.wisc.edu/archive/

> > >> >> >

> > >> >> >

> > >> >> > --

> > >> >> > =
Help        mailto:majordomo@net.doit.wi=
sc.edu and 

> say "help"

> > >> >> > in message

> > >> >> >

> > >> >> >

> > >> body

> > >>

> > >>

> > >> >> > Unsubscribe mailto:majordomo@net.doit.wi=
sc.edu and say

> > >> >> > "unsubscribe =
ipfix" in message body

> > >> >> > =
Archive     http://ipfix.doit.wisc.edu/archive/

> > >> >> >

> > >> >> >

> > >> >> >

> > >> >> >

> > > --

> > > =
Help        mailto:majordomo@net.doit.wi=
sc.edu and say "help" in

> > > message body

> > > Unsubscribe mailto:majordomo@net.doit.wi=
sc.edu and say

> > > "unsubscribe ipfix" in =
message body

> > > Archive     http://ipfix.doit.wisc.edu/archive/

> > >

> > >

> 

> --

> Help        =
mailto:majordomo@net.doit.wi=
sc.edu and say "help" 

> in message body

> Unsubscribe mailto:majordomo@net.doit.wi=
sc.edu and say

> "unsubscribe ipfix" in message =
body

> Archive     http://ipfix.doit.wisc.edu/archive/

> 





------_=_NextPart_001_01C28CC1.D3744C4A--

--
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 Nov 15 14:34:02 2002
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 OAA16400
	for ; Fri, 15 Nov 2002 14:34:01 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18Cm3W-000601-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 15 Nov 2002 13:23:06 -0600
Received: from mailhost2.auckland.ac.nz ([130.216.191.4])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18Cm3T-0005zU-00
	for ipfix@net.doit.wisc.edu; Fri, 15 Nov 2002 13:23:03 -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 IAA07464
	for ; Sat, 16 Nov 2002 08:23:00 +1300 (NZDT)
Received: from postbox.auckland.ac.nz (postbox.auckland.ac.nz [130.216.191.126])
	by mailhost.auckland.ac.nz (Mirapoint Messaging Server MOS 3.2.1.6-EA)
	with ESMTP id AJY02502;
	Sat, 16 Nov 2002 08:23:00 +1300 (NZDT)
Received: from localhost (hotlava.auckland.ac.nz [130.216.191.123])
	by postbox.auckland.ac.nz (8.11.6/8.11.6) with ESMTP id gAFJN0w25368
	for ; Sat, 16 Nov 2002 08:23:00 +1300
Received: from dyn42.caida.org (dyn42.caida.org [192.172.226.42]) 
	by hotlava.auckland.ac.nz (IMP) with HTTP 
	for ; Sat, 16 Nov 2002 08:23:00 +1300
Message-ID: <1037388180.3dd54994633ed@hotlava.auckland.ac.nz>
Date: Sat, 16 Nov 2002 08:23:00 +1300
From: Nevil Brownlee 
To: ipfix@net.doit.wisc.edu
Subject: [ipfix] Goals for Atlanta meeting
MIME-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) 4.0-cvs
X-Originating-IP: 192.172.226.42
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

Hello all:

After the flood of email on the IPFIX list, I couldn't resist taking off
my WG Co-chair hat for a moment and adding my own opinion ..

1) The WG charter is to 'standardise existing practice.'  To me that
   means 
    - Making a clear specification of IPFIX requirements, and
    - Documenting existing systems/protocols.
   As part of this, we want to address the various problems we've all
   encountered in using the existing systems.

2) Current issues.  
   * We agreed that dynamic configuration (of a flow exporter) is outside 
     the WG charter. [WG consensus]
   * It's clear that a 'standard IPFIX' must allow for various levels
     of reliability.  That suggests either having a base level (MUST) and
     higher levels (SHOULD and MAY), or having a mnimum set of features
     which applications can use to implement whatever level of reliability
     they need. [list consensus]
   * Flow attributes which relate to specific protocols (e.g. MPLS flow
     label, difserv code point) MUST be supported by devices which
     implement those protocols, and SHOULD be supported by other devices.
     [Nevil's own opinion]

3) Producing a Proposed Standard for IPFIX.
   While it would be wonderful if we could all agree on this, one must
   remember that we're looking at five existing protocols which have
   evolved to meet differing needs.  That means that a 'standard IPFIX'
   protocol will need to be one which vendors can migrate to gracefully,
   over some period of time.  

   To make progress on that standard, I hope we can
   * Reduce the number of protocols being considered, by eliminating
     any which clearly won't meet the requirements.
   * See whether some advocates could work together to merge their
     protocols together.

   After that we need to pick whichever of the existing protocols is
   the best fit to the requirements, and work on *small* modifications
   (e.g. supporting several different grades of reliability) to it.

For the Atlanta meeting, I trust we can reach consensus on the open
issues - allowing us to complete the requirements document - and make
some worthwhile progress on our protocol evaluation process.

Now I'll put my WG Co-chair hat back on, and look forward to seeing
you in Atlanta.

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 IMP: http://horde.org/imp/


--
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 Nov 15 15:19:36 2002
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 PAA18002
	for ; Fri, 15 Nov 2002 15:19:36 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18Cmjd-000729-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 15 Nov 2002 14:06:37 -0600
Received: from sj-msg-core-4.cisco.com ([171.71.163.54])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18Cmja-00071Y-00
	for ipfix@net.doit.wisc.edu; Fri, 15 Nov 2002 14:06:34 -0600
Received: from mira-sjc5-f.cisco.com (IDENT:mirapoint@mira-sjcd-1.cisco.com [171.69.43.44])
	by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gAFJwR5V021028;
	Fri, 15 Nov 2002 11:58:27 -0800 (PST)
Received: from cisco.com (dhcp-171-71-137-1.cisco.com [171.71.137.1])
	by mira-sjc5-f.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA)
	with ESMTP id ABU21312;
	Fri, 15 Nov 2002 11:59:31 -0800 (PST)
Message-ID: <3DD551E3.2F31CA39@cisco.com>
Date: Fri, 15 Nov 2002 11:58:27 -0800
From: Ganesh Sadasivan 
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: calato@riverstonenet.com
CC: Benoit Claise , Tal Givoly ,
        Jeff Meyer , carter@qosient.com,
        "'ipfixx'" 
Subject: Re: [ipfix] Multiple levels of Reliability and Directionality
References:  <3DD00105.C1F767EA@riverstonenet.com> <3DD4DB97.4080204@cisco.com> <3DD4F23A.2E67805@riverstonenet.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit



calato@riverstonenet.com wrote:

> Benoit Claise wrote:
> >
> > Paul,
> >
> > First of all, let me take back your initial email, for clarity
> > purposes
> >
> >         High   - Little to no data loss
> >         Medium - Minimal data loss is accepted
> >         Low    - Data sent is best effort
> >
> > The six combinations are shown below...
> >
> >                | Uni  |  Bi
> >         -------+------+---------
> >         High   |  1   |    4
> >         -------+------+--------
> >         Medium |  2   |    5
> >         -------+------+--------
> >         Low    |  3   |    6
> >
> > I think (IMHO) the most likely combinations are...
> >
> >         3. Low reliability and uni-directional. This will be used
> >            where the device and collector are in close proximity,
> >            there is high volume and some data loss is acceptable for
> >            the given application. Applications such as
> > Attack/Intrusion
> >            Detection Traffic Profiling, etc...
> >
> >         5. Bi-directional medium reliability. This will be used
> >            where high volume and increased reliability are needed.
> >            Applications
> >            such as Usage-based Accounting where 95th percentile
> > billing
> >            model is used. Or even Traffic Engineering where network
> >            policy decisions are based on the data collected.
> >
> >         4. Bi-directional high reliability would be used where the
> >            Usage-based Accounting application has strict requirements
> >            on data loss.
> >
> > I agree on 3, this is the minimum.
> >
> > I agree on 5 but I fear that the application level ACK will not always
> > be a possible solution from a router point of view. What if the router
> > exports so much flow records that it can't cache them while waiting
> > for the ACK.
> > So basically, resending the flow records is not always possible.
> > So, if you conclude that the requirement for 5 is the bidirectionality
> > with application level ACK, then this requirement is not always
> > possible!
>
>         Agreed. In very high volume deployments I would
>         use option #3.
>
> > IMHO, 5 could alos be
> >         2 with best-effort
> >         or 2 with a carefully designed network
>
>         If the customer can design their accounting network
>         in such away. But I'm not sure we want to require that.
>
>         Lets assume that aggregation is happening at
>         a reasonably high level (which drops the flow rate
>         to a manageable level). But the consequence is that
>         one lost record can be a huge chunk of missing data.
>
>         In this case reliability is the issue not the data
>         rate. I'm advocating a reliability option (note I said option)
>         as a way to solve this.
>
>
> >
> > Regarding 4, Randy replied already
> >
> >      > Somehow, the requirements discussion suffers from a split:
> >      > There are requirements resulting from the intention of
> >      > standardzing a highly reliable metering standard for
> >      precise
> >      > accounting (and billing). Differing from these are
> >      requirements
> >      > for a simpler metering standard more oriented at what I
> >      would
> >      > call "typical Internet reliability".
> >
> >       the original goal, which the iesg thinks was chartered,
> >      is the
> >      latter.
> >
>
>         There was a lot of push back by the group on that statement.
>         I asked for clarification but have not received any.

I feel the base line IPFIX protocol does require just 3 or 6. This would
provide the simplest and the most efficient means for all applications.
For those applications like billing with more stringent requirements,
why can't extensions be built on top of the base protocol as a higher
level application? By doing this we can cover the entire matrix.
There is a vast majority of apps that need just the 3.
and building a multi-level reliable scheme into the basre IPFIX protocol
would result in a less efficient use of the protocol for apps that really
don't care for this.

Thanks
Ganesh


>
>
>         Paul
>
> > > Let me see if we all agree on a couple things...
> > >
> > >         1. There is no such thing as partially uni-directional.
> > >         2. IPFIX ought to support a uni-directional mode of
> > > operation.
> > >
> > Agreed.
> >
> > Regards, Benoit.
> >
> > >
> > > Paul
> > >
> > > Tal Givoly wrote:
> > >
> > >
> > >> Jeff,
> > >>
> > >> I agree with you completely here - the protocol should focus on a
> > >> primarily
> > >> uni-directional feed from network/service elements
> > >> (metering+exporting
> > >> process) to collection process. Adding capabilities (such as
> > >> parameter
> > >> configuration, provisioning of other sorts, etc.) here is a
> > >> slippery slope.
> > >>
> > >> I would add, however, that the bi-directionality is needed both
> > >> for
> > >> assurance that messages are delivered as well as, IMHO, version,
> > >> capability
> > >> and template negotiation (which can be simplified as needed by
> > >> device).
> > >> Version and capability negotiation allows for forward/backward
> > >> interoperability and compatibility. Template negotiation allows
> > >> for more
> > >> efficient application-aware communication. As Peter explained
> > >> earlier
> > >> (http://ipfix.doit.wisc.edu/archive/1381.html - scenario #1 or
> > >> #2), it is
> > >> possible to have all these capabilities and have no impact on the
> > >> metering/export processes complexity - the complexity can be,
> > >> optionally,
> > >> added to the collection process (off the device) in order to allow
> > >> for
> > >> interoperability with multiple concurrent
> > >> versions/capabilities/templates in
> > >> the devices.
> > >>
> > >> Essentially, I believe we achieved consensus regarding the need
> > >> for template
> > >> capabilities to allow separation of the data model from the
> > >> protocol.
> > >> Version/capability negotiation are very useful for any protocol in
> > >> order to
> > >> increase its applicability and useful lifespan.
> > >>
> > >> Tal
> > >>
> > >> -----Original Message-----
> > >> From: Jeff Meyer [mailto:jeffm@cup.hp.com]
> > >> Sent: Monday, November 11, 2002 9:39 AM
> > >> To: calato@riverstonenet.com
> > >> Cc: Tal Givoly; carter@qosient.com; 'ipfixx'
> > >> Subject: Re: [ipfix] Multiple levels of Reliability and
> > >> Directionality
> > >>
> > >> OK, then based on this minimal definition of
> > >> bi-directional, I'm in complete agreement.
> > >>
> > >> It's the sliperry slope of other things one might
> > >> want to exchange once this two way channel is open,
> > >> which concerns me.  There are lots of things one
> > >> might want to exchange, but many of these are probably
> > >> better addressed by reusing existing protocols,
> > >> vs. stuffing into the IPFIX protocol.
> > >>
> > >> For example, controlling metering process is something
> > >> which can be separated out from IPFIX.  For example
> > >> by using SNMP and a MeterMIB.
> > >>
> > >> Just trying to apply the KISS (Keep it simple stupid)
> > >> principle.
> > >>
> > >> Regards,
> > >>
> > >>    Jeff Meyer
> > >>    hp
> > >>
> > >> calato@riverstonenet.com wrote:
> > >>
> > >>
> > >>
> > >> > Jeff Meyer wrote:
> > >> >
> > >> >
> > >> >
> > >> >>  Hi,
> > >> >>
> > >> >>    I agree with the aspect of varied reliability.
> > >> >>
> > >> >>    I am less clear on the need for bi-directional
> > >> >>  behavior.  The three scenarios you describe I
> > >> >>  agree with, but I'm not sure how the 2nd and
> > >> >>  3rd scenario as described have any dependence
> > >> >>  on bi-directional aside from the some level of
> > >> >>  application layer ack.
> > >> >>
> > >> >>
> > >> >>
> > >> >>
> > >> >       An application layer ACK all by itself makes the
> > >> >       protocol bi-directional.
> > >> >
> > >> >       Scenario #1 does not require the sender to also be a
> > >> > receiver.
> > >> >
> > >> >       Scenarios #2 & #3 do require the sender to also be a
> > >> >       receiver (even if only for ACK's).
> > >> >
> > >> >       Whether or not we decide to add other features in
> > >> >       scenarios #2 & #3 (such as field negotiation, capability
> > >> >       negotiation, etc...) is up to the WG. But they could
> > >> >       not be added to scenario #1.
> > >> >
> > >> >       Paul
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >>  Regards,
> > >> >>
> > >> >>    Jeff Meyer
> > >> >>
> > >> >>  Tal Givoly wrote:
> > >> >>
> > >> >>
> > >> >>
> > >> >>
> > >> >> > Paul,
> > >> >> >
> > >> >> > I agree completely - that captures the essense of the
> > >> >> > requirements. It
> > >> >> > allows balancing different application's need for different
> > >> >> > levels of
> > >> >> > reliability.
> > >> >> >
> > >> >> > Tal
> > >> >> >
> > >> >> > -----Original Message-----
> > >> >> > From: majordomo listserver [
> > >> >> > mailto:majordomo@mil.doit.wisc.edu]On Behalf
> > >> >> > Of Carter Bullard
> > >> >> > Sent: Thursday, November 07, 2002 8:40 AM
> > >> >> > To: calato@riverstonenet.com; 'ipfixx'
> > >> >> > Subject: RE: [ipfix] Multiple levels of Reliability and
> > >> >> > Directionality
> > >> >> >
> > >> >> >
> > >> >> > Hey Paul,
> > >> >> >  My 2 cents worth sez, absolutely yes!
> > >> >> > Carter
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> >>  -----Original Message-----
> > >> >> >>  From: majordomo listserver
> > >> >> >>  [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of
> > >> >> >>  calato@riverstonenet.com
> > >> >> >>  Sent: Thursday, November 07, 2002 9:46 AM
> > >> >> >>  To: ipfixx
> > >> >> >>  Subject: [ipfix] Multiple levels of Reliability and
> > >> >> >>  Directionality
> > >> >> >>
> > >> >> >>
> > >> >> >>
> > >> >> >>  Does IPFIX need to support multiple levels of reliability
> > >> >> >>  and directionality?
> > >> >> >>
> > >> >> >>  The applications IPFIX needs to support are quite varied
> > >> >> >>  and have differing needs in terms of reliability. Devices
> > >> >> >>  also have varying needs in terms of directionality.
> > >> >> >>
> > >> >> >>  I would like the WG to consider requirements on the protocol
> > >> >> >>  to support a tiered approach meet these needs.
> > >> >> >>
> > >> >> >>  Direction is either bi-directional or uni-directional. I've
> > >> >> >>  split
> > >> >> >>  reliability into 3 categories...
> > >> >> >>
> > >> >> >>        High   - Little to no data loss
> > >> >> >>        Medium - Minimal data loss is accepted
> > >> >> >>        Low    - Data sent is best effort
> > >> >> >>
> > >> >> >>
> > >> >> >>  The six combinations are shown below...
> > >> >> >>
> > >> >> >>
> > >> >> >>               | Uni  |  Bi
> > >> >> >>        -------+------+---------
> > >> >> >>        High   |  1   |    4
> > >> >> >>        -------+------+--------
> > >> >> >>        Medium |  2   |    5
> > >> >> >>        -------+------+--------
> > >> >> >>        Low    |  3   |    6
> > >> >> >>
> > >> >> >>
> > >> >> >>
> > >> >> >>  I think (IMHO) the most likely combinations are...
> > >> >> >>
> > >> >> >>        3. Low reliability and uni-directional. This will be
> > >> >> >>  used
> > >> >> >>           where the device and collector are in close
> > >> >> >>  proximity,
> > >> >> >>           there is high volume and some data loss is
> > >> >> >>  acceptable for
> > >> >> >>           the given application. Applications such as
> > >> >> >>  Attack/Intrusion Detection
> > >> >> >>           Traffic Profiling, etc...
> > >> >> >>
> > >> >> >>        5. Bi-directional medium reliability. This will be
> > >> >> >>  used
> > >> >> >>           where high volume and increased reliability are
> > >> >> >>  needed. Applications
> > >> >> >>           such as Usage-based Accounting where 95th
> > >> >> >>  percentile billing
> > >> >> >>           model is used. Or even Traffic Engineering where
> > >> >> >>  network policy
> > >> >> >>           decisions are based on the data collected.
> > >> >> >>
> > >> >> >>        4. Bi-directional high reliability would be used where
> > >> >> >>  the
> > >> >> >>           Usage-based Accounting application has strict
> > >> >> >>  requirements
> > >> >> >>           on data loss.
> > >> >> >>
> > >> >> >>  Does IPFIX need to support multiple levels of reliability
> > >> >> >>  and directionality?
> > >> >> >>
> > >> >> >>  Paul
> > >> >> >>
> > >> >> >>  --
> > >> >> >>  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/
> > >
> > >
>
> --
> 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 Nov 15 20:18:39 2002
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 UAA25731
	for ; Fri, 15 Nov 2002 20:18:38 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18CrSA-0006ha-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 15 Nov 2002 19:08:54 -0600
Received: from usmail.xacct.com ([204.253.100.12])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18CrS7-0006hN-00
	for ipfix-req@net.doit.wisc.edu; Fri, 15 Nov 2002 19:08:51 -0600
Received: from Givoly (inside.us.xacct.com [204.253.100.102])
	by usmail.xacct.com (8.11.2/8.11.2) with SMTP id gAG1CC215558;
	Fri, 15 Nov 2002 17:12:13 -0800
From: "Tal Givoly" 
To: "Reinaldo Penno" 
Cc: 
Subject: RE: [ipfix-req] IPFix Summary
Date: Fri, 15 Nov 2002 17:08:18 -0800
Message-ID: 
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0503_01C28CC9.9809A800"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <7B802811BE77D51189910002A55CFD2C045F0B93@zsc3c032.us.nortel.com>
X-RBL-Warning: (dnsbl.njabl.org) relay tested -- 1016746205
Precedence: bulk
Sender: majordomo listserver 

This is a multi-part message in MIME format.

------=_NextPart_000_0503_01C28CC9.9809A800
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

IPFix SummaryReinaldo,

Thanks for putting this all together and sorry for the late response.  I'll
try to address all the open issues you summarized below from my perspective
(including agreement's to advance consensus where appropriate) - comments
interspersed throughout this note  :
  -----Original Message-----
  From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf
Of Reinaldo Penno
  Sent: Sunday, October 27, 2002 2:31 PM
  To: ipfix-eval@net.doit.wisc.edu
  Cc: ipfix-req@net.doit.wisc.edu
  Subject: [ipfix-eval] IPFix Summary


  I burned a good chunk of my weekend trying to summarize our discussions.
If you think I didn't capture what was said adequately, please speak up.
This email does not substitute Juergen's on open issues, but is actually
trying to close some of those open issues. (Should I copy the main ipfix
list?)

  I revised most of the emails starting from Jeff Meyer's - "Discussion of
Candidate Protocols" on - 9/30.

  a)Regarding metering requirements and protocol candidates.

  There is consensus that the metering requirements should be N/A when
choosing the IPfix Export Protocol.

  A good summary was provided by Peter.

  * The protocol should cover only the issues of delivering data from the
exporter to the collector. It must be expressive

  enough to contain all the data defined in the data model.

  * The data model should cover the identification of the metrics and
attributes, their meanings, and how they are grouped

  together.

  * The architecture should cover issues such as where data are observed,
what data are required and what are optional, when

  reliability is needed, how the data can be manipulated (e.g., calculating
bandwidth), etc., etc.
  [Tal Givoly] Agreed.

  b) Regarding reliability



     - Congestion awareness.

  It is covered on the requirements draft
  [Tal Givoly] Agreed.

     - Message ordering (critical when the data spans several packets, e.g.
variable length fields)

  It seems there is consensus that message ordering is important.
  [Tal Givoly] Agreed.

     - Transport reliability -

  There is some confusion around this problem since transport reliability is
*not* explicit mentioned in the reqs draft, but

  since congestion awareness is, some people take it for granted.
  [Tal Givoly] I believe we should make explicit whether a transport such as
TCP or SCTP is mandatory or not - that issue has yet to be resolved.
Obviously, one of the candidate protocols (namely NetFlow) is still based on
UDP - is that a permitted mode of operation of the protocol or is that not?
We need to resolve this issue.

     - require application-level ACKs in the protocol (SHOULD be after
       data are persisted)

  There is consensus that application layer ACKs is important
  [Tal Givoly] Agreed.

     - require enable de-duplication of received records through a unique
key

  There is consensus that de-duplication is important.
  [Tal Givoly] Agreed.

     - Exporter should keep track of number of flow records + some important
totals
       and and periodically communicate this information to the
       collector.

  There is consensus that this or some other solution to capture the
  amount of lost *flow records for each key/field* (not packets) is
important
  [Tal Givoly]

  I agree in principal (there will always be situations where data can be
lost because of extended network outages, buffer overflows, insufficient
CPU, etc.),  but it is difficult to assume that all devices will be able to
report specific information without considerable sacrifice. So, rather than
having something that cannot be properly implemented, I would rather see
this issue refined as part of the data model.


  c) Regarding High-Availability

  we should have the ability to send to multiple collectors and for the
  exporter to be able to switch from one collector to another.
  [Tal Givoly] Agreed.

  d) Regarding Timestamps

  New text for section 5.4 (Disclaimer before somebody goes for my neck:
this affects the
  architecture/requirements, not the protocol evaluation.)



     The metering process MUST be able to generate wire-line timestamps
     (rather then flow cache timestamps) for the first and the last
     observed packet of a flow. The timestamp resolution MUST be at least
     the one of the sysUpTime [RFC1213], which is one centisecond.

  [Tal Givoly] Agreed.

  e) Regarding the Views on the Problem

  Some people advocate that exporting IP flows has nothing unique to it,
it's well known problem
  only with a different data model. I hope I captured this right. Anyway,
here it goes a quotation.

  "However, the statement that IP flow is somehow unique
  in its data requirements and as such a more generalized
  "data mover" is somehow problematic, is just plain wrong."
  [Tal Givoly] Agreed.

  f) Regarding the Field Experience of IPDR

  Some people wanted more information on this, so I'm pasting an email
  from Aron Heintz [aheintz@ipdr.org]. Any more in-depth information please
direct your
  questions to Jeff Meyer [jeffm@cup.hp.com] or Aron Heitz.
  [Tal Givoly] Feedback regarding this item shall be provided on a separate
thread.


  Thanks again for pulling all this together.

  Tal

------=_NextPart_000_0503_01C28CC9.9809A800
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


IPFix Summary




Reinaldo,


 


Thanks for putting this =
all together=20
and sorry for the late response.  I'll try to =
address all=20
the open issues you summarized below=20
from my perspective (including =
agreement's to advance consensus =
where appropriate)=20
- comments interspersed throughout this note  :


  
-----Original Message-----
From: majordomo =
listserver=20
  [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of Reinaldo=20
  Penno
Sent: Sunday, October 27, 2002 2:31 PM
To:=20
  ipfix-eval@net.doit.wisc.edu
Cc:=20
  ipfix-req@net.doit.wisc.edu
Subject: [ipfix-eval] IPFix=20
  Summary


  
I burned a good chunk of my weekend trying to =
summarize our=20
  discussions. If you think I didn't capture what was said adequately, =
please=20
  speak up. This email does not substitute Juergen's on open issues, but =
is=20
  actually trying to close some of those open issues. (Should I copy the =
main=20
  ipfix list?)

  
I revised most of the emails starting from Jeff =
Meyer's -=20
  "Discussion of Candidate Protocols" on - 9/30. 

  
a)Regarding metering requirements and protocol=20
  candidates. 

  
There is consensus that the metering requirements =
should be=20
  N/A when choosing the IPfix Export Protocol. 

  
A good summary was provided by Peter. 

  
* The protocol should cover only the issues of =
delivering data=20
  from the exporter to the collector. It must be expressive 

  
enough to contain all the data defined in the data =
model.=20
  

  
* The data model should cover the identification of =
the=20
  metrics and attributes, their meanings, and how they are grouped =


  
together. 

  
* The architecture should cover issues such as where =
data are=20
  observed, what data are required and what are optional, when =


  
reliability is needed, how the data can be =
manipulated (e.g.,=20
  calculating bandwidth), etc., etc. 
[Tal=20
  Givoly] Agreed. 

  
b) Regarding reliability 


  
   - Congestion awareness. 

  
It is covered on the requirements draft =

[Tal=20
  Givoly] Agreed. 

  
   - Message ordering (critical when the =
data spans=20
  several packets, e.g. variable length fields) 

  
It seems there is consensus that message ordering is =

  important. 
[Tal =
Givoly] Agreed. 

  
   - Transport reliability - 

  
There is some confusion around this problem since =
transport=20
  reliability is *not* explicit mentioned in the reqs draft, but =


  
since congestion awareness is, some people take it =
for=20
  granted. 
[Tal Givoly] I believe we should make explicit =
whether=20
  a transport such as TCP or SCTP is mandatory or not - that =
issue has=20
  yet to be resolved. Obviously, one of the candidate protocols =
(namely=20
  NetFlow) is still based on UDP - is that a permitted mode of =
operation of=20
  the protocol or is that not? We need to resolve this=20
  issue. 

  
   - require application-level ACKs in the =
protocol=20
  (SHOULD be after 
     =
data are=20
  persisted) 

  
There is consensus that application layer ACKs is=20
  important 
[Tal =
Givoly] Agreed. 

  
   - require enable de-duplication of =
received=20
  records through a unique key 

  
There is consensus that de-duplication is =
important.=20
  
[Tal=20
  Givoly] Agreed. 

  
   - Exporter should keep track of number =
of flow=20
  records + some important totals 
     and and periodically communicate =
this=20
  information to the 
    =20
  collector. 

  
There is consensus that this or some other solution =
to capture=20
  the 
amount of lost *flow records for each =
key/field*=20
  (not packets) is important 
[Tal =
Givoly] 

  
I=20
  agree in principal (there will always be situations where data can be =
lost=20
  because of extended network outages, buffer overflows, insufficient =
CPU,=20
  etc.),  but=20
  it is difficult to assume that all devices will be able to report =
specific=20
  information without considerable sacrifice. So, rather than having =
something=20
  that cannot be properly implemented, I would rather see this issue =
refined as=20
  part of the data model.


  
c) Regarding High-Availability 

  
we should have the ability to send to multiple =
collectors and=20
  for the 
exporter to be able to switch from =
one=20
  collector to another. 
[Tal=20
  Givoly] Agreed. 

  
d) Regarding Timestamps 

  
New text for section 5.4 (Disclaimer before somebody =
goes for=20
  my neck: this affects the 
architecture/requirements,=20
  not the protocol evaluation.) 


  
   The metering process MUST be able to =
generate=20
  wire-line timestamps 
   (rather =
then flow=20
  cache timestamps) for the first and the last 
   observed packet of a flow. The timestamp =
resolution MUST=20
  be at least 
   the one of the =
sysUpTime=20
  [RFC1213], which is one centisecond. 
[Tal=20
  Givoly] Agreed. 

  
e) Regarding the Views on the Problem 

  
Some people advocate that exporting IP flows has =
nothing=20
  unique to it, it's well known problem 
only =
with a=20
  different data model. I hope I captured this right. Anyway, here it =
goes a=20
  quotation. 

  
"However, the statement that IP flow is somehow =
unique=20
  
in its data requirements and as such a more=20
  generalized 
"data mover" is somehow =
problematic, is=20
  just plain wrong." 
[Tal =
Givoly] Agreed. 

  
f) Regarding the Field Experience of IPDR =


  
Some people wanted more information on this, so I'm =
pasting an=20
  email 
from Aron Heintz [aheintz@ipdr.org]. =
Any more=20
  in-depth information please direct your 
questions to=20
  Jeff Meyer [jeffm@cup.hp.com] or Aron Heitz. 
[Tal Givoly] Feedback regarding this =
item shall=20
  be provided on a separate thread.

  

Thanks again for pulling all =
this together.

  
 

  
Tal
=


------=_NextPart_000_0503_01C28CC9.9809A800--


--
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  Sat Nov 16 00:43:08 2002
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 AAA01302
	for ; Sat, 16 Nov 2002 00:43:08 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18Cvbx-00058X-00
	for ipfix-list@mil.doit.wisc.edu; Fri, 15 Nov 2002 23:35:17 -0600
Received: from usmail.xacct.com ([204.253.100.12])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18Cvbv-00058Q-00
	for ipfix@net.doit.wisc.edu; Fri, 15 Nov 2002 23:35:15 -0600
Received: from Givoly ([192.168.0.2])
	by usmail.xacct.com (8.11.2/8.11.2) with SMTP id gAG5co217712;
	Fri, 15 Nov 2002 21:38:51 -0800
From: "Tal Givoly" 
To: "Ganesh Sadasivan" 
Cc: "'ipfixx'" 
Subject: RE: [ipfix] Multiple levels of Reliability and Directionality
Date: Fri, 15 Nov 2002 21:34:57 -0800
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <3DD551E3.2F31CA39@cisco.com>
X-RBL-Warning: (dnsbl.njabl.org) relay tested -- 1016746205
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

Ganesh,

Obviously, this doesn't do justice to the requirements of many applications.
There is no dispute that there is a set of applications that would be
satisfied with level 3 or 6. However, flow export is also being used, and
there is a desire to expand its usage, for applications mentioned in the
charter that require that require higher levels of reliability. Most of our
many customers are seeking better interfaces down-to-the-device level. I can
refer you to many use cases and justifications of this position that
appeared in many previous posts.

Tal

-----Original Message-----
From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com]
Sent: Friday, November 15, 2002 11:58 AM
To: calato@riverstonenet.com
Cc: Benoit Claise; Tal Givoly; Jeff Meyer; carter@qosient.com; 'ipfixx'
Subject: Re: [ipfix] Multiple levels of Reliability and Directionality




calato@riverstonenet.com wrote:

> Benoit Claise wrote:
> >
> > Paul,
> >
> > First of all, let me take back your initial email, for clarity
> > purposes
> >
> >         High   - Little to no data loss
> >         Medium - Minimal data loss is accepted
> >         Low    - Data sent is best effort
> >
> > The six combinations are shown below...
> >
> >                | Uni  |  Bi
> >         -------+------+---------
> >         High   |  1   |    4
> >         -------+------+--------
> >         Medium |  2   |    5
> >         -------+------+--------
> >         Low    |  3   |    6
> >
> > I think (IMHO) the most likely combinations are...
> >
> >         3. Low reliability and uni-directional. This will be used
> >            where the device and collector are in close proximity,
> >            there is high volume and some data loss is acceptable for
> >            the given application. Applications such as
> > Attack/Intrusion
> >            Detection Traffic Profiling, etc...
> >
> >         5. Bi-directional medium reliability. This will be used
> >            where high volume and increased reliability are needed.
> >            Applications
> >            such as Usage-based Accounting where 95th percentile
> > billing
> >            model is used. Or even Traffic Engineering where network
> >            policy decisions are based on the data collected.
> >
> >         4. Bi-directional high reliability would be used where the
> >            Usage-based Accounting application has strict requirements
> >            on data loss.
> >
> > I agree on 3, this is the minimum.
> >
> > I agree on 5 but I fear that the application level ACK will not always
> > be a possible solution from a router point of view. What if the router
> > exports so much flow records that it can't cache them while waiting
> > for the ACK.
> > So basically, resending the flow records is not always possible.
> > So, if you conclude that the requirement for 5 is the bidirectionality
> > with application level ACK, then this requirement is not always
> > possible!
>
>         Agreed. In very high volume deployments I would
>         use option #3.
>
> > IMHO, 5 could alos be
> >         2 with best-effort
> >         or 2 with a carefully designed network
>
>         If the customer can design their accounting network
>         in such away. But I'm not sure we want to require that.
>
>         Lets assume that aggregation is happening at
>         a reasonably high level (which drops the flow rate
>         to a manageable level). But the consequence is that
>         one lost record can be a huge chunk of missing data.
>
>         In this case reliability is the issue not the data
>         rate. I'm advocating a reliability option (note I said option)
>         as a way to solve this.
>
>
> >
> > Regarding 4, Randy replied already
> >
> >      > Somehow, the requirements discussion suffers from a split:
> >      > There are requirements resulting from the intention of
> >      > standardzing a highly reliable metering standard for
> >      precise
> >      > accounting (and billing). Differing from these are
> >      requirements
> >      > for a simpler metering standard more oriented at what I
> >      would
> >      > call "typical Internet reliability".
> >
> >       the original goal, which the iesg thinks was chartered,
> >      is the
> >      latter.
> >
>
>         There was a lot of push back by the group on that statement.
>         I asked for clarification but have not received any.

I feel the base line IPFIX protocol does require just 3 or 6. This would
provide the simplest and the most efficient means for all applications.
For those applications like billing with more stringent requirements,
why can't extensions be built on top of the base protocol as a higher
level application? By doing this we can cover the entire matrix.
There is a vast majority of apps that need just the 3.
and building a multi-level reliable scheme into the basre IPFIX protocol
would result in a less efficient use of the protocol for apps that really
don't care for this.

Thanks
Ganesh


>
>
>         Paul
>
> > > Let me see if we all agree on a couple things...
> > >
> > >         1. There is no such thing as partially uni-directional.
> > >         2. IPFIX ought to support a uni-directional mode of
> > > operation.
> > >
> > Agreed.
> >
> > Regards, Benoit.
> >
> > >
> > > Paul
> > >
> > > Tal Givoly wrote:
> > >
> > >
> > >> Jeff,
> > >>
> > >> I agree with you completely here - the protocol should focus on a
> > >> primarily
> > >> uni-directional feed from network/service elements
> > >> (metering+exporting
> > >> process) to collection process. Adding capabilities (such as
> > >> parameter
> > >> configuration, provisioning of other sorts, etc.) here is a
> > >> slippery slope.
> > >>
> > >> I would add, however, that the bi-directionality is needed both
> > >> for
> > >> assurance that messages are delivered as well as, IMHO, version,
> > >> capability
> > >> and template negotiation (which can be simplified as needed by
> > >> device).
> > >> Version and capability negotiation allows for forward/backward
> > >> interoperability and compatibility. Template negotiation allows
> > >> for more
> > >> efficient application-aware communication. As Peter explained
> > >> earlier
> > >> (http://ipfix.doit.wisc.edu/archive/1381.html - scenario #1 or
> > >> #2), it is
> > >> possible to have all these capabilities and have no impact on the
> > >> metering/export processes complexity - the complexity can be,
> > >> optionally,
> > >> added to the collection process (off the device) in order to allow
> > >> for
> > >> interoperability with multiple concurrent
> > >> versions/capabilities/templates in
> > >> the devices.
> > >>
> > >> Essentially, I believe we achieved consensus regarding the need
> > >> for template
> > >> capabilities to allow separation of the data model from the
> > >> protocol.
> > >> Version/capability negotiation are very useful for any protocol in
> > >> order to
> > >> increase its applicability and useful lifespan.
> > >>
> > >> Tal
> > >>
> > >> -----Original Message-----
> > >> From: Jeff Meyer [mailto:jeffm@cup.hp.com]
> > >> Sent: Monday, November 11, 2002 9:39 AM
> > >> To: calato@riverstonenet.com
> > >> Cc: Tal Givoly; carter@qosient.com; 'ipfixx'
> > >> Subject: Re: [ipfix] Multiple levels of Reliability and
> > >> Directionality
> > >>
> > >> OK, then based on this minimal definition of
> > >> bi-directional, I'm in complete agreement.
> > >>
> > >> It's the sliperry slope of other things one might
> > >> want to exchange once this two way channel is open,
> > >> which concerns me.  There are lots of things one
> > >> might want to exchange, but many of these are probably
> > >> better addressed by reusing existing protocols,
> > >> vs. stuffing into the IPFIX protocol.
> > >>
> > >> For example, controlling metering process is something
> > >> which can be separated out from IPFIX.  For example
> > >> by using SNMP and a MeterMIB.
> > >>
> > >> Just trying to apply the KISS (Keep it simple stupid)
> > >> principle.
> > >>
> > >> Regards,
> > >>
> > >>    Jeff Meyer
> > >>    hp
> > >>
> > >> calato@riverstonenet.com wrote:
> > >>
> > >>
> > >>
> > >> > Jeff Meyer wrote:
> > >> >
> > >> >
> > >> >
> > >> >>  Hi,
> > >> >>
> > >> >>    I agree with the aspect of varied reliability.
> > >> >>
> > >> >>    I am less clear on the need for bi-directional
> > >> >>  behavior.  The three scenarios you describe I
> > >> >>  agree with, but I'm not sure how the 2nd and
> > >> >>  3rd scenario as described have any dependence
> > >> >>  on bi-directional aside from the some level of
> > >> >>  application layer ack.
> > >> >>
> > >> >>
> > >> >>
> > >> >>
> > >> >       An application layer ACK all by itself makes the
> > >> >       protocol bi-directional.
> > >> >
> > >> >       Scenario #1 does not require the sender to also be a
> > >> > receiver.
> > >> >
> > >> >       Scenarios #2 & #3 do require the sender to also be a
> > >> >       receiver (even if only for ACK's).
> > >> >
> > >> >       Whether or not we decide to add other features in
> > >> >       scenarios #2 & #3 (such as field negotiation, capability
> > >> >       negotiation, etc...) is up to the WG. But they could
> > >> >       not be added to scenario #1.
> > >> >
> > >> >       Paul
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >>  Regards,
> > >> >>
> > >> >>    Jeff Meyer
> > >> >>
> > >> >>  Tal Givoly wrote:
> > >> >>
> > >> >>
> > >> >>
> > >> >>
> > >> >> > Paul,
> > >> >> >
> > >> >> > I agree completely - that captures the essense of the
> > >> >> > requirements. It
> > >> >> > allows balancing different application's need for different
> > >> >> > levels of
> > >> >> > reliability.
> > >> >> >
> > >> >> > Tal
> > >> >> >
> > >> >> > -----Original Message-----
> > >> >> > From: majordomo listserver [
> > >> >> > mailto:majordomo@mil.doit.wisc.edu]On Behalf
> > >> >> > Of Carter Bullard
> > >> >> > Sent: Thursday, November 07, 2002 8:40 AM
> > >> >> > To: calato@riverstonenet.com; 'ipfixx'
> > >> >> > Subject: RE: [ipfix] Multiple levels of Reliability and
> > >> >> > Directionality
> > >> >> >
> > >> >> >
> > >> >> > Hey Paul,
> > >> >> >  My 2 cents worth sez, absolutely yes!
> > >> >> > Carter
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> >>  -----Original Message-----
> > >> >> >>  From: majordomo listserver
> > >> >> >>  [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of
> > >> >> >>  calato@riverstonenet.com
> > >> >> >>  Sent: Thursday, November 07, 2002 9:46 AM
> > >> >> >>  To: ipfixx
> > >> >> >>  Subject: [ipfix] Multiple levels of Reliability and
> > >> >> >>  Directionality
> > >> >> >>
> > >> >> >>
> > >> >> >>
> > >> >> >>  Does IPFIX need to support multiple levels of reliability
> > >> >> >>  and directionality?
> > >> >> >>
> > >> >> >>  The applications IPFIX needs to support are quite varied
> > >> >> >>  and have differing needs in terms of reliability. Devices
> > >> >> >>  also have varying needs in terms of directionality.
> > >> >> >>
> > >> >> >>  I would like the WG to consider requirements on the protocol
> > >> >> >>  to support a tiered approach meet these needs.
> > >> >> >>
> > >> >> >>  Direction is either bi-directional or uni-directional. I've
> > >> >> >>  split
> > >> >> >>  reliability into 3 categories...
> > >> >> >>
> > >> >> >>        High   - Little to no data loss
> > >> >> >>        Medium - Minimal data loss is accepted
> > >> >> >>        Low    - Data sent is best effort
> > >> >> >>
> > >> >> >>
> > >> >> >>  The six combinations are shown below...
> > >> >> >>
> > >> >> >>
> > >> >> >>               | Uni  |  Bi
> > >> >> >>        -------+------+---------
> > >> >> >>        High   |  1   |    4
> > >> >> >>        -------+------+--------
> > >> >> >>        Medium |  2   |    5
> > >> >> >>        -------+------+--------
> > >> >> >>        Low    |  3   |    6
> > >> >> >>
> > >> >> >>
> > >> >> >>
> > >> >> >>  I think (IMHO) the most likely combinations are...
> > >> >> >>
> > >> >> >>        3. Low reliability and uni-directional. This will be
> > >> >> >>  used
> > >> >> >>           where the device and collector are in close
> > >> >> >>  proximity,
> > >> >> >>           there is high volume and some data loss is
> > >> >> >>  acceptable for
> > >> >> >>           the given application. Applications such as
> > >> >> >>  Attack/Intrusion Detection
> > >> >> >>           Traffic Profiling, etc...
> > >> >> >>
> > >> >> >>        5. Bi-directional medium reliability. This will be
> > >> >> >>  used
> > >> >> >>           where high volume and increased reliability are
> > >> >> >>  needed. Applications
> > >> >> >>           such as Usage-based Accounting where 95th
> > >> >> >>  percentile billing
> > >> >> >>           model is used. Or even Traffic Engineering where
> > >> >> >>  network policy
> > >> >> >>           decisions are based on the data collected.
> > >> >> >>
> > >> >> >>        4. Bi-directional high reliability would be used where
> > >> >> >>  the
> > >> >> >>           Usage-based Accounting application has strict
> > >> >> >>  requirements
> > >> >> >>           on data loss.
> > >> >> >>
> > >> >> >>  Does IPFIX need to support multiple levels of reliability
> > >> >> >>  and directionality?
> > >> >> >>
> > >> >> >>  Paul
> > >> >> >>
> > >> >> >>  --
> > >> >> >>  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/
> > >
> > >
>
> --
> 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  Sun Nov 17 14:41:06 2002
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 OAA24090
	for ; Sun, 17 Nov 2002 14:41:05 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18DV8n-0000jm-00
	for ipfix-list@mil.doit.wisc.edu; Sun, 17 Nov 2002 13:31:33 -0600
Received: from [212.150.80.243] (helo=mailslide.airslide.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18DV8m-0000jW-00
	for ipfix-eval@net.doit.wisc.edu; Sun, 17 Nov 2002 13:31:32 -0600
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="windows-1255"
Subject: [ipfix-eval] Real-World Experience with CRANE Protocol
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Date: Sun, 17 Nov 2002 21:31:26 +0200
Message-ID: <0A6928AA2509EC4CAAC63C01A377988B33BF46@mailslide.airslide.com>
Thread-Topic: Real-World Experience with CRANE Protocol
Thread-Index: AcKOb+naP5uB3IsHRbegbtv9I5B5zw==
From: "Ronen Megged" 
To: 
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA24090

Hi,

I would like to share my views and experience on one of the protocols being reviewed by the IPFIX subgroup at IETF.

As a background, our platform provides intelligent signaling services to wireless carriers' networks.

Our platform requires the ability to export complex flow information that is related to short messages (SMS). The exported information is of high value to the carriers and therefore the carriers require fault tolerance in the interface between the operation and business support systems and our platform.

After an extensive evaluation of all available options, we decided to implement CRANE because it is the only solution that matched virtually all our requirements. Those requirements were:

- Reliability - ability to deploy redundant receivers and ensure that no records are lost due to network connectivity or receiver failure.
- Real-time - we needed delivery of the data within carrier's pre-determined configuration parameters. Typically, in the order of 500ms.
- Performance/scalability - we needed to export over 3,000 records per second from our device (one or two records are generated for every message/flow)
- Minimal impact on device - a critical function of our device is the ability to handle the messages/flows based on sophisticated policies. Impact must be minimal, both in case of normal processing, as well as in case of network/collector overload or failure.
- Proven technology - we wanted to adopt a technology with minimal risk with field proven deployments.

I realize that this is not a 100% match to the IPFIX requirements; however, we believe that carrier-grade reliability and scalability for flow-level granularity or aggregates thereof, is a crucial requirement for service providers. We believe that adopting a protocol with field-proven deployments in such environments has benefits. We were pleased to see that the overhead of achieving this reliability was minimal on our device and was well appreciated by our customers.

Ronen Megged
Director, Product Marketing
Airslide Systems
Tel: +972 9 970 9874
Cell: +972 54 416 463
Email: ronen.megged@airslide.com
Web: www.airslide.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  Mon Nov 18 09:48:00 2002
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 JAA22365
	for ; Mon, 18 Nov 2002 09:47:59 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18Dmx1-0005z7-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 18 Nov 2002 08:32:35 -0600
Received: from sj-msg-core-1.cisco.com ([171.71.163.11])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18Dmwz-0005y5-00
	for ipfix@net.doit.wisc.edu; Mon, 18 Nov 2002 08:32:33 -0600
Received: from mira-sjc5-f.cisco.com (IDENT:mirapoint@mira-sjcd-1.cisco.com [171.69.43.44])
	by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAIEW0Nf012001;
	Mon, 18 Nov 2002 06:32:00 -0800 (PST)
Received: from cisco.com (sjc-vpn3-514.cisco.com [10.21.66.2])
	by mira-sjc5-f.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA)
	with ESMTP id ABU66218;
	Mon, 18 Nov 2002 06:33:03 -0800 (PST)
Message-ID: <3DD8F9DD.8263A199@cisco.com>
Date: Mon, 18 Nov 2002 06:31:57 -0800
From: Ganesh Sadasivan 
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Tal Givoly 
CC: "'ipfixx'" 
Subject: Re: [ipfix] Multiple levels of Reliability and Directionality
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

Tal,


Tal Givoly wrote:

> Ganesh,
>
> Obviously, this doesn't do justice to the requirements of many applications.
> There is no dispute that there is a set of applications that would be
> satisfied with level 3 or 6. However, flow export is also being used, and
> there is a desire to expand its usage, for applications mentioned in the
> charter that require that require higher levels of reliability. Most of our

By doing this we are penalising the large set of existing  of application using
flow export were requirement is just a 3 or 6. BTW when I refer to 6,
I meant "ACK mechanism which covers like a summary of lost packets" and
not "application level ACK mechanism".
The number of apps that are and would be using this export mechanism is large and

their requirements are widely varying. Rather than addressing in detail the
need for each of the current set of application, it is better to keep a simple
infrastructure
and let the applications with more strict requirements build their own mechanism
on top of this infrastructure.

Thanks
Ganesh

> many customers are seeking better interfaces down-to-the-device level. I can
> refer you to many use cases and justifications of this position that
> appeared in many previous posts.

>
>
> Tal
>
> -----Original Message-----
> From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com]
> Sent: Friday, November 15, 2002 11:58 AM
> To: calato@riverstonenet.com
> Cc: Benoit Claise; Tal Givoly; Jeff Meyer; carter@qosient.com; 'ipfixx'
> Subject: Re: [ipfix] Multiple levels of Reliability and Directionality
>
> calato@riverstonenet.com wrote:
>
> > Benoit Claise wrote:
> > >
> > > Paul,
> > >
> > > First of all, let me take back your initial email, for clarity
> > > purposes
> > >
> > >         High   - Little to no data loss
> > >         Medium - Minimal data loss is accepted
> > >         Low    - Data sent is best effort
> > >
> > > The six combinations are shown below...
> > >
> > >                | Uni  |  Bi
> > >         -------+------+---------
> > >         High   |  1   |    4
> > >         -------+------+--------
> > >         Medium |  2   |    5
> > >         -------+------+--------
> > >         Low    |  3   |    6
> > >
> > > I think (IMHO) the most likely combinations are...
> > >
> > >         3. Low reliability and uni-directional. This will be used
> > >            where the device and collector are in close proximity,
> > >            there is high volume and some data loss is acceptable for
> > >            the given application. Applications such as
> > > Attack/Intrusion
> > >            Detection Traffic Profiling, etc...
> > >
> > >         5. Bi-directional medium reliability. This will be used
> > >            where high volume and increased reliability are needed.
> > >            Applications
> > >            such as Usage-based Accounting where 95th percentile
> > > billing
> > >            model is used. Or even Traffic Engineering where network
> > >            policy decisions are based on the data collected.
> > >
> > >         4. Bi-directional high reliability would be used where the
> > >            Usage-based Accounting application has strict requirements
> > >            on data loss.
> > >
> > > I agree on 3, this is the minimum.
> > >
> > > I agree on 5 but I fear that the application level ACK will not always
> > > be a possible solution from a router point of view. What if the router
> > > exports so much flow records that it can't cache them while waiting
> > > for the ACK.
> > > So basically, resending the flow records is not always possible.
> > > So, if you conclude that the requirement for 5 is the bidirectionality
> > > with application level ACK, then this requirement is not always
> > > possible!
> >
> >         Agreed. In very high volume deployments I would
> >         use option #3.
> >
> > > IMHO, 5 could alos be
> > >         2 with best-effort
> > >         or 2 with a carefully designed network
> >
> >         If the customer can design their accounting network
> >         in such away. But I'm not sure we want to require that.
> >
> >         Lets assume that aggregation is happening at
> >         a reasonably high level (which drops the flow rate
> >         to a manageable level). But the consequence is that
> >         one lost record can be a huge chunk of missing data.
> >
> >         In this case reliability is the issue not the data
> >         rate. I'm advocating a reliability option (note I said option)
> >         as a way to solve this.
> >
> >
> > >
> > > Regarding 4, Randy replied already
> > >
> > >      > Somehow, the requirements discussion suffers from a split:
> > >      > There are requirements resulting from the intention of
> > >      > standardzing a highly reliable metering standard for
> > >      precise
> > >      > accounting (and billing). Differing from these are
> > >      requirements
> > >      > for a simpler metering standard more oriented at what I
> > >      would
> > >      > call "typical Internet reliability".
> > >
> > >       the original goal, which the iesg thinks was chartered,
> > >      is the
> > >      latter.
> > >
> >
> >         There was a lot of push back by the group on that statement.
> >         I asked for clarification but have not received any.
>
> I feel the base line IPFIX protocol does require just 3 or 6. This would
> provide the simplest and the most efficient means for all applications.
> For those applications like billing with more stringent requirements,
> why can't extensions be built on top of the base protocol as a higher
> level application? By doing this we can cover the entire matrix.
> There is a vast majority of apps that need just the 3.
> and building a multi-level reliable scheme into the basre IPFIX protocol
> would result in a less efficient use of the protocol for apps that really
> don't care for this.
>
> Thanks
> Ganesh
>
> >
> >
> >         Paul
> >
> > > > Let me see if we all agree on a couple things...
> > > >
> > > >         1. There is no such thing as partially uni-directional.
> > > >         2. IPFIX ought to support a uni-directional mode of
> > > > operation.
> > > >
> > > Agreed.
> > >
> > > Regards, Benoit.
> > >
> > > >
> > > > Paul
> > > >
> > > > Tal Givoly wrote:
> > > >
> > > >
> > > >> Jeff,
> > > >>
> > > >> I agree with you completely here - the protocol should focus on a
> > > >> primarily
> > > >> uni-directional feed from network/service elements
> > > >> (metering+exporting
> > > >> process) to collection process. Adding capabilities (such as
> > > >> parameter
> > > >> configuration, provisioning of other sorts, etc.) here is a
> > > >> slippery slope.
> > > >>
> > > >> I would add, however, that the bi-directionality is needed both
> > > >> for
> > > >> assurance that messages are delivered as well as, IMHO, version,
> > > >> capability
> > > >> and template negotiation (which can be simplified as needed by
> > > >> device).
> > > >> Version and capability negotiation allows for forward/backward
> > > >> interoperability and compatibility. Template negotiation allows
> > > >> for more
> > > >> efficient application-aware communication. As Peter explained
> > > >> earlier
> > > >> (http://ipfix.doit.wisc.edu/archive/1381.html - scenario #1 or
> > > >> #2), it is
> > > >> possible to have all these capabilities and have no impact on the
> > > >> metering/export processes complexity - the complexity can be,
> > > >> optionally,
> > > >> added to the collection process (off the device) in order to allow
> > > >> for
> > > >> interoperability with multiple concurrent
> > > >> versions/capabilities/templates in
> > > >> the devices.
> > > >>
> > > >> Essentially, I believe we achieved consensus regarding the need
> > > >> for template
> > > >> capabilities to allow separation of the data model from the
> > > >> protocol.
> > > >> Version/capability negotiation are very useful for any protocol in
> > > >> order to
> > > >> increase its applicability and useful lifespan.
> > > >>
> > > >> Tal
> > > >>
> > > >> -----Original Message-----
> > > >> From: Jeff Meyer [mailto:jeffm@cup.hp.com]
> > > >> Sent: Monday, November 11, 2002 9:39 AM
> > > >> To: calato@riverstonenet.com
> > > >> Cc: Tal Givoly; carter@qosient.com; 'ipfixx'
> > > >> Subject: Re: [ipfix] Multiple levels of Reliability and
> > > >> Directionality
> > > >>
> > > >> OK, then based on this minimal definition of
> > > >> bi-directional, I'm in complete agreement.
> > > >>
> > > >> It's the sliperry slope of other things one might
> > > >> want to exchange once this two way channel is open,
> > > >> which concerns me.  There are lots of things one
> > > >> might want to exchange, but many of these are probably
> > > >> better addressed by reusing existing protocols,
> > > >> vs. stuffing into the IPFIX protocol.
> > > >>
> > > >> For example, controlling metering process is something
> > > >> which can be separated out from IPFIX.  For example
> > > >> by using SNMP and a MeterMIB.
> > > >>
> > > >> Just trying to apply the KISS (Keep it simple stupid)
> > > >> principle.
> > > >>
> > > >> Regards,
> > > >>
> > > >>    Jeff Meyer
> > > >>    hp
> > > >>
> > > >> calato@riverstonenet.com wrote:
> > > >>
> > > >>
> > > >>
> > > >> > Jeff Meyer wrote:
> > > >> >
> > > >> >
> > > >> >
> > > >> >>  Hi,
> > > >> >>
> > > >> >>    I agree with the aspect of varied reliability.
> > > >> >>
> > > >> >>    I am less clear on the need for bi-directional
> > > >> >>  behavior.  The three scenarios you describe I
> > > >> >>  agree with, but I'm not sure how the 2nd and
> > > >> >>  3rd scenario as described have any dependence
> > > >> >>  on bi-directional aside from the some level of
> > > >> >>  application layer ack.
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >       An application layer ACK all by itself makes the
> > > >> >       protocol bi-directional.
> > > >> >
> > > >> >       Scenario #1 does not require the sender to also be a
> > > >> > receiver.
> > > >> >
> > > >> >       Scenarios #2 & #3 do require the sender to also be a
> > > >> >       receiver (even if only for ACK's).
> > > >> >
> > > >> >       Whether or not we decide to add other features in
> > > >> >       scenarios #2 & #3 (such as field negotiation, capability
> > > >> >       negotiation, etc...) is up to the WG. But they could
> > > >> >       not be added to scenario #1.
> > > >> >
> > > >> >       Paul
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> >>  Regards,
> > > >> >>
> > > >> >>    Jeff Meyer
> > > >> >>
> > > >> >>  Tal Givoly wrote:
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >> > Paul,
> > > >> >> >
> > > >> >> > I agree completely - that captures the essense of the
> > > >> >> > requirements. It
> > > >> >> > allows balancing different application's need for different
> > > >> >> > levels of
> > > >> >> > reliability.
> > > >> >> >
> > > >> >> > Tal
> > > >> >> >
> > > >> >> > -----Original Message-----
> > > >> >> > From: majordomo listserver [
> > > >> >> > mailto:majordomo@mil.doit.wisc.edu]On Behalf
> > > >> >> > Of Carter Bullard
> > > >> >> > Sent: Thursday, November 07, 2002 8:40 AM
> > > >> >> > To: calato@riverstonenet.com; 'ipfixx'
> > > >> >> > Subject: RE: [ipfix] Multiple levels of Reliability and
> > > >> >> > Directionality
> > > >> >> >
> > > >> >> >
> > > >> >> > Hey Paul,
> > > >> >> >  My 2 cents worth sez, absolutely yes!
> > > >> >> > Carter
> > > >> >> >
> > > >> >> >
> > > >> >> >
> > > >> >> >
> > > >> >> >
> > > >> >> >>  -----Original Message-----
> > > >> >> >>  From: majordomo listserver
> > > >> >> >>  [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of
> > > >> >> >>  calato@riverstonenet.com
> > > >> >> >>  Sent: Thursday, November 07, 2002 9:46 AM
> > > >> >> >>  To: ipfixx
> > > >> >> >>  Subject: [ipfix] Multiple levels of Reliability and
> > > >> >> >>  Directionality
> > > >> >> >>
> > > >> >> >>
> > > >> >> >>
> > > >> >> >>  Does IPFIX need to support multiple levels of reliability
> > > >> >> >>  and directionality?
> > > >> >> >>
> > > >> >> >>  The applications IPFIX needs to support are quite varied
> > > >> >> >>  and have differing needs in terms of reliability. Devices
> > > >> >> >>  also have varying needs in terms of directionality.
> > > >> >> >>
> > > >> >> >>  I would like the WG to consider requirements on the protocol
> > > >> >> >>  to support a tiered approach meet these needs.
> > > >> >> >>
> > > >> >> >>  Direction is either bi-directional or uni-directional. I've
> > > >> >> >>  split
> > > >> >> >>  reliability into 3 categories...
> > > >> >> >>
> > > >> >> >>        High   - Little to no data loss
> > > >> >> >>        Medium - Minimal data loss is accepted
> > > >> >> >>        Low    - Data sent is best effort
> > > >> >> >>
> > > >> >> >>
> > > >> >> >>  The six combinations are shown below...
> > > >> >> >>
> > > >> >> >>
> > > >> >> >>               | Uni  |  Bi
> > > >> >> >>        -------+------+---------
> > > >> >> >>        High   |  1   |    4
> > > >> >> >>        -------+------+--------
> > > >> >> >>        Medium |  2   |    5
> > > >> >> >>        -------+------+--------
> > > >> >> >>        Low    |  3   |    6
> > > >> >> >>
> > > >> >> >>
> > > >> >> >>
> > > >> >> >>  I think (IMHO) the most likely combinations are...
> > > >> >> >>
> > > >> >> >>        3. Low reliability and uni-directional. This will be
> > > >> >> >>  used
> > > >> >> >>           where the device and collector are in close
> > > >> >> >>  proximity,
> > > >> >> >>           there is high volume and some data loss is
> > > >> >> >>  acceptable for
> > > >> >> >>           the given application. Applications such as
> > > >> >> >>  Attack/Intrusion Detection
> > > >> >> >>           Traffic Profiling, etc...
> > > >> >> >>
> > > >> >> >>        5. Bi-directional medium reliability. This will be
> > > >> >> >>  used
> > > >> >> >>           where high volume and increased reliability are
> > > >> >> >>  needed. Applications
> > > >> >> >>           such as Usage-based Accounting where 95th
> > > >> >> >>  percentile billing
> > > >> >> >>           model is used. Or even Traffic Engineering where
> > > >> >> >>  network policy
> > > >> >> >>           decisions are based on the data collected.
> > > >> >> >>
> > > >> >> >>        4. Bi-directional high reliability would be used where
> > > >> >> >>  the
> > > >> >> >>           Usage-based Accounting application has strict
> > > >> >> >>  requirements
> > > >> >> >>           on data loss.
> > > >> >> >>
> > > >> >> >>  Does IPFIX need to support multiple levels of reliability
> > > >> >> >>  and directionality?
> > > >> >> >>
> > > >> >> >>  Paul
> > > >> >> >>
> > > >> >> >>  --
> > > >> >> >>  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/
> > > >
> > > >
> >
> > --
> > 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 Nov 18 12:04:20 2002
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 MAA26642
	for ; Mon, 18 Nov 2002 12:04:20 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18Dp9B-0001mU-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 18 Nov 2002 10:53:17 -0600
Received: from usmail.xacct.com ([204.253.100.12])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18Dp98-0001lO-00
	for ipfix@net.doit.wisc.edu; Mon, 18 Nov 2002 10:53:14 -0600
Received: from Givoly ([192.168.0.2])
	by usmail.xacct.com (8.11.2/8.11.2) with SMTP id gAIGcU214572;
	Mon, 18 Nov 2002 08:38:33 -0800
From: "Tal Givoly" 
To: "Ganesh Sadasivan" 
Cc: "'ipfixx'" 
Subject: RE: [ipfix] Multiple levels of Reliability and Directionality
Date: Mon, 18 Nov 2002 08:34:34 -0800
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <3DD8F9DD.8263A199@cisco.com>
X-RBL-Warning: (dnsbl.njabl.org) relay tested -- 1016746205
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

Ganesh,

There is a middle ground here: multiple LEVELS/DEGREES of reliability which
are different modes of operation of the protocol. Depending on the exporter
and collector set of capabilities, they can negotiate or predefine that they
will operate in a specific mode. This way, some devices, under some
circumstances (for instance, high-speed flow export) may not support the
reliability capabilities. While at other situations, they may support
reliable exports due to the lower volume, high-value aggregate information
they are exporting. If footprint of implementation within device is
extremely constrained, they may have a subset of the capabilities
altogether.

This can be done without undue encumbrance on the device while permitting
cost-effective deployments for applications requiring more reliability.

This is also one of the reasons minimal, exporter-overridden, negotiation
capabilities are very useful. That would allow seamless interoperability
between collectors and exporters with varying degrees of capabilities and
interests in data.

Note that this is exactly the way faxes/modems knew how to interoperate and
spawned a huge industry as a result of such standardization leading to
seamless interopability.

Tal

-----Original Message-----
From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com]
Sent: Monday, November 18, 2002 6:32 AM
To: Tal Givoly
Cc: 'ipfixx'
Subject: Re: [ipfix] Multiple levels of Reliability and Directionality


Tal,


Tal Givoly wrote:

> Ganesh,
>
> Obviously, this doesn't do justice to the requirements of many
applications.
> There is no dispute that there is a set of applications that would be
> satisfied with level 3 or 6. However, flow export is also being used, and
> there is a desire to expand its usage, for applications mentioned in the
> charter that require that require higher levels of reliability. Most of
our

By doing this we are penalising the large set of existing  of application
using
flow export were requirement is just a 3 or 6. BTW when I refer to 6,
I meant "ACK mechanism which covers like a summary of lost packets" and
not "application level ACK mechanism".
The number of apps that are and would be using this export mechanism is
large and

their requirements are widely varying. Rather than addressing in detail the
need for each of the current set of application, it is better to keep a
simple
infrastructure
and let the applications with more strict requirements build their own
mechanism
on top of this infrastructure.

Thanks
Ganesh

> many customers are seeking better interfaces down-to-the-device level. I
can
> refer you to many use cases and justifications of this position that
> appeared in many previous posts.

>
>
> Tal
>
> -----Original Message-----
> From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com]
> Sent: Friday, November 15, 2002 11:58 AM
> To: calato@riverstonenet.com
> Cc: Benoit Claise; Tal Givoly; Jeff Meyer; carter@qosient.com; 'ipfixx'
> Subject: Re: [ipfix] Multiple levels of Reliability and Directionality
>
> calato@riverstonenet.com wrote:
>
> > Benoit Claise wrote:
> > >
> > > Paul,
> > >
> > > First of all, let me take back your initial email, for clarity
> > > purposes
> > >
> > >         High   - Little to no data loss
> > >         Medium - Minimal data loss is accepted
> > >         Low    - Data sent is best effort
> > >
> > > The six combinations are shown below...
> > >
> > >                | Uni  |  Bi
> > >         -------+------+---------
> > >         High   |  1   |    4
> > >         -------+------+--------
> > >         Medium |  2   |    5
> > >         -------+------+--------
> > >         Low    |  3   |    6
> > >
> > > I think (IMHO) the most likely combinations are...
> > >
> > >         3. Low reliability and uni-directional. This will be used
> > >            where the device and collector are in close proximity,
> > >            there is high volume and some data loss is acceptable for
> > >            the given application. Applications such as
> > > Attack/Intrusion
> > >            Detection Traffic Profiling, etc...
> > >
> > >         5. Bi-directional medium reliability. This will be used
> > >            where high volume and increased reliability are needed.
> > >            Applications
> > >            such as Usage-based Accounting where 95th percentile
> > > billing
> > >            model is used. Or even Traffic Engineering where network
> > >            policy decisions are based on the data collected.
> > >
> > >         4. Bi-directional high reliability would be used where the
> > >            Usage-based Accounting application has strict requirements
> > >            on data loss.
> > >
> > > I agree on 3, this is the minimum.
> > >
> > > I agree on 5 but I fear that the application level ACK will not always
> > > be a possible solution from a router point of view. What if the router
> > > exports so much flow records that it can't cache them while waiting
> > > for the ACK.
> > > So basically, resending the flow records is not always possible.
> > > So, if you conclude that the requirement for 5 is the bidirectionality
> > > with application level ACK, then this requirement is not always
> > > possible!
> >
> >         Agreed. In very high volume deployments I would
> >         use option #3.
> >
> > > IMHO, 5 could alos be
> > >         2 with best-effort
> > >         or 2 with a carefully designed network
> >
> >         If the customer can design their accounting network
> >         in such away. But I'm not sure we want to require that.
> >
> >         Lets assume that aggregation is happening at
> >         a reasonably high level (which drops the flow rate
> >         to a manageable level). But the consequence is that
> >         one lost record can be a huge chunk of missing data.
> >
> >         In this case reliability is the issue not the data
> >         rate. I'm advocating a reliability option (note I said option)
> >         as a way to solve this.
> >
> >
> > >
> > > Regarding 4, Randy replied already
> > >
> > >      > Somehow, the requirements discussion suffers from a split:
> > >      > There are requirements resulting from the intention of
> > >      > standardzing a highly reliable metering standard for
> > >      precise
> > >      > accounting (and billing). Differing from these are
> > >      requirements
> > >      > for a simpler metering standard more oriented at what I
> > >      would
> > >      > call "typical Internet reliability".
> > >
> > >       the original goal, which the iesg thinks was chartered,
> > >      is the
> > >      latter.
> > >
> >
> >         There was a lot of push back by the group on that statement.
> >         I asked for clarification but have not received any.
>
> I feel the base line IPFIX protocol does require just 3 or 6. This would
> provide the simplest and the most efficient means for all applications.
> For those applications like billing with more stringent requirements,
> why can't extensions be built on top of the base protocol as a higher
> level application? By doing this we can cover the entire matrix.
> There is a vast majority of apps that need just the 3.
> and building a multi-level reliable scheme into the basre IPFIX protocol
> would result in a less efficient use of the protocol for apps that really
> don't care for this.
>
> Thanks
> Ganesh
>
> >
> >
> >         Paul
> >
> > > > Let me see if we all agree on a couple things...
> > > >
> > > >         1. There is no such thing as partially uni-directional.
> > > >         2. IPFIX ought to support a uni-directional mode of
> > > > operation.
> > > >
> > > Agreed.
> > >
> > > Regards, Benoit.
> > >
> > > >
> > > > Paul
> > > >
> > > > Tal Givoly wrote:
> > > >
> > > >
> > > >> Jeff,
> > > >>
> > > >> I agree with you completely here - the protocol should focus on a
> > > >> primarily
> > > >> uni-directional feed from network/service elements
> > > >> (metering+exporting
> > > >> process) to collection process. Adding capabilities (such as
> > > >> parameter
> > > >> configuration, provisioning of other sorts, etc.) here is a
> > > >> slippery slope.
> > > >>
> > > >> I would add, however, that the bi-directionality is needed both
> > > >> for
> > > >> assurance that messages are delivered as well as, IMHO, version,
> > > >> capability
> > > >> and template negotiation (which can be simplified as needed by
> > > >> device).
> > > >> Version and capability negotiation allows for forward/backward
> > > >> interoperability and compatibility. Template negotiation allows
> > > >> for more
> > > >> efficient application-aware communication. As Peter explained
> > > >> earlier
> > > >> (http://ipfix.doit.wisc.edu/archive/1381.html - scenario #1 or
> > > >> #2), it is
> > > >> possible to have all these capabilities and have no impact on the
> > > >> metering/export processes complexity - the complexity can be,
> > > >> optionally,
> > > >> added to the collection process (off the device) in order to allow
> > > >> for
> > > >> interoperability with multiple concurrent
> > > >> versions/capabilities/templates in
> > > >> the devices.
> > > >>
> > > >> Essentially, I believe we achieved consensus regarding the need
> > > >> for template
> > > >> capabilities to allow separation of the data model from the
> > > >> protocol.
> > > >> Version/capability negotiation are very useful for any protocol in
> > > >> order to
> > > >> increase its applicability and useful lifespan.
> > > >>
> > > >> Tal
> > > >>
> > > >> -----Original Message-----
> > > >> From: Jeff Meyer [mailto:jeffm@cup.hp.com]
> > > >> Sent: Monday, November 11, 2002 9:39 AM
> > > >> To: calato@riverstonenet.com
> > > >> Cc: Tal Givoly; carter@qosient.com; 'ipfixx'
> > > >> Subject: Re: [ipfix] Multiple levels of Reliability and
> > > >> Directionality
> > > >>
> > > >> OK, then based on this minimal definition of
> > > >> bi-directional, I'm in complete agreement.
> > > >>
> > > >> It's the sliperry slope of other things one might
> > > >> want to exchange once this two way channel is open,
> > > >> which concerns me.  There are lots of things one
> > > >> might want to exchange, but many of these are probably
> > > >> better addressed by reusing existing protocols,
> > > >> vs. stuffing into the IPFIX protocol.
> > > >>
> > > >> For example, controlling metering process is something
> > > >> which can be separated out from IPFIX.  For example
> > > >> by using SNMP and a MeterMIB.
> > > >>
> > > >> Just trying to apply the KISS (Keep it simple stupid)
> > > >> principle.
> > > >>
> > > >> Regards,
> > > >>
> > > >>    Jeff Meyer
> > > >>    hp
> > > >>
> > > >> calato@riverstonenet.com wrote:
> > > >>
> > > >>
> > > >>
> > > >> > Jeff Meyer wrote:
> > > >> >
> > > >> >
> > > >> >
> > > >> >>  Hi,
> > > >> >>
> > > >> >>    I agree with the aspect of varied reliability.
> > > >> >>
> > > >> >>    I am less clear on the need for bi-directional
> > > >> >>  behavior.  The three scenarios you describe I
> > > >> >>  agree with, but I'm not sure how the 2nd and
> > > >> >>  3rd scenario as described have any dependence
> > > >> >>  on bi-directional aside from the some level of
> > > >> >>  application layer ack.
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >       An application layer ACK all by itself makes the
> > > >> >       protocol bi-directional.
> > > >> >
> > > >> >       Scenario #1 does not require the sender to also be a
> > > >> > receiver.
> > > >> >
> > > >> >       Scenarios #2 & #3 do require the sender to also be a
> > > >> >       receiver (even if only for ACK's).
> > > >> >
> > > >> >       Whether or not we decide to add other features in
> > > >> >       scenarios #2 & #3 (such as field negotiation, capability
> > > >> >       negotiation, etc...) is up to the WG. But they could
> > > >> >       not be added to scenario #1.
> > > >> >
> > > >> >       Paul
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> >>  Regards,
> > > >> >>
> > > >> >>    Jeff Meyer
> > > >> >>
> > > >> >>  Tal Givoly wrote:
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >> > Paul,
> > > >> >> >
> > > >> >> > I agree completely - that captures the essense of the
> > > >> >> > requirements. It
> > > >> >> > allows balancing different application's need for different
> > > >> >> > levels of
> > > >> >> > reliability.
> > > >> >> >
> > > >> >> > Tal
> > > >> >> >
> > > >> >> > -----Original Message-----
> > > >> >> > From: majordomo listserver [
> > > >> >> > mailto:majordomo@mil.doit.wisc.edu]On Behalf
> > > >> >> > Of Carter Bullard
> > > >> >> > Sent: Thursday, November 07, 2002 8:40 AM
> > > >> >> > To: calato@riverstonenet.com; 'ipfixx'
> > > >> >> > Subject: RE: [ipfix] Multiple levels of Reliability and
> > > >> >> > Directionality
> > > >> >> >
> > > >> >> >
> > > >> >> > Hey Paul,
> > > >> >> >  My 2 cents worth sez, absolutely yes!
> > > >> >> > Carter
> > > >> >> >
> > > >> >> >
> > > >> >> >
> > > >> >> >
> > > >> >> >
> > > >> >> >>  -----Original Message-----
> > > >> >> >>  From: majordomo listserver
> > > >> >> >>  [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of
> > > >> >> >>  calato@riverstonenet.com
> > > >> >> >>  Sent: Thursday, November 07, 2002 9:46 AM
> > > >> >> >>  To: ipfixx
> > > >> >> >>  Subject: [ipfix] Multiple levels of Reliability and
> > > >> >> >>  Directionality
> > > >> >> >>
> > > >> >> >>
> > > >> >> >>
> > > >> >> >>  Does IPFIX need to support multiple levels of reliability
> > > >> >> >>  and directionality?
> > > >> >> >>
> > > >> >> >>  The applications IPFIX needs to support are quite varied
> > > >> >> >>  and have differing needs in terms of reliability. Devices
> > > >> >> >>  also have varying needs in terms of directionality.
> > > >> >> >>
> > > >> >> >>  I would like the WG to consider requirements on the protocol
> > > >> >> >>  to support a tiered approach meet these needs.
> > > >> >> >>
> > > >> >> >>  Direction is either bi-directional or uni-directional. I've
> > > >> >> >>  split
> > > >> >> >>  reliability into 3 categories...
> > > >> >> >>
> > > >> >> >>        High   - Little to no data loss
> > > >> >> >>        Medium - Minimal data loss is accepted
> > > >> >> >>        Low    - Data sent is best effort
> > > >> >> >>
> > > >> >> >>
> > > >> >> >>  The six combinations are shown below...
> > > >> >> >>
> > > >> >> >>
> > > >> >> >>               | Uni  |  Bi
> > > >> >> >>        -------+------+---------
> > > >> >> >>        High   |  1   |    4
> > > >> >> >>        -------+------+--------
> > > >> >> >>        Medium |  2   |    5
> > > >> >> >>        -------+------+--------
> > > >> >> >>        Low    |  3   |    6
> > > >> >> >>
> > > >> >> >>
> > > >> >> >>
> > > >> >> >>  I think (IMHO) the most likely combinations are...
> > > >> >> >>
> > > >> >> >>        3. Low reliability and uni-directional. This will be
> > > >> >> >>  used
> > > >> >> >>           where the device and collector are in close
> > > >> >> >>  proximity,
> > > >> >> >>           there is high volume and some data loss is
> > > >> >> >>  acceptable for
> > > >> >> >>           the given application. Applications such as
> > > >> >> >>  Attack/Intrusion Detection
> > > >> >> >>           Traffic Profiling, etc...
> > > >> >> >>
> > > >> >> >>        5. Bi-directional medium reliability. This will be
> > > >> >> >>  used
> > > >> >> >>           where high volume and increased reliability are
> > > >> >> >>  needed. Applications
> > > >> >> >>           such as Usage-based Accounting where 95th
> > > >> >> >>  percentile billing
> > > >> >> >>           model is used. Or even Traffic Engineering where
> > > >> >> >>  network policy
> > > >> >> >>           decisions are based on the data collected.
> > > >> >> >>
> > > >> >> >>        4. Bi-directional high reliability would be used where
> > > >> >> >>  the
> > > >> >> >>           Usage-based Accounting application has strict
> > > >> >> >>  requirements
> > > >> >> >>           on data loss.
> > > >> >> >>
> > > >> >> >>  Does IPFIX need to support multiple levels of reliability
> > > >> >> >>  and directionality?
> > > >> >> >>
> > > >> >> >>  Paul
> > > >> >> >>
> > > >> >> >>  --
> > > >> >> >>  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/
> > > >
> > > >
> >
> > --
> > 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 Nov 18 14:04:02 2002
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 OAA00113
	for ; Mon, 18 Nov 2002 14:04:02 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18Dr1P-0004r0-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 18 Nov 2002 12:53:23 -0600
Received: from sj-msg-core-4.cisco.com ([171.71.163.54])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18Dr1L-0004m5-00
	for ipfix@net.doit.wisc.edu; Mon, 18 Nov 2002 12:53:19 -0600
Received: from mira-sjc5-f.cisco.com (IDENT:mirapoint@mira-sjcd-1.cisco.com [171.69.43.44])
	by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gAIIqm5V015694;
	Mon, 18 Nov 2002 10:52:49 -0800 (PST)
Received: from cisco.com (dhcp-171-71-137-63.cisco.com [171.71.137.63])
	by mira-sjc5-f.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA)
	with ESMTP id ABU74926;
	Mon, 18 Nov 2002 10:53:39 -0800 (PST)
Message-ID: <3DD936F1.8750F42C@cisco.com>
Date: Mon, 18 Nov 2002 10:52:33 -0800
From: Ganesh Sadasivan 
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Tal Givoly 
CC: "'ipfixx'" 
Subject: Re: [ipfix] Multiple levels of Reliability and Directionality
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

Tal,

   There has been discussion at length in the mailing list and IETF session as
to why
   we should refrain from  going with capability negotiation in IPFIX protocol.
See
   my response to Peter on this topic:
   http://ipfx.doit.wisc.edu/list/ipfix/archive/0753.html
   Though in theory this idea sounds fine the complexity of this feature when
trying
   to generalize for a framework like IPFIX is high. This was one of the main
reasons for
   dropping this feature off the IPFIX protocol.

Thanks
Ganesh

Tal Givoly wrote:

> Ganesh,
>
> There is a middle ground here: multiple LEVELS/DEGREES of reliability which
> are different modes of operation of the protocol. Depending on the exporter
> and collector set of capabilities, they can negotiate or predefine that they
> will operate in a specific mode. This way, some devices, under some
> circumstances (for instance, high-speed flow export) may not support the
> reliability capabilities. While at other situations, they may support
> reliable exports due to the lower volume, high-value aggregate information
> they are exporting. If footprint of implementation within device is
> extremely constrained, they may have a subset of the capabilities
> altogether.
>
> This can be done without undue encumbrance on the device while permitting
> cost-effective deployments for applications requiring more reliability.
>
> This is also one of the reasons minimal, exporter-overridden, negotiation
> capabilities are very useful. That would allow seamless interoperability
> between collectors and exporters with varying degrees of capabilities and
> interests in data.
>
> Note that this is exactly the way faxes/modems knew how to interoperate and
> spawned a huge industry as a result of such standardization leading to
> seamless interopability.
>
> Tal
>
> -----Original Message-----
> From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com]
> Sent: Monday, November 18, 2002 6:32 AM
> To: Tal Givoly
> Cc: 'ipfixx'
> Subject: Re: [ipfix] Multiple levels of Reliability and Directionality
>
> Tal,
>
> Tal Givoly wrote:
>
> > Ganesh,
> >
> > Obviously, this doesn't do justice to the requirements of many
> applications.
> > There is no dispute that there is a set of applications that would be
> > satisfied with level 3 or 6. However, flow export is also being used, and
> > there is a desire to expand its usage, for applications mentioned in the
> > charter that require that require higher levels of reliability. Most of
> our
>
> By doing this we are penalising the large set of existing  of application
> using
> flow export were requirement is just a 3 or 6. BTW when I refer to 6,
> I meant "ACK mechanism which covers like a summary of lost packets" and
> not "application level ACK mechanism".
> The number of apps that are and would be using this export mechanism is
> large and
>
> their requirements are widely varying. Rather than addressing in detail the
> need for each of the current set of application, it is better to keep a
> simple
> infrastructure
> and let the applications with more strict requirements build their own
> mechanism
> on top of this infrastructure.
>
> Thanks
> Ganesh
>
> > many customers are seeking better interfaces down-to-the-device level. I
> can
> > refer you to many use cases and justifications of this position that
> > appeared in many previous posts.
>
> >
> >
> > Tal
> >
> > -----Original Message-----
> > From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com]
> > Sent: Friday, November 15, 2002 11:58 AM
> > To: calato@riverstonenet.com
> > Cc: Benoit Claise; Tal Givoly; Jeff Meyer; carter@qosient.com; 'ipfixx'
> > Subject: Re: [ipfix] Multiple levels of Reliability and Directionality
> >
> > calato@riverstonenet.com wrote:
> >
> > > Benoit Claise wrote:
> > > >
> > > > Paul,
> > > >
> > > > First of all, let me take back your initial email, for clarity
> > > > purposes
> > > >
> > > >         High   - Little to no data loss
> > > >         Medium - Minimal data loss is accepted
> > > >         Low    - Data sent is best effort
> > > >
> > > > The six combinations are shown below...
> > > >
> > > >                | Uni  |  Bi
> > > >         -------+------+---------
> > > >         High   |  1   |    4
> > > >         -------+------+--------
> > > >         Medium |  2   |    5
> > > >         -------+------+--------
> > > >         Low    |  3   |    6
> > > >
> > > > I think (IMHO) the most likely combinations are...
> > > >
> > > >         3. Low reliability and uni-directional. This will be used
> > > >            where the device and collector are in close proximity,
> > > >            there is high volume and some data loss is acceptable for
> > > >            the given application. Applications such as
> > > > Attack/Intrusion
> > > >            Detection Traffic Profiling, etc...
> > > >
> > > >         5. Bi-directional medium reliability. This will be used
> > > >            where high volume and increased reliability are needed.
> > > >            Applications
> > > >            such as Usage-based Accounting where 95th percentile
> > > > billing
> > > >            model is used. Or even Traffic Engineering where network
> > > >            policy decisions are based on the data collected.
> > > >
> > > >         4. Bi-directional high reliability would be used where the
> > > >            Usage-based Accounting application has strict requirements
> > > >            on data loss.
> > > >
> > > > I agree on 3, this is the minimum.
> > > >
> > > > I agree on 5 but I fear that the application level ACK will not always
> > > > be a possible solution from a router point of view. What if the router
> > > > exports so much flow records that it can't cache them while waiting
> > > > for the ACK.
> > > > So basically, resending the flow records is not always possible.
> > > > So, if you conclude that the requirement for 5 is the bidirectionality
> > > > with application level ACK, then this requirement is not always
> > > > possible!
> > >
> > >         Agreed. In very high volume deployments I would
> > >         use option #3.
> > >
> > > > IMHO, 5 could alos be
> > > >         2 with best-effort
> > > >         or 2 with a carefully designed network
> > >
> > >         If the customer can design their accounting network
> > >         in such away. But I'm not sure we want to require that.
> > >
> > >         Lets assume that aggregation is happening at
> > >         a reasonably high level (which drops the flow rate
> > >         to a manageable level). But the consequence is that
> > >         one lost record can be a huge chunk of missing data.
> > >
> > >         In this case reliability is the issue not the data
> > >         rate. I'm advocating a reliability option (note I said option)
> > >         as a way to solve this.
> > >
> > >
> > > >
> > > > Regarding 4, Randy replied already
> > > >
> > > >      > Somehow, the requirements discussion suffers from a split:
> > > >      > There are requirements resulting from the intention of
> > > >      > standardzing a highly reliable metering standard for
> > > >      precise
> > > >      > accounting (and billing). Differing from these are
> > > >      requirements
> > > >      > for a simpler metering standard more oriented at what I
> > > >      would
> > > >      > call "typical Internet reliability".
> > > >
> > > >       the original goal, which the iesg thinks was chartered,
> > > >      is the
> > > >      latter.
> > > >
> > >
> > >         There was a lot of push back by the group on that statement.
> > >         I asked for clarification but have not received any.
> >
> > I feel the base line IPFIX protocol does require just 3 or 6. This would
> > provide the simplest and the most efficient means for all applications.
> > For those applications like billing with more stringent requirements,
> > why can't extensions be built on top of the base protocol as a higher
> > level application? By doing this we can cover the entire matrix.
> > There is a vast majority of apps that need just the 3.
> > and building a multi-level reliable scheme into the basre IPFIX protocol
> > would result in a less efficient use of the protocol for apps that really
> > don't care for this.
> >
> > Thanks
> > Ganesh
> >
> > >
> > >
> > >         Paul
> > >
> > > > > Let me see if we all agree on a couple things...
> > > > >
> > > > >         1. There is no such thing as partially uni-directional.
> > > > >         2. IPFIX ought to support a uni-directional mode of
> > > > > operation.
> > > > >
> > > > Agreed.
> > > >
> > > > Regards, Benoit.
> > > >
> > > > >
> > > > > Paul
> > > > >
> > > > > Tal Givoly wrote:
> > > > >
> > > > >
> > > > >> Jeff,
> > > > >>
> > > > >> I agree with you completely here - the protocol should focus on a
> > > > >> primarily
> > > > >> uni-directional feed from network/service elements
> > > > >> (metering+exporting
> > > > >> process) to collection process. Adding capabilities (such as
> > > > >> parameter
> > > > >> configuration, provisioning of other sorts, etc.) here is a
> > > > >> slippery slope.
> > > > >>
> > > > >> I would add, however, that the bi-directionality is needed both
> > > > >> for
> > > > >> assurance that messages are delivered as well as, IMHO, version,
> > > > >> capability
> > > > >> and template negotiation (which can be simplified as needed by
> > > > >> device).
> > > > >> Version and capability negotiation allows for forward/backward
> > > > >> interoperability and compatibility. Template negotiation allows
> > > > >> for more
> > > > >> efficient application-aware communication. As Peter explained
> > > > >> earlier
> > > > >> (http://ipfix.doit.wisc.edu/archive/1381.html - scenario #1 or
> > > > >> #2), it is
> > > > >> possible to have all these capabilities and have no impact on the
> > > > >> metering/export processes complexity - the complexity can be,
> > > > >> optionally,
> > > > >> added to the collection process (off the device) in order to allow
> > > > >> for
> > > > >> interoperability with multiple concurrent
> > > > >> versions/capabilities/templates in
> > > > >> the devices.
> > > > >>
> > > > >> Essentially, I believe we achieved consensus regarding the need
> > > > >> for template
> > > > >> capabilities to allow separation of the data model from the
> > > > >> protocol.
> > > > >> Version/capability negotiation are very useful for any protocol in
> > > > >> order to
> > > > >> increase its applicability and useful lifespan.
> > > > >>
> > > > >> Tal
> > > > >>
> > > > >> -----Original Message-----
> > > > >> From: Jeff Meyer [mailto:jeffm@cup.hp.com]
> > > > >> Sent: Monday, November 11, 2002 9:39 AM
> > > > >> To: calato@riverstonenet.com
> > > > >> Cc: Tal Givoly; carter@qosient.com; 'ipfixx'
> > > > >> Subject: Re: [ipfix] Multiple levels of Reliability and
> > > > >> Directionality
> > > > >>
> > > > >> OK, then based on this minimal definition of
> > > > >> bi-directional, I'm in complete agreement.
> > > > >>
> > > > >> It's the sliperry slope of other things one might
> > > > >> want to exchange once this two way channel is open,
> > > > >> which concerns me.  There are lots of things one
> > > > >> might want to exchange, but many of these are probably
> > > > >> better addressed by reusing existing protocols,
> > > > >> vs. stuffing into the IPFIX protocol.
> > > > >>
> > > > >> For example, controlling metering process is something
> > > > >> which can be separated out from IPFIX.  For example
> > > > >> by using SNMP and a MeterMIB.
> > > > >>
> > > > >> Just trying to apply the KISS (Keep it simple stupid)
> > > > >> principle.
> > > > >>
> > > > >> Regards,
> > > > >>
> > > > >>    Jeff Meyer
> > > > >>    hp
> > > > >>
> > > > >> calato@riverstonenet.com wrote:
> > > > >>
> > > > >>
> > > > >>
> > > > >> > Jeff Meyer wrote:
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> >>  Hi,
> > > > >> >>
> > > > >> >>    I agree with the aspect of varied reliability.
> > > > >> >>
> > > > >> >>    I am less clear on the need for bi-directional
> > > > >> >>  behavior.  The three scenarios you describe I
> > > > >> >>  agree with, but I'm not sure how the 2nd and
> > > > >> >>  3rd scenario as described have any dependence
> > > > >> >>  on bi-directional aside from the some level of
> > > > >> >>  application layer ack.
> > > > >> >>
> > > > >> >>
> > > > >> >>
> > > > >> >>
> > > > >> >       An application layer ACK all by itself makes the
> > > > >> >       protocol bi-directional.
> > > > >> >
> > > > >> >       Scenario #1 does not require the sender to also be a
> > > > >> > receiver.
> > > > >> >
> > > > >> >       Scenarios #2 & #3 do require the sender to also be a
> > > > >> >       receiver (even if only for ACK's).
> > > > >> >
> > > > >> >       Whether or not we decide to add other features in
> > > > >> >       scenarios #2 & #3 (such as field negotiation, capability
> > > > >> >       negotiation, etc...) is up to the WG. But they could
> > > > >> >       not be added to scenario #1.
> > > > >> >
> > > > >> >       Paul
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> >>  Regards,
> > > > >> >>
> > > > >> >>    Jeff Meyer
> > > > >> >>
> > > > >> >>  Tal Givoly wrote:
> > > > >> >>
> > > > >> >>
> > > > >> >>
> > > > >> >>
> > > > >> >> > Paul,
> > > > >> >> >
> > > > >> >> > I agree completely - that captures the essense of the
> > > > >> >> > requirements. It
> > > > >> >> > allows balancing different application's need for different
> > > > >> >> > levels of
> > > > >> >> > reliability.
> > > > >> >> >
> > > > >> >> > Tal
> > > > >> >> >
> > > > >> >> > -----Original Message-----
> > > > >> >> > From: majordomo listserver [
> > > > >> >> > mailto:majordomo@mil.doit.wisc.edu]On Behalf
> > > > >> >> > Of Carter Bullard
> > > > >> >> > Sent: Thursday, November 07, 2002 8:40 AM
> > > > >> >> > To: calato@riverstonenet.com; 'ipfixx'
> > > > >> >> > Subject: RE: [ipfix] Multiple levels of Reliability and
> > > > >> >> > Directionality
> > > > >> >> >
> > > > >> >> >
> > > > >> >> > Hey Paul,
> > > > >> >> >  My 2 cents worth sez, absolutely yes!
> > > > >> >> > Carter
> > > > >> >> >
> > > > >> >> >
> > > > >> >> >
> > > > >> >> >
> > > > >> >> >
> > > > >> >> >>  -----Original Message-----
> > > > >> >> >>  From: majordomo listserver
> > > > >> >> >>  [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of
> > > > >> >> >>  calato@riverstonenet.com
> > > > >> >> >>  Sent: Thursday, November 07, 2002 9:46 AM
> > > > >> >> >>  To: ipfixx
> > > > >> >> >>  Subject: [ipfix] Multiple levels of Reliability and
> > > > >> >> >>  Directionality
> > > > >> >> >>
> > > > >> >> >>
> > > > >> >> >>
> > > > >> >> >>  Does IPFIX need to support multiple levels of reliability
> > > > >> >> >>  and directionality?
> > > > >> >> >>
> > > > >> >> >>  The applications IPFIX needs to support are quite varied
> > > > >> >> >>  and have differing needs in terms of reliability. Devices
> > > > >> >> >>  also have varying needs in terms of directionality.
> > > > >> >> >>
> > > > >> >> >>  I would like the WG to consider requirements on the protocol
> > > > >> >> >>  to support a tiered approach meet these needs.
> > > > >> >> >>
> > > > >> >> >>  Direction is either bi-directional or uni-directional. I've
> > > > >> >> >>  split
> > > > >> >> >>  reliability into 3 categories...
> > > > >> >> >>
> > > > >> >> >>        High   - Little to no data loss
> > > > >> >> >>        Medium - Minimal data loss is accepted
> > > > >> >> >>        Low    - Data sent is best effort
> > > > >> >> >>
> > > > >> >> >>
> > > > >> >> >>  The six combinations are shown below...
> > > > >> >> >>
> > > > >> >> >>
> > > > >> >> >>               | Uni  |  Bi
> > > > >> >> >>        -------+------+---------
> > > > >> >> >>        High   |  1   |    4
> > > > >> >> >>        -------+------+--------
> > > > >> >> >>        Medium |  2   |    5
> > > > >> >> >>        -------+------+--------
> > > > >> >> >>        Low    |  3   |    6
> > > > >> >> >>
> > > > >> >> >>
> > > > >> >> >>
> > > > >> >> >>  I think (IMHO) the most likely combinations are...
> > > > >> >> >>
> > > > >> >> >>        3. Low reliability and uni-directional. This will be
> > > > >> >> >>  used
> > > > >> >> >>           where the device and collector are in close
> > > > >> >> >>  proximity,
> > > > >> >> >>           there is high volume and some data loss is
> > > > >> >> >>  acceptable for
> > > > >> >> >>           the given application. Applications such as
> > > > >> >> >>  Attack/Intrusion Detection
> > > > >> >> >>           Traffic Profiling, etc...
> > > > >> >> >>
> > > > >> >> >>        5. Bi-directional medium reliability. This will be
> > > > >> >> >>  used
> > > > >> >> >>           where high volume and increased reliability are
> > > > >> >> >>  needed. Applications
> > > > >> >> >>           such as Usage-based Accounting where 95th
> > > > >> >> >>  percentile billing
> > > > >> >> >>           model is used. Or even Traffic Engineering where
> > > > >> >> >>  network policy
> > > > >> >> >>           decisions are based on the data collected.
> > > > >> >> >>
> > > > >> >> >>        4. Bi-directional high reliability would be used where
> > > > >> >> >>  the
> > > > >> >> >>           Usage-based Accounting application has strict
> > > > >> >> >>  requirements
> > > > >> >> >>           on data loss.
> > > > >> >> >>
> > > > >> >> >>  Does IPFIX need to support multiple levels of reliability
> > > > >> >> >>  and directionality?
> > > > >> >> >>
> > > > >> >> >>  Paul
> > > > >> >> >>
> > > > >> >> >>  --
> > > > >> >> >>  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/
> > > > >
> > > > >
> > >
> > > --
> > > 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 Nov 18 14:36:38 2002
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 OAA01143
	for ; Mon, 18 Nov 2002 14:36:37 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18DrY8-0005kd-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 18 Nov 2002 13:27:12 -0600
Received: from pool-68-160-192-59.ny325.east.verizon.net ([68.160.192.59] helo=newyork.qosient.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18DrY5-0005kU-00
	for ipfix@net.doit.wisc.edu; Mon, 18 Nov 2002 13:27:09 -0600
Received: from sphynx (sphynx [192.168.0.64])
	by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id gAIJR1O04941;
	Mon, 18 Nov 2002 14:27:01 -0500
From: "Carter Bullard" 
To: "'Ganesh Sadasivan'" ,
        "'Tal Givoly'" 
Cc: "'ipfixx'" 
Subject: RE: [ipfix] Multiple levels of Reliability and Directionality
Date: Mon, 18 Nov 2002 14:26:52 -0500
Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A4C1@ptah.newyork.qosient.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <5C8959A16A71B449AE793CF52FBBED660DAB7B@ptah.newyork.qosient.com>
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

Gentle people,
   It may be of interest for the group to look at
RFC-3340 which deals with the issues of generic application
transport and capability negotiation, as well as reliability.
http://www.ietf.org/rfc/rfc3340.txt?number=3340.

Doesn't seem that hard.  When did IPFIX drop capability
negotiation as a requirement?

Carter

Carter Bullard
QoSient, LLC
300 E. 56th Street
Suite 18K
New York, New York 10022

+1 212 588-9133 Phone
+1 212 588-9134 Fax

> -----Original Message-----
> From: majordomo listserver 
> [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Ganesh Sadasivan
> Sent: Monday, November 18, 2002 1:53 PM
> To: Tal Givoly
> Cc: 'ipfixx'
> Subject: Re: [ipfix] Multiple levels of Reliability and Directionality
> 
> 
> Tal,
> 
>    There has been discussion at length in the mailing list 
> and IETF session as to why
>    we should refrain from  going with capability negotiation 
> in IPFIX protocol. See
>    my response to Peter on this topic:
>    http://ipfx.doit.wisc.edu/list/ipfix/archive/0753.html
>    Though in theory this idea sounds fine the complexity of 
> this feature when trying
>    to generalize for a framework like IPFIX is high. This was 
> one of the main reasons for
>    dropping this feature off the IPFIX protocol.
> 
> Thanks
> Ganesh
> 
> Tal Givoly wrote:
> 
> > Ganesh,
> >
> > There is a middle ground here: multiple LEVELS/DEGREES of 
> reliability 
> > which are different modes of operation of the protocol. 
> Depending on 
> > the exporter and collector set of capabilities, they can 
> negotiate or 
> > predefine that they will operate in a specific mode. This way, some 
> > devices, under some circumstances (for instance, high-speed flow 
> > export) may not support the reliability capabilities. While 
> at other 
> > situations, they may support reliable exports due to the 
> lower volume, 
> > high-value aggregate information they are exporting. If 
> footprint of 
> > implementation within device is extremely constrained, they 
> may have a 
> > subset of the capabilities altogether.
> >
> > This can be done without undue encumbrance on the device while 
> > permitting cost-effective deployments for applications 
> requiring more 
> > reliability.
> >
> > This is also one of the reasons minimal, exporter-overridden, 
> > negotiation capabilities are very useful. That would allow seamless 
> > interoperability between collectors and exporters with 
> varying degrees 
> > of capabilities and interests in data.
> >
> > Note that this is exactly the way faxes/modems knew how to 
> > interoperate and spawned a huge industry as a result of such 
> > standardization leading to seamless interopability.
> >
> > Tal
> >
> > -----Original Message-----
> > From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com]
> > Sent: Monday, November 18, 2002 6:32 AM
> > To: Tal Givoly
> > Cc: 'ipfixx'
> > Subject: Re: [ipfix] Multiple levels of Reliability and 
> Directionality
> >
> > Tal,
> >
> > Tal Givoly wrote:
> >
> > > Ganesh,
> > >
> > > Obviously, this doesn't do justice to the requirements of many
> > applications.
> > > There is no dispute that there is a set of applications 
> that would 
> > > be satisfied with level 3 or 6. However, flow export is 
> also being 
> > > used, and there is a desire to expand its usage, for applications 
> > > mentioned in the charter that require that require higher 
> levels of 
> > > reliability. Most of
> > our
> >
> > By doing this we are penalising the large set of existing  of 
> > application using flow export were requirement is just a 3 
> or 6. BTW 
> > when I refer to 6, I meant "ACK mechanism which covers like 
> a summary 
> > of lost packets" and not "application level ACK mechanism".
> > The number of apps that are and would be using this export 
> mechanism is
> > large and
> >
> > their requirements are widely varying. Rather than addressing in 
> > detail the need for each of the current set of application, it is 
> > better to keep a simple infrastructure
> > and let the applications with more strict requirements 
> build their own
> > mechanism
> > on top of this infrastructure.
> >
> > Thanks
> > Ganesh
> >
> > > many customers are seeking better interfaces down-to-the-device 
> > > level. I
> > can
> > > refer you to many use cases and justifications of this 
> position that 
> > > appeared in many previous posts.
> >
> > >
> > >
> > > Tal
> > >
> > > -----Original Message-----
> > > From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com]
> > > Sent: Friday, November 15, 2002 11:58 AM
> > > To: calato@riverstonenet.com
> > > Cc: Benoit Claise; Tal Givoly; Jeff Meyer; carter@qosient.com; 
> > > 'ipfixx'
> > > Subject: Re: [ipfix] Multiple levels of Reliability and 
> Directionality
> > >
> > > calato@riverstonenet.com wrote:
> > >
> > > > Benoit Claise wrote:
> > > > >
> > > > > Paul,
> > > > >
> > > > > First of all, let me take back your initial email, 
> for clarity 
> > > > > purposes
> > > > >
> > > > >         High   - Little to no data loss
> > > > >         Medium - Minimal data loss is accepted
> > > > >         Low    - Data sent is best effort
> > > > >
> > > > > The six combinations are shown below...
> > > > >
> > > > >                | Uni  |  Bi
> > > > >         -------+------+---------
> > > > >         High   |  1   |    4
> > > > >         -------+------+--------
> > > > >         Medium |  2   |    5
> > > > >         -------+------+--------
> > > > >         Low    |  3   |    6
> > > > >
> > > > > I think (IMHO) the most likely combinations are...
> > > > >
> > > > >         3. Low reliability and uni-directional. This 
> will be used
> > > > >            where the device and collector are in 
> close proximity,
> > > > >            there is high volume and some data loss is 
> acceptable for
> > > > >            the given application. Applications such as 
> > > > > Attack/Intrusion
> > > > >            Detection Traffic Profiling, etc...
> > > > >
> > > > >         5. Bi-directional medium reliability. This 
> will be used
> > > > >            where high volume and increased 
> reliability are needed.
> > > > >            Applications
> > > > >            such as Usage-based Accounting where 95th 
> percentile 
> > > > > billing
> > > > >            model is used. Or even Traffic Engineering 
> where network
> > > > >            policy decisions are based on the data collected.
> > > > >
> > > > >         4. Bi-directional high reliability would be 
> used where the
> > > > >            Usage-based Accounting application has 
> strict requirements
> > > > >            on data loss.
> > > > >
> > > > > I agree on 3, this is the minimum.
> > > > >
> > > > > I agree on 5 but I fear that the application level 
> ACK will not 
> > > > > always be a possible solution from a router point of 
> view. What 
> > > > > if the router exports so much flow records that it 
> can't cache 
> > > > > them while waiting for the ACK. So basically, 
> resending the flow 
> > > > > records is not always possible. So, if you conclude that the 
> > > > > requirement for 5 is the bidirectionality with 
> application level 
> > > > > ACK, then this requirement is not always possible!
> > > >
> > > >         Agreed. In very high volume deployments I would
> > > >         use option #3.
> > > >
> > > > > IMHO, 5 could alos be
> > > > >         2 with best-effort
> > > > >         or 2 with a carefully designed network
> > > >
> > > >         If the customer can design their accounting network
> > > >         in such away. But I'm not sure we want to require that.
> > > >
> > > >         Lets assume that aggregation is happening at
> > > >         a reasonably high level (which drops the flow rate
> > > >         to a manageable level). But the consequence is that
> > > >         one lost record can be a huge chunk of missing data.
> > > >
> > > >         In this case reliability is the issue not the data
> > > >         rate. I'm advocating a reliability option (note 
> I said option)
> > > >         as a way to solve this.
> > > >
> > > >
> > > > >
> > > > > Regarding 4, Randy replied already
> > > > >
> > > > >      > Somehow, the requirements discussion suffers 
> from a split:
> > > > >      > There are requirements resulting from the intention of
> > > > >      > standardzing a highly reliable metering standard for
> > > > >      precise
> > > > >      > accounting (and billing). Differing from these are
> > > > >      requirements
> > > > >      > for a simpler metering standard more oriented at what I
> > > > >      would
> > > > >      > call "typical Internet reliability".
> > > > >
> > > > >       the original goal, which the iesg thinks 
> was chartered,
> > > > >      is the
> > > > >      latter.
> > > > >
> > > >
> > > >         There was a lot of push back by the group on 
> that statement.
> > > >         I asked for clarification but have not received any.
> > >
> > > I feel the base line IPFIX protocol does require just 3 
> or 6. This 
> > > would provide the simplest and the most efficient means for all 
> > > applications. For those applications like billing with more 
> > > stringent requirements, why can't extensions be built on 
> top of the 
> > > base protocol as a higher level application? By doing this we can 
> > > cover the entire matrix. There is a vast majority of apps 
> that need 
> > > just the 3. and building a multi-level reliable scheme into the 
> > > basre IPFIX protocol would result in a less efficient use of the 
> > > protocol for apps that really don't care for this.
> > >
> > > Thanks
> > > Ganesh
> > >
> > > >
> > > >
> > > >         Paul
> > > >
> > > > > > Let me see if we all agree on a couple things...
> > > > > >
> > > > > >         1. There is no such thing as partially 
> uni-directional.
> > > > > >         2. IPFIX ought to support a uni-directional mode of 
> > > > > > operation.
> > > > > >
> > > > > Agreed.
> > > > >
> > > > > Regards, Benoit.
> > > > >
> > > > > >
> > > > > > Paul
> > > > > >
> > > > > > Tal Givoly wrote:
> > > > > >
> > > > > >
> > > > > >> Jeff,
> > > > > >>
> > > > > >> I agree with you completely here - the protocol 
> should focus 
> > > > > >> on a primarily uni-directional feed from network/service 
> > > > > >> elements (metering+exporting
> > > > > >> process) to collection process. Adding 
> capabilities (such as
> > > > > >> parameter
> > > > > >> configuration, provisioning of other sorts, etc.) here is a
> > > > > >> slippery slope.
> > > > > >>
> > > > > >> I would add, however, that the bi-directionality is needed 
> > > > > >> both for assurance that messages are delivered as well as, 
> > > > > >> IMHO, version, capability
> > > > > >> and template negotiation (which can be simplified 
> as needed by
> > > > > >> device).
> > > > > >> Version and capability negotiation allows for 
> forward/backward
> > > > > >> interoperability and compatibility. Template 
> negotiation allows
> > > > > >> for more
> > > > > >> efficient application-aware communication. As 
> Peter explained
> > > > > >> earlier
> > > > > >> (http://ipfix.doit.wisc.edu/archive/1381.html - 
> scenario #1 or
> > > > > >> #2), it is
> > > > > >> possible to have all these capabilities and have 
> no impact on the
> > > > > >> metering/export processes complexity - the 
> complexity can be,
> > > > > >> optionally,
> > > > > >> added to the collection process (off the device) 
> in order to allow
> > > > > >> for
> > > > > >> interoperability with multiple concurrent
> > > > > >> versions/capabilities/templates in
> > > > > >> the devices.
> > > > > >>
> > > > > >> Essentially, I believe we achieved consensus regarding the 
> > > > > >> need for template capabilities to allow separation of the 
> > > > > >> data model from the protocol.
> > > > > >> Version/capability negotiation are very useful for 
> any protocol in
> > > > > >> order to
> > > > > >> increase its applicability and useful lifespan.
> > > > > >>
> > > > > >> Tal
> > > > > >>
> > > > > >> -----Original Message-----
> > > > > >> From: Jeff Meyer [mailto:jeffm@cup.hp.com]
> > > > > >> Sent: Monday, November 11, 2002 9:39 AM
> > > > > >> To: calato@riverstonenet.com
> > > > > >> Cc: Tal Givoly; carter@qosient.com; 'ipfixx'
> > > > > >> Subject: Re: [ipfix] Multiple levels of Reliability and 
> > > > > >> Directionality
> > > > > >>
> > > > > >> OK, then based on this minimal definition of 
> bi-directional, 
> > > > > >> I'm in complete agreement.
> > > > > >>
> > > > > >> It's the sliperry slope of other things one might want to 
> > > > > >> exchange once this two way channel is open, which concerns 
> > > > > >> me.  There are lots of things one might want to 
> exchange, but 
> > > > > >> many of these are probably better addressed by reusing 
> > > > > >> existing protocols, vs. stuffing into the IPFIX protocol.
> > > > > >>
> > > > > >> For example, controlling metering process is 
> something which 
> > > > > >> can be separated out from IPFIX.  For example by 
> using SNMP 
> > > > > >> and a MeterMIB.
> > > > > >>
> > > > > >> Just trying to apply the KISS (Keep it simple stupid) 
> > > > > >> principle.
> > > > > >>
> > > > > >> Regards,
> > > > > >>
> > > > > >>    Jeff Meyer
> > > > > >>    hp
> > > > > >>
> > > > > >> calato@riverstonenet.com wrote:
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> > Jeff Meyer wrote:
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> >>  Hi,
> > > > > >> >>
> > > > > >> >>    I agree with the aspect of varied reliability.
> > > > > >> >>
> > > > > >> >>    I am less clear on the need for bi-directional  
> > > > > >> >> behavior.  The three scenarios you describe I  
> agree with, 
> > > > > >> >> but I'm not sure how the 2nd and  3rd scenario as 
> > > > > >> >> described have any dependence  on bi-directional aside 
> > > > > >> >> from the some level of  application layer ack.
> > > > > >> >>
> > > > > >> >>
> > > > > >> >>
> > > > > >> >>
> > > > > >> >       An application layer ACK all by itself makes the
> > > > > >> >       protocol bi-directional.
> > > > > >> >
> > > > > >> >       Scenario #1 does not require the sender to 
> also be a 
> > > > > >> > receiver.
> > > > > >> >
> > > > > >> >       Scenarios #2 & #3 do require the sender to 
> also be a
> > > > > >> >       receiver (even if only for ACK's).
> > > > > >> >
> > > > > >> >       Whether or not we decide to add other features in
> > > > > >> >       scenarios #2 & #3 (such as field 
> negotiation, capability
> > > > > >> >       negotiation, etc...) is up to the WG. But 
> they could
> > > > > >> >       not be added to scenario #1.
> > > > > >> >
> > > > > >> >       Paul
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> >>  Regards,
> > > > > >> >>
> > > > > >> >>    Jeff Meyer
> > > > > >> >>
> > > > > >> >>  Tal Givoly wrote:
> > > > > >> >>
> > > > > >> >>
> > > > > >> >>
> > > > > >> >>
> > > > > >> >> > Paul,
> > > > > >> >> >
> > > > > >> >> > I agree completely - that captures the essense of the 
> > > > > >> >> > requirements. It allows balancing different 
> > > > > >> >> > application's need for different levels of
> > > > > >> >> > reliability.
> > > > > >> >> >
> > > > > >> >> > Tal
> > > > > >> >> >
> > > > > >> >> > -----Original Message-----
> > > > > >> >> > From: majordomo listserver [ 
> > > > > >> >> > mailto:majordomo@mil.doit.wisc.edu]On Behalf 
> Of Carter 
> > > > > >> >> > Bullard
> > > > > >> >> > Sent: Thursday, November 07, 2002 8:40 AM
> > > > > >> >> > To: calato@riverstonenet.com; 'ipfixx'
> > > > > >> >> > Subject: RE: [ipfix] Multiple levels of 
> Reliability and 
> > > > > >> >> > Directionality
> > > > > >> >> >
> > > > > >> >> >
> > > > > >> >> > Hey Paul,
> > > > > >> >> >  My 2 cents worth sez, absolutely yes!
> > > > > >> >> > Carter
> > > > > >> >> >
> > > > > >> >> >
> > > > > >> >> >
> > > > > >> >> >
> > > > > >> >> >
> > > > > >> >> >>  -----Original Message-----
> > > > > >> >> >>  From: majordomo listserver  
> > > > > >> >> >> [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of  
> > > > > >> >> >> calato@riverstonenet.com
> > > > > >> >> >>  Sent: Thursday, November 07, 2002 9:46 AM
> > > > > >> >> >>  To: ipfixx
> > > > > >> >> >>  Subject: [ipfix] Multiple levels of 
> Reliability and  
> > > > > >> >> >> Directionality
> > > > > >> >> >>
> > > > > >> >> >>
> > > > > >> >> >>
> > > > > >> >> >>  Does IPFIX need to support multiple levels of 
> > > > > >> >> >> reliability  and directionality?
> > > > > >> >> >>
> > > > > >> >> >>  The applications IPFIX needs to support are quite 
> > > > > >> >> >> varied  and have differing needs in terms of 
> > > > > >> >> >> reliability. Devices  also have varying 
> needs in terms 
> > > > > >> >> >> of directionality.
> > > > > >> >> >>
> > > > > >> >> >>  I would like the WG to consider requirements on the 
> > > > > >> >> >> protocol  to support a tiered approach meet these 
> > > > > >> >> >> needs.
> > > > > >> >> >>
> > > > > >> >> >>  Direction is either bi-directional or 
> uni-directional. 
> > > > > >> >> >> I've  split  reliability into 3 categories...
> > > > > >> >> >>
> > > > > >> >> >>        High   - Little to no data loss
> > > > > >> >> >>        Medium - Minimal data loss is accepted
> > > > > >> >> >>        Low    - Data sent is best effort
> > > > > >> >> >>
> > > > > >> >> >>
> > > > > >> >> >>  The six combinations are shown below...
> > > > > >> >> >>
> > > > > >> >> >>
> > > > > >> >> >>               | Uni  |  Bi
> > > > > >> >> >>        -------+------+---------
> > > > > >> >> >>        High   |  1   |    4
> > > > > >> >> >>        -------+------+--------
> > > > > >> >> >>        Medium |  2   |    5
> > > > > >> >> >>        -------+------+--------
> > > > > >> >> >>        Low    |  3   |    6
> > > > > >> >> >>
> > > > > >> >> >>
> > > > > >> >> >>
> > > > > >> >> >>  I think (IMHO) the most likely combinations are...
> > > > > >> >> >>
> > > > > >> >> >>        3. Low reliability and uni-directional. This 
> > > > > >> >> >> will be  used
> > > > > >> >> >>           where the device and collector are 
> in close  
> > > > > >> >> >> proximity,
> > > > > >> >> >>           there is high volume and some data 
> loss is  
> > > > > >> >> >> acceptable for
> > > > > >> >> >>           the given application. 
> Applications such as  
> > > > > >> >> >> Attack/Intrusion Detection
> > > > > >> >> >>           Traffic Profiling, etc...
> > > > > >> >> >>
> > > > > >> >> >>        5. Bi-directional medium reliability. 
> This will 
> > > > > >> >> >> be  used
> > > > > >> >> >>           where high volume and increased 
> reliability 
> > > > > >> >> >> are  needed. Applications
> > > > > >> >> >>           such as Usage-based Accounting where 95th  
> > > > > >> >> >> percentile billing
> > > > > >> >> >>           model is used. Or even Traffic Engineering 
> > > > > >> >> >> where  network policy
> > > > > >> >> >>           decisions are based on the data collected.
> > > > > >> >> >>
> > > > > >> >> >>        4. Bi-directional high reliability 
> would be used 
> > > > > >> >> >> where  the
> > > > > >> >> >>           Usage-based Accounting application 
> has strict  
> > > > > >> >> >> requirements
> > > > > >> >> >>           on data loss.
> > > > > >> >> >>
> > > > > >> >> >>  Does IPFIX need to support multiple levels of 
> > > > > >> >> >> reliability  and directionality?
> > > > > >> >> >>
> > > > > >> >> >>  Paul
> > > > > >> >> >>
> > > > > >> >> >>  --
> > > > > >> >> >>  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/
> > > > > >
> > > > > >
> > > >
> > > > --
> > > > 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 Nov 18 14:55:00 2002
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 OAA01593
	for ; Mon, 18 Nov 2002 14:55:00 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18Drtd-0006Dz-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 18 Nov 2002 13:49:25 -0600
Received: from dplonka by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18Drtb-0006Dr-00; Mon, 18 Nov 2002 13:49:23 -0600
Date: Mon, 18 Nov 2002 13:49:23 -0600
From: Dave Plonka 
To: ipfix@net.doit.wisc.edu
Cc: Carter Bullard 
Subject: Re: [ipfix] Multiple levels of Reliability and Directionality
Message-ID: <20021118134923.C22036@doit.wisc.edu>
Reply-To: plonka@doit.wisc.edu
References: <5C8959A16A71B449AE793CF52FBBED660DAB7B@ptah.newyork.qosient.com> <5C8959A16A71B449AE793CF52FBBED6607A4C1@ptah.newyork.qosient.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <5C8959A16A71B449AE793CF52FBBED6607A4C1@ptah.newyork.qosient.com>; from carter@qosient.com on Mon, Nov 18, 2002 at 02:26:52PM -0500
Organization: UW-Madison, DoIT, Network Services
X-VMS-Error: %SYSTEM-E-NOCMDMEM, no command memory has been allocated
X-Shakespearean-Insult: Thou yeasty full-gorged hugger-mugger
Precedence: bulk
Sender: majordomo listserver 


Hi Carter,

On Mon, Nov 18, 2002 at 02:26:52PM -0500, Carter Bullard wrote:
>    It may be of interest for the group to look at
> RFC-3340 which deals with the issues of generic application
> transport and capability negotiation, as well as reliability.
> http://www.ietf.org/rfc/rfc3340.txt?number=3340.
> 
> Doesn't seem that hard.  When did IPFIX drop capability
> negotiation as a requirement?

I don't believe IPFIX ever had capability negotiation as a requirement.

Quoting from "http://ipfix.doit.wisc.edu/IETF53/minutes.txt":

   Regarding capability negotiation, consensus amongst attendees (by a
   hum) was that neither exporter configuration nor capabilities
   negotiation between collectors and exporters should be addressed by
   IPFIX.  The chairs will follow-up with a call on the mailing list on
   this topic.

I was remiss in not following up beyond posting the minutes to the list
for review, but AFAIK the issue has not been contentious given our
"standardize existing practice" mantra and that negotiation hasn't been
substantively mentioned since before IETF53, when Juergen posted his
concerns about negotiation feature creep:

   http://ipfix.doit.wisc.edu/archive/0461.html

to which there were no follow-ups.

Dave

-- 
plonka@doit.wisc.edu  http://net.doit.wisc.edu/~plonka  ARS:N9HZF  Madison, WI

--
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 Nov 18 16:43:44 2002
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 QAA04525
	for ; Mon, 18 Nov 2002 16:43:43 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18DtYP-0000u1-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 18 Nov 2002 15:35:37 -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 18DtYN-0000tj-00
	for ipfix@net.doit.wisc.edu; Mon, 18 Nov 2002 15:35:35 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Subject: RE: [ipfix] Multiple levels of Reliability and Directionality
Date: Mon, 18 Nov 2002 13:35:04 -0800
Message-ID: <80CC8579BE94854FB8AA48856AA8B33607B2CF@rs-sc-exc4.rs.riverstonenet.com>
Thread-Topic: [ipfix] Multiple levels of Reliability and Directionality
Thread-Index: AcKM4oDmitAJVpYDTTWs9a6g4/tnpQCZgRjc
From: "Paul Calato" 
To: "Ganesh Sadasivan" 
Cc: "Benoit Claise" , "Tal Givoly" ,
        "Jeff Meyer" , ,
        "ipfixx" 
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ietf.org id QAA04525

 

	-----Original Message----- 
	From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com] 
	Sent: Fri 11/15/2002 11:58 AM 
	To: Paul Calato 
	Cc: Benoit Claise; Tal Givoly; Jeff Meyer; carter@qosient.com; 'ipfixx' 
	Subject: Re: [ipfix] Multiple levels of Reliability and Directionality
	
	



	calato@riverstonenet.com wrote:
	
	> Benoit Claise wrote:
	> >
	> > Paul,
	> >
	> > First of all, let me take back your initial email, for clarity
	> > purposes
	> >
	> >         High   - Little to no data loss
	> >         Medium - Minimal data loss is accepted
	> >         Low    - Data sent is best effort
	> >
	> > The six combinations are shown below...
	> >
	> >                | Uni  |  Bi
	> >         -------+-----+--------
	> >         High   |  1   |    4
	> >         -------+-----+-------
	> >         Medium |  2   |    5
	> >         -------+-----+-------
	> >         Low    |  3   |    6
	> >
	> > I think (IMHO) the most likely combinations are...
	> >
	> >         3. Low reliability and uni-directional. This will be used
	> >            where the device and collector are in close proximity,
	> >            there is high volume and some data loss is acceptable for
	> >            the given application. Applications such as
	> > Attack/Intrusion
	> >            Detection Traffic Profiling, etc...
	> >
	> >         5. Bi-directional medium reliability. This will be used
	> >            where high volume and increased reliability are needed.
	> >            Applications
	> >            such as Usage-based Accounting where 95th percentile
	> > billing
	> >            model is used. Or even Traffic Engineering where network
	> >            policy decisions are based on the data collected.
	> >
	> >         4. Bi-directional high reliability would be used where the
	> >            Usage-based Accounting application has strict requirements
	> >            on data loss.
	> >
	> > I agree on 3, this is the minimum.
	> >
	> > I agree on 5 but I fear that the application level ACK will not always
	> > be a possible solution from a router point of view. What if the router
	> > exports so much flow records that it can't cache them while waiting
	> > for the ACK.
	> > So basically, resending the flow records is not always possible.
	> > So, if you conclude that the requirement for 5 is the bidirectionality
	> > with application level ACK, then this requirement is not always
	> > possible!
	>
	>         Agreed. In very high volume deployments I would
	>         use option #3.
	>
	> > IMHO, 5 could alos be
	> >         2 with best-effort
	> >         or 2 with a carefully designed network
	>
	>         If the customer can design their accounting network
	>         in such away. But I'm not sure we want to require that.
	>
	>         Lets assume that aggregation is happening at
	>         a reasonably high level (which drops the flow rate
	>         to a manageable level). But the consequence is that
	>         one lost record can be a huge chunk of missing data.
	>
	>         In this case reliability is the issue not the data
	>         rate. I'm advocating a reliability option (note I said option)
	>         as a way to solve this.
	>
	>
	> >
	> > Regarding 4, Randy replied already
	> >
	> >      > Somehow, the requirements discussion suffers from a split:
	> >      > There are requirements resulting from the intention of
	> >      > standardzing a highly reliable metering standard for
	> >      precise
	> >      > accounting (and billing). Differing from these are
	> >      requirements
	> >      > for a simpler metering standard more oriented at what I
	> >      would
	> >      > call "typical Internet reliability".
	> >
	> >       the original goal, which the iesg thinks was chartered,
	> >      is the
	> >      latter.
	> >
	>
	>         There was a lot of push back by the group on that statement.
	>         I asked for clarification but have not received any.
	
	I feel the base line IPFIX protocol does require just 3 or 6. This would
	provide the simplest and the most efficient means for all applications.
	For those applications like billing with more stringent requirements,
	why can't extensions be built on top of the base protocol as a higher
	level application? By doing this we can cover the entire matrix.
	There is a vast majority of apps that need just the 3.
	and building a multi-level reliable scheme into the basre IPFIX protocol
	would result in a less efficient use of the protocol for apps that really
	don't care for this.

	[paul] If we have a simple, uni-directional unreliable base (#3) then adding reliability

	on top of that base can still be part of the IPFIX working group. It would seem there

	are important applications which need that feature, there is support on the list for specifying

	it and it seems there are valid deployment scenarios where it would be used (e.g. aggregated

	records).

	 

	Would you support an approach with #3 as a base and  #4 and #5 as additions? I think the

	key here is really keeping #3 as the base and #4 and #5 as enhancements. For example,

	if #3 solves passing the template info #4 and #5 cannot change how that is done. Otherwise

	it would lead to too much divergence.

	[Paul-end]
	
	Thanks
	Ganesh
	
	
	>
	>
	>         Paul
	>
	> > > Let me see if we all agree on a couple things...
	> > >
	> > >         1. There is no such thing as partially uni-directional.
	> > >         2. IPFIX ought to support a uni-directional mode of
	> > > operation.
	> > >
	> > Agreed.
	> >
	> > Regards, Benoit.
	> >
	> > >
	> > > Paul
	> > >
	> > > Tal Givoly wrote:
	> > >
	> > >
	> > >> Jeff,
	> > >>
	> > >> I agree with you completely here - the protocol should focus on a
	> > >> primarily
	> > >> uni-directional feed from network/service elements
	> > >> (meteringç¬šæ¢®í¢§
	> > >> process) to collection process. Adding capabilities (such as
	> > >> parameter
	> > >> configuration, provisioning of other sorts, etc.) here is a
	> > >> slippery slope.
	> > >>
	> > >> I would add, however, that the bi-directionality is needed both
	> > >> for
	> > >> assurance that messages are delivered as well as, IMHO, version,
	> > >> capability
	> > >> and template negotiation (which can be simplified as needed by
	> > >> device).
	> > >> Version and capability negotiation allows for forward/backward
	> > >> interoperability and compatibility. Template negotiation allows
	> > >> for more
	> > >> efficient application-aware communication. As Peter explained
	> > >> earlier
	> > >> (http://ipfix.doit.wisc.edu/archive/1381.html - scenario #1 or
	> > >> #2), it is
	> > >> possible to have all these capabilities and have no impact on the
	> > >> metering/export processes complexity - the complexity can be,
	> > >> optionally,
	> > >> added to the collection process (off the device) in order to allow
	> > >> for
	> > >> interoperability with multiple concurrent
	> > >> versions/capabilities/templates in
	> > >> the devices.
	> > >>
	> > >> Essentially, I believe we achieved consensus regarding the need
	> > >> for template
	> > >> capabilities to allow separation of the data model from the
	> > >> protocol.
	> > >> Version/capability negotiation are very useful for any protocol in
	> > >> order to
	> > >> increase its applicability and useful lifespan.
	> > >>
	> > >> Tal
	> > >>
	> > >> -----Original Message-----
	> > >> From: Jeff Meyer [mailto:jeffm@cup.hp.com]
	> > >> Sent: Monday, November 11, 2002 9:39 AM
	> > >> To: calato@riverstonenet.com
	> > >> Cc: Tal Givoly; carter@qosient.com; 'ipfixx'
	> > >> Subject: Re: [ipfix] Multiple levels of Reliability and
	> > >> Directionality
	> > >>
	> > >> OK, then based on this minimal definition of
	> > >> bi-directional, I'm in complete agreement.
	> > >>
	> > >> It's the sliperry slope of other things one might
	> > >> want to exchange once this two way channel is open,
	> > >> which concerns me.  There are lots of things one
	> > >> might want to exchange, but many of these are probably
	> > >> better addressed by reusing existing protocols,
	> > >> vs. stuffing into the IPFIX protocol.
	> > >>
	> > >> For example, controlling metering process is something
	> > >> which can be separated out from IPFIX.  For example
	> > >> by using SNMP and a MeterMIB.
	> > >>
	> > >> Just trying to apply the KISS (Keep it simple stupid)
	> > >> principle.
	> > >>
	> > >> Regards,
	> > >>
	> > >>    Jeff Meyer
	> > >>    hp
	> > >>
	> > >> calato@riverstonenet.com wrote:
	> > >>
	> > >>
	> > >>
	> > >> > Jeff Meyer wrote:
	> > >> >
	> > >> >
	> > >> >
	> > >> >>  Hi,
	> > >> >>
	> > >> >>    I agree with the aspect of varied reliability.
	> > >> >>
	> > >> >>    I am less clear on the need for bi-directional
	> > >> >>  behavior.  The three scenarios you describe I
	> > >> >>  agree with, but I'm not sure how the 2nd and
	> > >> >>  3rd scenario as described have any dependence
	> > >> >>  on bi-directional aside from the some level of
	> > >> >>  application layer ack.
	> > >> >>
	> > >> >>
	> > >> >>
	> > >> >>
	> > >> >       An application layer ACK all by itself makes the
	> > >> >       protocol bi-directional.
	> > >> >
	> > >> >       Scenario #1 does not require the sender to also be a
	> > >> > receiver.
	> > >> >
	> > >> >       Scenarios #2 & #3 do require the sender to also be a
	> > >> >       receiver (even if only for ACK's).
	> > >> >
	> > >> >       Whether or not we decide to add other features in
	> > >> >       scenarios #2 & #3 (such as field negotiation, capability
	> > >> >       negotiation, etc...) is up to the WG. But they could
	> > >> >       not be added to scenario #1.
	> > >> >
	> > >> >       Paul
	> > >> >
	> > >> >
	> > >> >
	> > >> >
	> > >> >
	> > >> >>  Regards,
	> > >> >>
	> > >> >>    Jeff Meyer
	> > >> >>
	> > >> >>  Tal Givoly wrote:
	> > >> >>
	> > >> >>
	> > >> >>
	> > >> >>
	> > >> >> > Paul,
	> > >> >> >
	> > >> >> > I agree completely - that captures the essense of the
	> > >> >> > requirements. It
	> > >> >> > allows balancing different application's need for different
	> > >> >> > levels of
	> > >> >> > reliability.
	> > >> >> >
	> > >> >> > Tal
	> > >> >> >
	> > >> >> > -----Original Message-----
	> > >> >> > From: majordomo listserver [
	> > >> >> > mailto:majordomo@mil.doit.wisc.edu]On Behalf
	> > >> >> > Of Carter Bullard
	> > >> >> > Sent: Thursday, November 07, 2002 8:40 AM
	> > >> >> > To: calato@riverstonenet.com; 'ipfixx'
	> > >> >> > Subject: RE: [ipfix] Multiple levels of Reliability and
	> > >> >> > Directionality
	> > >> >> >
	> > >> >> >
	> > >> >> > Hey Paul,
	> > >> >> >  My 2 cents worth sez, absolutely yes!
	> > >> >> > Carter
	> > >> >> >
	> > >> >> >
	> > >> >> >
	> > >> >> >
	> > >> >> >
	> > >> >> >>  -----Original Message-----
	> > >> >> >>  From: majordomo listserver
	> > >> >> >>  [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of
	> > >> >> >>  calato@riverstonenet.com
	> > >> >> >>  Sent: Thursday, November 07, 2002 9:46 AM
	> > >> >> >>  To: ipfixx
	> > >> >> >>  Subject: [ipfix] Multiple levels of Reliability and
	> > >> >> >>  Directionality
	> > >> >> >>
	> > >> >> >>
	> > >> >> >>
	> > >> >> >>  Does IPFIX need to support multiple levels of reliability
	> > >> >> >>  and directionality?
	> > >> >> >>
	> > >> >> >>  The applications IPFIX needs to support are quite varied
	> > >> >> >>  and have differing needs in terms of reliability. Devices
	> > >> >> >>  also have varying needs in terms of directionality.
	> > >> >> >>
	> > >> >> >>  I would like the WG to consider requirements on the protocol
	> > >> >> >>  to support a tiered approach meet these needs.
	> > >> >> >>
	> > >> >> >>  Direction is either bi-directional or uni-directional. I've
	> > >> >> >>  split
	> > >> >> >>  reliability into 3 categories...
	> > >> >> >>
	> > >> >> >>        High   - Little to no data loss
	> > >> >> >>        Medium - Minimal data loss is accepted
	> > >> >> >>        Low    - Data sent is best effort
	> > >> >> >>
	> > >> >> >>
	> > >> >> >>  The six combinations are shown below...
	> > >> >> >>
	> > >> >> >>
	> > >> >> >>               | Uni  |  Bi
	> > >> >> >>        -------+-----+--------
	> > >> >> >>        High   |  1   |    4
	> > >> >> >>        -------+-----+-------
	> > >> >> >>        Medium |  2   |    5
	> > >> >> >>        -------+-----+-------
	> > >> >> >>        Low    |  3   |    6
	> > >> >> >>
	> > >> >> >>
	> > >> >> >>
	> > >> >> >>  I think (IMHO) the most likely combinations are...
	> > >> >> >>
	> > >> >> >>        3. Low reliability and uni-directional. This will be
	> > >> >> >>  used
	> > >> >> >>           where the device and collector are in close
	> > >> >> >>  proximity,
	> > >> >> >>           there is high volume and some data loss is
	> > >> >> >>  acceptable for
	> > >> >> >>           the given application. Applications such as
	> > >> >> >>  Attack/Intrusion Detection
	> > >> >> >>           Traffic Profiling, etc...
	> > >> >> >>
	> > >> >> >>        5. Bi-directional medium reliability. This will be
	> > >> >> >>  used
	> > >> >> >>           where high volume and increased reliability are
	> > >> >> >>  needed. Applications
	> > >> >> >>           such as Usage-based Accounting where 95th
	> > >> >> >>  percentile billing
	> > >> >> >>           model is used. Or even Traffic Engineering where
	> > >> >> >>  network policy
	> > >> >> >>           decisions are based on the data collected.
	> > >> >> >>
	> > >> >> >>        4. Bi-directional high reliability would be used where
	> > >> >> >>  the
	> > >> >> >>           Usage-based Accounting application has strict
	> > >> >> >>  requirements
	> > >> >> >>           on data loss.
	> > >> >> >>
	> > >> >> >>  Does IPFIX need to support multiple levels of reliability
	> > >> >> >>  and directionality?
	> > >> >> >>
	> > >> >> >>  Paul
	> > >> >> >>
	> > >> >> >>  --
	> > >> >> >>  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/
	> > >
	> > >
	>
	> --
	> 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/
	
	

ÿñÞ–™šŠ[hþf£¢·hšçzßÝ¢+ÿÂ+ýçnjwlk/ázZÿŠyž²Æ yºÉIì¹»®&Þ™¨¥¶æj:+v‰¨þw­ýÚ"·ü"±ÏÞvæ§vƲþéì¹»®&ÞŠ—âÇø§™ë,j›¡Ü€­Èb½èm¶Ÿÿþ*_‹Ý¢+ÿÂ+ýçnýªÜ†+Þ


From majordomo@mil.doit.wisc.edu  Mon Nov 18 17:47:40 2002
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 RAA06458
	for ; Mon, 18 Nov 2002 17:47:39 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18DubW-0002Rx-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 18 Nov 2002 16:42:54 -0600
Received: from winger.mail.pas.earthlink.net ([207.217.120.100])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18DubU-0002Rq-00
	for ipfix@net.doit.wisc.edu; Mon, 18 Nov 2002 16:42:52 -0600
Received: from wengerlaptop.it.earthlink.net ([207.217.88.93] helo=paslap000495)
	by winger.mail.pas.earthlink.net with smtp (Exim 3.33 #1)
	id 18DubR-0004OK-00
	for ipfix@net.doit.wisc.edu; Mon, 18 Nov 2002 14:42:49 -0800
From: "Ivan Batanov" 
To: 
Subject: [ipfix] RE: [ipfix-eval] IPDR response to evaluation drafts
Date: Mon, 18 Nov 2002 14:37:51 -0800
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
In-Reply-To: 
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

Hello!

Regarding the current deployment status of IPDR I would like to add my
comments on the lack of current deployment using IPDR streaming protocol
that has been proposed to the IPFIX WG.

To the best of my knowledge there has been no interoperability testing of
this proposed streaming protocol, nor is there any "field proven"
implementation. These remarks do not imply that IPDR streaming would not
work, but the evaluators might not have understood the implications of what
Jeff Meyer's comment:

"The specific procedures introduced in Streaming IPDR are not currently
available with commercial products."
(from http://ipfix.doit.wisc.edu/eval/draft-meyer-ipfix-ipdr-eval-00.txt).

As IPDR NDM-U version 3.1 (the first version with XDR-based data
representation) was just approved in October, 2002 and there are no
production deployments of this substantially new version of the protocol.
IPDR streaming is based on this new data representation, with further
extensions (not yet approved by IPDR.org) for streaming, identified as
future version 4 of the protocol (as documented in the submission) . All
references to interoperability of IPDR are based on previous versions of the
protocol, which are usinb verbose XML instead of the proposed compact binary
representation.

There has been interoperability testing between a few of the IPDR.org
members using libraries implementing the compact reporesentation. Such
libraries are available to the IPDR members. These interoparabilities
typically employ file-based transports (FTP/shared directories) rather than
the proposed streaming IPDR protocol.

"Field proven" for IPDR should be considered to refer to older versions of a
file-based, XML-encoded version of the protocol that does not support
streaming and which is so verbose as to be unusable by IPFIX.

Furthermore, the terms "field proven" or "widely deployed" mentioned here
relate to the "D" interface (as specified in NDM-U 3.1) - the interface
between mediation systems and billing systems - not the "A" interface
(between network elements and mediation systems - which is deemed out of
scope in section 2.4.2.1 of the recently approved NDM-U 3.1). This means
that the field experience of IPDR, besides rare possible exceptions, hasn't
reached routers, switches, or other "devices", but rather was focused on
host-based IPC mechanisms.

Yours sincerely,

Ivan Batanov
Senior Network Engineer
Earthlink, Inc.
e-mail: ivanb@corp.earthlink.net


--
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 Nov 18 18:04:51 2002
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 SAA06861
	for ; Mon, 18 Nov 2002 18:04:51 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18DurI-0002q0-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 18 Nov 2002 16:59:13 -0600
Received: from pool-68-160-192-59.ny325.east.verizon.net ([68.160.192.59] helo=newyork.qosient.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18DurH-0002pt-00
	for ipfix@net.doit.wisc.edu; Mon, 18 Nov 2002 16:59:11 -0600
Received: from sphynx (sphynx [192.168.0.64])
	by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id gAIMxAO05074;
	Mon, 18 Nov 2002 17:59:10 -0500
From: "Carter Bullard" 
To: , 
Subject: RE: [ipfix] Multiple levels of Reliability and Directionality
Date: Mon, 18 Nov 2002 17:59:01 -0500
Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A4C2@ptah.newyork.qosient.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <5C8959A16A71B449AE793CF52FBBED660DABB5@ptah.newyork.qosient.com>
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

Hey Dave,
Hope all is well!  Yes, I apologize for my humor, but
I thought I was being funny, as I never thought capability
negotiation was a requirement.   Of course I should know
better, so I apologize to the list.  I'll try to remember
to put the ole ;0) at the end next time!!!!

Sorry I won't make it to Hotlanta for the meeting,
as I've been glued to the couch since my foot surgery
in Sept.  Atlanta is my home town, mom and siblings are
all there, and so I'll be missing more than just an IETF
event.  Hopefully I'll make the next one, hopefully without
the cast and crutches.

I believe that you guys should make good progress
in coming to some decisions on the protocol.  My vote
is to keep it simple, avoid specifying an IPFIX probe,
and not getting in the way of vendors using IPFIX to
transport new types of IP flow metrics.  It would be a
shame to go to all this effort and not be able to support
the next wave of flow technology.  If there is anyway to
make IPFIX reliable, that would be great, but not at the
expense of getting a usable protocol out the door.  There
is always V2 of everything.

Have fun, and be sure and try the Varsity for fast hamburgers
and hot dogs, its about 10 blocks from the hotel, just across
the Interstate from Georgia Tech.   Mostly a cultural
experience, and the hot dogs are very good.

Best Regards!!

Carter


> -----Original Message-----
> From: majordomo listserver 
> [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Dave Plonka
> Sent: Monday, November 18, 2002 2:49 PM
> To: ipfix@net.doit.wisc.edu
> Cc: Carter Bullard
> Subject: Re: [ipfix] Multiple levels of Reliability and Directionality
> 
> 
> 
> Hi Carter,
> 
> On Mon, Nov 18, 2002 at 02:26:52PM -0500, Carter Bullard wrote:
> >    It may be of interest for the group to look at
> > RFC-3340 which deals with the issues of generic application
> > transport and capability negotiation, as well as reliability.
> > http://www.ietf.org/rfc/rfc3340.txt?number=3340.
> > 
> > Doesn't seem that hard.  When did IPFIX drop capability
> > negotiation as a requirement?
> 
> I don't believe IPFIX ever had capability negotiation as a 
> requirement.
> 
> Quoting from "http://ipfix.doit.wisc.edu/IETF53/minutes.txt":
> 
>    Regarding capability negotiation, consensus amongst attendees (by a
>    hum) was that neither exporter configuration nor capabilities
>    negotiation between collectors and exporters should be addressed by
>    IPFIX.  The chairs will follow-up with a call on the 
> mailing list on
>    this topic.
> 
> I was remiss in not following up beyond posting the minutes 
> to the list
> for review, but AFAIK the issue has not been contentious given our
> "standardize existing practice" mantra and that negotiation 
> hasn't been
> substantively mentioned since before IETF53, when Juergen posted his
> concerns about negotiation feature creep:
> 
   http://ipfix.doit.wisc.edu/archive/0461.html

to which there were no follow-ups.

Dave

-- 
plonka@doit.wisc.edu  http://net.doit.wisc.edu/~plonka  ARS:N9HZF
Madison, WI

--
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 Nov 18 18:40:33 2002
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 SAA07542
	for ; Mon, 18 Nov 2002 18:40:32 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18DvPI-0003ck-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 18 Nov 2002 17:34:20 -0600
Received: from usmail.xacct.com ([204.253.100.12])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18DvPH-0003ce-00
	for ipfix@net.doit.wisc.edu; Mon, 18 Nov 2002 17:34:19 -0600
Received: from peter ([192.168.0.163])
	by usmail.xacct.com (8.11.2/8.11.2) with SMTP id gAINbT222247;
	Mon, 18 Nov 2002 15:37:41 -0800
From: "Peter Ludemann" 
To: "Ganesh Sadasivan" , "Tal Givoly" 
Cc: "'ipfixx'" 
Subject: RE: [ipfix] Multiple levels of Reliability and Directionality
Date: Mon, 18 Nov 2002 15:33:39 -0800
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <3DD936F1.8750F42C@cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

Ganesh Sadasivan wrote Monday, November 18, 2002 10:53 AM:

> See my response to Peter on this topic:
>    http://ipfx.doit.wisc.edu/list/ipfix/archive/0753.html

Ganesh, it seems to me that your position is:

  Ganesh's devices (routers) main job is switching packets; he
  doesn't want to spend one extra cycle where not utterly justified.
  Therefore, Ganesh wants the lowest overhead protocol possible.
  Period.

I agree ... if Ganesh's business case is that his customers
care passionately about packets/sec and not about flow reporting,
who am I to argue?

But if we have a protocol that allows a minimal implementation
(that's what levels of reliability means) without any of the
overheads, what's the problem? (e.g., with CRANE-lite == NetFlowV9).
Those who don't mind paying some of the overheads can have what
they want; and Cisco can provide the minimal outputs that they
believe their customers want. Everybody is happy.

  [A protocol specification that allows higher degrees of
   reliability gives Cisco flexibility if customers do want more flow
   information; Cisco can add a more reliable protocol in the future
   within the same framework (e.g., NetFlowV9-reliable == CRANE).]

For setting the reliability level:
  a. hard-coded in the device and the receiver; or
  b. defined by configuration; or
  c. determined by a simple initial negotiation, like the one
     we have for CRANE -- this was originally designed to allow
     upgrading to a new version of the protocol, but could equally
     well be used for determining reliability level (it's just a
     UDP request to the device, whose response is a list of versions
     and associated transport protocols and ports).

Again, the minimal implementation (which Ganesh seems to want)
requires *no* extra work and no extra performance overhead; only
those who want more need to implement more and spend more CPU cycles.

 -peter


--
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 Nov 18 18:45:33 2002
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 SAA07677
	for ; Mon, 18 Nov 2002 18:45:33 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18DvUr-0003oZ-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 18 Nov 2002 17:40:05 -0600
Received: from srv0.ietf55.ops.ietf.org ([205.238.48.2] helo=srv0.ops.ietf.org)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18DvUp-0003oS-00
	for ipfix@net.doit.wisc.edu; Mon, 18 Nov 2002 17:40:03 -0600
Received: from beta.ietf55.ops.ietf.org ([204.42.66.105] helo=BETA)
	by srv0.ops.ietf.org with esmtp (Exim 4.10)
	id 18DvUo-000PEo-00
	for ipfix@net.doit.wisc.edu; Mon, 18 Nov 2002 23:40:02 +0000
Date: Tue, 19 Nov 2002 00:39:06 +0100
From: Juergen Quittek 
To: ipfix@net.doit.wisc.edu
Subject: [ipfix] charter re-negotiation?
Message-ID: <11880893.1037666346@BETA>
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

Hi all,

I have a request for clarification.

Nevil identified a list consensus on supporting multiple
levels of reliability:

-- Nevil Brownlee wrote on 16 November 2002 08:23 +1300:
>    * It's clear that a 'standard IPFIX' must allow for various levels
>      of reliability.  That suggests either having a base level (MUST) and
>      higher levels (SHOULD and MAY), or having a mnimum set of features
>      which applications can use to implement whatever level of reliability
>      they need. [list consensus]
in http://ipfix.doit.wisc.edu/archive/1462.html

But my understandung of Randy's message http://ipfix.doit.wisc.edu/archive/1408.html
is that the high "carrier class" reliability level is out of scope:

-- Randy Bush wrote on 11 November 2002 09:48 -0800:
> 
>
>> I feel strongly that "typical Internet reliability" is
>> insufficient to make this standard of value for a large set of
>> applications.
>
> this is trivially true.  the question is whether such applications
> are, or should be, in the charter of this wg.  currently they are
> not.  if you wish to change that, then a change to the charter will
> be needed.  in this case, as it would seriously affect many
> parties, that will be a rather inclusive process and success is far
> from sure.
>
> it would be nice if the wg could abjure mission creep.
>
> 

Consequently, if we have consensus that we need more than "typical Internet
reliabiltiy", then we should add the item "charter re-negotiation" to the
agenda of our session on Thursday.

Am I wrong with this assessment?

    Juergen


--
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 Nov 18 20:43:36 2002
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 UAA10469
	for ; Mon, 18 Nov 2002 20:43:35 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18DxHl-0006Iy-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 18 Nov 2002 19:34:41 -0600
Received: from palrel12.hp.com ([156.153.255.237])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18DxHj-0006Iq-00
	for ipfix@net.doit.wisc.edu; Mon, 18 Nov 2002 19:34:39 -0600
Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203])
	by palrel12.hp.com (Postfix) with ESMTP id 1A57DE00E29
	for ; Mon, 18 Nov 2002 17:34:36 -0800 (PST)
Received: from simail.cup.hp.com (imail@sim.cup.hp.com [15.16.123.26])
	by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id RAA08049
	for ; Mon, 18 Nov 2002 17:34:18 -0800 (PST)
Received: from cup.hp.com ([15.16.124.96]) by simail.cup.hp.com
          (InterMail vM.5.01.03.01 201-253-122-118-101-20010319) with ESMTP
          id <20021119013430.BFED1825.simail.cup.hp.com@cup.hp.com>
          for ; Mon, 18 Nov 2002 17:34:30 -0800
Message-ID: <3DD995BE.9000104@cup.hp.com>
Date: Mon, 18 Nov 2002 17:37:02 -0800
From: Jeff Meyer 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3
X-Accept-Language: en-us
MIME-Version: 1.0
To: ipfix@net.doit.wisc.edu
Subject: RE: [ipfix] RE: [ipfix-eval] IPDR response to evaluation drafts
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

Hi,

   Let me correct Ivan's comments.  NDM-U 3.1.1 was approved
in Oct. 2002.  NDM-U 3.0, which introduced the binary
protocol was approved in November 2001.  (See the
revision history on p.5-7 of the specification):

   http://www.ipdr.org/documents/NDM-U_3.1.1.pdf

   Interoperability of the binary/compact IPDR was demonstrated
at BillingWorld2002 in June 2002.  The libraries (in
C and Java) to aid vendors in developing interoperable
implementations were developed between Oct. 2001 and
March 2002.

   As stated in the draft, the addition of the streaming
model for Compact IPDR builds on top of the NDM-U 3.1
specification and has not been deployed, yet.

   Given the wide industry interest I have seen in
reducing the "Tower of Babel" of formats for data,
I believe IPDR offers a tremendous benefit over the
alternatives.

   In particular:

     o a formal data definition language based on a
      subset of XML-Schema.  I.e. don't invent a new
      data definition model, XML-Schema already
      does a fine job.

     o a mapping of this formal definition to both XML
      and binary formats.  For the binary format, don't
      invent a new encoding scheme, reuse an existing
      one, XDR.

     o independence between payload and transport.  I.e.
      this model can be used for file based exchange or
      network connection.  And for those exchange protocols,
      reuse existing mechanisms such as TCP, SCTP, HTTP,
      FTP or SOAP.

   In addition this data modelling approach could be used
to bridge with other protocols, if it is deemed we
really need yet another protocol, we can by using the
same mapping approach used with the XDR.

   For instance if NetflowV9 is seen as being needed for
addressing lower reliability exchange, a mapping of the
data model could be defined.  Likewise for Diameter.


   Basically I'm advocating layering.  And I believe that
the approach taken by IPDR provides a very good framework
for building protocols via composition, rather than
throwing everything into a single pot.


Regards,

   Jeff Meyer


 > -----Original Message-----
 > From: Ivan Batanov [mailto:ivanb@corp.earthlink.net]
 > Sent: Monday, November 18, 2002 2:38 PM
 > To: ipfix@net.doit.wisc.edu
 > Subject: [ipfix] RE: [ipfix-eval] IPDR response to evaluation drafts
 >
 >
 > Hello!
 >
 > Regarding the current deployment status of IPDR I would like to add my
 > comments on the lack of current deployment using IPDR
 > streaming protocol
 > that has been proposed to the IPFIX WG.
 >
 > To the best of my knowledge there has been no
 > interoperability testing of
 > this proposed streaming protocol, nor is there any "field proven"
 > implementation. These remarks do not imply that IPDR
 > streaming would not
 > work, but the evaluators might not have understood the
 > implications of what
 > Jeff Meyer's comment:
 >
 > "The specific procedures introduced in Streaming IPDR are not
 > currently
 > available with commercial products."
 > (from
 > http://ipfix.doit.wisc.edu/eval/draft-meyer-ipfix-ipdr-eval-00.txt).
 >
 > As IPDR NDM-U version 3.1 (the first version with XDR-based data
 > representation) was just approved in October, 2002 and there are no
 > production deployments of this substantially new version of
 > the protocol.
 > IPDR streaming is based on this new data representation, with further
 > extensions (not yet approved by IPDR.org) for streaming, identified as
 > future version 4 of the protocol (as documented in the
 > submission) . All
 > references to interoperability of IPDR are based on previous
 > versions of the
 > protocol, which are usinb verbose XML instead of the proposed
 > compact binary
 > representation.
 >
 > There has been interoperability testing between a few of the IPDR.org
 > members using libraries implementing the compact reporesentation. Such
 > libraries are available to the IPDR members. These interoparabilities
 > typically employ file-based transports (FTP/shared
 > directories) rather than
 > the proposed streaming IPDR protocol.
 >
 > "Field proven" for IPDR should be considered to refer to
 > older versions of a
 > file-based, XML-encoded version of the protocol that does not support
 > streaming and which is so verbose as to be unusable by IPFIX.
 >
 > Furthermore, the terms "field proven" or "widely deployed"
 > mentioned here
 > relate to the "D" interface (as specified in NDM-U 3.1) - the
 > interface
 > between mediation systems and billing systems - not the "A" interface
 > (between network elements and mediation systems - which is
 > deemed out of
 > scope in section 2.4.2.1 of the recently approved NDM-U 3.1).
 > This means
 > that the field experience of IPDR, besides rare possible
 > exceptions, hasn't
 > reached routers, switches, or other "devices", but rather was
 > focused on
 > host-based IPC mechanisms.
 >
 > Yours sincerely,
 >
 > Ivan Batanov
 > Senior Network Engineer
 > Earthlink, Inc.
 > e-mail: ivanb@corp.earthlink.net
 >
 >
 > --
 > 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 Nov 18 20:56:16 2002
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 UAA10702
	for ; Mon, 18 Nov 2002 20:56:16 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18DxTt-0006cx-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 18 Nov 2002 19:47:13 -0600
Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18DxTr-0006c7-00
	for ipfix@net.doit.wisc.edu; Mon, 18 Nov 2002 19:47:11 -0600
Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gAJ1ke613942;
	Mon, 18 Nov 2002 19:46:41 -0600 (CST)
Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 18 Nov 2002 17:46:27 -0800
Message-ID: <0A11633F61BD9F40B43ABCC694004F93299588@zsc3c026.us.nortel.com>
From: "Reinaldo Penno" 
To: Juergen Quittek , ipfix@net.doit.wisc.edu
Subject: RE: [ipfix] charter re-negotiation?
Date: Mon, 18 Nov 2002 17:46:27 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C28F6D.796E85AE"
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_01C28F6D.796E85AE
Content-Type: text/plain;
	charset="iso-8859-1"

Hello Juergen,

I disagree. The charter is already explicit about billing and accounting.
You cannot be more explicit than this..

"As such, there is a need in industry and the Internet research community
for IP devices such as routers to export flow information in a standard way
to external systems such as mediation systems, accounting/billing systems,
and network management systems to facilitate services such as Internet
research, measurement, accounting, and billing. "

There was also already a lot of feedback on the list supporting different
kinds of billing/accounting requirements. What else is needed? 

Now, if someone's interpretation/thinking of the sentence above is regarding
some unique mode of billing and accounting or some special billing and
accounting...well...what is to say? 

regards,

Reinaldo

I will also ask again: What is the meaning of "Typical Internet
reliability"? People are throwing this concept around I still do not know
what it means. 


> -----Original Message-----
> From: Juergen Quittek [mailto:quittek@ccrle.nec.de]
> Sent: Monday, November 18, 2002 6:39 PM
> To: ipfix@net.doit.wisc.edu
> Subject: [ipfix] charter re-negotiation?
> 
> 
> Hi all,
> 
> I have a request for clarification.
> 
> Nevil identified a list consensus on supporting multiple
> levels of reliability:
> 
> -- Nevil Brownlee wrote on 16 November 2002 08:23 +1300:
> >    * It's clear that a 'standard IPFIX' must allow for 
> various levels
> >      of reliability.  That suggests either having a base 
> level (MUST) and
> >      higher levels (SHOULD and MAY), or having a mnimum set 
> of features
> >      which applications can use to implement whatever level 
> of reliability
> >      they need. [list consensus]
> in http://ipfix.doit.wisc.edu/archive/1462.html
> 
> But my understandung of Randy's message 
> http://ipfix.doit.wisc.edu/archive/1408.html
> is that the high "carrier class" reliability level is out of scope:
> 
> -- Randy Bush wrote on 11 November 2002 09:48 -0800:
> > 
> >
> >> I feel strongly that "typical Internet reliability" is
> >> insufficient to make this standard of value for a large set of
> >> applications.
> >
> > this is trivially true.  the question is whether such applications
> > are, or should be, in the charter of this wg.  currently they are
> > not.  if you wish to change that, then a change to the charter will
> > be needed.  in this case, as it would seriously affect many
> > parties, that will be a rather inclusive process and success is far
> > from sure.
> >
> > it would be nice if the wg could abjure mission creep.
> >
> > 
> 
> Consequently, if we have consensus that we need more than 
> "typical Internet
> reliabiltiy", then we should add the item "charter 
> re-negotiation" to the
> agenda of our session on Thursday.
> 
> Am I wrong with this assessment?
> 
>     Juergen
> 
> 
> --
> 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/
> 

------_=_NextPart_001_01C28F6D.796E85AE
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [ipfix] charter re-negotiation?




Hello Juergen,




I disagree. The charter is already explicit about =
billing and accounting. You cannot be more explicit than this..




"As such, there is a need in industry and the =
Internet research community for IP devices such as routers to export =
flow information in a standard way to external systems such as =
mediation systems, accounting/billing systems, and network management =
systems to facilitate services such as Internet research, measurement, =
accounting, and billing. "



There was also already a lot of feedback on the list =
supporting different kinds of billing/accounting requirements. What =
else is needed? 



Now, if someone's interpretation/thinking of the =
sentence above is regarding some unique mode of billing and accounting =
or some special billing and accounting...well...what is to say? =




regards,




Reinaldo




I will also ask again: What is the meaning of =
"Typical Internet reliability"? People are throwing this =
concept around I still do not know what it means. 





> -----Original Message-----

> From: Juergen Quittek [mailto:quittek@ccrle.nec.de]

> Sent: Monday, November 18, 2002 6:39 PM

> To: ipfix@net.doit.wisc.edu

> Subject: [ipfix] charter re-negotiation?

> 

> 

> Hi all,

> 

> I have a request for clarification.

> 

> Nevil identified a list consensus on supporting =
multiple

> levels of reliability:

> 

> -- Nevil Brownlee wrote on 16 November 2002 =
08:23 +1300:

> >    * It's clear that a =
'standard IPFIX' must allow for 

> various levels

> >      of =
reliability.  That suggests either having a base 

> level (MUST) and

> >      higher =
levels (SHOULD and MAY), or having a mnimum set 

> of features

> >      which =
applications can use to implement whatever level 

> of reliability

> >      they need. =
[list consensus]

> in http://ipfix.doit.wisc.edu/archive/1462.html

> 

> But my understandung of Randy's message 

> http://ipfix.doit.wisc.edu/archive/1408.html

> is that the high "carrier class" =
reliability level is out of scope:

> 

> -- Randy Bush wrote on 11 November 2002 09:48 =
-0800:

> > <ad>

> >

> >> I feel strongly that "typical =
Internet reliability" is

> >> insufficient to make this standard of =
value for a large set of

> >> applications.

> >

> > this is trivially true.  the question =
is whether such applications

> > are, or should be, in the charter of this =
wg.  currently they are

> > not.  if you wish to change that, =
then a change to the charter will

> > be needed.  in this case, as it would =
seriously affect many

> > parties, that will be a rather inclusive =
process and success is far

> > from sure.

> >

> > it would be nice if the wg could abjure =
mission creep.

> >

> > </ad>

> 

> Consequently, if we have consensus that we need =
more than 

> "typical Internet

> reliabiltiy", then we should add the item =
"charter 

> re-negotiation" to the

> agenda of our session on Thursday.

> 

> Am I wrong with this assessment?

> 

>     Juergen

> 

> 

> --

> Help        =
mailto:majordomo@net.doit.wi=
sc.edu and say "help" 

> in message body

> Unsubscribe mailto:majordomo@net.doit.wi=
sc.edu and say

> "unsubscribe ipfix" in message =
body

> Archive     http://ipfix.doit.wisc.edu/archive/

> 





------_=_NextPart_001_01C28F6D.796E85AE--

--
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 Nov 18 22:56:19 2002
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 WAA14227
	for ; Mon, 18 Nov 2002 22:56:18 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18DzKr-0001SC-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 18 Nov 2002 21:46:01 -0600
Received: from srv0.ietf55.ops.ietf.org ([205.238.48.2] helo=srv0.ops.ietf.org)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18DzKp-0001Rz-00
	for ipfix@net.doit.wisc.edu; Mon, 18 Nov 2002 21:45:59 -0600
Received: from beta.ietf55.ops.ietf.org ([204.42.66.105] helo=BETA)
	by srv0.ops.ietf.org with esmtp (Exim 4.10)
	id 18DzKj-0001ZE-00; Tue, 19 Nov 2002 03:45:53 +0000
Date: Tue, 19 Nov 2002 04:44:56 +0100
From: Juergen Quittek 
To: Reinaldo Penno , ipfix@net.doit.wisc.edu
Subject: RE: [ipfix] charter re-negotiation?
Message-ID: <26629731.1037681095@BETA>
In-Reply-To: <0A11633F61BD9F40B43ABCC694004F93299588@zsc3c026.us.nortel.com>
References:  <0A11633F61BD9F40B43ABCC694004F93299588@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,

I agree that accounting and billing are applications included in
the charter. However, they do not necessarily require high reliability.

They can operate with different levels of reliability. If they can't,
they are not covered by the current charter. Quoting Randy with AD hat on:
  "the question is whether such applications are, or should be,
   in the charter of this wg.  currently they are not."
This is a clear statement giving very little freedom to interpretation.

Therefore, I think we need re-chartering if we want to support them.

    Juergen





-- Reinaldo Penno wrote on 18 November 2002 17:46 -0800:

> Hello Juergen,
>
> I disagree. The charter is already explicit about billing and accounting.
> You cannot be more explicit than this..
>
> "As such, there is a need in industry and the Internet research community
> for IP devices such as routers to export flow information in a standard way
> to external systems such as mediation systems, accounting/billing systems,
> and network management systems to facilitate services such as Internet
> research, measurement, accounting, and billing. "
>
> There was also already a lot of feedback on the list supporting different
> kinds of billing/accounting requirements. What else is needed?
>
> Now, if someone's interpretation/thinking of the sentence above is regarding
> some unique mode of billing and accounting or some special billing and
> accounting...well...what is to say?
>
> regards,
>
> Reinaldo
>
> I will also ask again: What is the meaning of "Typical Internet
> reliability"? People are throwing this concept around I still do not know
> what it means.
>
>
>> -----Original Message-----
>> From: Juergen Quittek [mailto:quittek@ccrle.nec.de]
>> Sent: Monday, November 18, 2002 6:39 PM
>> To: ipfix@net.doit.wisc.edu
>> Subject: [ipfix] charter re-negotiation?
>>
>>
>> Hi all,
>>
>> I have a request for clarification.
>>
>> Nevil identified a list consensus on supporting multiple
>> levels of reliability:
>>
>> -- Nevil Brownlee wrote on 16 November 2002 08:23 +1300:
>> >    * It's clear that a 'standard IPFIX' must allow for
>> various levels
>> >      of reliability.  That suggests either having a base
>> level (MUST) and
>> >      higher levels (SHOULD and MAY), or having a mnimum set
>> of features
>> >      which applications can use to implement whatever level
>> of reliability
>> >      they need. [list consensus]
>> in http://ipfix.doit.wisc.edu/archive/1462.html
>>
>> But my understandung of Randy's message
>> http://ipfix.doit.wisc.edu/archive/1408.html
>> is that the high "carrier class" reliability level is out of scope:
>>
>> -- Randy Bush wrote on 11 November 2002 09:48 -0800:
>> > 
>> >
>> >> I feel strongly that "typical Internet reliability" is
>> >> insufficient to make this standard of value for a large set of
>> >> applications.
>> >
>> > this is trivially true.  the question is whether such applications
>> > are, or should be, in the charter of this wg.  currently they are
>> > not.  if you wish to change that, then a change to the charter will
>> > be needed.  in this case, as it would seriously affect many
>> > parties, that will be a rather inclusive process and success is far
>> > from sure.
>> >
>> > it would be nice if the wg could abjure mission creep.
>> >
>> > 
>>
>> Consequently, if we have consensus that we need more than
>> "typical Internet
>> reliabiltiy", then we should add the item "charter
>> re-negotiation" to the
>> agenda of our session on Thursday.
>>
>> Am I wrong with this assessment?
>>
>>     Juergen
>>
>>
>> --
>> 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 Nov 18 23:31:54 2002
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 XAA14875
	for ; Mon, 18 Nov 2002 23:31:54 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18Dzy3-0002RO-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 18 Nov 2002 22:26:32 -0600
Received: from pool-68-160-192-59.ny325.east.verizon.net ([68.160.192.59] helo=newyork.qosient.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18Dzy2-0002RF-00
	for ipfix@net.doit.wisc.edu; Mon, 18 Nov 2002 22:26:30 -0600
Received: from SET (set [192.168.0.161])
	by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id gAJ4QTO05500;
	Mon, 18 Nov 2002 23:26:29 -0500
Reply-To: 
From: "Carter Bullard" 
To: "'Reinaldo Penno'" ,
        "'Juergen Quittek'" , 
Subject: RE: [ipfix] charter re-negotiation?
Date: Mon, 18 Nov 2002 23:26:14 -0500
Organization: QoSient, LLC
Message-ID: <5C8959A16A71B449AE793CF52FBBED6607E6FD@ptah.newyork.qosient.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
In-Reply-To: <5C8959A16A71B449AE793CF52FBBED660DAD23@ptah.newyork.qosient.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

Hey Reinaldo,
   I would interpret "traditional Internet reliability" 
as "best effort", which I interpret as unreliable.

Carter



-----Original Message-----
From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] On
Behalf Of Reinaldo Penno
Sent: Monday, November 18, 2002 8:46 PM
To: Juergen Quittek; ipfix@net.doit.wisc.edu
Subject: RE: [ipfix] charter re-negotiation?


Hello Juergen, 
I disagree. The charter is already explicit about billing and
accounting. You cannot be more explicit than this.. 
"As such, there is a need in industry and the Internet research
community for IP devices such as routers to export flow information in a
standard way to external systems such as mediation systems,
accounting/billing systems, and network management systems to facilitate
services such as Internet research, measurement, accounting, and
billing. "
There was also already a lot of feedback on the list supporting
different kinds of billing/accounting requirements. What else is needed?

Now, if someone's interpretation/thinking of the sentence above is
regarding some unique mode of billing and accounting or some special
billing and accounting...well...what is to say? 
regards, 
Reinaldo 
I will also ask again: What is the meaning of "Typical Internet
reliability"? People are throwing this concept around I still do not
know what it means. 


> -----Original Message----- 
> From: Juergen Quittek [mailto:quittek@ccrle.nec.de] 
> Sent: Monday, November 18, 2002 6:39 PM 
> To: ipfix@net.doit.wisc.edu 
> Subject: [ipfix] charter re-negotiation? 
> 
> 
> Hi all, 
> 
> I have a request for clarification. 
> 
> Nevil identified a list consensus on supporting multiple 
> levels of reliability: 
> 
> -- Nevil Brownlee wrote on 16 November 2002 08:23 +1300: 
> >    * It's clear that a 'standard IPFIX' must allow for 
> various levels 
> >      of reliability.  That suggests either having a base 
> level (MUST) and 
> >      higher levels (SHOULD and MAY), or having a mnimum set 
> of features 
> >      which applications can use to implement whatever level 
> of reliability 
> >      they need. [list consensus] 
> in http://ipfix.doit.wisc.edu/archive/1462.html 
> 
> But my understandung of Randy's message 
> http://ipfix.doit.wisc.edu/archive/1408.html 
> is that the high "carrier class" reliability level is out of scope: 
> 
> -- Randy Bush wrote on 11 November 2002 09:48 -0800: 
> >  
> > 
> >> I feel strongly that "typical Internet reliability" is 
> >> insufficient to make this standard of value for a large set of 
> >> applications. 
> > 
> > this is trivially true.  the question is whether such applications 
> > are, or should be, in the charter of this wg.  currently they are 
> > not.  if you wish to change that, then a change to the charter will 
> > be needed.  in this case, as it would seriously affect many 
> > parties, that will be a rather inclusive process and success is far 
> > from sure. 
> > 
> > it would be nice if the wg could abjure mission creep. 
> > 
> >  
> 
> Consequently, if we have consensus that we need more than 
> "typical Internet 
> reliabiltiy", then we should add the item "charter 
> re-negotiation" to the 
> agenda of our session on Thursday. 
> 
> Am I wrong with this assessment? 
> 
>     Juergen 
> 
> 
> -- 
> 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 Nov 19 00:15:37 2002
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 AAA15651
	for ; Tue, 19 Nov 2002 00:15:37 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18E0ZJ-0003Dk-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 18 Nov 2002 23:05:01 -0600
Received: from usmail.xacct.com ([204.253.100.12])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18E0ZH-0003DQ-00
	for ipfix@net.doit.wisc.edu; Mon, 18 Nov 2002 23:04:59 -0600
Received: from Givoly ([192.168.0.2])
	by usmail.xacct.com (8.11.2/8.11.2) with SMTP id gAJ58F225869;
	Mon, 18 Nov 2002 21:08:23 -0800
From: "Tal Givoly" 
To: "Juergen Quittek" ,
        "Reinaldo Penno" ,
        
Subject: RE: [ipfix] charter re-negotiation?
Date: Mon, 18 Nov 2002 21:04:19 -0800
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <26629731.1037681095@BETA>
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

I must agree with Reinaldo.

a) Billing and Accounting are part of the charter. Otherwise, we would not
have been involved to begin with. Furthermore, I made arguments to this
affect in previous postings.
b) "typical Internet reliability" is "best effort" - as Carter says -
unreliable at best, obviously ambiguous.
c) Billing applications do require high reliabilty. I'm sure Jeff can attest
to the extent to which carriers sometimes go to ensure reliable delivery of
data all the way from network/service elements to business support systems.
We have over 80 customers world wide. Many of which are Tier-1 carriers. For
them, lost usage data may imply lost revenue. Lost data in minds of many of
our customers is inexcusable. There are many levels/degrees of reliability
offered. These degrees have various impacts on devices and on collecting
systems. The various protocols proposed have various degrees of reliability.
d) As I urged earlier, we need to decide whether "standardizing NetFlow" is
the charter, or finding something that supports the various applications
mentioned explicitly in the charter and requirements document.

Tal

-----Original Message-----
From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf
Of Juergen Quittek
Sent: Monday, November 18, 2002 7:45 PM
To: Reinaldo Penno; ipfix@net.doit.wisc.edu
Subject: RE: [ipfix] charter re-negotiation?


Reinaldo,

I agree that accounting and billing are applications included in
the charter. However, they do not necessarily require high reliability.

They can operate with different levels of reliability. If they can't,
they are not covered by the current charter. Quoting Randy with AD hat on:
  "the question is whether such applications are, or should be,
   in the charter of this wg.  currently they are not."
This is a clear statement giving very little freedom to interpretation.

Therefore, I think we need re-chartering if we want to support them.

    Juergen





-- Reinaldo Penno wrote on 18 November 2002 17:46 -0800:

> Hello Juergen,
>
> I disagree. The charter is already explicit about billing and accounting.
> You cannot be more explicit than this..
>
> "As such, there is a need in industry and the Internet research community
> for IP devices such as routers to export flow information in a standard
way
> to external systems such as mediation systems, accounting/billing systems,
> and network management systems to facilitate services such as Internet
> research, measurement, accounting, and billing. "
>
> There was also already a lot of feedback on the list supporting different
> kinds of billing/accounting requirements. What else is needed?
>
> Now, if someone's interpretation/thinking of the sentence above is
regarding
> some unique mode of billing and accounting or some special billing and
> accounting...well...what is to say?
>
> regards,
>
> Reinaldo
>
> I will also ask again: What is the meaning of "Typical Internet
> reliability"? People are throwing this concept around I still do not know
> what it means.
>
>
>> -----Original Message-----
>> From: Juergen Quittek [mailto:quittek@ccrle.nec.de]
>> Sent: Monday, November 18, 2002 6:39 PM
>> To: ipfix@net.doit.wisc.edu
>> Subject: [ipfix] charter re-negotiation?
>>
>>
>> Hi all,
>>
>> I have a request for clarification.
>>
>> Nevil identified a list consensus on supporting multiple
>> levels of reliability:
>>
>> -- Nevil Brownlee wrote on 16 November 2002 08:23 +1300:
>> >    * It's clear that a 'standard IPFIX' must allow for
>> various levels
>> >      of reliability.  That suggests either having a base
>> level (MUST) and
>> >      higher levels (SHOULD and MAY), or having a mnimum set
>> of features
>> >      which applications can use to implement whatever level
>> of reliability
>> >      they need. [list consensus]
>> in http://ipfix.doit.wisc.edu/archive/1462.html
>>
>> But my understandung of Randy's message
>> http://ipfix.doit.wisc.edu/archive/1408.html
>> is that the high "carrier class" reliability level is out of scope:
>>
>> -- Randy Bush wrote on 11 November 2002 09:48 -0800:
>> > 
>> >
>> >> I feel strongly that "typical Internet reliability" is
>> >> insufficient to make this standard of value for a large set of
>> >> applications.
>> >
>> > this is trivially true.  the question is whether such applications
>> > are, or should be, in the charter of this wg.  currently they are
>> > not.  if you wish to change that, then a change to the charter will
>> > be needed.  in this case, as it would seriously affect many
>> > parties, that will be a rather inclusive process and success is far
>> > from sure.
>> >
>> > it would be nice if the wg could abjure mission creep.
>> >
>> > 
>>
>> Consequently, if we have consensus that we need more than
>> "typical Internet
>> reliabiltiy", then we should add the item "charter
>> re-negotiation" to the
>> agenda of our session on Thursday.
>>
>> Am I wrong with this assessment?
>>
>>     Juergen
>>
>>
>> --
>> 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 Nov 19 00:55:48 2002
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 AAA16411
	for ; Tue, 19 Nov 2002 00:55:48 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18E19a-00044k-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 18 Nov 2002 23:42:30 -0600
Received: from srv0.ietf55.ops.ietf.org ([205.238.48.2] helo=srv0.ops.ietf.org)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18E19Y-00044c-00
	for ipfix@net.doit.wisc.edu; Mon, 18 Nov 2002 23:42:28 -0600
Received: from beta.ietf55.ops.ietf.org ([204.42.66.105] helo=BETA)
	by srv0.ops.ietf.org with esmtp (Exim 4.10)
	id 18E19V-0002Ym-00; Tue, 19 Nov 2002 05:42:25 +0000
Date: Tue, 19 Nov 2002 06:41:30 +0100
From: Juergen Quittek 
To: Tal Givoly , Reinaldo Penno ,
        ipfix@net.doit.wisc.edu
Subject: RE: [ipfix] charter re-negotiation?
Message-ID: <1886582.1037688089@BETA>
In-Reply-To: 
References:  
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

Tal,

-- Tal Givoly wrote on 18 November 2002 21:04 -0800:

> I must agree with Reinaldo.
>
> a) Billing and Accounting are part of the charter. Otherwise, we would not
> have been involved to begin with. Furthermore, I made arguments to this
> affect in previous postings.

No disagreement at all. This is obvious.

> b) "typical Internet reliability" is "best effort" - as Carter says -
> unreliable at best, obviously ambiguous.

Everything is unreliable. This is just polemics.
Do you know any operator that never ever issued a wrong bill?

> c) Billing applications do require high reliabilty. I'm sure Jeff can attest

Most do, some don't. But here Randy's statement is very clear: if they do,
they are not covered by the current charter. Or can you tell me how to
interpret his statement otherwise?

> to the extent to which carriers sometimes go to ensure reliable delivery of
> data all the way from network/service elements to business support systems.
> We have over 80 customers world wide. Many of which are Tier-1 carriers. For
> them, lost usage data may imply lost revenue. Lost data in minds of many of

If you have an average loss of 1% of accounting data, you can cover your
operational cost with a tariff that is about 1% higher than the one you would
offer with a loss of 0.001% of all accounting data.

But most probably your tariff would be even lower, because equipment with
1% loss tends to be much cheaper than equipment guaranteeing 0.001% loss.

> our customers is inexcusable. There are many levels/degrees of reliability
> offered. These degrees have various impacts on devices and on collecting
> systems. The various protocols proposed have various degrees of reliability.
> d) As I urged earlier, we need to decide whether "standardizing NetFlow" is
> the charter, or finding something that supports the various applications
> mentioned explicitly in the charter and requirements document.

We just need to realize, that standardizing something with a reliability
similar to NetFlow is intended by the charter.

>
> Tal
>
> -----Original Message-----
> From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf
> Of Juergen Quittek
> Sent: Monday, November 18, 2002 7:45 PM
> To: Reinaldo Penno; ipfix@net.doit.wisc.edu
> Subject: RE: [ipfix] charter re-negotiation?
>
>
> Reinaldo,
>
> I agree that accounting and billing are applications included in
> the charter. However, they do not necessarily require high reliability.
>
> They can operate with different levels of reliability. If they can't,
> they are not covered by the current charter. Quoting Randy with AD hat on:
>   "the question is whether such applications are, or should be,
>    in the charter of this wg.  currently they are not."
> This is a clear statement giving very little freedom to interpretation.
>
> Therefore, I think we need re-chartering if we want to support them.
>
>     Juergen
>
>
>
>
>
> -- Reinaldo Penno wrote on 18 November 2002 17:46 -0800:
>
>> Hello Juergen,
>>
>> I disagree. The charter is already explicit about billing and accounting.
>> You cannot be more explicit than this..
>>
>> "As such, there is a need in industry and the Internet research community
>> for IP devices such as routers to export flow information in a standard
> way
>> to external systems such as mediation systems, accounting/billing systems,
>> and network management systems to facilitate services such as Internet
>> research, measurement, accounting, and billing. "
>>
>> There was also already a lot of feedback on the list supporting different
>> kinds of billing/accounting requirements. What else is needed?
>>
>> Now, if someone's interpretation/thinking of the sentence above is
> regarding
>> some unique mode of billing and accounting or some special billing and
>> accounting...well...what is to say?
>>
>> regards,
>>
>> Reinaldo
>>
>> I will also ask again: What is the meaning of "Typical Internet
>> reliability"? People are throwing this concept around I still do not know
>> what it means.
>>
>>
>>> -----Original Message-----
>>> From: Juergen Quittek [mailto:quittek@ccrle.nec.de]
>>> Sent: Monday, November 18, 2002 6:39 PM
>>> To: ipfix@net.doit.wisc.edu
>>> Subject: [ipfix] charter re-negotiation?
>>>
>>>
>>> Hi all,
>>>
>>> I have a request for clarification.
>>>
>>> Nevil identified a list consensus on supporting multiple
>>> levels of reliability:
>>>
>>> -- Nevil Brownlee wrote on 16 November 2002 08:23 +1300:
>>> >    * It's clear that a 'standard IPFIX' must allow for
>>> various levels
>>> >      of reliability.  That suggests either having a base
>>> level (MUST) and
>>> >      higher levels (SHOULD and MAY), or having a mnimum set
>>> of features
>>> >      which applications can use to implement whatever level
>>> of reliability
>>> >      they need. [list consensus]
>>> in http://ipfix.doit.wisc.edu/archive/1462.html
>>>
>>> But my understandung of Randy's message
>>> http://ipfix.doit.wisc.edu/archive/1408.html
>>> is that the high "carrier class" reliability level is out of scope:
>>>
>>> -- Randy Bush wrote on 11 November 2002 09:48 -0800:
>>> > 
>>> >
>>> >> I feel strongly that "typical Internet reliability" is
>>> >> insufficient to make this standard of value for a large set of
>>> >> applications.
>>> >
>>> > this is trivially true.  the question is whether such applications
>>> > are, or should be, in the charter of this wg.  currently they are
>>> > not.  if you wish to change that, then a change to the charter will
>>> > be needed.  in this case, as it would seriously affect many
>>> > parties, that will be a rather inclusive process and success is far
>>> > from sure.
>>> >
>>> > it would be nice if the wg could abjure mission creep.
>>> >
>>> > 
>>>
>>> Consequently, if we have consensus that we need more than
>>> "typical Internet
>>> reliabiltiy", then we should add the item "charter
>>> re-negotiation" to the
>>> agenda of our session on Thursday.
>>>
>>> Am I wrong with this assessment?
>>>
>>>     Juergen
>>>
>>>
>>> --
>>> 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 Nov 19 01:18:17 2002
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 BAA16851
	for ; Tue, 19 Nov 2002 01:18:17 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18E1W4-0004Z8-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 19 Nov 2002 00:05:44 -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 18E1W2-0004Xw-00
	for ipfix@net.doit.wisc.edu; Tue, 19 Nov 2002 00:05:42 -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 gAJ63dU20355;
	Mon, 18 Nov 2002 22:03:39 -0800 (PST)
Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 18 Nov 2002 22:03:39 -0800
Message-ID: <0A11633F61BD9F40B43ABCC694004F932995FE@zsc3c026.us.nortel.com>
From: "Reinaldo Penno" 
To: Juergen Quittek , Tal Givoly ,
        ipfix@net.doit.wisc.edu
Subject: RE: [ipfix] charter re-negotiation?
Date: Mon, 18 Nov 2002 22:03:38 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C28F91.6753B848"
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_01C28F91.6753B848
Content-Type: text/plain;
	charset="iso-8859-1"



> -----Original Message-----
> From: Juergen Quittek [mailto:quittek@ccrle.nec.de]
> Sent: Tuesday, November 19, 2002 12:42 AM
> To: Tal Givoly; Penno, Reinaldo [BL60:0430:EXCH];
> ipfix@net.doit.wisc.edu
> Subject: RE: [ipfix] charter re-negotiation?
> 
> 
> Tal,
> 
> -- Tal Givoly wrote on 18 November 2002 21:04 -0800:
> 
> > I must agree with Reinaldo.
> >
> > a) Billing and Accounting are part of the charter. 
> Otherwise, we would not
> > have been involved to begin with. Furthermore, I made 
> arguments to this
> > affect in previous postings.
> 
> No disagreement at all. This is obvious.
> 
> > b) "typical Internet reliability" is "best effort" - as 
> Carter says -
> > unreliable at best, obviously ambiguous.
> 
> Everything is unreliable. This is just polemics.
> Do you know any operator that never ever issued a wrong bill?
> 
> > c) Billing applications do require high reliabilty. I'm 
> sure Jeff can attest
> 
> Most do, some don't. But here Randy's statement is very 
> clear: if they do,
> they are not covered by the current charter. Or can you tell me how to
> interpret his statement otherwise?
> 
> > to the extent to which carriers sometimes go to ensure 
> reliable delivery of
> > data all the way from network/service elements to business 
> support systems.
> > We have over 80 customers world wide. Many of which are 
> Tier-1 carriers. For
> > them, lost usage data may imply lost revenue. Lost data in 
> minds of many of
> 
> If you have an average loss of 1% of accounting data, you can 
> cover your
> operational cost with a tariff that is about 1% higher than 
> the one you would
> offer with a loss of 0.001% of all accounting data.
> 
> But most probably your tariff would be even lower, because 
> equipment with
> 1% loss tends to be much cheaper than equipment guaranteeing 
> 0.001% loss.
> 
> > our customers is inexcusable. There are many levels/degrees 
> of reliability
> > offered. These degrees have various impacts on devices and 
> on collecting
> > systems. The various protocols proposed have various 
> degrees of reliability.
> > d) As I urged earlier, we need to decide whether 
> "standardizing NetFlow" is
> > the charter, or finding something that supports the various 
> applications
> > mentioned explicitly in the charter and requirements document.
> 
> We just need to realize, that standardizing something with a 
> reliability
> similar to NetFlow is intended by the charter.

What you mean by "need to realize, that standardizing something with a
reliability similar to NetFlow is intended by the charter"? ohh, never
mind...

Anyway, personally I would like us to tackle these applications (of course
we can be fair not imposing high reliability all the time), but my
participation in this group is not driven by it. 

On the other hand I have to say that unfortunately there might be people
that spent money-$$, time and effort on this initiative based on what is
written in the charter and maybe wouldn't if the charter was more explicit.
IMO many IETFs later saying that since the beggining "accounting and
billing" actually meant "acounting and billing with typical reliability" and
that we need to realize that "standardizing something with a reliability
similar to Netflow is intended by the charter" is something that might not
be taken lightly at all. Well, nobody can say bad things about laywers in
this case...

-RP


> 
> >
> > Tal
> >
> > -----Original Message-----
> > From: majordomo listserver 
> [mailto:majordomo@mil.doit.wisc.edu]On Behalf
> > Of Juergen Quittek
> > Sent: Monday, November 18, 2002 7:45 PM
> > To: Reinaldo Penno; ipfix@net.doit.wisc.edu
> > Subject: RE: [ipfix] charter re-negotiation?
> >
> >
> > Reinaldo,
> >
> > I agree that accounting and billing are applications included in
> > the charter. However, they do not necessarily require high 
> reliability.
> >
> > They can operate with different levels of reliability. If 
> they can't,
> > they are not covered by the current charter. Quoting Randy 
> with AD hat on:
> >   "the question is whether such applications are, or should be,
> >    in the charter of this wg.  currently they are not."
> > This is a clear statement giving very little freedom to 
> interpretation.
> >
> > Therefore, I think we need re-chartering if we want to support them.
> >
> >     Juergen
> >
> >
> >
> >
> >
> > -- Reinaldo Penno wrote on 18 November 2002 17:46 -0800:
> >
> >> Hello Juergen,
> >>
> >> I disagree. The charter is already explicit about billing 
> and accounting.
> >> You cannot be more explicit than this..
> >>
> >> "As such, there is a need in industry and the Internet 
> research community
> >> for IP devices such as routers to export flow information 
> in a standard
> > way
> >> to external systems such as mediation systems, 
> accounting/billing systems,
> >> and network management systems to facilitate services such 
> as Internet
> >> research, measurement, accounting, and billing. "
> >>
> >> There was also already a lot of feedback on the list 
> supporting different
> >> kinds of billing/accounting requirements. What else is needed?
> >>
> >> Now, if someone's interpretation/thinking of the sentence above is
> > regarding
> >> some unique mode of billing and accounting or some special 
> billing and
> >> accounting...well...what is to say?
> >>
> >> regards,
> >>
> >> Reinaldo
> >>
> >> I will also ask again: What is the meaning of "Typical Internet
> >> reliability"? People are throwing this concept around I 
> still do not know
> >> what it means.
> >>
> >>
> >>> -----Original Message-----
> >>> From: Juergen Quittek [mailto:quittek@ccrle.nec.de]
> >>> Sent: Monday, November 18, 2002 6:39 PM
> >>> To: ipfix@net.doit.wisc.edu
> >>> Subject: [ipfix] charter re-negotiation?
> >>>
> >>>
> >>> Hi all,
> >>>
> >>> I have a request for clarification.
> >>>
> >>> Nevil identified a list consensus on supporting multiple
> >>> levels of reliability:
> >>>
> >>> -- Nevil Brownlee wrote on 16 November 2002 08:23 +1300:
> >>> >    * It's clear that a 'standard IPFIX' must allow for
> >>> various levels
> >>> >      of reliability.  That suggests either having a base
> >>> level (MUST) and
> >>> >      higher levels (SHOULD and MAY), or having a mnimum set
> >>> of features
> >>> >      which applications can use to implement whatever level
> >>> of reliability
> >>> >      they need. [list consensus]
> >>> in http://ipfix.doit.wisc.edu/archive/1462.html
> >>>
> >>> But my understandung of Randy's message
> >>> http://ipfix.doit.wisc.edu/archive/1408.html
> >>> is that the high "carrier class" reliability level is out 
> of scope:
> >>>
> >>> -- Randy Bush wrote on 11 November 2002 09:48 -0800:
> >>> > 
> >>> >
> >>> >> I feel strongly that "typical Internet reliability" is
> >>> >> insufficient to make this standard of value for a large set of
> >>> >> applications.
> >>> >
> >>> > this is trivially true.  the question is whether such 
> applications
> >>> > are, or should be, in the charter of this wg.  
> currently they are
> >>> > not.  if you wish to change that, then a change to the 
> charter will
> >>> > be needed.  in this case, as it would seriously affect many
> >>> > parties, that will be a rather inclusive process and 
> success is far
> >>> > from sure.
> >>> >
> >>> > it would be nice if the wg could abjure mission creep.
> >>> >
> >>> > 
> >>>
> >>> Consequently, if we have consensus that we need more than
> >>> "typical Internet
> >>> reliabiltiy", then we should add the item "charter
> >>> re-negotiation" to the
> >>> agenda of our session on Thursday.
> >>>
> >>> Am I wrong with this assessment?
> >>>
> >>>     Juergen
> >>>
> >>>
> >>> --
> >>> 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/
> >
> 
> 
> 

------_=_NextPart_001_01C28F91.6753B848
Content-Type: text/html;
	charset="iso-8859-1"






RE: [ipfix] charter re-negotiation?








> -----Original Message-----

> From: Juergen Quittek [mailto:quittek@ccrle.nec.de]

> Sent: Tuesday, November 19, 2002 12:42 AM

> To: Tal Givoly; Penno, Reinaldo [BL60:0430:EXCH];

> ipfix@net.doit.wisc.edu

> Subject: RE: [ipfix] charter re-negotiation?

> 

> 

> Tal,

> 

> -- Tal Givoly wrote on 18 November 2002 21:04 -0800:

> 

> > I must agree with Reinaldo.

> >

> > a) Billing and Accounting are part of the charter. 

> Otherwise, we would not

> > have been involved to begin with. Furthermore, I made 

> arguments to this

> > affect in previous postings.

> 

> No disagreement at all. This is obvious.

> 

> > b) "typical Internet reliability" is "best effort" - as 

> Carter says -

> > unreliable at best, obviously ambiguous.

> 

> Everything is unreliable. This is just polemics.

> Do you know any operator that never ever issued a wrong bill?

> 

> > c) Billing applications do require high reliabilty. I'm 

> sure Jeff can attest

> 

> Most do, some don't. But here Randy's statement is very 

> clear: if they do,

> they are not covered by the current charter. Or can you tell me how to

> interpret his statement otherwise?

> 

> > to the extent to which carriers sometimes go to ensure 

> reliable delivery of

> > data all the way from network/service elements to business 

> support systems.

> > We have over 80 customers world wide. Many of which are 

> Tier-1 carriers. For

> > them, lost usage data may imply lost revenue. Lost data in 

> minds of many of

> 

> If you have an average loss of 1% of accounting data, you can 

> cover your

> operational cost with a tariff that is about 1% higher than 

> the one you would

> offer with a loss of 0.001% of all accounting data.

> 

> But most probably your tariff would be even lower, because 

> equipment with

> 1% loss tends to be much cheaper than equipment guaranteeing 

> 0.001% loss.

> 

> > our customers is inexcusable. There are many levels/degrees 

> of reliability

> > offered. These degrees have various impacts on devices and 

> on collecting

> > systems. The various protocols proposed have various 

> degrees of reliability.

> > d) As I urged earlier, we need to decide whether 

> "standardizing NetFlow" is

> > the charter, or finding something that supports the various 

> applications

> > mentioned explicitly in the charter and requirements document.

> 

> We just need to realize, that standardizing something with a 

> reliability

> similar to NetFlow is intended by the charter.




What you mean by "need to realize, that standardizing something with a reliability similar to NetFlow is intended by the charter"? ohh, never mind...



Anyway, personally I would like us to tackle these applications (of course we can be fair not imposing high reliability all the time), but my participation in this group is not driven by it. 



On the other hand I have to say that unfortunately there might be people that spent money-$$, time and effort on this initiative based on what is written in the charter and maybe wouldn't if the charter was more explicit. IMO many IETFs later saying that since the beggining "accounting and billing" actually meant "acounting and billing with typical reliability" and that we need to realize that "standardizing something with a reliability similar to Netflow is intended by the charter" is something that might not be taken lightly at all. Well, nobody can say bad things about laywers in this case...



-RP






> 

> >

> > Tal

> >

> > -----Original Message-----

> > From: majordomo listserver 

> [mailto:majordomo@mil.doit.wisc.edu]On Behalf

> > Of Juergen Quittek

> > Sent: Monday, November 18, 2002 7:45 PM

> > To: Reinaldo Penno; ipfix@net.doit.wisc.edu

> > Subject: RE: [ipfix] charter re-negotiation?

> >

> >

> > Reinaldo,

> >

> > I agree that accounting and billing are applications included in

> > the charter. However, they do not necessarily require high 

> reliability.

> >

> > They can operate with different levels of reliability. If 

> they can't,

> > they are not covered by the current charter. Quoting Randy 

> with AD hat on:

> >   "the question is whether such applications are, or should be,

> >    in the charter of this wg.  currently they are not."

> > This is a clear statement giving very little freedom to 

> interpretation.

> >

> > Therefore, I think we need re-chartering if we want to support them.

> >

> >     Juergen

> >

> >

> >

> >

> >

> > -- Reinaldo Penno wrote on 18 November 2002 17:46 -0800:

> >

> >> Hello Juergen,

> >>

> >> I disagree. The charter is already explicit about billing 

> and accounting.

> >> You cannot be more explicit than this..

> >>

> >> "As such, there is a need in industry and the Internet 

> research community

> >> for IP devices such as routers to export flow information 

> in a standard

> > way

> >> to external systems such as mediation systems, 

> accounting/billing systems,

> >> and network management systems to facilitate services such 

> as Internet

> >> research, measurement, accounting, and billing. "

> >>

> >> There was also already a lot of feedback on the list 

> supporting different

> >> kinds of billing/accounting requirements. What else is needed?

> >>

> >> Now, if someone's interpretation/thinking of the sentence above is

> > regarding

> >> some unique mode of billing and accounting or some special 

> billing and

> >> accounting...well...what is to say?

> >>

> >> regards,

> >>

> >> Reinaldo

> >>

> >> I will also ask again: What is the meaning of "Typical Internet

> >> reliability"? People are throwing this concept around I 

> still do not know

> >> what it means.

> >>

> >>

> >>> -----Original Message-----

> >>> From: Juergen Quittek [mailto:quittek@ccrle.nec.de]

> >>> Sent: Monday, November 18, 2002 6:39 PM

> >>> To: ipfix@net.doit.wisc.edu

> >>> Subject: [ipfix] charter re-negotiation?

> >>>

> >>>

> >>> Hi all,

> >>>

> >>> I have a request for clarification.

> >>>

> >>> Nevil identified a list consensus on supporting multiple

> >>> levels of reliability:

> >>>

> >>> -- Nevil Brownlee wrote on 16 November 2002 08:23 +1300:

> >>> >    * It's clear that a 'standard IPFIX' must allow for

> >>> various levels

> >>> >      of reliability.  That suggests either having a base

> >>> level (MUST) and

> >>> >      higher levels (SHOULD and MAY), or having a mnimum set

> >>> of features

> >>> >      which applications can use to implement whatever level

> >>> of reliability

> >>> >      they need. [list consensus]

> >>> in http://ipfix.doit.wisc.edu/archive/1462.html

> >>>

> >>> But my understandung of Randy's message

> >>> http://ipfix.doit.wisc.edu/archive/1408.html

> >>> is that the high "carrier class" reliability level is out 

> of scope:

> >>>

> >>> -- Randy Bush wrote on 11 November 2002 09:48 -0800:

> >>> > <ad>

> >>> >

> >>> >> I feel strongly that "typical Internet reliability" is

> >>> >> insufficient to make this standard of value for a large set of

> >>> >> applications.

> >>> >

> >>> > this is trivially true.  the question is whether such 

> applications

> >>> > are, or should be, in the charter of this wg.  

> currently they are

> >>> > not.  if you wish to change that, then a change to the 

> charter will

> >>> > be needed.  in this case, as it would seriously affect many

> >>> > parties, that will be a rather inclusive process and 

> success is far

> >>> > from sure.

> >>> >

> >>> > it would be nice if the wg could abjure mission creep.

> >>> >

> >>> > </ad>

> >>>

> >>> Consequently, if we have consensus that we need more than

> >>> "typical Internet

> >>> reliabiltiy", then we should add the item "charter

> >>> re-negotiation" to the

> >>> agenda of our session on Thursday.

> >>>

> >>> Am I wrong with this assessment?

> >>>

> >>>     Juergen

> >>>

> >>>

> >>> --

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

> >

> 

> 

> 





------_=_NextPart_001_01C28F91.6753B848--

--
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 Nov 19 01:26:45 2002
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 BAA17057
	for ; Tue, 19 Nov 2002 01:26:45 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18E1eo-0004kp-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 19 Nov 2002 00:14:46 -0600
Received: from srv0.ietf55.ops.ietf.org ([205.238.48.2] helo=srv0.ops.ietf.org)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18E1em-0004kj-00
	for ipfix@net.doit.wisc.edu; Tue, 19 Nov 2002 00:14:44 -0600
Received: from beta.ietf55.ops.ietf.org ([204.42.66.105] helo=BETA)
	by srv0.ops.ietf.org with esmtp (Exim 4.10)
	id 18E1ej-0002pO-00; Tue, 19 Nov 2002 06:14:42 +0000
Date: Tue, 19 Nov 2002 07:13:46 +0100
From: Juergen Quittek 
To: Reinaldo Penno , Tal Givoly ,
        ipfix@net.doit.wisc.edu
Subject: RE: [ipfix] charter re-negotiation?
Message-ID: <3823307.1037690026@BETA>
In-Reply-To: <0A11633F61BD9F40B43ABCC694004F932995FE@zsc3c026.us.nortel.com>
References:  <0A11633F61BD9F40B43ABCC694004F932995FE@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,

I clearly see the need for high reliability in several accounting
applications. And in my company, we also would like to have a
standardized technology for flow measurement with high reliability.

I just have doubts that it is covered by our charter.

    Juergen


-- Reinaldo Penno wrote on 18 November 2002 22:03 -0800:

>
>
>> -----Original Message-----
>> From: Juergen Quittek [mailto:quittek@ccrle.nec.de]
>> Sent: Tuesday, November 19, 2002 12:42 AM
>> To: Tal Givoly; Penno, Reinaldo [BL60:0430:EXCH];
>> ipfix@net.doit.wisc.edu
>> Subject: RE: [ipfix] charter re-negotiation?
>>
>>
>> Tal,
>>
>> -- Tal Givoly wrote on 18 November 2002 21:04 -0800:
>>
>> > I must agree with Reinaldo.
>> >
>> > a) Billing and Accounting are part of the charter.
>> Otherwise, we would not
>> > have been involved to begin with. Furthermore, I made
>> arguments to this
>> > affect in previous postings.
>>
>> No disagreement at all. This is obvious.
>>
>> > b) "typical Internet reliability" is "best effort" - as
>> Carter says -
>> > unreliable at best, obviously ambiguous.
>>
>> Everything is unreliable. This is just polemics.
>> Do you know any operator that never ever issued a wrong bill?
>>
>> > c) Billing applications do require high reliabilty. I'm
>> sure Jeff can attest
>>
>> Most do, some don't. But here Randy's statement is very
>> clear: if they do,
>> they are not covered by the current charter. Or can you tell me how to
>> interpret his statement otherwise?
>>
>> > to the extent to which carriers sometimes go to ensure
>> reliable delivery of
>> > data all the way from network/service elements to business
>> support systems.
>> > We have over 80 customers world wide. Many of which are
>> Tier-1 carriers. For
>> > them, lost usage data may imply lost revenue. Lost data in
>> minds of many of
>>
>> If you have an average loss of 1% of accounting data, you can
>> cover your
>> operational cost with a tariff that is about 1% higher than
>> the one you would
>> offer with a loss of 0.001% of all accounting data.
>>
>> But most probably your tariff would be even lower, because
>> equipment with
>> 1% loss tends to be much cheaper than equipment guaranteeing
>> 0.001% loss.
>>
>> > our customers is inexcusable. There are many levels/degrees
>> of reliability
>> > offered. These degrees have various impacts on devices and
>> on collecting
>> > systems. The various protocols proposed have various
>> degrees of reliability.
>> > d) As I urged earlier, we need to decide whether
>> "standardizing NetFlow" is
>> > the charter, or finding something that supports the various
>> applications
>> > mentioned explicitly in the charter and requirements document.
>>
>> We just need to realize, that standardizing something with a
>> reliability
>> similar to NetFlow is intended by the charter.
>
> What you mean by "need to realize, that standardizing something with a
> reliability similar to NetFlow is intended by the charter"? ohh, never
> mind...
>
> Anyway, personally I would like us to tackle these applications (of course
> we can be fair not imposing high reliability all the time), but my
> participation in this group is not driven by it.
>
> On the other hand I have to say that unfortunately there might be people
> that spent money-$$, time and effort on this initiative based on what is
> written in the charter and maybe wouldn't if the charter was more explicit.
> IMO many IETFs later saying that since the beggining "accounting and
> billing" actually meant "acounting and billing with typical reliability" and
> that we need to realize that "standardizing something with a reliability
> similar to Netflow is intended by the charter" is something that might not
> be taken lightly at all. Well, nobody can say bad things about laywers in
> this case...
>
> -RP
>
>
>>
>> >
>> > Tal
>> >
>> > -----Original Message-----
>> > From: majordomo listserver
>> [mailto:majordomo@mil.doit.wisc.edu]On Behalf
>> > Of Juergen Quittek
>> > Sent: Monday, November 18, 2002 7:45 PM
>> > To: Reinaldo Penno; ipfix@net.doit.wisc.edu
>> > Subject: RE: [ipfix] charter re-negotiation?
>> >
>> >
>> > Reinaldo,
>> >
>> > I agree that accounting and billing are applications included in
>> > the charter. However, they do not necessarily require high
>> reliability.
>> >
>> > They can operate with different levels of reliability. If
>> they can't,
>> > they are not covered by the current charter. Quoting Randy
>> with AD hat on:
>> >   "the question is whether such applications are, or should be,
>> >    in the charter of this wg.  currently they are not."
>> > This is a clear statement giving very little freedom to
>> interpretation.
>> >
>> > Therefore, I think we need re-chartering if we want to support them.
>> >
>> >     Juergen
>> >
>> >
>> >
>> >
>> >
>> > -- Reinaldo Penno wrote on 18 November 2002 17:46 -0800:
>> >
>> >> Hello Juergen,
>> >>
>> >> I disagree. The charter is already explicit about billing
>> and accounting.
>> >> You cannot be more explicit than this..
>> >>
>> >> "As such, there is a need in industry and the Internet
>> research community
>> >> for IP devices such as routers to export flow information
>> in a standard
>> > way
>> >> to external systems such as mediation systems,
>> accounting/billing systems,
>> >> and network management systems to facilitate services such
>> as Internet
>> >> research, measurement, accounting, and billing. "
>> >>
>> >> There was also already a lot of feedback on the list
>> supporting different
>> >> kinds of billing/accounting requirements. What else is needed?
>> >>
>> >> Now, if someone's interpretation/thinking of the sentence above is
>> > regarding
>> >> some unique mode of billing and accounting or some special
>> billing and
>> >> accounting...well...what is to say?
>> >>
>> >> regards,
>> >>
>> >> Reinaldo
>> >>
>> >> I will also ask again: What is the meaning of "Typical Internet
>> >> reliability"? People are throwing this concept around I
>> still do not know
>> >> what it means.
>> >>
>> >>
>> >>> -----Original Message-----
>> >>> From: Juergen Quittek [mailto:quittek@ccrle.nec.de]
>> >>> Sent: Monday, November 18, 2002 6:39 PM
>> >>> To: ipfix@net.doit.wisc.edu
>> >>> Subject: [ipfix] charter re-negotiation?
>> >>>
>> >>>
>> >>> Hi all,
>> >>>
>> >>> I have a request for clarification.
>> >>>
>> >>> Nevil identified a list consensus on supporting multiple
>> >>> levels of reliability:
>> >>>
>> >>> -- Nevil Brownlee wrote on 16 November 2002 08:23 +1300:
>> >>> >    * It's clear that a 'standard IPFIX' must allow for
>> >>> various levels
>> >>> >      of reliability.  That suggests either having a base
>> >>> level (MUST) and
>> >>> >      higher levels (SHOULD and MAY), or having a mnimum set
>> >>> of features
>> >>> >      which applications can use to implement whatever level
>> >>> of reliability
>> >>> >      they need. [list consensus]
>> >>> in http://ipfix.doit.wisc.edu/archive/1462.html
>> >>>
>> >>> But my understandung of Randy's message
>> >>> http://ipfix.doit.wisc.edu/archive/1408.html
>> >>> is that the high "carrier class" reliability level is out
>> of scope:
>> >>>
>> >>> -- Randy Bush wrote on 11 November 2002 09:48 -0800:
>> >>> > 
>> >>> >
>> >>> >> I feel strongly that "typical Internet reliability" is
>> >>> >> insufficient to make this standard of value for a large set of
>> >>> >> applications.
>> >>> >
>> >>> > this is trivially true.  the question is whether such
>> applications
>> >>> > are, or should be, in the charter of this wg.
>> currently they are
>> >>> > not.  if you wish to change that, then a change to the
>> charter will
>> >>> > be needed.  in this case, as it would seriously affect many
>> >>> > parties, that will be a rather inclusive process and
>> success is far
>> >>> > from sure.
>> >>> >
>> >>> > it would be nice if the wg could abjure mission creep.
>> >>> >
>> >>> > 
>> >>>
>> >>> Consequently, if we have consensus that we need more than
>> >>> "typical Internet
>> >>> reliabiltiy", then we should add the item "charter
>> >>> re-negotiation" to the
>> >>> agenda of our session on Thursday.
>> >>>
>> >>> Am I wrong with this assessment?
>> >>>
>> >>>     Juergen
>> >>>
>> >>>
>> >>> --
>> >>> 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 Nov 19 01:46:57 2002
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 BAA17452
	for ; Tue, 19 Nov 2002 01:46:57 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18E1zb-0005Da-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 19 Nov 2002 00:36:15 -0600
Received: from srv0.ietf55.ops.ietf.org ([205.238.48.2] helo=srv0.ops.ietf.org)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18E1zY-0005DT-00
	for ipfix@net.doit.wisc.edu; Tue, 19 Nov 2002 00:36:12 -0600
Received: from beta.ietf55.ops.ietf.org ([204.42.66.105] helo=BETA)
	by srv0.ops.ietf.org with esmtp (Exim 4.10)
	id 18E1z3-0002zm-00; Tue, 19 Nov 2002 06:35:41 +0000
Date: Tue, 19 Nov 2002 07:34:45 +0100
From: Juergen Quittek 
To: Nevil Brownlee ,
        Dave Plonka 
cc: ipfix@net.doit.wisc.edu
Subject: RE: [ipfix] charter re-negotiation?
Message-ID: <5082468.1037691285@BETA>
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

Nevil and Dave,

Before this thread produces another 50 emails:
Could you please comment on it with WG chair hat on?

You wrote an negotiated the charter. Do you agree with
Randy's clear statement that high reliability is not covered
by the charter? Or do you disagree?

In either case, clarification will speed up our progress.

    Juergen


-- Juergen Quittek wrote on 19 November 2002 06:41 +0100:

> Tal,
>
> -- Tal Givoly wrote on 18 November 2002 21:04 -0800:
>
>> I must agree with Reinaldo.
>>
>> a) Billing and Accounting are part of the charter. Otherwise, we would not
>> have been involved to begin with. Furthermore, I made arguments to this
>> affect in previous postings.
>
> No disagreement at all. This is obvious.
>
>> b) "typical Internet reliability" is "best effort" - as Carter says -
>> unreliable at best, obviously ambiguous.
>
> Everything is unreliable. This is just polemics.
> Do you know any operator that never ever issued a wrong bill?
>
>> c) Billing applications do require high reliabilty. I'm sure Jeff can attest
>
> Most do, some don't. But here Randy's statement is very clear: if they do,
> they are not covered by the current charter. Or can you tell me how to
> interpret his statement otherwise?
>
>> to the extent to which carriers sometimes go to ensure reliable delivery of
>> data all the way from network/service elements to business support systems.
>> We have over 80 customers world wide. Many of which are Tier-1 carriers. For
>> them, lost usage data may imply lost revenue. Lost data in minds of many of
>
> If you have an average loss of 1% of accounting data, you can cover your
> operational cost with a tariff that is about 1% higher than the one you would
> offer with a loss of 0.001% of all accounting data.
>
> But most probably your tariff would be even lower, because equipment with
> 1% loss tends to be much cheaper than equipment guaranteeing 0.001% loss.
>
>> our customers is inexcusable. There are many levels/degrees of reliability
>> offered. These degrees have various impacts on devices and on collecting
>> systems. The various protocols proposed have various degrees of reliability.
>> d) As I urged earlier, we need to decide whether "standardizing NetFlow" is
>> the charter, or finding something that supports the various applications
>> mentioned explicitly in the charter and requirements document.
>
> We just need to realize, that standardizing something with a reliability
> similar to NetFlow is intended by the charter.
>
>>
>> Tal
>>
>> -----Original Message-----
>> From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf
>> Of Juergen Quittek
>> Sent: Monday, November 18, 2002 7:45 PM
>> To: Reinaldo Penno; ipfix@net.doit.wisc.edu
>> Subject: RE: [ipfix] charter re-negotiation?
>>
>>
>> Reinaldo,
>>
>> I agree that accounting and billing are applications included in
>> the charter. However, they do not necessarily require high reliability.
>>
>> They can operate with different levels of reliability. If they can't,
>> they are not covered by the current charter. Quoting Randy with AD hat on:
>>   "the question is whether such applications are, or should be,
>>    in the charter of this wg.  currently they are not."
>> This is a clear statement giving very little freedom to interpretation.
>>
>> Therefore, I think we need re-chartering if we want to support them.
>>
>>     Juergen
>>
>>
>>
>>
>>
>> -- Reinaldo Penno wrote on 18 November 2002 17:46 -0800:
>>
>>> Hello Juergen,
>>>
>>> I disagree. The charter is already explicit about billing and accounting.
>>> You cannot be more explicit than this..
>>>
>>> "As such, there is a need in industry and the Internet research community
>>> for IP devices such as routers to export flow information in a standard
>> way
>>> to external systems such as mediation systems, accounting/billing systems,
>>> and network management systems to facilitate services such as Internet
>>> research, measurement, accounting, and billing. "
>>>
>>> There was also already a lot of feedback on the list supporting different
>>> kinds of billing/accounting requirements. What else is needed?
>>>
>>> Now, if someone's interpretation/thinking of the sentence above is
>> regarding
>>> some unique mode of billing and accounting or some special billing and
>>> accounting...well...what is to say?
>>>
>>> regards,
>>>
>>> Reinaldo
>>>
>>> I will also ask again: What is the meaning of "Typical Internet
>>> reliability"? People are throwing this concept around I still do not know
>>> what it means.
>>>
>>>
>>>> -----Original Message-----
>>>> From: Juergen Quittek [mailto:quittek@ccrle.nec.de]
>>>> Sent: Monday, November 18, 2002 6:39 PM
>>>> To: ipfix@net.doit.wisc.edu
>>>> Subject: [ipfix] charter re-negotiation?
>>>>
>>>>
>>>> Hi all,
>>>>
>>>> I have a request for clarification.
>>>>
>>>> Nevil identified a list consensus on supporting multiple
>>>> levels of reliability:
>>>>
>>>> -- Nevil Brownlee wrote on 16 November 2002 08:23 +1300:
>>>> >    * It's clear that a 'standard IPFIX' must allow for
>>>> various levels
>>>> >      of reliability.  That suggests either having a base
>>>> level (MUST) and
>>>> >      higher levels (SHOULD and MAY), or having a mnimum set
>>>> of features
>>>> >      which applications can use to implement whatever level
>>>> of reliability
>>>> >      they need. [list consensus]
>>>> in http://ipfix.doit.wisc.edu/archive/1462.html
>>>>
>>>> But my understandung of Randy's message
>>>> http://ipfix.doit.wisc.edu/archive/1408.html
>>>> is that the high "carrier class" reliability level is out of scope:
>>>>
>>>> -- Randy Bush wrote on 11 November 2002 09:48 -0800:
>>>> > 
>>>> >
>>>> >> I feel strongly that "typical Internet reliability" is
>>>> >> insufficient to make this standard of value for a large set of
>>>> >> applications.
>>>> >
>>>> > this is trivially true.  the question is whether such applications
>>>> > are, or should be, in the charter of this wg.  currently they are
>>>> > not.  if you wish to change that, then a change to the charter will
>>>> > be needed.  in this case, as it would seriously affect many
>>>> > parties, that will be a rather inclusive process and success is far
>>>> > from sure.
>>>> >
>>>> > it would be nice if the wg could abjure mission creep.
>>>> >
>>>> > 
>>>>
>>>> Consequently, if we have consensus that we need more than
>>>> "typical Internet
>>>> reliabiltiy", then we should add the item "charter
>>>> re-negotiation" to the
>>>> agenda of our session on Thursday.
>>>>
>>>> Am I wrong with this assessment?
>>>>
>>>>     Juergen
>>>>
>>>>
>>>> --
>>>> 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  Tue Nov 19 03:05:41 2002
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 DAA28520
	for ; Tue, 19 Nov 2002 03:05:41 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18E3FP-00072a-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 19 Nov 2002 01:56:39 -0600
Received: from usmail.xacct.com ([204.253.100.12])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18E3FN-00072O-00
	for ipfix@net.doit.wisc.edu; Tue, 19 Nov 2002 01:56:37 -0600
Received: from peter ([192.168.0.163])
	by usmail.xacct.com (8.11.2/8.11.2) with SMTP id gAJ7xs227248;
	Mon, 18 Nov 2002 23:59:55 -0800
From: "Peter Ludemann" 
To: "Juergen Quittek" , "Tal Givoly" ,
        "Reinaldo Penno" ,
        
Subject: RE: [ipfix] charter re-negotiation?
Date: Mon, 18 Nov 2002 23:56:02 -0800
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <1886582.1037688089@BETA>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

Comments interspersed.

> -----Original Message-----
> From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf
> Of Juergen Quittek
> Sent: Monday, November 18, 2002 9:42 PM
> To: Tal Givoly; Reinaldo Penno; ipfix@net.doit.wisc.edu
> Subject: RE: [ipfix] charter re-negotiation?
>
>
> Tal,
>
> -- Tal Givoly wrote on 18 November 2002 21:04 -0800:
>
> > I must agree with Reinaldo.
> >
> > a) Billing and Accounting are part of the charter. Otherwise,
> we would not
> > have been involved to begin with. Furthermore, I made arguments to this
> > affect in previous postings.
>
> No disagreement at all. This is obvious.
>
> > b) "typical Internet reliability" is "best effort" - as Carter says -
> > unreliable at best, obviously ambiguous.
>
> Everything is unreliable. This is just polemics.
> Do you know any operator that never ever issued a wrong bill?

True but irrelevant (see below).

> > c) Billing applications do require high reliabilty. I'm sure
> Jeff can attest
>
> Most do, some don't. But here Randy's statement is very clear: if they do,
> they are not covered by the current charter. Or can you tell me how to
> interpret his statement otherwise?

I would rather have the Chairman clarify.

Words mean whatever everyone agrees they mean. As somebody said, "I don't
know what programming language we'll be using next century but I know it'll
be called 'Fortran'." Similarly, we could call this WG the
NetFlow-standardization group (as Randy seemed to suggest), but that could
be just interpreted as flexibly as the word 'Fortran'.

As to the issue of standardising current practice -- for some of us, current
practice is to do our best to collect NetFlow (pre-V9) data in a reliable
way. This is very difficult and expensive; and I would hardly want IETF to
standardise an ineffective technique.

> > to the extent to which carriers sometimes go to ensure reliable
> delivery of
> > data all the way from network/service elements to business
> support systems.
> > We have over 80 customers world wide. Many of which are Tier-1
> carriers. For
> > them, lost usage data may imply lost revenue. Lost data in
> minds of many of
>
> If you have an average loss of 1% of accounting data, you can cover your
> operational cost with a tariff that is about 1% higher than the
> one you would
> offer with a loss of 0.001% of all accounting data.
>
> But most probably your tariff would be even lower, because equipment with
> 1% loss tends to be much cheaper than equipment guaranteeing 0.001% loss.

You're being much too logical. :-) We're talking about telephone companies
here ...

Also, there are legal issues which make such an approach inadvisable (i.e.,
forbidden by law to have the possibility of overcharging).

Also, data collection is only one component of a whole process of massaging
data and creating bills.  I recently spec-ed a system with completely
duplicated data collection and failover -- the data collection component,
with all its redundancy, is less than 5% of the total system cost.

> > our customers is inexcusable. There are many levels/degrees of
> reliability
> > offered. These degrees have various impacts on devices and on collecting
> > systems. The various protocols proposed have various degrees of
> reliability.
> > d) As I urged earlier, we need to decide whether "standardizing
> NetFlow" is
> > the charter, or finding something that supports the various applications
> > mentioned explicitly in the charter and requirements document.
>
> We just need to realize, that standardizing something with a reliability
> similar to NetFlow is intended by the charter.

See above my comment about the meaning of "NetFlow". Even Cisco has allowed
the possibility of TCP or SCTP instead of UDP.

> >
> > Tal
> >
> > -----Original Message-----
> > From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf
> > Of Juergen Quittek
> > Sent: Monday, November 18, 2002 7:45 PM
> > To: Reinaldo Penno; ipfix@net.doit.wisc.edu
> > Subject: RE: [ipfix] charter re-negotiation?
> >
> >
> > Reinaldo,
> >
> > I agree that accounting and billing are applications included in
> > the charter. However, they do not necessarily require high reliability.
> >
> > They can operate with different levels of reliability. If they can't,
> > they are not covered by the current charter. Quoting Randy with
> AD hat on:
> >   "the question is whether such applications are, or should be,
> >    in the charter of this wg.  currently they are not."
> > This is a clear statement giving very little freedom to interpretation.
> >
> > Therefore, I think we need re-chartering if we want to support them.
> >
> >     Juergen
> >
> >
> >
> >
> >
> > -- Reinaldo Penno wrote on 18 November 2002 17:46 -0800:
> >
> >> Hello Juergen,
> >>
> >> I disagree. The charter is already explicit about billing and
> accounting.
> >> You cannot be more explicit than this..
> >>
> >> "As such, there is a need in industry and the Internet
> research community
> >> for IP devices such as routers to export flow information in a standard
> > way
> >> to external systems such as mediation systems,
> accounting/billing systems,
> >> and network management systems to facilitate services such as Internet
> >> research, measurement, accounting, and billing. "
> >>
> >> There was also already a lot of feedback on the list
> supporting different
> >> kinds of billing/accounting requirements. What else is needed?
> >>
> >> Now, if someone's interpretation/thinking of the sentence above is
> > regarding
> >> some unique mode of billing and accounting or some special billing and
> >> accounting...well...what is to say?
> >>
> >> regards,
> >>
> >> Reinaldo
> >>
> >> I will also ask again: What is the meaning of "Typical Internet
> >> reliability"? People are throwing this concept around I still
> do not know
> >> what it means.
> >>
> >>
> >>> -----Original Message-----
> >>> From: Juergen Quittek [mailto:quittek@ccrle.nec.de]
> >>> Sent: Monday, November 18, 2002 6:39 PM
> >>> To: ipfix@net.doit.wisc.edu
> >>> Subject: [ipfix] charter re-negotiation?
> >>>
> >>>
> >>> Hi all,
> >>>
> >>> I have a request for clarification.
> >>>
> >>> Nevil identified a list consensus on supporting multiple
> >>> levels of reliability:
> >>>
> >>> -- Nevil Brownlee wrote on 16 November 2002 08:23 +1300:
> >>> >    * It's clear that a 'standard IPFIX' must allow for
> >>> various levels
> >>> >      of reliability.  That suggests either having a base
> >>> level (MUST) and
> >>> >      higher levels (SHOULD and MAY), or having a mnimum set
> >>> of features
> >>> >      which applications can use to implement whatever level
> >>> of reliability
> >>> >      they need. [list consensus]
> >>> in http://ipfix.doit.wisc.edu/archive/1462.html
> >>>
> >>> But my understandung of Randy's message
> >>> http://ipfix.doit.wisc.edu/archive/1408.html
> >>> is that the high "carrier class" reliability level is out of scope:
> >>>
> >>> -- Randy Bush wrote on 11 November 2002 09:48 -0800:
> >>> > 
> >>> >
> >>> >> I feel strongly that "typical Internet reliability" is
> >>> >> insufficient to make this standard of value for a large set of
> >>> >> applications.
> >>> >
> >>> > this is trivially true.  the question is whether such applications
> >>> > are, or should be, in the charter of this wg.  currently they are
> >>> > not.  if you wish to change that, then a change to the charter will
> >>> > be needed.  in this case, as it would seriously affect many
> >>> > parties, that will be a rather inclusive process and success is far
> >>> > from sure.
> >>> >
> >>> > it would be nice if the wg could abjure mission creep.
> >>> >
> >>> > 
> >>>
> >>> Consequently, if we have consensus that we need more than
> >>> "typical Internet
> >>> reliabiltiy", then we should add the item "charter
> >>> re-negotiation" to the
> >>> agenda of our session on Thursday.
> >>>
> >>> Am I wrong with this assessment?
> >>>
> >>>     Juergen


--
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 Nov 19 07:38:53 2002
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 HAA03402
	for ; Tue, 19 Nov 2002 07:38:53 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18E7R0-0007W3-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 19 Nov 2002 06:24:54 -0600
Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18E7Qz-0007VE-00; Tue, 19 Nov 2002 06:24:53 -0600
Received: from cisco.com (ams-clip-vpn-dhcp4193.cisco.com [10.50.16.96])
	by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id gAJCOD715989;
	Tue, 19 Nov 2002 13:24:13 +0100 (CET)
Message-ID: <3DDA2D6C.600@cisco.com>
Date: Tue, 19 Nov 2002 13:24:12 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020815
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Reinaldo Penno 
CC: Simon Leinen , ipfix-eval@net.doit.wisc.edu,
        ipfix-req@net.doit.wisc.edu
Subject: Re: [ipfix-eval] Some comments on the evaluation team draft
References: <0A11633F61BD9F40B43ABCC694004F9320258F@zsc3c026.us.nortel.com>
Content-Type: multipart/alternative;
 boundary="------------040002030404010205070502"
Precedence: bulk
Sender: majordomo listserver 


--------------040002030404010205070502
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Reinaldo,

> Benoit,
>  
> you can use other fields, such as IP Proto, TCP Ports, packet size, 
> etc, etc..

My solution would be: I use a template which exports only IP proto, TCP 
ports, packet size, etc, etc... but not the IP addresses.
And because I don't do any aggregation, I keep the same flow granularity.
Now if I don't need the flow granularity, I can aggregate on the router.

Again, my point was: "So what's the point to export something that you 
can't use?"

Regards, Benoit.

> There are several sites where you can download public data from 
> probes/exporters where the IP addresses are maked by a one-way 
> function but the other fields can be seen. See for instance 
> http://tracer.csl.sony.co.jp/mawi/guideline.txt
>  
> "Protecting User Privacy
>
> There are 2 issues regarding user privacy.
>
> 1. Removing user data:
> Leave only protocol headers and remove protocol
> payload which could contain user data.
> 2. Providing anonymity:
> Scramble addresses which could be used to identify a
> user.
> "
>  
> regards,
>  
> Reinaldo
>
>     -----Original Message-----
>     *From:* Benoit Claise [mailto:bclaise@cisco.com]
>     *Sent:* Friday, November 15, 2002 8:51 AM
>     *To:* Simon Leinen
>     *Cc:* ipfix-eval@net.doit.wisc.edu; ipfix-req@net.doit.wisc.edu
>     *Subject:* Re: [ipfix-eval] Some comments on the evaluation team draft
>
>     Simon,
>
>>On Thu, 14 Nov 2002 16:52:35 +0100, Benoit Claise  said:
>>  
>>
>>>5.7 Anonymization  (6.7)   LFAP: E     CRANE: E     IPDR: E
>>>NetFlow: E     Diameter: E
>>>    
>>>
>>
>>  
>>
>>>In my draft http://www.ietf.org/internet-drafts/draft-claise-ipfix-eval-netflow-03.txt, I wrote
>>>    
>>>
>>
>>
>>  
>>
>>>    3.5.7 Anonymization (6.6)
>>>            "The exporting process MAY be capable of anonymizing
>>>source and
>>>       destination IP addresses in flow data before exporting them."
>>>       _Total Compliance. _
>>>    
>>>
>>
>>  
>>
>>>You can export the prefix is you want to and not the specific source
>>>and destination IP addresses.
>>>    
>>>
>>
>>I would call that "(router-based) aggregation" rather than
>>"anonymization".  With anonymization you somehow expect to maintain
>>granularity, but want some kind of (non-reversible?) scrambling to
>>cover up privacy-sensitive parts of the traffic data, such as IP
>>addresses.
>>
>     So what's the point to export something that you can't use?
>
>     Benoit.
>
>>Don't take this requirement too seriously.  None of the candidates has
>>addressed this, and I think as a requirement it hasn't been thought
>>through too well.  It doesn't really reflect current practice, and
>>personally I think this is better done on the collector side.
>>  
>>
>
>



--------------040002030404010205070502
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit




  
  


Reinaldo,


 
 
  
  
   
  
 
  
Benoit,

 
  
 

 
  
you  can use other fields, such as IP Proto, TCP
Ports, packet size, etc, etc..



My solution would be: I use a template which exports only IP proto, TCP ports,
packet size, etc, etc... but not the IP addresses.

And because I don't do any aggregation, I keep the same flow granularity.

Now if I don't need the flow granularity, I can aggregate on the router.



Again, my point was: "So what's the point to export something that you  
 can't use?"



Regards, Benoit.





  
There  are several sites where you can download
public data from probes/exporters where  the IP addresses are maked by a
one-way function but the other fields can  be seen. See for instance http://tracer.csl.sony.co.jp/mawi/guideline.txt

 
  
 

 
  
"Protecting
User Privacy

  

	There  are 2 issues regarding user privacy.

  

	1. Removing user data:

		Leave  only protocol headers and remove protocol

		payload which could contain user  data.

	2. Providing anonymity:

		Scramble addresses which could be used to  identify a

		user.

"

 
  
 

 
  
regards,

 
  
 

 
  
Reinaldo

 
  
 
  
    
-----Original Message-----

    From: Benoit Claise    [mailto:bclaise@cisco.com]

    Sent: Friday, November 15, 2002 8:51    AM

    To: Simon Leinen

    Cc: ipfix-eval@net.doit.wisc.edu;    ipfix-req@net.doit.wisc.edu

    Subject: Re: [ipfix-eval] Some comments    on the evaluation team
draft

    

    

Simon,

   
    

      
On Thu, 14 Nov 2002 16:52:35 +0100, Benoit Claise <bclaise@cisco.com> said:
  

     
      

        
5.7 Anonymization  (6.7)   LFAP: E     CRANE: E     IPDR: E
NetFlow: E     Diameter: E
    

      

      

  

     
      

        
In my draft http://www.ietf.org/internet-drafts/draft-claise-ipfix-eval-netflow-03.txt, I wrote
    

      

      


  

     
      

        
    3.5.7 Anonymization (6.6)
            "The exporting process MAY be capable of anonymizing
source and
       destination IP addresses in flow data before exporting them."
       _Total Compliance. _
    

      

      

  

     
      

        
You can export the prefix is you want to and not the specific source
and destination IP addresses.
    

      

      

I would call that "(router-based) aggregation" rather than
"anonymization".  With anonymization you somehow expect to maintain
granularity, but want some kind of (non-reversible?) scrambling to
cover up privacy-sensitive parts of the traffic data, such as IP
addresses.

    

So what's the point to export something that you    can't use?

    

Benoit.

   
    

      
Don't take this requirement too seriously.  None of the candidates has
addressed this, and I think as a requirement it hasn't been thought
through too well.  It doesn't really reflect current practice, and
personally I think this is better done on the collector side.
  

    

    

    

  










--------------040002030404010205070502--


--
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 Nov 19 07:59:26 2002
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 HAA03888
	for ; Tue, 19 Nov 2002 07:59:26 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18E7rZ-0000N3-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 19 Nov 2002 06:52:21 -0600
Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18E7Qz-0007VE-00; Tue, 19 Nov 2002 06:24:53 -0600
Received: from cisco.com (ams-clip-vpn-dhcp4193.cisco.com [10.50.16.96])
	by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id gAJCOD715989;
	Tue, 19 Nov 2002 13:24:13 +0100 (CET)
Message-ID: <3DDA2D6C.600@cisco.com>
Date: Tue, 19 Nov 2002 13:24:12 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020815
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Reinaldo Penno 
CC: Simon Leinen , ipfix-eval@net.doit.wisc.edu,
        ipfix-req@net.doit.wisc.edu
Subject: [ipfix-req] Re: [ipfix-eval] Some comments on the evaluation team draft
References: <0A11633F61BD9F40B43ABCC694004F9320258F@zsc3c026.us.nortel.com>
Content-Type: multipart/alternative;
 boundary="------------040002030404010205070502"
Precedence: bulk
Sender: majordomo listserver 


--------------040002030404010205070502
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Reinaldo,

> Benoit,
>  
> you can use other fields, such as IP Proto, TCP Ports, packet size, 
> etc, etc..

My solution would be: I use a template which exports only IP proto, TCP 
ports, packet size, etc, etc... but not the IP addresses.
And because I don't do any aggregation, I keep the same flow granularity.
Now if I don't need the flow granularity, I can aggregate on the router.

Again, my point was: "So what's the point to export something that you 
can't use?"

Regards, Benoit.

> There are several sites where you can download public data from 
> probes/exporters where the IP addresses are maked by a one-way 
> function but the other fields can be seen. See for instance 
> http://tracer.csl.sony.co.jp/mawi/guideline.txt
>  
> "Protecting User Privacy
>
> There are 2 issues regarding user privacy.
>
> 1. Removing user data:
> Leave only protocol headers and remove protocol
> payload which could contain user data.
> 2. Providing anonymity:
> Scramble addresses which could be used to identify a
> user.
> "
>  
> regards,
>  
> Reinaldo
>
>     -----Original Message-----
>     *From:* Benoit Claise [mailto:bclaise@cisco.com]
>     *Sent:* Friday, November 15, 2002 8:51 AM
>     *To:* Simon Leinen
>     *Cc:* ipfix-eval@net.doit.wisc.edu; ipfix-req@net.doit.wisc.edu
>     *Subject:* Re: [ipfix-eval] Some comments on the evaluation team draft
>
>     Simon,
>
>>On Thu, 14 Nov 2002 16:52:35 +0100, Benoit Claise  said:
>>  
>>
>>>5.7 Anonymization  (6.7)   LFAP: E     CRANE: E     IPDR: E
>>>NetFlow: E     Diameter: E
>>>    
>>>
>>
>>  
>>
>>>In my draft http://www.ietf.org/internet-drafts/draft-claise-ipfix-eval-netflow-03.txt, I wrote
>>>    
>>>
>>
>>
>>  
>>
>>>    3.5.7 Anonymization (6.6)
>>>            "The exporting process MAY be capable of anonymizing
>>>source and
>>>       destination IP addresses in flow data before exporting them."
>>>       _Total Compliance. _
>>>    
>>>
>>
>>  
>>
>>>You can export the prefix is you want to and not the specific source
>>>and destination IP addresses.
>>>    
>>>
>>
>>I would call that "(router-based) aggregation" rather than
>>"anonymization".  With anonymization you somehow expect to maintain
>>granularity, but want some kind of (non-reversible?) scrambling to
>>cover up privacy-sensitive parts of the traffic data, such as IP
>>addresses.
>>
>     So what's the point to export something that you can't use?
>
>     Benoit.
>
>>Don't take this requirement too seriously.  None of the candidates has
>>addressed this, and I think as a requirement it hasn't been thought
>>through too well.  It doesn't really reflect current practice, and
>>personally I think this is better done on the collector side.
>>  
>>
>
>



--------------040002030404010205070502
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit




  
  


Reinaldo,


 
 
  
  
   
  
 
  
Benoit,

 
  
 

 
  
you  can use other fields, such as IP Proto, TCP
Ports, packet size, etc, etc..



My solution would be: I use a template which exports only IP proto, TCP ports,
packet size, etc, etc... but not the IP addresses.

And because I don't do any aggregation, I keep the same flow granularity.

Now if I don't need the flow granularity, I can aggregate on the router.



Again, my point was: "So what's the point to export something that you  
 can't use?"



Regards, Benoit.





  
There  are several sites where you can download
public data from probes/exporters where  the IP addresses are maked by a
one-way function but the other fields can  be seen. See for instance http://tracer.csl.sony.co.jp/mawi/guideline.txt

 
  
 

 
  
"Protecting
User Privacy

  

	There  are 2 issues regarding user privacy.

  

	1. Removing user data:

		Leave  only protocol headers and remove protocol

		payload which could contain user  data.

	2. Providing anonymity:

		Scramble addresses which could be used to  identify a

		user.

"

 
  
 

 
  
regards,

 
  
 

 
  
Reinaldo

 
  
 
  
    
-----Original Message-----

    From: Benoit Claise    [mailto:bclaise@cisco.com]

    Sent: Friday, November 15, 2002 8:51    AM

    To: Simon Leinen

    Cc: ipfix-eval@net.doit.wisc.edu;    ipfix-req@net.doit.wisc.edu

    Subject: Re: [ipfix-eval] Some comments    on the evaluation team
draft

    

    

Simon,

   
    

      
On Thu, 14 Nov 2002 16:52:35 +0100, Benoit Claise <bclaise@cisco.com> said:
  

     
      

        
5.7 Anonymization  (6.7)   LFAP: E     CRANE: E     IPDR: E
NetFlow: E     Diameter: E
    

      

      

  

     
      

        
In my draft http://www.ietf.org/internet-drafts/draft-claise-ipfix-eval-netflow-03.txt, I wrote
    

      

      


  

     
      

        
    3.5.7 Anonymization (6.6)
            "The exporting process MAY be capable of anonymizing
source and
       destination IP addresses in flow data before exporting them."
       _Total Compliance. _
    

      

      

  

     
      

        
You can export the prefix is you want to and not the specific source
and destination IP addresses.
    

      

      

I would call that "(router-based) aggregation" rather than
"anonymization".  With anonymization you somehow expect to maintain
granularity, but want some kind of (non-reversible?) scrambling to
cover up privacy-sensitive parts of the traffic data, such as IP
addresses.

    

So what's the point to export something that you    can't use?

    

Benoit.

   
    

      
Don't take this requirement too seriously.  None of the candidates has
addressed this, and I think as a requirement it hasn't been thought
through too well.  It doesn't really reflect current practice, and
personally I think this is better done on the collector side.
  

    

    

    

  










--------------040002030404010205070502--


--
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 Nov 19 08:02:43 2002
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 IAA04002
	for ; Tue, 19 Nov 2002 08:02:42 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18E7wK-0000XS-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 19 Nov 2002 06:57:16 -0600
Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18E7wI-0000WI-00
	for ipfix@net.doit.wisc.edu; Tue, 19 Nov 2002 06:57:14 -0600
Received: from cisco.com (ams-clip-vpn-dhcp4193.cisco.com [10.50.16.96])
	by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id gAJCtw711389;
	Tue, 19 Nov 2002 13:55:58 +0100 (CET)
Message-ID: <3DDA34DD.1080706@cisco.com>
Date: Tue, 19 Nov 2002 13:55:57 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020815
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Juergen Quittek ,
        Nevil Brownlee
 ,
        Dave Plonka , Randy Bush
 
CC: ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] charter re-negotiation?
References: <5082468.1037691285@BETA>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

Dear all,

> Nevil and Dave,
>
> Before this thread produces another 50 emails:
> Could you please comment on it with WG chair hat on?
>
> You wrote an negotiated the charter. Do you agree with
> Randy's clear statement that high reliability is not covered
> by the charter? Or do you disagree? 

Yes, I think that this issue has been lasting too long! And we see two 
distinct groups of people with different goals.
We see the same arguments over and over on the mailing list. And this is 
not very productive!
Maybe a combined email from Randy, Nevil and Dave with their respective 
hats on would do the trick.

Note: personally, I was thinking that Randy's message was clear enough 
but ...

Regards, Benoit.

>
>
> In either case, clarification will speed up our progress.
>
>    Juergen
>
>
> -- Juergen Quittek wrote on 19 November 2002 06:41 +0100:
>
>> Tal,
>>
>> -- Tal Givoly wrote on 18 November 2002 21:04 -0800:
>>
>>> I must agree with Reinaldo.
>>>
>>> a) Billing and Accounting are part of the charter. Otherwise, we 
>>> would not
>>> have been involved to begin with. Furthermore, I made arguments to this
>>> affect in previous postings.
>>
>>
>> No disagreement at all. This is obvious.
>>
>>> b) "typical Internet reliability" is "best effort" - as Carter says -
>>> unreliable at best, obviously ambiguous.
>>
>>
>> Everything is unreliable. This is just polemics.
>> Do you know any operator that never ever issued a wrong bill?
>>
>>> c) Billing applications do require high reliabilty. I'm sure Jeff 
>>> can attest
>>
>>
>> Most do, some don't. But here Randy's statement is very clear: if 
>> they do,
>> they are not covered by the current charter. Or can you tell me how to
>> interpret his statement otherwise?
>>
>>> to the extent to which carriers sometimes go to ensure reliable 
>>> delivery of
>>> data all the way from network/service elements to business support 
>>> systems.
>>> We have over 80 customers world wide. Many of which are Tier-1 
>>> carriers. For
>>> them, lost usage data may imply lost revenue. Lost data in minds of 
>>> many of
>>
>>
>> If you have an average loss of 1% of accounting data, you can cover your
>> operational cost with a tariff that is about 1% higher than the one 
>> you would
>> offer with a loss of 0.001% of all accounting data.
>>
>> But most probably your tariff would be even lower, because equipment 
>> with
>> 1% loss tends to be much cheaper than equipment guaranteeing 0.001% 
>> loss.
>>
>>> our customers is inexcusable. There are many levels/degrees of 
>>> reliability
>>> offered. These degrees have various impacts on devices and on 
>>> collecting
>>> systems. The various protocols proposed have various degrees of 
>>> reliability.
>>> d) As I urged earlier, we need to decide whether "standardizing 
>>> NetFlow" is
>>> the charter, or finding something that supports the various 
>>> applications
>>> mentioned explicitly in the charter and requirements document.
>>
>>
>> We just need to realize, that standardizing something with a reliability
>> similar to NetFlow is intended by the charter.
>>
>>>
>>> Tal
>>>
>>> -----Original Message-----
>>> From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On 
>>> Behalf
>>> Of Juergen Quittek
>>> Sent: Monday, November 18, 2002 7:45 PM
>>> To: Reinaldo Penno; ipfix@net.doit.wisc.edu
>>> Subject: RE: [ipfix] charter re-negotiation?
>>>
>>>
>>> Reinaldo,
>>>
>>> I agree that accounting and billing are applications included in
>>> the charter. However, they do not necessarily require high reliability.
>>>
>>> They can operate with different levels of reliability. If they can't,
>>> they are not covered by the current charter. Quoting Randy with AD 
>>> hat on:
>>>   "the question is whether such applications are, or should be,
>>>    in the charter of this wg.  currently they are not."
>>> This is a clear statement giving very little freedom to interpretation.
>>>
>>> Therefore, I think we need re-chartering if we want to support them.
>>>
>>>     Juergen
>>>
>>>
>>>
>>>
>>>
>>> -- Reinaldo Penno wrote on 18 November 2002 17:46 -0800:
>>>
>>>> Hello Juergen,
>>>>
>>>> I disagree. The charter is already explicit about billing and 
>>>> accounting.
>>>> You cannot be more explicit than this..
>>>>
>>>> "As such, there is a need in industry and the Internet research 
>>>> community
>>>> for IP devices such as routers to export flow information in a 
>>>> standard
>>>
>>> way
>>>
>>>> to external systems such as mediation systems, accounting/billing 
>>>> systems,
>>>> and network management systems to facilitate services such as Internet
>>>> research, measurement, accounting, and billing. "
>>>>
>>>> There was also already a lot of feedback on the list supporting 
>>>> different
>>>> kinds of billing/accounting requirements. What else is needed?
>>>>
>>>> Now, if someone's interpretation/thinking of the sentence above is
>>>
>>> regarding
>>>
>>>> some unique mode of billing and accounting or some special billing and
>>>> accounting...well...what is to say?
>>>>
>>>> regards,
>>>>
>>>> Reinaldo
>>>>
>>>> I will also ask again: What is the meaning of "Typical Internet
>>>> reliability"? People are throwing this concept around I still do 
>>>> not know
>>>> what it means.
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Juergen Quittek [mailto:quittek@ccrle.nec.de]
>>>>> Sent: Monday, November 18, 2002 6:39 PM
>>>>> To: ipfix@net.doit.wisc.edu
>>>>> Subject: [ipfix] charter re-negotiation?
>>>>>
>>>>>
>>>>> Hi all,
>>>>>
>>>>> I have a request for clarification.
>>>>>
>>>>> Nevil identified a list consensus on supporting multiple
>>>>> levels of reliability:
>>>>>
>>>>> -- Nevil Brownlee wrote on 16 November 2002 08:23 +1300:
>>>>> >    * It's clear that a 'standard IPFIX' must allow for
>>>>> various levels
>>>>> >      of reliability.  That suggests either having a base
>>>>> level (MUST) and
>>>>> >      higher levels (SHOULD and MAY), or having a mnimum set
>>>>> of features
>>>>> >      which applications can use to implement whatever level
>>>>> of reliability
>>>>> >      they need. [list consensus]
>>>>> in http://ipfix.doit.wisc.edu/archive/1462.html
>>>>>
>>>>> But my understandung of Randy's message
>>>>> http://ipfix.doit.wisc.edu/archive/1408.html
>>>>> is that the high "carrier class" reliability level is out of scope:
>>>>>
>>>>> -- Randy Bush wrote on 11 November 2002 09:48 -0800:
>>>>> > 
>>>>> >
>>>>> >> I feel strongly that "typical Internet reliability" is
>>>>> >> insufficient to make this standard of value for a large set of
>>>>> >> applications.
>>>>> >
>>>>> > this is trivially true.  the question is whether such applications
>>>>> > are, or should be, in the charter of this wg.  currently they are
>>>>> > not.  if you wish to change that, then a change to the charter will
>>>>> > be needed.  in this case, as it would seriously affect many
>>>>> > parties, that will be a rather inclusive process and success is far
>>>>> > from sure.
>>>>> >
>>>>> > it would be nice if the wg could abjure mission creep.
>>>>> >
>>>>> > 
>>>>>
>>>>> Consequently, if we have consensus that we need more than
>>>>> "typical Internet
>>>>> reliabiltiy", then we should add the item "charter
>>>>> re-negotiation" to the
>>>>> agenda of our session on Thursday.
>>>>>
>>>>> Am I wrong with this assessment?
>>>>>
>>>>>     Juergen
>>>>>
>>>>>
>>>>> -- 
>>>>> 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/





--
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 Nov 19 14:36:17 2002
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 OAA14327
	for ; Tue, 19 Nov 2002 14:36:16 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18EE2c-0002Aw-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 19 Nov 2002 13:28:10 -0600
Received: from dplonka by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18EE2a-0002Ao-00
	for ipfix@net.doit.wisc.edu; Tue, 19 Nov 2002 13:28:08 -0600
Date: Tue, 19 Nov 2002 13:28:08 -0600
From: Dave Plonka 
To: ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] charter re-negotiation?
Message-ID: <20021119132808.C3127@doit.wisc.edu>
Reply-To: plonka@doit.wisc.edu
References: <5082468.1037691285@BETA>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <5082468.1037691285@BETA>; from quittek@ccrle.nec.de on Tue, Nov 19, 2002 at 07:34:45AM +0100
Organization: UW-Madison, DoIT, Network Services
X-VMS-Error: %SYSTEM-F-RESET, circuit was reset
X-Shakespearean-Insult: Thou qualling folly-fallen miscreant
Precedence: bulk
Sender: majordomo listserver 


IPFIXers,

Nevil and I have had the opportunity to discuss this...
Here is our understanding (but in my own words of course):

Our charter does not mandate that IPFIX be highly reliable at the
transport nor the application layer.  This was intentional - only a
subset of applications benefit significantly from that somewhat
complicated feature which is costly to implement on some exporter
platforms.  That said, IPFIX doesn't preclude transport or
application-level reliability.  So, it is possible to build a
highly-reliable system that is IPFIX conforming.

The IPFIX WG, through our evaluation process, will select a protocol
that (1) satisfies the requirements and (2) is preferred with respect
to less tangible aspects including flexibility, simplicity, etc.

If some among us believe have identified applications that require
absolute reliability at the transport or application layer, then IPFIX
requirements are perhaps insufficient for your applications
requirements.  We mean IPFIX to be the "lingua franca" for the routed
Internet, so relaxing applications requirements to make use of
ubiquitous IP flow data may be in your best interest.  If that is not
possible, perhaps you can lobby an IPFIX canidate protocol advocate to
optionally support some more reliable mode for your application domain.

To the best of my knowledge, no IP router stops forwarding packets
because of occasionally reporting system failures (at least not by
design ;^), and that could be one ultimate consequence of mandating
application-level reliability and implementing it on a router.

Instead, IPFIX defines the failure modes for the flow information
export; it defines how the system behaves when confronted with
transport congestion or resource overloads, so that we can bound, or at
least know, the error.

Dave

On Tue, Nov 19, 2002 at 07:34:45AM +0100, Juergen Quittek wrote:
> Nevil and Dave,
> 
> Before this thread produces another 50 emails:
> Could you please comment on it with WG chair hat on?
 
> You wrote an negotiated the charter. Do you agree with
> Randy's clear statement that high reliability is not covered
> by the charter? Or do you disagree?
> 
> In either case, clarification will speed up our progress.


-- 
plonka@doit.wisc.edu  http://net.doit.wisc.edu/~plonka  ARS:N9HZF  Madison, WI

--
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 Nov 19 16:37:08 2002
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 QAA17474
	for ; Tue, 19 Nov 2002 16:37:08 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18EFxI-0004ws-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 19 Nov 2002 15:30:48 -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 18EFxG-0004wT-00
	for ipfix@net.doit.wisc.edu; Tue, 19 Nov 2002 15:30:46 -0600
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Subject: RE: [ipfix] charter re-negotiation?
Date: Tue, 19 Nov 2002 13:30:15 -0800
Message-ID: <80CC8579BE94854FB8AA48856AA8B33607B2D7@rs-sc-exc4.rs.riverstonenet.com>
Thread-Topic: [ipfix] charter re-negotiation?
Thread-Index: AcKQAf5zhnzWcVgXRQqemnmb8CE3PQAELvdc
From: "Paul Calato" 
To: , 
X-RBL-Warning: (bl.spamcop.net) Blocked - see http://spamcop.net/bl.shtml?64.95.122.60
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ietf.org id QAA17474

If sending aggregated data via IPFIX is in scope then I ask you to consider 
the affect of send and forget in that scenairo.
 
It is no longer billing applications looking for 100%  reliability but rather 
any application that wants reasonable data. Aggregated records can represent 
such large chunks of information that loosing a fewof them is likely to be a problem.
 
Is that a scenairo IPFIX is/should be concerned about?
 
Paul

	-----Original Message----- 
	From: Dave Plonka [mailto:plonka@doit.wisc.edu] 
	Sent: Tue 11/19/2002 11:28 AM 
	To: ipfix@net.doit.wisc.edu 
	Cc: 
	Subject: Re: [ipfix] charter re-negotiation?
	
	


	IPFIXers,
	
	Nevil and I have had the opportunity to discuss this...
	Here is our understanding (but in my own words of course):
	
	Our charter does not mandate that IPFIX be highly reliable at the
	transport nor the application layer.  This was intentional - only a
	subset of applications benefit significantly from that somewhat
	complicated feature which is costly to implement on some exporter
	platforms.  That said, IPFIX doesn't preclude transport or
	application-level reliability.  So, it is possible to build a
	highly-reliable system that is IPFIX conforming.
	
	The IPFIX WG, through our evaluation process, will select a protocol
	that (1) satisfies the requirements and (2) is preferred with respect
	to less tangible aspects including flexibility, simplicity, etc.
	
	If some among us believe have identified applications that require
	absolute reliability at the transport or application layer, then IPFIX
	requirements are perhaps insufficient for your applications
	requirements.  We mean IPFIX to be the "lingua franca" for the routed
	Internet, so relaxing applications requirements to make use of
	ubiquitous IP flow data may be in your best interest.  If that is not
	possible, perhaps you can lobby an IPFIX canidate protocol advocate to
	optionally support some more reliable mode for your application domain.
	
	To the best of my knowledge, no IP router stops forwarding packets
	because of occasionally reporting system failures (at least not by
	design ;^), and that could be one ultimate consequence of mandating
	application-level reliability and implementing it on a router.
	
	Instead, IPFIX defines the failure modes for the flow information
	export; it defines how the system behaves when confronted with
	transport congestion or resource overloads, so that we can bound, or at
	least know, the error.
	
	Dave
	
	On Tue, Nov 19, 2002 at 07:34:45AM +0100, Juergen Quittek wrote:
	> Nevil and Dave,
	>
	> Before this thread produces another 50 emails:
	> Could you please comment on it with WG chair hat on?
	
	> You wrote an negotiated the charter. Do you agree with
	> Randy's clear statement that high reliability is not covered
	> by the charter? Or do you disagree?
	>
	> In either case, clarification will speed up our progress.
	
	
	--
	plonka@doit.wisc.edu  http://net.doit.wisc.edu/~plonka  ARS:N9HZF  Madison, WI
	
	--
	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/
	

ÿñÞ–™šŠ[hþf£¢·hšçzßÝ¢+ÿÂ+ýçnjwlk/ázZÿŠyž²Æ yºÉIì¹»®&Þ™¨¥¶æj:+v‰¨þw­ýÚ"·ü"±ÏÞvæ§vƲþéì¹»®&ÞŠ—âÇø§™ë,j›¡Ü€­Èb½èm¶Ÿÿþ*_‹Ý¢+ÿÂ+ýçnýªÜ†+Þ


From majordomo@mil.doit.wisc.edu  Tue Nov 19 18:01:18 2002
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 SAA19875
	for ; Tue, 19 Nov 2002 18:01:17 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18EHHq-0006qo-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 19 Nov 2002 16:56:06 -0600
Received: from [147.28.4.2] (helo=roam.psg.com ident=mailnull)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18EHHn-0006qa-00
	for ipfix@net.doit.wisc.edu; Tue, 19 Nov 2002 16:56:03 -0600
Received: from localhost
	([127.0.0.1] helo=roam.psg.com.psg.com ident=randy)
	by roam.psg.com with esmtp (Exim 4.10)
	id 18EHHY-0002GA-00; Tue, 19 Nov 2002 17:55:48 -0500
From: Randy Bush 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: "Carter Bullard" 
Cc: "'Reinaldo Penno'" ,
        "'Juergen Quittek'" , 
Subject: RE: [ipfix] charter re-negotiation?
References: <5C8959A16A71B449AE793CF52FBBED660DAD23@ptah.newyork.qosient.com>
	<5C8959A16A71B449AE793CF52FBBED6607E6FD@ptah.newyork.qosient.com>
Message-Id: 
Date: Tue, 19 Nov 2002 17:55:48 -0500
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

>    I would interpret "traditional Internet reliability" 
> as "best effort", which I interpret as unreliable.

yup.  but i did receive your email.

randy


--
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 Nov 19 18:01:25 2002
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 SAA19888
	for ; Tue, 19 Nov 2002 18:01:24 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18EHIo-0006s9-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 19 Nov 2002 16:57:06 -0600
Received: from [147.28.4.2] (helo=roam.psg.com ident=mailnull)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18EHIl-0006s2-00
	for ipfix@net.doit.wisc.edu; Tue, 19 Nov 2002 16:57:04 -0600
Received: from localhost
	([127.0.0.1] helo=roam.psg.com.psg.com ident=randy)
	by roam.psg.com with esmtp (Exim 4.10)
	id 18EHIj-0002GT-00; Tue, 19 Nov 2002 17:57:01 -0500
From: Randy Bush 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: "Tal Givoly" 
Cc: "Juergen Quittek" ,
        "Reinaldo Penno" ,
        
Subject: RE: [ipfix] charter re-negotiation?
References: <26629731.1037681095@BETA>
	
Message-Id: 
Date: Tue, 19 Nov 2002 17:57:01 -0500
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

> a) Billing and Accounting are part of the charter. Otherwise, we would not
> have been involved to begin with. Furthermore, I made arguments to this
> affect in previous postings.
> b) "typical Internet reliability" is "best effort" - as Carter says -
> unreliable at best, obviously ambiguous.
> c) Billing applications do require high reliabilty.


as people keep trying to point out, if you want to do precise billing
this is not the WG for you.

randy


--
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 Nov 19 18:04:43 2002
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 SAA20004
	for ; Tue, 19 Nov 2002 18:04:43 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18EHLO-0006vK-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 19 Nov 2002 16:59:46 -0600
Received: from [147.28.4.2] (helo=roam.psg.com ident=mailnull)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18EHLL-0006vD-00
	for ipfix@net.doit.wisc.edu; Tue, 19 Nov 2002 16:59:44 -0600
Received: from localhost
	([127.0.0.1] helo=roam.psg.com.psg.com ident=randy)
	by roam.psg.com with esmtp (Exim 4.10)
	id 18EHLI-0002H5-00; Tue, 19 Nov 2002 17:59:40 -0500
From: Randy Bush 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Juergen Quittek 
Cc: Tal Givoly , Reinaldo Penno ,
        ipfix@net.doit.wisc.edu
Subject: RE: [ipfix] charter re-negotiation?
References: 
	<1886582.1037688089@BETA>
Message-Id: 
Date: Tue, 19 Nov 2002 17:59:40 -0500
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

> We just need to realize, that standardizing something with a reliability
> similar to NetFlow is intended by the charter.



indeed.  and if we need to have the charter changed to make that
sufficiently clear, just say so and it will be done.

randy


--
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 Nov 19 18:26:18 2002
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 SAA20608
	for ; Tue, 19 Nov 2002 18:26:18 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18EHgH-0007QZ-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 19 Nov 2002 17:21:21 -0600
Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18EHgG-0007Q1-00
	for ipfix@net.doit.wisc.edu; Tue, 19 Nov 2002 17:21:20 -0600
Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gAJNKJ425024;
	Tue, 19 Nov 2002 17:20:19 -0600 (CST)
Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 19 Nov 2002 15:20:06 -0800
Message-ID: <0A11633F61BD9F40B43ABCC694004F93299CE3@zsc3c026.us.nortel.com>
From: "Reinaldo Penno" 
To: Randy Bush , Juergen Quittek 
Cc: Tal Givoly , ipfix@net.doit.wisc.edu
Subject: RE: [ipfix] charter re-negotiation?
Date: Tue, 19 Nov 2002 15:20:06 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C29022.31EFEB90"
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_01C29022.31EFEB90
Content-Type: text/plain;
	charset="iso-8859-1"

Randy,

that would be my strong suggestion (make it crystal clear); change the
charter so that is clear we can have any congestion aware transport protocol
and the application protocol will be unidirectional with sequence numbers on
the headers. 

We should also remove billing and accounting from target applications and
point out this is out of scope. Or maybe say that the protocol might provide
unreliable (or best effort) billing and accouting and that carrier grade
billing and accounting should be pursed elsewhere.

regards,

Reinaldo

> -----Original Message-----
> From: Randy Bush [mailto:randy@psg.com]
> Sent: Tuesday, November 19, 2002 6:00 PM
> To: Juergen Quittek
> Cc: Tal Givoly; Penno, Reinaldo [BL60:0430:EXCH];
> ipfix@net.doit.wisc.edu
> Subject: RE: [ipfix] charter re-negotiation?
> 
> 
> > We just need to realize, that standardizing something with 
> a reliability
> > similar to NetFlow is intended by the charter.
> 
> 
> 
> indeed.  and if we need to have the charter changed to make that
> sufficiently clear, just say so and it will be done.
> 
> randy
> 
> 

------_=_NextPart_001_01C29022.31EFEB90
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [ipfix] charter re-negotiation?




Randy,




that would be my strong suggestion (make it crystal =
clear); change the charter so that is clear we can have any congestion =
aware transport protocol and the application protocol will be =
unidirectional with sequence numbers on the headers. 



We should also remove billing and accounting from =
target applications and point out this is out of scope. Or maybe say =
that the protocol might provide unreliable (or best effort) billing and =
accouting and that carrier grade billing and accounting should be =
pursed elsewhere.



regards,




Reinaldo




> -----Original Message-----

> From: Randy Bush [mailto:randy@psg.com]

> Sent: Tuesday, November 19, 2002 6:00 PM

> To: Juergen Quittek

> Cc: Tal Givoly; Penno, Reinaldo =
[BL60:0430:EXCH];

> ipfix@net.doit.wisc.edu

> Subject: RE: [ipfix] charter =
re-negotiation?

> 

> 

> > We just need to realize, that =
standardizing something with 

> a reliability

> > similar to NetFlow is intended by the =
charter.

> 

> <ad hat>

> 

> indeed.  and if we need to have the =
charter changed to make that

> sufficiently clear, just say so and it will be =
done.

> 

> randy

> 

> 





------_=_NextPart_001_01C29022.31EFEB90--

--
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 Nov 19 19:00:13 2002
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 TAA21096
	for ; Tue, 19 Nov 2002 19:00:12 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18EICJ-0000Rf-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 19 Nov 2002 17:54:27 -0600
Received: from sj-msg-core-2.cisco.com ([171.70.145.30])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18EICI-0000Qy-00
	for ipfix@net.doit.wisc.edu; Tue, 19 Nov 2002 17:54:26 -0600
Received: from mira-sjc5-f.cisco.com (IDENT:mirapoint@mira-sjc5-f.cisco.com [171.71.163.13])
	by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id gAJNkKu4027606;
	Tue, 19 Nov 2002 15:46:20 -0800 (PST)
Received: from cisco.com (dhcp-171-71-137-63.cisco.com [171.71.137.63])
	by mira-sjc5-f.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA)
	with ESMTP id AAJ40478;
	Tue, 19 Nov 2002 15:46:25 -0800 (PST)
Message-ID: <3DDACD50.24CD679B@cisco.com>
Date: Tue, 19 Nov 2002 15:46:24 -0800
From: Ganesh Sadasivan 
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Calato 
CC: Benoit Claise , Tal Givoly ,
        Jeff Meyer , carter@qosient.com,
        ipfixx 
Subject: Re: [ipfix] Multiple levels of Reliability and Directionality
References: <80CC8579BE94854FB8AA48856AA8B33607B2CF@rs-sc-exc4.rs.riverstonenet.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit



Paul Calato wrote:

>
>
>         -----Original Message-----
>         From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com]
>         Sent: Fri 11/15/2002 11:58 AM
>         To: Paul Calato
>         Cc: Benoit Claise; Tal Givoly; Jeff Meyer; carter@qosient.com; 'ipfixx'
>         Subject: Re: [ipfix] Multiple levels of Reliability and Directionality
>
>
>
>         calato@riverstonenet.com wrote:
>
>         > Benoit Claise wrote:
>         > >
>         > > Paul,
>         > >
>         > > First of all, let me take back your initial email, for clarity
>         > > purposes
>         > >
>         > >         High   - Little to no data loss
>         > >         Medium - Minimal data loss is accepted
>         > >         Low    - Data sent is best effort
>         > >
>         > > The six combinations are shown below...
>         > >
>         > >                | Uni  |  Bi
>         > >         -------+-----+--------
>         > >         High   |  1   |    4
>         > >         -------+-----+-------
>         > >         Medium |  2   |    5
>         > >         -------+-----+-------
>         > >         Low    |  3   |    6
>         > >
>         > > I think (IMHO) the most likely combinations are...
>         > >
>         > >         3. Low reliability and uni-directional. This will be used
>         > >            where the device and collector are in close proximity,
>         > >            there is high volume and some data loss is acceptable for
>         > >            the given application. Applications such as
>         > > Attack/Intrusion
>         > >            Detection Traffic Profiling, etc...
>         > >
>         > >         5. Bi-directional medium reliability. This will be used
>         > >            where high volume and increased reliability are needed.
>         > >            Applications
>         > >            such as Usage-based Accounting where 95th percentile
>         > > billing
>         > >            model is used. Or even Traffic Engineering where network
>         > >            policy decisions are based on the data collected.
>         > >
>         > >         4. Bi-directional high reliability would be used where the
>         > >            Usage-based Accounting application has strict requirements
>         > >            on data loss.
>         > >
>         > > I agree on 3, this is the minimum.
>         > >
>         > > I agree on 5 but I fear that the application level ACK will not always
>         > > be a possible solution from a router point of view. What if the router
>         > > exports so much flow records that it can't cache them while waiting
>         > > for the ACK.
>         > > So basically, resending the flow records is not always possible.
>         > > So, if you conclude that the requirement for 5 is the bidirectionality
>         > > with application level ACK, then this requirement is not always
>         > > possible!
>         >
>         >         Agreed. In very high volume deployments I would
>         >         use option #3.
>         >
>         > > IMHO, 5 could alos be
>         > >         2 with best-effort
>         > >         or 2 with a carefully designed network
>         >
>         >         If the customer can design their accounting network
>         >         in such away. But I'm not sure we want to require that.
>         >
>         >         Lets assume that aggregation is happening at
>         >         a reasonably high level (which drops the flow rate
>         >         to a manageable level). But the consequence is that
>         >         one lost record can be a huge chunk of missing data.
>         >
>         >         In this case reliability is the issue not the data
>         >         rate. I'm advocating a reliability option (note I said option)
>         >         as a way to solve this.
>         >
>         >
>         > >
>         > > Regarding 4, Randy replied already
>         > >
>         > >      > Somehow, the requirements discussion suffers from a split:
>         > >      > There are requirements resulting from the intention of
>         > >      > standardzing a highly reliable metering standard for
>         > >      precise
>         > >      > accounting (and billing). Differing from these are
>         > >      requirements
>         > >      > for a simpler metering standard more oriented at what I
>         > >      would
>         > >      > call "typical Internet reliability".
>         > >
>         > >       the original goal, which the iesg thinks was chartered,
>         > >      is the
>         > >      latter.
>         > >
>         >
>         >         There was a lot of push back by the group on that statement.
>         >         I asked for clarification but have not received any.
>
>         I feel the base line IPFIX protocol does require just 3 or 6. This would
>         provide the simplest and the most efficient means for all applications.
>         For those applications like billing with more stringent requirements,
>         why can't extensions be built on top of the base protocol as a higher
>         level application? By doing this we can cover the entire matrix.
>         There is a vast majority of apps that need just the 3.
>         and building a multi-level reliable scheme into the basre IPFIX protocol
>         would result in a less efficient use of the protocol for apps that really
>         don't care for this.
>
>         [paul] If we have a simple, uni-directional unreliable base (#3) then adding reliability
>
>         on top of that base can still be part of the IPFIX working group. It would seem there
>
>         are important applications which need that feature, there is support on the list for specifying
>
>         it and it seems there are valid deployment scenarios where it would be used (e.g. aggregated
>
>         records).
>

What I meant here is that a system implementing #3 alone should be sufficient enough
to be IPFIX compliant. Depending on validity and extensiveness of deployment one could
put in additional features on top of #3  . This list I guess would  be a growing one, as
different apps have different sets of constraints.
-ganesh

>
>
>
>         Would you support an approach with #3 as a base and  #4 and #5 as additions? I think the

>
>
>         key here is really keeping #3 as the base and #4 and #5 as enhancements. For example,
>
>         if #3 solves passing the template info #4 and #5 cannot change how that is done. Otherwise
>
>         it would lead to too much divergence.

Agreed.

Thanks
Ganesh

>
>
>         [Paul-end]
>
>         Thanks
>         Ganesh
>
>
>         >
>         >
>         >         Paul
>         >
>         > > > Let me see if we all agree on a couple things...
>         > > >
>         > > >         1. There is no such thing as partially uni-directional.
>         > > >         2. IPFIX ought to support a uni-directional mode of
>         > > > operation.
>         > > >
>         > > Agreed.
>         > >
>         > > 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  Tue Nov 19 23:43:23 2002
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 XAA17076
	for ; Tue, 19 Nov 2002 23:43:23 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18EMU8-0006Yg-00
	for ipfix-list@mil.doit.wisc.edu; Tue, 19 Nov 2002 22:29:08 -0600
Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18EMU4-0006YN-00
	for ipfix-eval@net.doit.wisc.edu; Tue, 19 Nov 2002 22:29:04 -0600
Received: from cisco.com (ams-clip-vpn-dhcp13.cisco.com [10.50.0.12])
	by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id gAK4SW702865
	for ; Wed, 20 Nov 2002 05:28:32 +0100 (CET)
Message-ID: <3DDB0F6F.8040905@cisco.com>
Date: Wed, 20 Nov 2002 05:28:31 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020815
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ipfix-eval@net.doit.wisc.edu
Subject: [ipfix-eval] NetFlow V9: SCTP 
References: <0A11633F61BD9F40B43ABCC694004F930DAD32@zsc3c026.us.nortel.com>  <3DD00643.E62AF044@riverstonenet.com>
Content-Type: multipart/alternative;
 boundary="------------000607090909030508010907"
Precedence: bulk
Sender: majordomo listserver 


--------------000607090909030508010907
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

One clarification about the transport protocol that will be used NetFlow 
version 9, as UDP is not congestion aware.
Let me also stress that NetFlow version 9 has been designed to be 
transport protocol independent!

Cisco's official position is:
Reliable & congestion aware transport for NetFlow v9 is on the roadmap 
for Cisco IOS.  Cisco is currently studying various transport mechanisms 
including SCTP; if determined that SCTP is the best solution to satify 
this requirement, it will soon be implemented. 

http://www2.auckland.ac.nz/net//ipfix/draft-ietf-ipfix-protocol-eval-00.txt
If you feel appropriate, the evaluation team should  update the section 
5.3 on data transfer accordingly (maybe U for upcoming compliance for 
example,)

5.3 Data Transfer  (6.3) 
    
5.3.1 Congestion Awareness  (6.3.1) 

LFAP: T     CRANE: T     IPDR: T     NetFlow: E     Diameter: T
                                       
5.3.2 Reliability  (6.3.2) 

LFAP: T     CRANE: T     IPDR: T     NetFlow: P     Diameter: T



     -E  Extension required for total compliance: The protocol is 
         prepared to be extended and it is possible to extend it in a 
         way that it meets the requirement. This grade is only 
         applicable to protocols that are explicitly open to externally 
         defined extensions, such as SNMP is extended by MIB modules or 
         DIAMETER is extended by application modules. It is not 
         applicable to protocols, where the protocol specification   
         itself needs to be extended in order to comply with the     
         requirement. 
    
     -P  Partial compliance: The requirement is met partially by the 
         protocol specification. 
    
     -U  Upcoming compliance: The requirement is not met or met 
          partially by the protocol specification, but there is a 
          concrete plan for an upcoming version of the protocol. 

Regards, Benoit.



--------------000607090909030508010907
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit




  
  


Dear all,



One clarification about the transport protocol that will be used NetFlow
version 9, as UDP is not congestion aware.

Let me also stress that NetFlow version 9 has been designed to be transport
protocol independent!



Cisco's official position is:


Reliable & congestion aware 
 transport for NetFlow v9 is on the roadmap for Cisco IOS.  Cisco is  currently 
studying various transport mechanisms including SCTP; if determined  that 
SCTP is the best solution to satify this requirement, it will soon be  implemented. 




http://www2.auckland.ac.nz/net//ipfix/draft-ietf-ipfix-protocol-eval-00.txt

If you feel appropriate, the evaluation
team should  update the section 5.3 on data transfer accordingly
(maybe U for upcoming compliance for example,)



  
5.3 Data Transfer  (6.3) 
    
5.3.1 Congestion Awareness  (6.3.1) 

LFAP: T     CRANE: T     IPDR: T     NetFlow: E     Diameter: T
                                       
5.3.2 Reliability  (6.3.2) 

LFAP: T     CRANE: T     IPDR: T     NetFlow: P     Diameter: T









     -E  Extension required for total compliance: The protocol is 
         prepared to be extended and it is possible to extend it in a 
         way that it meets the requirement. This grade is only 
         applicable to protocols that are explicitly open to externally 
         defined extensions, such as SNMP is extended by MIB modules or 
         DIAMETER is extended by application modules. It is not 
         applicable to protocols, where the protocol specification   
         itself needs to be extended in order to comply with the     
         requirement. 
    
     -P  Partial compliance: The requirement is met partially by the 
         protocol specification. 
    
     -U  Upcoming compliance: The requirement is not met or met 
          partially by the protocol specification, but there is a 
          concrete plan for an upcoming version of the protocol. 

Regards, Benoit.










--------------000607090909030508010907--


--
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 Nov 20 01:31:49 2002
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 BAA18912
	for ; Wed, 20 Nov 2002 01:31:48 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18EOFj-000175-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 20 Nov 2002 00:22:23 -0600
Received: from rip.psg.com ([147.28.0.39])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18EOFh-00016x-00
	for ipfix-eval@net.doit.wisc.edu; Wed, 20 Nov 2002 00:22:21 -0600
Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com)
	by rip.psg.com with esmtp (Exim 4.10)
	id 18EOFg-000AZ2-00; Tue, 19 Nov 2002 22:22:20 -0800
From: Randy Bush 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Benoit Claise 
Cc: ipfix-eval@net.doit.wisc.edu
Subject: Re: [ipfix-eval] NetFlow V9: SCTP 
References: <0A11633F61BD9F40B43ABCC694004F930DAD32@zsc3c026.us.nortel.com>
	
	<3DD00643.E62AF044@riverstonenet.com>
	<3DDB0F6F.8040905@cisco.com>
Message-Id: 
Date: Tue, 19 Nov 2002 22:22:20 -0800
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit



> Cisco's official position is:

this is EXCEEDINGLY INAPPROPRIATE for an IETF mailing list.

randy


--
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 Nov 20 11:23:22 2002
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 LAA23756
	for ; Wed, 20 Nov 2002 11:23:21 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18EXEj-0000p2-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 20 Nov 2002 09:57:57 -0600
Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18EXEh-0000oL-00
	for ipfix-eval@net.doit.wisc.edu; Wed, 20 Nov 2002 09:57:56 -0600
Received: from cisco.com (ams-clip-vpn-dhcp7.cisco.com [10.50.0.6])
	by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id gAKFuo719588;
	Wed, 20 Nov 2002 16:56:51 +0100 (CET)
Message-ID: <3DDBB0C1.9070908@cisco.com>
Date: Wed, 20 Nov 2002 16:56:49 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020815
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Randy Bush 
CC: ipfix-eval@net.doit.wisc.edu
Subject: Re: [ipfix-eval] NetFlow V9: SCTP
References: <0A11633F61BD9F40B43ABCC694004F930DAD32@zsc3c026.us.nortel.com>		<3DD00643.E62AF044@riverstonenet.com>	<3DDB0F6F.8040905@cisco.com> 
Content-Type: multipart/alternative;
 boundary="------------080202050909020809000909"
Precedence: bulk
Sender: majordomo listserver 


--------------080202050909020809000909
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

I just wanted to adjust a section in 
http://www2.auckland.ac.nz/net//ipfix/draft-ietf-ipfix-protocol-eval-00.txt
Because I was seing the evaluation team not using the Upcoming 
Compliance status, even if I put it in my draft 
http://www.ietf.org/internet-drafts/draft-claise-ipfix-eval-netflow-03.txt

    3.5.3.1 Congestion Awareness (6.3.1)
    Upcoming Compliance with SCTP.


Part of the IPFIX evaluation process, we are asked to evaluate our 
protocol against the IPFIX requirements.
We were even asked to say what we had in mind to make it more compliant 
(roadmap?). At least, this is the way I understood it.

     -U  Upcoming compliance: The requirement is not met or met
          partially by the protocol specification, but there is a
          concrete plan for an upcoming version of the protocol.

Regarding future directions, I was thinking an official statement was 
appropriate.
Sorry if I offended anybody.

Now, maybe the question is about the Upcoming Compliance.
If this is not used by the evaluation team, maybe it should be removed 
from the evaluation process?

Regards, Benoit.

>
>
>  
>
>>Cisco's official position is:
>>    
>>
>
>this is EXCEEDINGLY INAPPROPRIATE for an IETF mailing list.
>
>randy
>  
>



--------------080202050909020809000909
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit




  
  


Dear all,



I just wanted to adjust a section in http://www2.auckland.ac.nz/net//ipfix/draft-ietf-ipfix-protocol-eval-00.txt

Because I was seing the evaluation team not using the Upcoming Compliance
status, even if I put it in my draft http://www.ietf.org/internet-drafts/draft-claise-ipfix-eval-netflow-03.txt


3.5.3.1 Congestion Awareness (6.3.1) 

Upcoming Compliance with SCTP. 





Part of the IPFIX evaluation process, we are asked to evaluate our protocol
against the IPFIX requirements.

We were even asked to say what we had in mind to make it more compliant (roadmap?).
At least, this is the way I understood it.



     -U  Upcoming compliance: The requirement is not met or met 

          partially by the protocol specification, but there is a 

          concrete plan for an upcoming version of the protocol. 



Regarding future directions, I was thinking an official statement was appropriate.

Sorry if I offended anybody.



Now, maybe the question is about the Upcoming Compliance.

If this is not used by the evaluation team, maybe it should be removed from
the evaluation process?



Regards, Benoit.





  
<ad hat on>

  

  

    
Cisco's official position is:
    

  

  

this is EXCEEDINGLY INAPPROPRIATE for an IETF mailing list.

randy
  










--------------080202050909020809000909--


--
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 Nov 20 14:59:27 2002
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 OAA29138
	for ; Wed, 20 Nov 2002 14:59:26 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18EakQ-000680-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 20 Nov 2002 13:42:54 -0600
Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18EakO-00067s-00
	for ipfix@net.doit.wisc.edu; Wed, 20 Nov 2002 13:42:52 -0600
Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gAKJg2520897;
	Wed, 20 Nov 2002 13:42:03 -0600 (CST)
Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id ; Wed, 20 Nov 2002 11:41:49 -0800
Message-ID: <0A11633F61BD9F40B43ABCC694004F93313105@zsc3c026.us.nortel.com>
From: "Reinaldo Penno" 
To: "Reinaldo Penno" , Randy Bush 
Cc: ipfix@net.doit.wisc.edu
Subject: RE: [ipfix] charter re-negotiation?
Date: Wed, 20 Nov 2002 11:41:43 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C290CC.DA2CFDE8"
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_01C290CC.DA2CFDE8
Content-Type: text/plain;
	charset="iso-8859-1"

Given the amount of emails I got on this....
 
yes, I was being serious. If that's what the ADs and Chairs want It's better
to be specific and get over with this than to keep "cooking" this decision.
Then everything is specified and in clear.
 
regards,
 
Reinaldo

-----Original Message-----
From: Penno, Reinaldo [BL60:0430:EXCH] 
Sent: Tuesday, November 19, 2002 6:20 PM
To: Randy Bush; Juergen Quittek
Cc: Tal Givoly; ipfix@net.doit.wisc.edu
Subject: RE: [ipfix] charter re-negotiation?



Randy, 

that would be my strong suggestion (make it crystal clear); change the
charter so that is clear we can have any congestion aware transport protocol
and the application protocol will be unidirectional with sequence numbers on
the headers. 

We should also remove billing and accounting from target applications and
point out this is out of scope. Or maybe say that the protocol might provide
unreliable (or best effort) billing and accouting and that carrier grade
billing and accounting should be pursed elsewhere.

regards, 

Reinaldo 

> -----Original Message----- 
> From: Randy Bush [ mailto:randy@psg.com  ] 
> Sent: Tuesday, November 19, 2002 6:00 PM 
> To: Juergen Quittek 
> Cc: Tal Givoly; Penno, Reinaldo [BL60:0430:EXCH]; 
> ipfix@net.doit.wisc.edu 
> Subject: RE: [ipfix] charter re-negotiation? 
> 
> 
> > We just need to realize, that standardizing something with 
> a reliability 
> > similar to NetFlow is intended by the charter. 
> 
>  
> 
> indeed.  and if we need to have the charter changed to make that 
> sufficiently clear, just say so and it will be done. 
> 
> randy 
> 
> 


------_=_NextPart_001_01C290CC.DA2CFDE8
Content-Type: text/html;
	charset="iso-8859-1"




RE: [ipfix] charter re-negotiation?




Given 
the amount of emails I got on this....


 


yes, I 
was being serious. If that's what the ADs and Chairs want It's better to be 
specific and get over with this than to keep "cooking" this decision. Then 
everything is specified and in clear.


 


regards,


 


Reinaldo



  
-----Original Message-----
From: Penno, Reinaldo 
  [BL60:0430:EXCH] 
Sent: Tuesday, November 19, 2002 6:20 
  PM
To: Randy Bush; Juergen Quittek
Cc: Tal Givoly; 
  ipfix@net.doit.wisc.edu
Subject: RE: [ipfix] charter 
  re-negotiation?


  
Randy, 

  
that would be my strong suggestion (make it crystal clear); 
  change the charter so that is clear we can have any congestion aware transport 
  protocol and the application protocol will be unidirectional with sequence 
  numbers on the headers. 

  
We should also remove billing and accounting from target 
  applications and point out this is out of scope. Or maybe say that the 
  protocol might provide unreliable (or best effort) billing and accouting and 
  that carrier grade billing and accounting should be pursed 
  elsewhere.

  
regards, 

  
Reinaldo 

  
> -----Original Message----- 
> 
  From: Randy Bush [mailto:randy@psg.com] 
> Sent: Tuesday, November 19, 2002 6:00 PM 
> To: Juergen Quittek 
> Cc: Tal Givoly; 
  Penno, Reinaldo [BL60:0430:EXCH]; 
> 
  ipfix@net.doit.wisc.edu 
> Subject: RE: [ipfix] 
  charter re-negotiation? 
> 
> 
> > We just need to realize, that 
  standardizing something with 
> a reliability 
  
> > similar to NetFlow is intended by the 
  charter. 
> 
> <ad 
  hat> 
> 
> 
  indeed.  and if we need to have the charter changed to make that 
  
> sufficiently clear, just say so and it will be 
  done. 
> 
> randy 
  
> 
> 



------_=_NextPart_001_01C290CC.DA2CFDE8--

--
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 Nov 20 22:16:25 2002
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 WAA10024
	for ; Wed, 20 Nov 2002 22:16:25 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18Ehg4-0000jS-00
	for ipfix-list@mil.doit.wisc.edu; Wed, 20 Nov 2002 21:06:52 -0600
Received: from atlrel6.hp.com ([156.153.255.205])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18Ehg2-0000jI-00
	for ipfix@net.doit.wisc.edu; Wed, 20 Nov 2002 21:06:51 -0600
Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191])
	by atlrel6.hp.com (Postfix) with ESMTP
	id 9E663905; Wed, 20 Nov 2002 22:06:49 -0500 (EST)
Received: from xatlbh4.atl.hp.com (xatlbh4.atl.hp.com [15.45.89.189])
	by xatlrelay2.atl.hp.com (Postfix) with ESMTP
	id 381F4400086; Wed, 20 Nov 2002 22:06:23 -0500 (EST)
Received: by xatlbh4.atl.hp.com with Internet Mail Service (5.5.2655.55)
	id ; Wed, 20 Nov 2002 22:06:13 -0500
Message-ID: <4341EF5F8B4AD311AB4B00902740B9F212D249D8@xcup02.cup.hp.com>
From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" 
To: "'Reinaldo Penno'" , Randy Bush 
Cc: ipfix@net.doit.wisc.edu
Subject: RE: [ipfix] charter re-negotiation?
Date: Wed, 20 Nov 2002 22:06:12 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2910A.F2562EB0"
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_01C2910A.F2562EB0
Content-Type: text/plain;
	charset="iso-8859-1"

It sounds like the intent is to change to charter to better suit some
candidate protocols.  If that is the case, then a tremendous amount of time
by various participants has been wasted.
 
I'm sorry I took the statement in the charter of addressing accounting and
billing at face value :-(
 
I also suspect that this will do a lot of disservice to paying customers who
would like to employ this technology for business activities.
 
Perhaps at tomorrows meeting we can settle this.
 
Regards,
 
  Jeff Meyer

-----Original Message-----
From: Reinaldo Penno [mailto:rpenno@nortelnetworks.com]
Sent: Wednesday, November 20, 2002 11:42 AM
To: Reinaldo Penno; Randy Bush
Cc: ipfix@net.doit.wisc.edu
Subject: RE: [ipfix] charter re-negotiation?


Given the amount of emails I got on this....
 
yes, I was being serious. If that's what the ADs and Chairs want It's better
to be specific and get over with this than to keep "cooking" this decision.
Then everything is specified and in clear.
 
regards,
 
Reinaldo

-----Original Message-----
From: Penno, Reinaldo [BL60:0430:EXCH] 
Sent: Tuesday, November 19, 2002 6:20 PM
To: Randy Bush; Juergen Quittek
Cc: Tal Givoly; ipfix@net.doit.wisc.edu
Subject: RE: [ipfix] charter re-negotiation?



Randy, 

that would be my strong suggestion (make it crystal clear); change the
charter so that is clear we can have any congestion aware transport protocol
and the application protocol will be unidirectional with sequence numbers on
the headers. 

We should also remove billing and accounting from target applications and
point out this is out of scope. Or maybe say that the protocol might provide
unreliable (or best effort) billing and accouting and that carrier grade
billing and accounting should be pursed elsewhere.

regards, 

Reinaldo 

> -----Original Message----- 
> From: Randy Bush [ mailto:randy@psg.com  ] 
> Sent: Tuesday, November 19, 2002 6:00 PM 
> To: Juergen Quittek 
> Cc: Tal Givoly; Penno, Reinaldo [BL60:0430:EXCH]; 
> ipfix@net.doit.wisc.edu 
> Subject: RE: [ipfix] charter re-negotiation? 
> 
> 
> > We just need to realize, that standardizing something with 
> a reliability 
> > similar to NetFlow is intended by the charter. 
> 
>  
> 
> indeed.  and if we need to have the charter changed to make that 
> sufficiently clear, just say so and it will be done. 
> 
> randy 
> 
> 


------_=_NextPart_001_01C2910A.F2562EB0
Content-Type: text/html;
	charset="iso-8859-1"




RE: [ipfix] charter re-negotiation?




It 
sounds like the intent is to change to charter to better suit some candidate 
protocols.  If that is the case, then a tremendous amount of time by 
various participants has been wasted.


 


I'm 
sorry I took the statement in the charter of addressing accounting and billing 
at face value :-(


 


I also 
suspect that this will do a lot of disservice to paying customers who would like 
to employ this technology for business activities.


 


Perhaps at tomorrows meeting we can settle this.


 


Regards,


 


  
Jeff Meyer



  
-----Original Message-----
From: Reinaldo Penno 
  [mailto:rpenno@nortelnetworks.com]
Sent: Wednesday, November 20, 
  2002 11:42 AM
To: Reinaldo Penno; Randy Bush
Cc: 
  ipfix@net.doit.wisc.edu
Subject: RE: [ipfix] charter 
  re-negotiation?


  
Given the amount of emails I got on this....

  
 

  
yes, 
  I was being serious. If that's what the ADs and Chairs want It's better to be 
  specific and get over with this than to keep "cooking" this decision. Then 
  everything is specified and in clear.

  
 

  
regards,

  
 

  
Reinaldo

  

    
-----Original Message-----
From: Penno, Reinaldo 
    [BL60:0430:EXCH] 
Sent: Tuesday, November 19, 2002 6:20 
    PM
To: Randy Bush; Juergen Quittek
Cc: Tal Givoly; 
    ipfix@net.doit.wisc.edu
Subject: RE: [ipfix] charter 
    re-negotiation?


    
Randy, 

    
that would be my strong suggestion (make it crystal clear); 
    change the charter so that is clear we can have any congestion aware 
    transport protocol and the application protocol will be unidirectional with 
    sequence numbers on the headers. 

    
We should also remove billing and accounting from target 
    applications and point out this is out of scope. Or maybe say that the 
    protocol might provide unreliable (or best effort) billing and accouting and 
    that carrier grade billing and accounting should be pursed 
    elsewhere.

    
regards, 

    
Reinaldo 

    
> -----Original Message----- 
> 
    From: Randy Bush [mailto:randy@psg.com] 
> Sent: Tuesday, November 19, 2002 6:00 PM 
> To: Juergen Quittek 
> Cc: Tal Givoly; 
    Penno, Reinaldo [BL60:0430:EXCH]; 
> 
    ipfix@net.doit.wisc.edu 
> Subject: RE: [ipfix] 
    charter re-negotiation? 
> 
> 
> > We just need to realize, that 
    standardizing something with 
> a 
    reliability 
> > similar to NetFlow is intended 
    by the charter. 
> 
> 
    <ad hat> 
> 
> 
    indeed.  and if we need to have the charter changed to make that 
    
> sufficiently clear, just say so and it will be 
    done. 
> 
> randy 
    
> 
> 



------_=_NextPart_001_01C2910A.F2562EB0--

--
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 Nov 21 01:59:02 2002
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 BAA14439
	for ; Thu, 21 Nov 2002 01:59:02 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18El6w-0005TO-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 21 Nov 2002 00:46:50 -0600
Received: from smtp.desyne.com ([64.124.142.14])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18El6u-0005TJ-00
	for ipfix@net.doit.wisc.edu; Thu, 21 Nov 2002 00:46:48 -0600
Received: from AHEINTZPC (slip-12-64-54-254.mis.prserv.net [12.64.54.254])
	by smtp.desyne.com (8.11.4/8.11.3) with SMTP id gAL6klP00550;
	Thu, 21 Nov 2002 01:46:47 -0500
From: "Aron Heintz" 
To: "Ivan Batanov" , 
Cc: "Jeff Meyer" 
Subject: RE: [ipfix] RE: [ipfix-eval] IPDR response to evaluation drafts
Date: Thu, 21 Nov 2002 01:50:21 -0500
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4920.2300
In-reply-to: 
Importance: Normal
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

	I'd like to point out that Ivan here violates the norms that permit healthy
dialog and collaboration in the IETF environment.  Specifically, he:

	1) Contributed misinformation instead of speaking from a position of
knowledge.  He either spent less than an hour reading NDM-U v3, or (worse)
is intentionally distorting the history of the specification.
	2) Posted criticism of one of the protocol candidates without revealing
which candidate he is advocating.  It is clear that he has a hidden agenda
of supporting one of the other candidates.  Which is it?
	3) Speaks briefly from the requirements, but fails to apply the same
measures to the other protocol candidates.  To a literal-minded thinker,
Diameter, Netflow v9, and Streaming IPDR should all be eliminated based on
"lack of current implementations", even though all are minor evolutions of
widely proven technologies.

	Jeff did a good job of correcting the misinformation in the original
message - I refer to Jeff's comments for technical clarity.

Aron Heintz
President, www.IPDR.org
+1 202-258-5544

-----Original Message-----
From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf
Of Ivan Batanov
Sent: Monday, November 18, 2002 5:38
To: ipfix@net.doit.wisc.edu
Subject: [ipfix] RE: [ipfix-eval] IPDR response to evaluation drafts


Hello!

Regarding the current deployment status of IPDR I would like to add my
comments on the lack of current deployment using IPDR streaming protocol
that has been proposed to the IPFIX WG.

To the best of my knowledge there has been no interoperability testing of
this proposed streaming protocol, nor is there any "field proven"
implementation. These remarks do not imply that IPDR streaming would not
work, but the evaluators might not have understood the implications of what
Jeff Meyer's comment:

"The specific procedures introduced in Streaming IPDR are not currently
available with commercial products."
(from http://ipfix.doit.wisc.edu/eval/draft-meyer-ipfix-ipdr-eval-00.txt).

As IPDR NDM-U version 3.1 (the first version with XDR-based data
representation) was just approved in October, 2002 and there are no
production deployments of this substantially new version of the protocol.
IPDR streaming is based on this new data representation, with further
extensions (not yet approved by IPDR.org) for streaming, identified as
future version 4 of the protocol (as documented in the submission) . All
references to interoperability of IPDR are based on previous versions of the
protocol, which are usinb verbose XML instead of the proposed compact binary
representation.

There has been interoperability testing between a few of the IPDR.org
members using libraries implementing the compact reporesentation. Such
libraries are available to the IPDR members. These interoparabilities
typically employ file-based transports (FTP/shared directories) rather than
the proposed streaming IPDR protocol.

"Field proven" for IPDR should be considered to refer to older versions of a
file-based, XML-encoded version of the protocol that does not support
streaming and which is so verbose as to be unusable by IPFIX.

Furthermore, the terms "field proven" or "widely deployed" mentioned here
relate to the "D" interface (as specified in NDM-U 3.1) - the interface
between mediation systems and billing systems - not the "A" interface
(between network elements and mediation systems - which is deemed out of
scope in section 2.4.2.1 of the recently approved NDM-U 3.1). This means
that the field experience of IPDR, besides rare possible exceptions, hasn't
reached routers, switches, or other "devices", but rather was focused on
host-based IPC mechanisms.

Yours sincerely,

Ivan Batanov
Senior Network Engineer
Earthlink, Inc.
e-mail: ivanb@corp.earthlink.net


--
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 Nov 21 07:35:03 2002
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 HAA29488
	for ; Thu, 21 Nov 2002 07:35:02 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18EqMU-0007NR-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 21 Nov 2002 06:23:14 -0600
Received: from usmail.xacct.com ([204.253.100.12])
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 18EqMS-0007NA-00
	for ipfix@net.doit.wisc.edu; Thu, 21 Nov 2002 06:23:12 -0600
Received: from peter (slip-210-88-163-182.to.jp.prserv.net [210.88.163.182])
	by usmail.xacct.com (8.11.2/8.11.2) with SMTP id gALCQE200363;
	Thu, 21 Nov 2002 04:26:21 -0800
From: "Peter Ludemann" 
To: "Aron Heintz" ,
        "Ivan Batanov" , 
Cc: "Jeff Meyer" 
Subject: RE: [ipfix] RE: [ipfix-eval] IPDR response to evaluation drafts
Date: Thu, 21 Nov 2002 04:22:20 -0800
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: 
Precedence: bulk
Sender: majordomo listserver 
Content-Transfer-Encoding: 7bit

Sitting in my hotel room in Tokyo, I feel disappointed at missing IETF ...
the back-and-forth of email is almost as entertaining as the sumo matches on
TV.

Ah, for the old days of "rough consensus and running code" ... because
there's nothing like the actual experience of implementation to validate a
design. I defy anybody to implement TCP from just RFC 793 -- if you don't
believe me, ask people who lived through networks that had both the BSD and
Microsoft implementations.

Are Diameter, NetFlowV9, Streaming IPDR merely "minor evolutions of widely
proven technologies" as Aron claims, and not needing an implementation to
show how well they work? I can't speak to Diameter; but NetFlow is not easy
to collect (presumably it's easy to generate); and anybody implementing
IPDR-streaming will discover that building a system that can fail-over
nicely is just a bit trickier than it appears -- I wish I could be in
Atlanta to regale y'all over a few beers.

- peter

> -----Original Message-----
> From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf
> Of Aron Heintz
> Sent: Wednesday, November 20, 2002 10:50 PM
> To: Ivan Batanov; ipfix@net.doit.wisc.edu
> Cc: Jeff Meyer
> Subject: RE: [ipfix] RE: [ipfix-eval] IPDR response to evaluation drafts
>
>
> 	I'd like to point out that Ivan here violates the norms
> that permit healthy
> dialog and collaboration in the IETF environment.  Specifically, he:
>
> 	1) Contributed misinformation instead of speaking from a position of
> knowledge.  He either spent less than an hour reading NDM-U v3, or (worse)
> is intentionally distorting the history of the specification.
> 	2) Posted criticism of one of the protocol candidates
> without revealing
> which candidate he is advocating.  It is clear that he has a hidden agenda
> of supporting one of the other candidates.  Which is it?
> 	3) Speaks briefly from the requirements, but fails to apply the same
> measures to the other protocol candidates.  To a literal-minded thinker,
> Diameter, Netflow v9, and Streaming IPDR should all be eliminated based on
> "lack of current implementations", even though all are minor evolutions of
> widely proven technologies.
>
> 	Jeff did a good job of correcting the misinformation in the original
> message - I refer to Jeff's comments for technical clarity.
>
> Aron Heintz
> President, www.IPDR.org
> +1 202-258-5544
>
> -----Original Message-----
> From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf
> Of Ivan Batanov
> Sent: Monday, November 18, 2002 5:38
> To: ipfix@net.doit.wisc.edu
> Subject: [ipfix] RE: [ipfix-eval] IPDR response to evaluation drafts
>
>
> Hello!
>
> Regarding the current deployment status of IPDR I would like to add my
> comments on the lack of current deployment using IPDR streaming protocol
> that has been proposed to the IPFIX WG.
>
> To the best of my knowledge there has been no interoperability testing of
> this proposed streaming protocol, nor is there any "field proven"
> implementation. These remarks do not imply that IPDR streaming would not
> work, but the evaluators might not have understood the
> implications of what
> Jeff Meyer's comment:
>
> "The specific procedures introduced in Streaming IPDR are not currently
> available with commercial products."
> (from http://ipfix.doit.wisc.edu/eval/draft-meyer-ipfix-ipdr-eval-00.txt).
>
> As IPDR NDM-U version 3.1 (the first version with XDR-based data
> representation) was just approved in October, 2002 and there are no
> production deployments of this substantially new version of the protocol.
> IPDR streaming is based on this new data representation, with further
> extensions (not yet approved by IPDR.org) for streaming, identified as
> future version 4 of the protocol (as documented in the submission) . All
> references to interoperability of IPDR are based on previous
> versions of the
> protocol, which are usinb verbose XML instead of the proposed
> compact binary
> representation.
>
> There has been interoperability testing between a few of the IPDR.org
> members using libraries implementing the compact reporesentation. Such
> libraries are available to the IPDR members. These interoparabilities
> typically employ file-based transports (FTP/shared directories)
> rather than
> the proposed streaming IPDR protocol.
>
> "Field proven" for IPDR should be considered to refer to older
> versions of a
> file-based, XML-encoded version of the protocol that does not support
> streaming and which is so verbose as to be unusable by IPFIX.
>
> Furthermore, the terms "field proven" or "widely deployed" mentioned here
> relate to the "D" interface (as specified in NDM-U 3.1) - the interface
> between mediation systems and billing systems - not the "A" interface
> (between network elements and mediation systems - which is deemed out of
> scope in section 2.4.2.1 of the recently approved NDM-U 3.1). This means
> that the field experience of IPDR, besides rare possible
> exceptions, hasn't
> reached routers, switches, or other "devices", but rather was focused on
> host-based IPC mechanisms.
>
> Yours sincerely,
>
> Ivan Batanov
> Senior Network Engineer
> Earthlink, Inc.
> e-mail: ivanb@corp.earthlink.net
> 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 Nov 25 12:26:54 2002
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 MAA11313
	for ; Mon, 25 Nov 2002 12:26:54 -0500 (EST)
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18GM7f-0004fQ-00
	for ipfix-list@mil.doit.wisc.edu; Mon, 25 Nov 2002 10:30:11 -0600
Received: from dplonka by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 18GM7c-0004fK-00; Mon, 25 Nov 2002 10:30:08 -0600
Date: Mon, 25 Nov 2002 10:30:08 -0600
From: Dave Plonka 
To: ipfix@net.doit.wisc.edu
Cc: Randy Bush , Bert Wijnen 
Subject: [ipfix] DRAFT IPFIX meeting minutes, IETF55
Message-ID: <20021125103008.A16548@doit.wisc.edu>
Reply-To: plonka@doit.wisc.edu
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="jRHKVT23PllUwdXP"
X-Mailer: Mutt 1.0.1i
Organization: UW-Madison, DoIT, Network Services
X-VMS-Error: %SYSTEM-F-LOGSTALL, transaction logging activity is stalled
X-Shakespearean-Insult: Thou ruttish tickle-brained death-token
Precedence: bulk
Sender: majordomo listserver 


--jRHKVT23PllUwdXP
Content-Type: text/plain; charset=us-ascii


IPFIXers,

Please review the attached DRAFT minutes of the IPFIX meeting last week
at IET55 in Atlanta.  Please send any follow-up comments/suggestions/
corrections to the list.

Thanks,
Dave

P.S. The slide shows (and also the draft minutes) are available at:

   http://ipfix.doit.wisc.edu/IETF55/

The eval slide show is pending...

-- 
plonka@doit.wisc.edu  http://net.doit.wisc.edu/~plonka  ARS:N9HZF  Madison, WI

--jRHKVT23PllUwdXP
Content-Type: text/plain
Content-Disposition: attachment; filename="minutes.txt"

DRAFT Minutes of the IP Flow Information eXport (IPFIX) WG
IETF 55, Atlanta, Thursday November 21, 2002
49 people in attendance

Reported by Dave Plonka & Nevil Brownlee (co-chairs) based on notes
from scribes Cindy Mills, Chris Elliot, and George Michaelson

The meeting agenda and slides are available here:

   http://ipfix.doit.wisc.edu/IETF55/

Mark Allman gave a short "public service announcement" regaring the IMRG.

Opening remarks from the chair: IPFIX charter remains the same.
Focus is on 'base level' standard which supports what people do now
using one-way transport, but should not lock out the ability to do
a next level on top of IPFIX that can provide different levels of
transport reliability/service.

The Applicability Draft "draft-zseby-ipfix-applicability-00.txt"
was adopted as a WG draft by a hum, i.e. the next version will be
submitted as a WG draft.

Juergen Quittek presented the requirements draft
"draft-ietf-ipfix-reqs-07.txt".

Regarding the requirement of reporting ICMP type and code it was
agreed by a hum that the requirements document will be updated
to say SHOULD rather than MUST.

No objections were raised regarding leaving the document as-is
with respect to these issues:

 - VPN-ID attribute
 - exporting NAT'ed flows
 - Ignore Port Copy
 - anonymization
 - MPLS label/FEC
 - enabling de-duplication of received records

Paul Calato reminded us about the outstanding issue of requiring the
export to identify which flow attributes were used to distinguish
the flows, i.e. which were part of the "flow key".  He will supply
clarifying text for the requirements document.

The issue of reliability was discussed.  Juergen proposed, and it was
agreed to by a hum, that the requirements document should specify
that the IPFIX protocol MAY have "aditional reliability" and that
it MUST be open to reliability extensions.  Tal Givoly will supply
clarifying text about this higher level of reliability, describing
it in an implementation independent way.

Reinaldo Penno presented the evaluation team's report.  None of the
protocols conform to the requirements as they stand today.  He suggest
that two more revisions of the advocacy drafts and evaluation report
would probably be required.

It was pointed out that IPDR shouldn't be marked as "'F'ailed" for
Pull Mode reporting, since it is a supported IPDR mode.  (The editor
is requested to correct this.)

Various participants expressed concern that the evaluation summary
(requirements compatibility matrix) did not indicate the importance
of the requirements or other distinguishing features of the candidate
protocols.

It was suggested that advocates must elaborate on how their protocol
will be extended, it is not sufficient for an unexplained "'E'xtension
Needed" status to appear in the evaluation matrix.  For example, an
advocate who proposes to use SCTP for transport or IPSEC for security
must explain which modes and/or options of these protocols will be
used to comply with the IPFIX requirements.  The evaluation team can
take into account the degree of difficulty to implement the extension.

Arguments were made for and against the current list of compatibility
status values, including proposals to discard the "'U'pcoming" status,
to further differentiate amongst the candidate protocols.  However,
no consensus was reached.

A member of the evaluation team commented that the team is to look at
protocols, not products, therefore installed base is not an important
feature, a well-defined protocol is what's important.  Evaluators
should decide if protocols can be implemented at reasonable cost.

Another member of the team said that the team should complete this
document and give it back to the advocates so that the advocates can
see how much effort they neec to expend to make their E's into T's.

Reinaldo agreed to submit the "-00" draft for commentary as soon
as possible.

To accelerate the evluation process, the chair encouraged the advocates
to critically evaluate each others protocols, and to interact with
the evaluation team members (in the public IPFIX mailing list).

Bert Wijnen, sitting in as our Area Director, reminded us that the
working group, not necessarily the advocate, will modify the protocol
as it sees fit once it has been selected as the IPFIX starting point.

Juergen Quittek, co-chair of the PSAMP working group, gave a short
presentation on possible synergies between PSAMP and IPFIX.

Nevil reviewed the milestones and the following updates were
suggested, to which there were no objections:

 - the evaluation draft version "-01" (or greater) will be submitted
   by late January, 2002.
 - the applicability document versions will be postponed until after
   the selection of one of the candidate protocols.
 - the starting-point IPFIX protocol will be selected in the March/April
   timeframe.

--
$Id: minutes.txt,v 1.2 2002/11/25 14:45:33 dplonka Exp $

--jRHKVT23PllUwdXP--

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