From majordomo@mil.doit.wisc.edu Tue Mar 4 09:01:50 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22002 for ; Tue, 4 Mar 2003 09:01:50 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18qCUl-0007GK-00 for ipfix-list@mil.doit.wisc.edu; Tue, 04 Mar 2003 07:30:11 -0600 Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18qCUi-0007GD-00 for ipfix-eval@net.doit.wisc.edu; Tue, 04 Mar 2003 07:30:09 -0600 Received: from cisco.com (bclaise-isdn-home3.cisco.com [10.49.4.220]) by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id h24DU6I01777 for ; Tue, 4 Mar 2003 14:30:06 +0100 (CET) Message-ID: <3E64AA5D.6020007@cisco.com> Date: Tue, 04 Mar 2003 14:30:05 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-eval@net.doit.wisc.edu Subject: [ipfix-eval] [Fwd: I-D ACTION:draft-claise-ipfix-eval-netflow-04.txt] Content-Type: multipart/alternative; boundary="------------090807030901010103060407" Precedence: bulk Sender: majordomo listserver --------------090807030901010103060407 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Dear all, A few comments on this draft, and the big differences with the previous version. 1. From the "summary of the first version of Evaluation Draft" presented by Reinaldo during the last meeting, I see for NetFlow Extension Required Sampling This has been corrected and it's now a Total Compliance 2. From the "summary of the first version of Evaluation Draft" presented by Reinaldo during the last meeting, I see for NetFlow Partial Compliance Time Synchronization This has been corrected and it's now a Total Compliance 3. The advocate were asked to described some more what would be done for upcoming compliance. We know have a distinct draft about SCTP, which is referenced in this draft. http://www.ietf.org/internet-drafts/draft-djernaes-netflow-9-transport-00.txt Anyway, I encourage you to read the entire draft. A lot of improvements were made to NetFlow/to the draft!. Regards, Benoit. -------- Original Message -------- Subject: I-D ACTION:draft-claise-ipfix-eval-netflow-04.txt Date: Tue, 04 Mar 2003 07:27:43 -0500 From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org To: IETF-Announce: ; CC: ipfix@net.doit.wisc.edu A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Evaluation Of NetFlow Version 9 Against IPFIX Requirements Author(s) : B. Claise Filename : draft-claise-ipfix-eval-netflow-04.txt Pages : 26 Date : 2003-3-3 This document provides an evaluation of the applicability of the NetFlow flow record export protocol version 9 as an IPFIX protocol. It compares the properties and capabilities of the NetFlow flow record export protocol version 9 to the IPFIX requirements [IPFIX- REQ]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-claise-ipfix-eval-netflow-04.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-claise-ipfix-eval-netflow-04.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-claise-ipfix-eval-netflow-04.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. --------------090807030901010103060407 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all,

A few comments on this draft, and the big differences with the previous version.

1. From the "summary of the first version of Evaluation Draft" presented by Reinaldo during the last meeting, I see for NetFlow
   Extension Required        Sampling
This has been corrected and it's now a Total Compliance

2. From the "summary of the first version of Evaluation Draft" presented by Reinaldo during the last meeting, I see for NetFlow
Partial Compliance     Time Synchronization
This has been corrected and it's now a Total Compliance

3. The advocate were asked to described some more what would be done for upcoming compliance.
We know have a distinct draft about SCTP, which is referenced in this draft.
http://www.ietf.org/internet-drafts/draft-djernaes-netflow-9-transport-00.txt
Anyway, I encourage you to read the entire draft. A lot of improvements were made to NetFlow/to the draft!.

Regards, Benoit.

-------- Original Message --------
Subject: I-D ACTION:draft-claise-ipfix-eval-netflow-04.txt
Date: Tue, 04 Mar 2003 07:27:43 -0500
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
To: IETF-Announce: ;
CC: ipfix@net.doit.wisc.edu 


A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Evaluation Of NetFlow Version 9 Against IPFIX 
                          Requirements
	Author(s)	: B. Claise
	Filename	: draft-claise-ipfix-eval-netflow-04.txt
	Pages		: 26
	Date		: 2003-3-3
	
This document provides an evaluation of the applicability of the 
NetFlow flow record export protocol version 9 as an IPFIX protocol. 
It compares the properties and capabilities of the NetFlow flow 
record export protocol version 9 to the IPFIX requirements [IPFIX-
REQ].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-claise-ipfix-eval-netflow-04.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-claise-ipfix-eval-netflow-04.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-claise-ipfix-eval-netflow-04.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.
--------------090807030901010103060407-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" 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 Mar 6 13:17:11 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04397 for ; Thu, 6 Mar 2003 13:17:11 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18qzZe-0007B9-00 for ipfix-list@mil.doit.wisc.edu; Thu, 06 Mar 2003 11:54:30 -0600 Received: from mailhost2.auckland.ac.nz ([130.216.1.4]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18qzZb-0007Ay-00 for ipfix@net.doit.wisc.edu; Thu, 06 Mar 2003 11:54:27 -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 GAA11397 for ; Fri, 7 Mar 2003 06:54:25 +1300 (NZDT) Received: from hotlava.auckland.ac.nz (hotlava.auckland.ac.nz [130.216.191.123]) by mailhost.auckland.ac.nz (Mirapoint Messaging Server MOS 3.3.2-CR) with ESMTP id ANM95556; Fri, 7 Mar 2003 06:54:24 +1300 (NZDT) Received: (from apache@localhost) by hotlava.auckland.ac.nz (8.11.6/8.11.6) id h26HsOt10502 for ipfix@net.doit.wisc.edu; Fri, 7 Mar 2003 06:54:24 +1300 X-Authentication-Warning: hotlava.auckland.ac.nz: apache set sender to n.brownlee@auckland.ac.nz using -f Received: from dyn54.caida.org (dyn54.caida.org [192.172.226.54]) by hotlava.auckland.ac.nz (Horde) with HTTP for ; Fri, 7 Mar 2003 06:54:24 +1300 Message-ID: <1046973264.31fab19fc2940@hotlava.auckland.ac.nz> Date: Fri, 7 Mar 2003 06:54:24 +1300 From: Nevil Brownlee To: ipfix@net.doit.wisc.edu Subject: [ipfix] Agenda for SFO meeting MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-Originating-IP: 192.172.226.54 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit IPFIX Agenda for San Francisco ------------------------------ Hello all: The IPFIX WG meeting is scheduled for Thursday 20 Mar 03, at 1530 (last session Thursday afternoon). minutes 5 1) Agenda Review 10 2) Requirements Draft (Submitted to IESG, in AD Evaluation state) Juergen Quittek, draft-ietf-ipfix-reqs-09.txt + Review of changes since Atlanta meeting 3) Evaluation process + Updates to Advocacy Drafts 10 Benoit Claise, draft-claise-ipfix-eval-netflow-04.txt 55 + Discussion: Which of the advocated protocols should we choose? We need to decide, so we can move forward with the Architecture and Data Model drafts 5 4) Review of WG Milestones 10 5) IPFIX-PSAMP relationship Benoit Claise, draft-quittek-psamp-ipfix-01.txt 15 5) Measurement and Monitoring draft Supratik Bhattacharyya, draft-ietf-monitoring-sprint-01.txt "Requirements for integrating monitoring with operations, and thorny issues such as the problem of data export." 5 6) 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 ----------------------------------------------------------------------- Nevil Brownlee Director, Technology Development Phone: +64 9 373 7599 x88941 ITSS, The University of Auckland FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand ------------------------------------------------- This mail sent through University of Auckland http://www.auckland.ac.nz/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Mar 10 21:42:45 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24691 for ; Mon, 10 Mar 2003 21:42:44 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18sZKc-0004La-00 for ipfix-list@mil.doit.wisc.edu; Mon, 10 Mar 2003 20:17:30 -0600 Received: from atlrel6.hp.com ([156.153.255.205]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18sZKa-0004LQ-00 for ipfix@net.doit.wisc.edu; Mon, 10 Mar 2003 20:17:28 -0600 Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel6.hp.com (Postfix) with ESMTP id 2BD971C018F4 for ; Mon, 10 Mar 2003 21:17:28 -0500 (EST) Received: from xatlbh1.atl.hp.com (xatlbh1.atl.hp.com [15.45.89.186]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id 1DCA21C00097 for ; Mon, 10 Mar 2003 21:17:28 -0500 (EST) Received: by xatlbh1.atl.hp.com with Internet Mail Service (5.5.2655.55) id ; Mon, 10 Mar 2003 21:17:27 -0500 Message-ID: <4341EF5F8B4AD311AB4B00902740B9F21471895D@xcup02.cup.hp.com> From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" To: "'ipfix@net.doit.wisc.edu'" Subject: [ipfix] Observations on Selection Process and Requirements Date: Mon, 10 Mar 2003 21:17:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk Sender: majordomo listserver Hi, As the advocate for Streaming IPDR, which represents the collected work of most vendors in the mediation and billing space, and as a member of HP's Software Business Unit, a leading provider of network management systems, I would like to reemphasize my belief that Streaming IPDR, or a version representing some compromise among the other IPFIX stakeholders, utilizing many of the concepts of IPDR, is the correct choice, for addressing such a protocol. Note, I have not seen an offer of compromise from other advocates at the mailing list level to date. I'm listening... The first paragraph of the IPFIX WG's charter states: "...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 one of the key goals for Feb. '03 is listed as: "Select IPFIX protocol, revise Architecture and Data Model drafts." After rereading the various submissions, the IPFIX requirements draft and other relevant RFC's, I'd like to share a few observations which should at the least produce some relevant conversation. I apologize for the length of this memo, but I'd encourage people to slog through it... 1. The IPFIX protocol operates as an accounting protocol. I notice that the current requirements draft does not cite the following important RFC's: RFC2975 - Introduction to Accounting Management RFC2924 - Accounting Attributes and Record Formats It should. My bad for coming in past "last call". They're still relevant even if not cited. If folks believe that IPFIX is defining something other than an accounting protocol, this should be a point of discussion. 2. The problem being dealt with is complex, and as such decomposing the problem, "divide and conquer" or "separation of concerns" plays an important role. I believe that the requirements draft does a good job of this in defining functional areas such as the "observation point", "metering process" "exporter" and "collector". However, to the extent that these areas can be discussed separately, they should be. Otherwise unnecessary complexity creeps in from the "tangling" of concerns which can be treated separately. I've noticed a lot of discussion around the behavior of the metering process, which is interesting, yet should be irrelevant to the selection of a protocol. 3. The use of UDP as a transport for flow information is widely used today. Despite the statement in section 6.3.1 of the IPFIX requirements document that the protocol MUST be congestion aware, it is likely that the "backpressure" associated with congestion aware protocols will put an unacceptable burden on SOME common observation points in SOME situations. This seems to be an item which has been avoided because of the IESG mandate on congestion aware protocols, however it seems quite relevant to this particular domain. Cisco has just recently provided a mapping of their proposed NFv9 to SCTP, but at the same time left the door open to use variants of SCTP which continue to allow them to "fire and forget". There is probably a meaningful technical issue here, which should not be ignored. I.e. although from a collector/reliablity perspective, TCP is much more desirable, especially given the relative immaturity and expense of SCTP implementations on general purpose platforms, there seems to be a desire to avoid TCP on the part of a major player in the flow observation equipment space. This should be explored! 4. The use of the flow information does not just stop at the collector. This information may be used by a variety of applications. As such some of the ideas put forth in RFC2924 are worth considering: (Nevil, as a coauthor of RFC2924, please feel free to speak up!) - Sec. 9.4.1 "Service Independence" - talks about the benefit of separation of concerns. And cites SNMP as a key example of having an independent "Service Definition Model". IPDR provides just that. And rather than using the cumbersome ASN.1 mechanism for this, IPDR uses XML Schema as the means to create independent service defintions. Given the availability of tools and reference material around XML, I see no compelling argument in favor of any other structured information model for DESCRIBING the content. PLEASE avoid the confusion that IPDR's use of XML for describing the service definition (or "Information Model") requires XML format for the actual transfer of flow information. IPDR defines a very compact, template-based, binary means of encoding. - Sec. 9.4.4 "Service Namespace Management" - this articulates the benefit of allowing independent vendor extension, some candidates have a very limited means of addressing this. IPDR uses XML Namespaces to allow for independent vendor extension, and puts all namespaces on equal footing. - Sec. 10 "Encodings" - describes the potential benefit of supporting multiple encodings. IPDR does just that. For high volume exchange a binary format is defined; for other applications, e.g. presentation or human editing, an XML format is defined. IPDR provides a lossless and unambiguous mapping between the two. - Sec. 9.1 "Record Format vs. Protocol" - describes the benefit of separating the encoding model from the transport. So that a variety of transports, including batch file oriented transports can be employed. IPDR does just this. 5. Terminology. The requirements draft talks of an Information Model, a Data Model and a Transport. The distinction between the words "Information" and "Data" is probably subject to debate. Rather than sticking with these terms, I'd recommend the IPDR terminology which is "Service Definition" and "Encoding". Or "Information Model" and "Encoding". In conclusion, the apparent 5 way tie between the various protocol candidates appears to be the result of the current framing of the requirements. The recent changes to the requirements seems unlikely to change the outcome of the current scoring model in any material way. The recent dialog around "reliability" on the mailing list, may in fact be more related to the ignored issue cited in observation #3 than anyone has explicitly acknowledged. It may imply that some compromise around the use of UDP may be in order. Note that there is also an extensive discussion of reliability in section 2.1 of RFC 2975. I would however point out that if some of the aspects from RFC's 2975 and 2924 were considered, and the requirements were either broken down around these terms, or scored on a 1-5 vs. 0-1 basis that breaking the tie would likely be easier. As someone who has had to architect and lead development of a system which accomodates the current "Tower of Babel" in the accounting space, I can certainly say that creating yet another narrow accounting format is NOT a good thing for the industry. This is why I've been very active in evolving IPDR over the past three and a half years. To define a clean, open and extensible separation between the Service Definition, encoding and transport. This allows for a single Service definition model to drive current and future encodings and transports. And IPFIX is an ideal candidate to take advantage of this. Regards, Jeff Meyer Chief Architect HP OpenView Internet Usage Manager IPDR Advocate http://www.hp.com/usage http://www.ipdr.org/documents/ipfix -- Help mailto:majordomo@net.doit.wisc.edu and say "help" 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 Mar 11 15:22:41 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10664 for ; Tue, 11 Mar 2003 15:22:40 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18sppz-00047e-00 for ipfix-list@mil.doit.wisc.edu; Tue, 11 Mar 2003 13:54:59 -0600 Received: from [130.216.191.4] (helo=mailhost2.auckland.ac.nz) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18sppw-00047V-00 for ipfix@net.doit.wisc.edu; Tue, 11 Mar 2003 13:54:57 -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 IAA07669; Wed, 12 Mar 2003 08:54:52 +1300 (NZDT) Received: from hotlava.auckland.ac.nz (hotlava.auckland.ac.nz [130.216.191.123]) by mailhost.auckland.ac.nz (Mirapoint Messaging Server MOS 3.3.2-CR) with ESMTP id ANQ74822; Wed, 12 Mar 2003 08:54:51 +1300 (NZDT) Received: (from apache@localhost) by hotlava.auckland.ac.nz (8.11.6/8.11.6) id h2BJso725143; Wed, 12 Mar 2003 08:54:50 +1300 X-Authentication-Warning: hotlava.auckland.ac.nz: apache set sender to n.brownlee@auckland.ac.nz using -f Received: from dyn54.caida.org (dyn54.caida.org [192.172.226.54]) by hotlava.auckland.ac.nz (Horde) with HTTP for ; Wed, 12 Mar 2003 08:54:50 +1300 Message-ID: <1047412490.2865344752cba@hotlava.auckland.ac.nz> Date: Wed, 12 Mar 2003 08:54:50 +1300 From: Nevil Brownlee To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" Cc: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Observations on Selection Process and Requirements References: <4341EF5F8B4AD311AB4B00902740B9F21471895D@xcup02.cup.hp.com> In-Reply-To: <4341EF5F8B4AD311AB4B00902740B9F21471895D@xcup02.cup.hp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-Originating-IP: 192.172.226.54 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hello Jeff: Some comments in response to your 'Observations on Selection Process ..' Your point 3, use of UDP transport. As Allison pointed out, the use of congestion-aware transport for new standards-track protocols is an IETF consensus, not an IESG mandate. Of course people who implement new applications may choose, for whatever reason, to use transport which is not congestion-aware. That's fine, but it won't conform to the standard. Or to put it another way, to be standards-compliant, a vendor has to give customers the ability to use congestion-aware transport. Having said that, this is a rathole which the WG spent a lot of time exploring in the first half of last year - we're not going to go there again. Now your other points: I agree that RFCs 2975 and 2924 are relevant. They came from the AAA WG, which was strongly focussed on Accounting. Their end product is DIAMETER, which is designed to be an all-inclusive protocol for all three A's. So if we want a one-true-faith Accounting protocol, we should all use DIAMETER. Alas, reality isn't like that. A lot of the complexity in DIAMETER comes from its need to handle Authentication and Authorisation across multiple provider realms, so Accounting is only a subset of DIAMETER. Again, there are lots of network operators (not to mention researchers) using LFAP, NetFlow, RTFM, etc. to gather flow data from routers and switches, who do it to gain understanding of how their network is behaving, and who probably have no interest in using that data to recover costs. IPFIX started in this context, with the notion of setting a single standard for exporting flow data from routers and switches. That's only part of making a 'universal accounting protocol,' but it would nonetheless be a very useful step forward. And one which, to me at least, seems achievable. Your remarks about the Data Model are interesting. In writing the 'attributes' part of RFC 2924 I was trying to make a list of all the attributes in use or defined at the time, and looking at extensible ways to encode them. Although it would be nice to have everyone use a single description/encoding method, I'd be happy to settle for two or three methods, with the user choosing the one which is most suitable for any particular situation. To sum up: although it would be nice to have IPFIX become the one method everyone uses for all accounting-related flow data export, that seems a distant goal right now. Since IP mediation vendors are coping now with the variety of flow export systems in use, concentrating on something which only handles export from routers and switches would be a fine goal for IPFIX. That way, AAA servers could become the logical clearing-house, taking flow data from routers and switches, and passing it - along with user identification, etc. - to IP mediation (i.e. billing) systems. See you in San Francisco! Cheers, Nevil ----------------------------------------------------------------------- Nevil Brownlee Director, Technology Development Phone: +64 9 373 7599 x88941 ITSS, The University of Auckland FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand ------------------------------------------------- This mail sent through University of Auckland http://www.auckland.ac.nz/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Mar 11 15:53:11 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11767 for ; Tue, 11 Mar 2003 15:53:10 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18sqS2-0004z3-00 for ipfix-list@mil.doit.wisc.edu; Tue, 11 Mar 2003 14:34:18 -0600 Received: from atlrel9.hp.com ([156.153.255.214]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18sqS0-0004yy-00 for ipfix@net.doit.wisc.edu; Tue, 11 Mar 2003 14:34:16 -0600 Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190]) by atlrel9.hp.com (Postfix) with ESMTP id 527491C01496; Tue, 11 Mar 2003 15:34:16 -0500 (EST) Received: from xatlbh2.atl.hp.com (xatlbh2.atl.hp.com [15.45.89.187]) by xatlrelay1.atl.hp.com (Postfix) with ESMTP id 014331C009D3; Tue, 11 Mar 2003 15:34:16 -0500 (EST) Received: by xatlbh2.atl.hp.com with Internet Mail Service (5.5.2655.55) id ; Tue, 11 Mar 2003 15:34:15 -0500 Message-ID: <4341EF5F8B4AD311AB4B00902740B9F21471896B@xcup02.cup.hp.com> From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" To: "'Nevil Brownlee'" , "MEYER,JEFFREY D (HP-Cupertino,ex1)" Cc: ipfix@net.doit.wisc.edu Subject: RE: [ipfix] Observations on Selection Process and Requirements Date: Tue, 11 Mar 2003 15:34:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk Sender: majordomo listserver Nevil, Thanks for your dual role comments. My mistake on the IESG/IETF "mandate"/"consensus", thanks for the correction. Regarding Diameter as the universal accounting protocol, I feel in general, as you point out, that when you mix in the "other 2 A's", what you end up with is something which is adequate for all, but certainly not optimized for the needs of "accounting only" device behavior. Specifically, an accounting only model implies to me an effectively unidirectional transfer of information from the exporter to the collector. Now if you want some reliability, you'll need some feedback from the application OR you'll want some non-volatile storage and a pull based model. Another observation regarding pure accounting is that there is likely a large amount of homogenous "records" being sent. A template based approach, vs. a TLV approach helps reduce the per record overhead on transfer. CRANE, NFv9 and IPDR all take a similar approach. In fact the encoding of the flow records themselves are pretty near identical. This "pure accounting" model is not unique to IP Flows, but also includes "Layer 7 probes", Application Servers, WAP Gateways and Gateway devices in the 3G space. Having had to develop the consumer end for all these protocols, I can say that I can see no good reason that all of these use different protocols, other than the lack of an established convention/standard protocol. I'm hoping that IPFIX can be done in such a way that does accomodate this broader industry need, which I have to deal with on a daily basis. And if we truly do separate the concerns around the lines defined in the requirements draft, I think it is highly acheivable, and will not unduly burden (or burden in any way) IPFIX's specific area of interest around IP Flows. Regards, Jeff Meyer > -----Original Message----- > From: Nevil Brownlee [mailto:n.brownlee@auckland.ac.nz] > Sent: Tuesday, March 11, 2003 11:55 AM > To: MEYER,JEFFREY D (HP-Cupertino,ex1) > Cc: ipfix@net.doit.wisc.edu > Subject: Re: [ipfix] Observations on Selection Process and > Requirements > > > > Hello Jeff: > > Some comments in response to your 'Observations on Selection > Process ..' > > > Your point 3, use of UDP transport. As Allison pointed out, the use > of congestion-aware transport for new standards-track protocols is an > IETF consensus, not an IESG mandate. > > Of course people who implement new applications may choose, for > whatever reason, to use transport which is not congestion-aware. > That's fine, but it won't conform to the standard. Or to put it > another way, to be standards-compliant, a vendor has to give customers > the ability to use congestion-aware transport. > > Having said that, this is a rathole which the WG spent a lot of time > exploring in the first half of last year - we're not going to > go there > again. > > > Now your other points: > > > > I agree that RFCs 2975 and 2924 are relevant. They came from the > AAA WG, which was strongly focussed on Accounting. Their end product > is DIAMETER, which is designed to be an all-inclusive protocol for > all three A's. So if we want a one-true-faith Accounting protocol, > we should all use DIAMETER. > > Alas, reality isn't like that. A lot of the complexity in DIAMETER > comes from its need to handle Authentication and Authorisation across > multiple provider realms, so Accounting is only a subset of DIAMETER. > > Again, there are lots of network operators (not to mention > researchers) > using LFAP, NetFlow, RTFM, etc. to gather flow data from routers and > switches, who do it to gain understanding of how their network is > behaving, and who probably have no interest in using that data to > recover costs. IPFIX started in this context, with the notion of > setting a single standard for exporting flow data from routers and > switches. That's only part of making a 'universal accounting > protocol,' > but it would nonetheless be a very useful step forward. And > one which, > to me at least, seems achievable. > > Your remarks about the Data Model are interesting. In writing the > 'attributes' part of RFC 2924 I was trying to make a list of all the > attributes in use or defined at the time, and looking at > extensible ways > to encode them. Although it would be nice to have everyone use a > single description/encoding method, I'd be happy to settle for two > or three methods, with the user choosing the one which is > most suitable > for any particular situation. > > To sum up: although it would be nice to have IPFIX become the one > method everyone uses for all accounting-related flow data export, > that seems a distant goal right now. > > Since IP mediation vendors are coping now with the variety of flow > export systems in use, concentrating on something which only handles > export from routers and switches would be a fine goal for IPFIX. > That way, AAA servers could become the logical clearing-house, taking > flow data from routers and switches, and passing it - along with > user identification, etc. - to IP mediation (i.e. billing) systems. > > > > See you in San Francisco! > > Cheers, Nevil > > -------------------------------------------------------------- > --------- > Nevil Brownlee Director, Technology Development > Phone: +64 9 373 7599 x88941 ITSS, The University of Auckland > FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand > > > ------------------------------------------------- > This mail sent through University of Auckland > http://www.auckland.ac.nz/ > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Mar 14 13:15:35 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04540 for ; Fri, 14 Mar 2003 13:15:35 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18ttRH-0003Na-00 for ipfix-list@mil.doit.wisc.edu; Fri, 14 Mar 2003 11:57:51 -0600 Received: from sj-core-5.cisco.com ([171.71.177.238]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18ttRG-0003NS-00 for ipfix@net.doit.wisc.edu; Fri, 14 Mar 2003 11:57:50 -0600 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2EHvlhs007972; Fri, 14 Mar 2003 09:57:47 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEO06631; Fri, 14 Mar 2003 09:57:45 -0800 (PST) Message-ID: <3E721819.4050401@cisco.com> Date: Fri, 14 Mar 2003 11:57:45 -0600 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "MEYER,JEFFREY D (HP-Cupertino,ex1)" CC: "'ipfix@net.doit.wisc.edu'" Subject: Re: [ipfix] Observations on Selection Process and Requirements References: <4341EF5F8B4AD311AB4B00902740B9F21471895D@xcup02.cup.hp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Jeff: A couple of quick comments to some of what you said :> MEYER,JEFFREY D (HP-Cupertino,ex1) wrote: > > 3. The use of UDP as a transport for flow information is widely used > today. Despite the statement in section 6.3.1 of the IPFIX requirements > document that the protocol MUST be congestion aware, it is likely that > the "backpressure" associated with congestion aware protocols will put > an unacceptable burden on SOME common observation points in SOME > situations. > > This seems to be an item which has been avoided because of the IESG > mandate on congestion aware protocols, however it seems quite relevant > to this particular domain. Cisco has just recently provided a mapping > of their proposed NFv9 to SCTP, but at the same time left the door open > to use variants of SCTP which continue to allow them to "fire > and forget". There is probably a meaningful technical issue here, > which should not be ignored. > > Yes there is a technical issue.. and I think the PR-SCTP draft removes the concern and thus is why NFv9 has a mapping to SCTP and specifically will use PR-SCTP's features... > I.e. although from a collector/reliablity perspective, TCP is much more > desirable, especially given the relative immaturity and expense of SCTP > I am a bit curious about these comments above... There have so far been 5 SCTP-bakeoffs (including connect-a-thon last year)... and all of these went well. There are a huge number of implementations if I remember some of the major ones (my aplogies if I miss any .. there are a lot more ...): 1) Linux has an implementation (it will be standard in 2.6 and is available now in 2.5) 2) IBM AIX had a killer version at the last bakeoff. 3) The BSD's have the version that I wrote and can be found in the KAME release. 4) HP has interop'd a version 5) Compac (now I guess HP :->) has shown up with a version 6) Sun has a version.. and a huge number of telco mfngr's (Nokia, Erricison and Seimens).. to name a few... and there were lots more as well from smaller companies... the big ones stick in my mind :-D the last bakeoff had close to 20 participants.. and every single implementation interop'd fine... So, since it is available free... and is in LOT of implementations I am not sure what you mean by the "expense" of SCTP? And as far as maturity goes.. well.. as of the last bakeoff the fact that every implementation was able to interop with every other one is to me a sign that it IS maturing quite nicely... As far as PR-SCTP.. I know from the BSD work it was an addtion of about 20-40 lines of code and I think the same is true for the IOS version of SCTP... So I am a bit baffeled by your statements... especially when PR-SCTP will allow an ipfix device to be able to send completely reliable and partially reliable data over the same congestion controlled association... a very desireable thing in my view.. R > implementations on general purpose platforms, there seems to be a desire > to avoid TCP on the part of a major player in the flow observation > equipment space. This should be explored! > > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) -- Help mailto:majordomo@net.doit.wisc.edu and say "help" 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 Mar 14 15:40:25 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13568 for ; Fri, 14 Mar 2003 15:40:24 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18tvtb-0007d2-00 for ipfix-list@mil.doit.wisc.edu; Fri, 14 Mar 2003 14:35:15 -0600 Received: from usmail.xacct.com ([204.253.100.12]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18tvtZ-0007cp-00 for ipfix@net.doit.wisc.edu; Fri, 14 Mar 2003 14:35:13 -0600 Received: from peterl (inside.us.xacct.com [204.253.100.102]) by usmail.xacct.com (8.11.2/8.11.2) with ESMTP id h2EKehi10871; Fri, 14 Mar 2003 12:40:48 -0800 From: "Peter Ludemann" To: "'Randall Stewart \(cisco\)'" Cc: Subject: RE: [ipfix] Observations on Selection Process and Requirements Date: Fri, 14 Mar 2003 12:34:55 -0800 Message-ID: <000b01c2ea69$31a52f50$7800000a@peterl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <3E721819.4050401@cisco.com> Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA13568 Randall Stewart wrote Friday, March 14, 2003 9:58 AM: > There have so far been 5 SCTP-bakeoffs (including connect-a-thon > last year)... and all of these went well. There are a huge > number of implementations if I remember some of > the major ones (my apologies if I miss any .. there are a lot more ...): The latest list of implementations (Oct 2002) seems to be: http://www.sctp.org/archive/0123.html and http://www.sctp.org/archive/0129.html ... Is there anything else? Are there any implementations of SCTP that I can use from Java without wrapping in JNI? (That is, the way I can use TCP and UDP without wrapping in JNI.) For Java, I could only find http://www.sctp.org/archive/0282.html , which recommended using JNI. - 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 Fri Mar 14 15:40:25 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13569 for ; Fri, 14 Mar 2003 15:40:24 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18tvsC-0007ac-00 for ipfix-list@mil.doit.wisc.edu; Fri, 14 Mar 2003 14:33:48 -0600 Received: from atlrel6.hp.com ([156.153.255.205]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18tvsA-0007aV-00 for ipfix@net.doit.wisc.edu; Fri, 14 Mar 2003 14:33:46 -0600 Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel6.hp.com (Postfix) with ESMTP id 50C171C013FC; Fri, 14 Mar 2003 15:33:46 -0500 (EST) Received: from xatlbh3.atl.hp.com (xatlbh3.atl.hp.com [15.45.89.188]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id 2F19F1C00A76; Fri, 14 Mar 2003 15:33:46 -0500 (EST) Received: by xatlbh3.atl.hp.com with Internet Mail Service (5.5.2655.55) id ; Fri, 14 Mar 2003 15:33:45 -0500 Message-ID: <4341EF5F8B4AD311AB4B00902740B9F2147189AF@xcup02.cup.hp.com> From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" To: "'Randall Stewart (cisco) '" , "MEYER,JEFFREY D (HP-Cupertino,ex1)" Cc: "''ipfix@net.doit.wisc.edu' '" Subject: RE: [ipfix] Observations on Selection Process and Requirements Date: Fri, 14 Mar 2003 15:33:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk Sender: majordomo listserver Randall, Thanks for bringing up the SCTP. My point about expense/immaturity of SCTP is that if I pick any random machine that I want to plunk down collection software on, odds are it will NOT have SCTP. Since SCTP is an OS level service, adding support to this is something that some people may think twice about, vs. adding a piece of software. I didn't see Microsoft listed here. Given the number of likely desktops which might want to collect, it would be nice to have. Go to Microsoft's website and search for SCTP. There is ONE link. And this hit is simply because they have a copy of the IP protocol table (SCTP is #132). So, that's what I meant. I'm sure you could get access to it, but it ain't seamless today, like TCP. So, I'd be much happier with a solution which only relied on user space changes vs. kernel changes. Regards, Jeff Meyer -----Original Message----- From: Randall Stewart (cisco) To: MEYER,JEFFREY D (HP-Cupertino,ex1) Cc: 'ipfix@net.doit.wisc.edu' Sent: 3/14/03 9:57 AM Subject: Re: [ipfix] Observations on Selection Process and Requirements Jeff: A couple of quick comments to some of what you said :> MEYER,JEFFREY D (HP-Cupertino,ex1) wrote: > > 3. The use of UDP as a transport for flow information is widely used > today. Despite the statement in section 6.3.1 of the IPFIX requirements > document that the protocol MUST be congestion aware, it is likely that > the "backpressure" associated with congestion aware protocols will put > an unacceptable burden on SOME common observation points in SOME > situations. > > This seems to be an item which has been avoided because of the IESG > mandate on congestion aware protocols, however it seems quite relevant > to this particular domain. Cisco has just recently provided a mapping > of their proposed NFv9 to SCTP, but at the same time left the door open > to use variants of SCTP which continue to allow them to "fire > and forget". There is probably a meaningful technical issue here, > which should not be ignored. > > Yes there is a technical issue.. and I think the PR-SCTP draft removes the concern and thus is why NFv9 has a mapping to SCTP and specifically will use PR-SCTP's features... > I.e. although from a collector/reliablity perspective, TCP is much more > desirable, especially given the relative immaturity and expense of SCTP > I am a bit curious about these comments above... There have so far been 5 SCTP-bakeoffs (including connect-a-thon last year)... and all of these went well. There are a huge number of implementations if I remember some of the major ones (my aplogies if I miss any .. there are a lot more ...): 1) Linux has an implementation (it will be standard in 2.6 and is available now in 2.5) 2) IBM AIX had a killer version at the last bakeoff. 3) The BSD's have the version that I wrote and can be found in the KAME release. 4) HP has interop'd a version 5) Compac (now I guess HP :->) has shown up with a version 6) Sun has a version.. and a huge number of telco mfngr's (Nokia, Erricison and Seimens).. to name a few... and there were lots more as well from smaller companies... the big ones stick in my mind :-D the last bakeoff had close to 20 participants.. and every single implementation interop'd fine... So, since it is available free... and is in LOT of implementations I am not sure what you mean by the "expense" of SCTP? And as far as maturity goes.. well.. as of the last bakeoff the fact that every implementation was able to interop with every other one is to me a sign that it IS maturing quite nicely... As far as PR-SCTP.. I know from the BSD work it was an addtion of about 20-40 lines of code and I think the same is true for the IOS version of SCTP... So I am a bit baffeled by your statements... especially when PR-SCTP will allow an ipfix device to be able to send completely reliable and partially reliable data over the same congestion controlled association... a very desireable thing in my view.. R > implementations on general purpose platforms, there seems to be a desire > to avoid TCP on the part of a major player in the flow observation > equipment space. This should be explored! > > > > -- Randall R. Stewart ITD Cisco Systems Inc. rrs@cisco.com 815-342-5222(cell) or 815-477-2127(office) -- Help mailto:majordomo@net.doit.wisc.edu and say "help" 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 Mar 14 15:47:18 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13849 for ; Fri, 14 Mar 2003 15:47:18 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18tw1c-00003d-00 for ipfix-list@mil.doit.wisc.edu; Fri, 14 Mar 2003 14:43:32 -0600 Received: from atlrel8.hp.com ([156.153.255.206]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18tw1a-00003V-00 for ipfix@net.doit.wisc.edu; Fri, 14 Mar 2003 14:43:30 -0600 Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel8.hp.com (Postfix) with ESMTP id 46AAD1C00CC8; Fri, 14 Mar 2003 15:43:30 -0500 (EST) Received: from xatlbh3.atl.hp.com (xatlbh3.atl.hp.com [15.45.89.188]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id 313CD1C000B9; Fri, 14 Mar 2003 15:43:30 -0500 (EST) Received: by xatlbh3.atl.hp.com with Internet Mail Service (5.5.2655.55) id ; Fri, 14 Mar 2003 15:43:29 -0500 Message-ID: <4341EF5F8B4AD311AB4B00902740B9F2147189B0@xcup02.cup.hp.com> From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" To: "'Peter Ludemann '" , "''Randall Stewart (cisco)' '" Cc: "'ipfix@net.doit.wisc.edu '" Subject: RE: [ipfix] Observations on Selection Process and Requirements Date: Fri, 14 Mar 2003 15:43:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk Sender: majordomo listserver Thanks Peter I failed to mention the lack of Java. Combine this with the lack of free (any?) support on Windows, and I'd have to say, this doesn't sound very compelling in the near term. -- Jeff -----Original Message----- From: Peter Ludemann To: 'Randall Stewart (cisco)' Cc: ipfix@net.doit.wisc.edu Sent: 3/14/03 12:34 PM Subject: RE: [ipfix] Observations on Selection Process and Requirements Randall Stewart wrote Friday, March 14, 2003 9:58 AM: > There have so far been 5 SCTP-bakeoffs (including connect-a-thon > last year)... and all of these went well. There are a huge > number of implementations if I remember some of > the major ones (my apologies if I miss any .. there are a lot more ...): The latest list of implementations (Oct 2002) seems to be: http://www.sctp.org/archive/0123.html and http://www.sctp.org/archive/0129.html ... Is there anything else? Are there any implementations of SCTP that I can use from Java without wrapping in JNI? (That is, the way I can use TCP and UDP without wrapping in JNI.) For Java, I could only find http://www.sctp.org/archive/0282.html , which recommended using JNI. - 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 Mar 19 11:58:15 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25813 for ; Wed, 19 Mar 2003 11:58:13 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18vgWu-0005oh-00 for ipfix-list@mil.doit.wisc.edu; Wed, 19 Mar 2003 10:35:04 -0600 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18vgWs-0005oa-00 for ipfix-req@net.doit.wisc.edu; Wed, 19 Mar 2003 10:35:02 -0600 Received: from fokus.fraunhofer.de (wl-130-209.wireless.ietf56.ietf.org [130.129.130.209]) by mailhub.fokus.fraunhofer.de (8.11.6/8.11.6) with ESMTP id h2JGYuF14056; Wed, 19 Mar 2003 17:34:57 +0100 (MET) Message-ID: <3E789C2F.9020609@fokus.fraunhofer.de> Date: Wed, 19 Mar 2003 17:34:55 +0100 From: Tanja Zseby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: de-de, de, en-us MIME-Version: 1.0 To: Mark Thibodeau CC: ipfix-req@net.doit.wisc.edu Subject: Re: [ipfix-req] Content Based Sampling References: <3E5B9DF0.33FB8BAA@alcatel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Mark, content-based sampling refers to packet selection functions that take the packet content into account. So actually it is some form of filtering. It can also be hash-based sampling where the intention is to achieve some pseudo random selection. Maybe you can have a look at the psamp packet selection draft draft-ietf-psamp-sample-tech-01.txt. There we made a first attempt to categorize the schemes. Combined schemes (as you explained) are explicitely allowed. In my opinion you would need to export both, the filter rule and the sampling scheme. Regards, Tanja Mark Thibodeau wrote: >Hi, > >I have some questions about the requirements for sampling. From >requirements 8: > >.... >5.2. Sampling > >... > selection of one packet can for instance be triggered by its arrival > time (time-based sampling), by its position in the flow (count-based > sampling) or by the packet content (content-based sampling). >.... > >What is meant by "content-based sampling"? Is this basically ACL >filtering that tells you whether or not to monitor a flow? > >If it refers to ACL filtering, then I have some more questions. > >.... >6.1. Information Model >.... > > 14. if sampling is used: sampling configuration >.... > >If we are using content-based sampling, what information do we want >exported with the flow? Is it basically an ACL rule identifier? Or do >we want to export the entire ACL rule itself? > >If we need to export a rule identifier or something like that, then >there is another situation which presents itself. > >Let's say there are multiple rules which can cause packets to be >monitored. If we are also doing aggregation, there is the potential for >2 or more ACL rules to all point to the same flow record. When this >flow record is exported, which rule identifier should it give? > >There is also another situation. An implementation could support >simultaneously ACL filtering and packet sampling. For instance, only >the flows that match a certain ACL rule will be monitored. However, >only every 100th packet is sampled. If this combination is supported, >what is the sampling configuration that is exported? Should we export >the rule identifier as well as the sampling rate? > >Thanks, >Mark > >-- > >**************************************************** >* Mark Thibodeau, P Eng. >* 670 RSP Development - Firmware Designer >* Alcatel CID - (613) 784-5375 >* Fax - (613) 599-3696 >* mark.thibodeau@alcatel.com >**************************************************** > > > >-- >Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body >Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >"unsubscribe ipfix" in message body >Archive http://ipfix.doit.wisc.edu/archive/ > > -- Dipl.-Ing. Tanja Zseby Fraunhofer Institute FOKUS Email: zseby@fokus.fraunhofer.de Kaiserin-Augusta-Allee 31 Phone: +49-30-3463-7153 D-10589 Berlin, Germany Fax: +49-30-3463-8153 -------------------------------------------------------------------------------------- "Living on earth is expensive but it includes a free trip around the sun." (Anonymous) -------------------------------------------------------------------------------------- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" 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 Mar 19 22:49:47 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22799 for ; Wed, 19 Mar 2003 22:49:47 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18vqlx-0000IH-00 for ipfix-list@mil.doit.wisc.edu; Wed, 19 Mar 2003 21:31:17 -0600 Received: from eng4.oar.net ([192.148.244.24]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 18vqlw-0000IC-00 for ipfix-req@net.doit.wisc.edu; Wed, 19 Mar 2003 21:31:16 -0600 Received: (qmail 8523 invoked by uid 4454); 20 Mar 2003 03:31:15 -0000 Date: Wed, 19 Mar 2003 22:31:15 -0500 From: Mark Fullmer To: Tanja Zseby Cc: Mark Thibodeau , ipfix-req@net.doit.wisc.edu Subject: Re: [ipfix-req] Content Based Sampling Message-ID: <20030319223115.A8515@net.ohio-state.edu> References: <3E5B9DF0.33FB8BAA@alcatel.com> <3E789C2F.9020609@fokus.fraunhofer.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <3E789C2F.9020609@fokus.fraunhofer.de>; from zseby@fokus.fraunhofer.de on Wed, Mar 19, 2003 at 05:34:55PM +0100 Precedence: bulk Sender: majordomo listserver I really doubt this group is going to come up with a definition for "ACL" that will get group consensus, let alone encoding it in a packet. A reasonable alternative, IMHO is to have named templates (ie "tcp-port-flows", where the name is user selectable on the exporter. mark On Wed, Mar 19, 2003 at 05:34:55PM +0100, Tanja Zseby wrote: > Hi Mark, > > content-based sampling refers to packet selection functions that take > the packet content into account. So actually it is some form of > filtering. It can also be hash-based sampling where the intention is to > achieve some pseudo random selection. > Maybe you can have a look at the psamp packet selection draft > draft-ietf-psamp-sample-tech-01.txt. There we made a first attempt to > categorize the schemes. Combined schemes (as you explained) are > explicitely allowed. > In my opinion you would need to export both, the filter rule and the > sampling scheme. > > Regards, > Tanja > > > Mark Thibodeau wrote: > > >Hi, > > > >I have some questions about the requirements for sampling. From > >requirements 8: > > > >.... > >5.2. Sampling > > > >... > > selection of one packet can for instance be triggered by its arrival > > time (time-based sampling), by its position in the flow (count-based > > sampling) or by the packet content (content-based sampling). > >.... > > > >What is meant by "content-based sampling"? Is this basically ACL > >filtering that tells you whether or not to monitor a flow? > > > >If it refers to ACL filtering, then I have some more questions. > > > >.... > >6.1. Information Model > >.... > > > > 14. if sampling is used: sampling configuration > >.... > > > >If we are using content-based sampling, what information do we want > >exported with the flow? Is it basically an ACL rule identifier? Or do > >we want to export the entire ACL rule itself? > > > >If we need to export a rule identifier or something like that, then > >there is another situation which presents itself. > > > >Let's say there are multiple rules which can cause packets to be > >monitored. If we are also doing aggregation, there is the potential for > >2 or more ACL rules to all point to the same flow record. When this > >flow record is exported, which rule identifier should it give? > > > >There is also another situation. An implementation could support > >simultaneously ACL filtering and packet sampling. For instance, only > >the flows that match a certain ACL rule will be monitored. However, > >only every 100th packet is sampled. If this combination is supported, > >what is the sampling configuration that is exported? Should we export > >the rule identifier as well as the sampling rate? > > > >Thanks, > >Mark > > > >-- > > > >**************************************************** > >* Mark Thibodeau, P Eng. > >* 670 RSP Development - Firmware Designer > >* Alcatel CID - (613) 784-5375 > >* Fax - (613) 599-3696 > >* mark.thibodeau@alcatel.com > >**************************************************** > > > > > > > >-- > >Help mailto:majordomo@net.doit.wisc.edu and say "help" in > message body > >Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > >"unsubscribe ipfix" in message body > >Archive http://ipfix.doit.wisc.edu/archive/ > > > > > > -- > Dipl.-Ing. Tanja Zseby > Fraunhofer Institute FOKUS Email: zseby@fokus.fraunhofer.de > Kaiserin-Augusta-Allee 31 Phone: +49-30-3463-7153 > D-10589 Berlin, Germany Fax: +49-30-3463-8153 > -------------------------------------------------------------------------------------- > > "Living on earth is expensive but it includes a free trip around the > sun." (Anonymous) > -------------------------------------------------------------------------------------- > > > > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" 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 Mar 20 09:32:22 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18588 for ; Thu, 20 Mar 2003 09:32:21 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18w0mS-0006f8-00 for ipfix-list@mil.doit.wisc.edu; Thu, 20 Mar 2003 08:12:28 -0600 Received: from [209.202.115.138] (helo=kanmx1.ca.alcatel.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 18w0mQ-0006f2-00 for ipfix-req@net.doit.wisc.edu; Thu, 20 Mar 2003 08:12:26 -0600 Received: (qmail 6253 invoked from network); 20 Mar 2003 14:20:22 -0000 Received: from unknown (HELO alcatel.com) (138.120.51.110) by kanmx1.ca.alcatel.com with SMTP; 20 Mar 2003 14:20:22 -0000 Message-ID: <3E79CC3E.C3DF158A@alcatel.com> Date: Thu, 20 Mar 2003 09:12:14 -0500 From: Mark Thibodeau X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Fullmer CC: Tanja Zseby , ipfix-req@net.doit.wisc.edu Subject: Re: [ipfix-req] Content Based Sampling References: <3E5B9DF0.33FB8BAA@alcatel.com> <3E789C2F.9020609@fokus.fraunhofer.de> <20030319223115.A8515@net.ohio-state.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Mark, Are you referring to Cisco-style templates? In Cisco's v9 format, there is the capability for up to 64k templates. However, on a line card there may be many more ACL rules (or filters). It may not be possible to have a one-to-one mapping between ACL rule and Netflow template. Or, did you have some other scheme in mind? If communicating the filter rule is required, I agree with Tanja. Some how the rule will need to be encoded in the exported packet. It could be that we just send a Rule ID. But, I'm not sure how the collector will be able to retrieve the ACL rule by using the exported RuleID. Now I'm wondering......why does the collector need to know which filter rule was used? What application will it use this information for? If a user wants to know if an ACL filter is being hit, they can normally look at the ACL statistics on the node. I don't see any benefit of communicating this information to the collector. Do you? Thanks, Mark Mark Fullmer wrote: > I really doubt this group is going to come up with a definition for > "ACL" that will get group consensus, let alone encoding it in a > packet. > > A reasonable alternative, IMHO is to have named templates (ie > "tcp-port-flows", where the name is user selectable on the > exporter. > > mark > > On Wed, Mar 19, 2003 at 05:34:55PM +0100, Tanja Zseby wrote: > > Hi Mark, > > > > content-based sampling refers to packet selection functions that take > > the packet content into account. So actually it is some form of > > filtering. It can also be hash-based sampling where the intention is to > > achieve some pseudo random selection. > > Maybe you can have a look at the psamp packet selection draft > > draft-ietf-psamp-sample-tech-01.txt. There we made a first attempt to > > categorize the schemes. Combined schemes (as you explained) are > > explicitely allowed. > > In my opinion you would need to export both, the filter rule and the > > sampling scheme. > > > > Regards, > > Tanja > > > > > > Mark Thibodeau wrote: > > > > >Hi, > > > > > >I have some questions about the requirements for sampling. From > > >requirements 8: > > > > > >.... > > >5.2. Sampling > > > > > >... > > > selection of one packet can for instance be triggered by its arrival > > > time (time-based sampling), by its position in the flow (count-based > > > sampling) or by the packet content (content-based sampling). > > >.... > > > > > >What is meant by "content-based sampling"? Is this basically ACL > > >filtering that tells you whether or not to monitor a flow? > > > > > >If it refers to ACL filtering, then I have some more questions. > > > > > >.... > > >6.1. Information Model > > >.... > > > > > > 14. if sampling is used: sampling configuration > > >.... > > > > > >If we are using content-based sampling, what information do we want > > >exported with the flow? Is it basically an ACL rule identifier? Or do > > >we want to export the entire ACL rule itself? > > > > > >If we need to export a rule identifier or something like that, then > > >there is another situation which presents itself. > > > > > >Let's say there are multiple rules which can cause packets to be > > >monitored. If we are also doing aggregation, there is the potential for > > >2 or more ACL rules to all point to the same flow record. When this > > >flow record is exported, which rule identifier should it give? > > > > > >There is also another situation. An implementation could support > > >simultaneously ACL filtering and packet sampling. For instance, only > > >the flows that match a certain ACL rule will be monitored. However, > > >only every 100th packet is sampled. If this combination is supported, > > >what is the sampling configuration that is exported? Should we export > > >the rule identifier as well as the sampling rate? > > > > > >Thanks, > > >Mark > > > > > >-- > > > > > >**************************************************** > > >* Mark Thibodeau, P Eng. > > >* 670 RSP Development - Firmware Designer > > >* Alcatel CID - (613) 784-5375 > > >* Fax - (613) 599-3696 > > >* mark.thibodeau@alcatel.com > > >**************************************************** > > > > > > > > > > > >-- > > >Help mailto:majordomo@net.doit.wisc.edu and say "help" in > > message body > > >Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > >"unsubscribe ipfix" in message body > > >Archive http://ipfix.doit.wisc.edu/archive/ > > > > > > > > > > -- > > Dipl.-Ing. Tanja Zseby > > Fraunhofer Institute FOKUS Email: zseby@fokus.fraunhofer.de > > Kaiserin-Augusta-Allee 31 Phone: +49-30-3463-7153 > > D-10589 Berlin, Germany Fax: +49-30-3463-8153 > > -------------------------------------------------------------------------------------- > > > > "Living on earth is expensive but it includes a free trip around the > > sun." (Anonymous) > > -------------------------------------------------------------------------------------- > > > > > > > > > > > > -- > > Help mailto:majordomo@net.doit.wisc.edu and say "help" 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/ -- **************************************************** * Mark Thibodeau, P Eng. * 670 RSP Development - Firmware Designer * Alcatel CID - (613) 784-5375 * Fax - (613) 599-3696 * mark.thibodeau@alcatel.com **************************************************** -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Mar 20 19:51:47 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16096 for ; Thu, 20 Mar 2003 19:51:46 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18wAUo-0004SZ-00 for ipfix-list@mil.doit.wisc.edu; Thu, 20 Mar 2003 18:34:54 -0600 Received: from [12.25.1.120] (helo=ctron-dnm.enterasys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 18wAUm-0004SU-00 for ipfix@net.doit.wisc.edu; Thu, 20 Mar 2003 18:34:53 -0600 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id TAA08439 for ; Thu, 20 Mar 2003 19:47:52 -0500 (EST) Received: from unknown(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma008403; Thu, 20 Mar 03 19:47:19 -0500 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.122]) by NHROCAVG2.ets.enterasys.com with InterScan Messaging Security Suite for SMTP; Thu, 20 Mar 2003 19:34:57 -0500 Received: from nhrocmbx1.enterasys.com ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 20 Mar 2003 19:34:56 -0500 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="US-ASCII" Subject: RE: [ipfix] Agenda for SFO meeting Date: Thu, 20 Mar 2003 19:34:56 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA88BF6B@NHROCMBX1.ets.enterasys.com> Thread-Topic: [ipfix] Agenda for SFO meeting Thread-Index: AcLkC13EmQwSjhTLRF6RUSE0XaaUOwLNiF8A From: "Harrington, David" To: "Nevil Brownlee" , X-OriginalArrivalTime: 21 Mar 2003 00:34:57.0097 (UTC) FILETIME=[B2C51B90:01C2EF41] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA16096 Hi, I believe that the proposed approach forward is a good one. Dbh Co-chair snmpv3 WG --- David Harrington Network Management Architect dbh@enterasys.com Office of the CTO +1 603 337 2614 - voice Enterasys Networks +1 603 332 1524 - fax Rochester NH, USA -- Help mailto:majordomo@net.doit.wisc.edu and say "help" 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 Mar 21 13:26:16 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21632 for ; Fri, 21 Mar 2003 13:26:16 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18wQwf-00043P-00 for ipfix-list@mil.doit.wisc.edu; Fri, 21 Mar 2003 12:08:45 -0600 Received: from eng4.oar.net ([192.148.244.24]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 18wQwd-00043G-00 for ipfix-req@net.doit.wisc.edu; Fri, 21 Mar 2003 12:08:43 -0600 Received: (qmail 15968 invoked by uid 4454); 21 Mar 2003 18:08:42 -0000 Date: Fri, 21 Mar 2003 13:08:42 -0500 From: Mark Fullmer To: Mark Thibodeau Cc: Tanja Zseby , ipfix-req@net.doit.wisc.edu Subject: Re: [ipfix-req] Content Based Sampling Message-ID: <20030321130842.A15893@net.ohio-state.edu> References: <3E5B9DF0.33FB8BAA@alcatel.com> <3E789C2F.9020609@fokus.fraunhofer.de> <20030319223115.A8515@net.ohio-state.edu> <3E79CC3E.C3DF158A@alcatel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <3E79CC3E.C3DF158A@alcatel.com>; from mark.thibodeau@alcatel.com on Thu, Mar 20, 2003 at 09:12:14AM -0500 Precedence: bulk Sender: majordomo listserver Yes. The template ID's have no meaning though, ie you can't tie a template ID back to a configuration on the exporter, where the configuration might include ACL's, sampling, or other attributes. All that's required is having a template id or name. Then some other method (SNMP, etc) can be used to query the exporter for the other attributes, for example the filter/access-list applied to the metering process used by the template. Exporting other attributes such as access lists, or even ifNames that are available in other ways (ie SNMP) is not a road we should go down. mark On Thu, Mar 20, 2003 at 09:12:14AM -0500, Mark Thibodeau wrote: > Hi Mark, > > Are you referring to Cisco-style templates? In Cisco's v9 format, there is the capability > for up to 64k templates. However, on a line card there may be many more ACL rules (or > filters). It may not be possible to have a one-to-one mapping between ACL rule and Netflow > template. Or, did you have some other scheme in mind? > > If communicating the filter rule is required, I agree with Tanja. Some how the rule will > need to be encoded in the exported packet. It could be that we just send a Rule ID. But, > I'm not sure how the collector will be able to retrieve the ACL rule by using the exported > RuleID. > > Now I'm wondering......why does the collector need to know which filter rule was used? What > application will it use this information for? If a user wants to know if an ACL filter is > being hit, they can normally look at the ACL statistics on the node. I don't see any > benefit of communicating this information to the collector. Do you? > > Thanks, > Mark > > > Mark Fullmer wrote: > > > I really doubt this group is going to come up with a definition for > > "ACL" that will get group consensus, let alone encoding it in a > > packet. > > > > A reasonable alternative, IMHO is to have named templates (ie > > "tcp-port-flows", where the name is user selectable on the > > exporter. > > > > mark > > > > On Wed, Mar 19, 2003 at 05:34:55PM +0100, Tanja Zseby wrote: > > > Hi Mark, > > > > > > content-based sampling refers to packet selection functions that take > > > the packet content into account. So actually it is some form of > > > filtering. It can also be hash-based sampling where the intention is to > > > achieve some pseudo random selection. > > > Maybe you can have a look at the psamp packet selection draft > > > draft-ietf-psamp-sample-tech-01.txt. There we made a first attempt to > > > categorize the schemes. Combined schemes (as you explained) are > > > explicitely allowed. > > > In my opinion you would need to export both, the filter rule and the > > > sampling scheme. > > > > > > Regards, > > > Tanja > > > > > > > > > Mark Thibodeau wrote: > > > > > > >Hi, > > > > > > > >I have some questions about the requirements for sampling. From > > > >requirements 8: > > > > > > > >.... > > > >5.2. Sampling > > > > > > > >... > > > > selection of one packet can for instance be triggered by its arrival > > > > time (time-based sampling), by its position in the flow (count-based > > > > sampling) or by the packet content (content-based sampling). > > > >.... > > > > > > > >What is meant by "content-based sampling"? Is this basically ACL > > > >filtering that tells you whether or not to monitor a flow? > > > > > > > >If it refers to ACL filtering, then I have some more questions. > > > > > > > >.... > > > >6.1. Information Model > > > >.... > > > > > > > > 14. if sampling is used: sampling configuration > > > >.... > > > > > > > >If we are using content-based sampling, what information do we want > > > >exported with the flow? Is it basically an ACL rule identifier? Or do > > > >we want to export the entire ACL rule itself? > > > > > > > >If we need to export a rule identifier or something like that, then > > > >there is another situation which presents itself. > > > > > > > >Let's say there are multiple rules which can cause packets to be > > > >monitored. If we are also doing aggregation, there is the potential for > > > >2 or more ACL rules to all point to the same flow record. When this > > > >flow record is exported, which rule identifier should it give? > > > > > > > >There is also another situation. An implementation could support > > > >simultaneously ACL filtering and packet sampling. For instance, only > > > >the flows that match a certain ACL rule will be monitored. However, > > > >only every 100th packet is sampled. If this combination is supported, > > > >what is the sampling configuration that is exported? Should we export > > > >the rule identifier as well as the sampling rate? > > > > > > > >Thanks, > > > >Mark > > > > > > > >-- > > > > > > > >**************************************************** > > > >* Mark Thibodeau, P Eng. > > > >* 670 RSP Development - Firmware Designer > > > >* Alcatel CID - (613) 784-5375 > > > >* Fax - (613) 599-3696 > > > >* mark.thibodeau@alcatel.com > > > >**************************************************** > > > > > > > > > > > > > > > >-- > > > >Help mailto:majordomo@net.doit.wisc.edu and say "help" in > > > message body > > > >Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > > >"unsubscribe ipfix" in message body > > > >Archive http://ipfix.doit.wisc.edu/archive/ > > > > > > > > > > > > > > -- > > > Dipl.-Ing. Tanja Zseby > > > Fraunhofer Institute FOKUS Email: zseby@fokus.fraunhofer.de > > > Kaiserin-Augusta-Allee 31 Phone: +49-30-3463-7153 > > > D-10589 Berlin, Germany Fax: +49-30-3463-8153 > > > -------------------------------------------------------------------------------------- > > > > > > "Living on earth is expensive but it includes a free trip around the > > > sun." (Anonymous) > > > -------------------------------------------------------------------------------------- > > > > > > > > > > > > > > > > > > -- > > > Help mailto:majordomo@net.doit.wisc.edu and say "help" 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/ > > -- > > **************************************************** > * Mark Thibodeau, P Eng. > * 670 RSP Development - Firmware Designer > * Alcatel CID - (613) 784-5375 > * Fax - (613) 599-3696 > * mark.thibodeau@alcatel.com > **************************************************** > > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" 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 Mar 21 13:29:48 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21798 for ; Fri, 21 Mar 2003 13:29:48 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18wR2M-0004BT-00 for ipfix-list@mil.doit.wisc.edu; Fri, 21 Mar 2003 12:14:38 -0600 Received: from kanfw1.ottawa.alcatel.ca ([192.75.23.69] helo=kanmx2.ca.alcatel.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 18wR2K-0004BM-00 for ipfix-req@net.doit.wisc.edu; Fri, 21 Mar 2003 12:14:36 -0600 Received: (qmail 19745 invoked from network); 21 Mar 2003 18:16:47 -0000 Received: from unknown (HELO alcatel.com) (138.120.51.110) by kanmx2.ca.alcatel.com with SMTP; 21 Mar 2003 18:16:47 -0000 Message-ID: <3E7B567D.78504723@alcatel.com> Date: Fri, 21 Mar 2003 13:14:21 -0500 From: Mark Thibodeau X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Fullmer CC: Tanja Zseby , ipfix-req@net.doit.wisc.edu Subject: Re: [ipfix-req] Content Based Sampling References: <3E5B9DF0.33FB8BAA@alcatel.com> <3E789C2F.9020609@fokus.fraunhofer.de> <20030319223115.A8515@net.ohio-state.edu> <3E79CC3E.C3DF158A@alcatel.com> <20030321130842.A15893@net.ohio-state.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Are you aware of any router or probe that is currently doing something like this? Thanks, Mark Mark Fullmer wrote: > Yes. The template ID's have no meaning though, ie you can't tie a template > ID back to a configuration on the exporter, where the configuration might > include ACL's, sampling, or other attributes. > > All that's required is having a template id or name. Then some other > method (SNMP, etc) can be used to query the exporter for the other > attributes, for example the filter/access-list applied to the metering > process used by the template. > > Exporting other attributes such as access lists, or even ifNames that are > available in other ways (ie SNMP) is not a road we should go down. > > mark > > On Thu, Mar 20, 2003 at 09:12:14AM -0500, Mark Thibodeau wrote: > > Hi Mark, > > > > Are you referring to Cisco-style templates? In Cisco's v9 format, there is the capability > > for up to 64k templates. However, on a line card there may be many more ACL rules (or > > filters). It may not be possible to have a one-to-one mapping between ACL rule and Netflow > > template. Or, did you have some other scheme in mind? > > > > If communicating the filter rule is required, I agree with Tanja. Some how the rule will > > need to be encoded in the exported packet. It could be that we just send a Rule ID. But, > > I'm not sure how the collector will be able to retrieve the ACL rule by using the exported > > RuleID. > > > > Now I'm wondering......why does the collector need to know which filter rule was used? What > > application will it use this information for? If a user wants to know if an ACL filter is > > being hit, they can normally look at the ACL statistics on the node. I don't see any > > benefit of communicating this information to the collector. Do you? > > > > Thanks, > > Mark > > > > > > Mark Fullmer wrote: > > > > > I really doubt this group is going to come up with a definition for > > > "ACL" that will get group consensus, let alone encoding it in a > > > packet. > > > > > > A reasonable alternative, IMHO is to have named templates (ie > > > "tcp-port-flows", where the name is user selectable on the > > > exporter. > > > > > > mark > > > > > > On Wed, Mar 19, 2003 at 05:34:55PM +0100, Tanja Zseby wrote: > > > > Hi Mark, > > > > > > > > content-based sampling refers to packet selection functions that take > > > > the packet content into account. So actually it is some form of > > > > filtering. It can also be hash-based sampling where the intention is to > > > > achieve some pseudo random selection. > > > > Maybe you can have a look at the psamp packet selection draft > > > > draft-ietf-psamp-sample-tech-01.txt. There we made a first attempt to > > > > categorize the schemes. Combined schemes (as you explained) are > > > > explicitely allowed. > > > > In my opinion you would need to export both, the filter rule and the > > > > sampling scheme. > > > > > > > > Regards, > > > > Tanja > > > > > > > > > > > > Mark Thibodeau wrote: > > > > > > > > >Hi, > > > > > > > > > >I have some questions about the requirements for sampling. From > > > > >requirements 8: > > > > > > > > > >.... > > > > >5.2. Sampling > > > > > > > > > >... > > > > > selection of one packet can for instance be triggered by its arrival > > > > > time (time-based sampling), by its position in the flow (count-based > > > > > sampling) or by the packet content (content-based sampling). > > > > >.... > > > > > > > > > >What is meant by "content-based sampling"? Is this basically ACL > > > > >filtering that tells you whether or not to monitor a flow? > > > > > > > > > >If it refers to ACL filtering, then I have some more questions. > > > > > > > > > >.... > > > > >6.1. Information Model > > > > >.... > > > > > > > > > > 14. if sampling is used: sampling configuration > > > > >.... > > > > > > > > > >If we are using content-based sampling, what information do we want > > > > >exported with the flow? Is it basically an ACL rule identifier? Or do > > > > >we want to export the entire ACL rule itself? > > > > > > > > > >If we need to export a rule identifier or something like that, then > > > > >there is another situation which presents itself. > > > > > > > > > >Let's say there are multiple rules which can cause packets to be > > > > >monitored. If we are also doing aggregation, there is the potential for > > > > >2 or more ACL rules to all point to the same flow record. When this > > > > >flow record is exported, which rule identifier should it give? > > > > > > > > > >There is also another situation. An implementation could support > > > > >simultaneously ACL filtering and packet sampling. For instance, only > > > > >the flows that match a certain ACL rule will be monitored. However, > > > > >only every 100th packet is sampled. If this combination is supported, > > > > >what is the sampling configuration that is exported? Should we export > > > > >the rule identifier as well as the sampling rate? > > > > > > > > > >Thanks, > > > > >Mark > > > > > > > > > >-- > > > > > > > > > >**************************************************** > > > > >* Mark Thibodeau, P Eng. > > > > >* 670 RSP Development - Firmware Designer > > > > >* Alcatel CID - (613) 784-5375 > > > > >* Fax - (613) 599-3696 > > > > >* mark.thibodeau@alcatel.com > > > > >**************************************************** > > > > > > > > > > > > > > > > > > > >-- > > > > >Help mailto:majordomo@net.doit.wisc.edu and say "help" in > > > > message body > > > > >Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > > > >"unsubscribe ipfix" in message body > > > > >Archive http://ipfix.doit.wisc.edu/archive/ > > > > > > > > > > > > > > > > > > -- > > > > Dipl.-Ing. Tanja Zseby > > > > Fraunhofer Institute FOKUS Email: zseby@fokus.fraunhofer.de > > > > Kaiserin-Augusta-Allee 31 Phone: +49-30-3463-7153 > > > > D-10589 Berlin, Germany Fax: +49-30-3463-8153 > > > > -------------------------------------------------------------------------------------- > > > > > > > > "Living on earth is expensive but it includes a free trip around the > > > > sun." (Anonymous) > > > > -------------------------------------------------------------------------------------- > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Help mailto:majordomo@net.doit.wisc.edu and say "help" 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/ > > > > -- > > > > **************************************************** > > * Mark Thibodeau, P Eng. > > * 670 RSP Development - Firmware Designer > > * Alcatel CID - (613) 784-5375 > > * Fax - (613) 599-3696 > > * mark.thibodeau@alcatel.com > > **************************************************** > > > > > > > > -- > > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > "unsubscribe ipfix" in message body > > Archive http://ipfix.doit.wisc.edu/archive/ -- **************************************************** * Mark Thibodeau, P Eng. * 670 RSP Development - Firmware Designer * Alcatel CID - (613) 784-5375 * Fax - (613) 599-3696 * mark.thibodeau@alcatel.com **************************************************** -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Mar 21 13:56:52 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22536 for ; Fri, 21 Mar 2003 13:56:51 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18wRSl-0004lx-00 for ipfix-list@mil.doit.wisc.edu; Fri, 21 Mar 2003 12:41:55 -0600 Received: from eng4.oar.net ([192.148.244.24]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 18wRSi-0004kK-00 for ipfix-req@net.doit.wisc.edu; Fri, 21 Mar 2003 12:41:52 -0600 Received: (qmail 16134 invoked by uid 4454); 21 Mar 2003 18:40:57 -0000 Date: Fri, 21 Mar 2003 13:40:57 -0500 From: Mark Fullmer To: Mark Thibodeau Cc: Tanja Zseby , ipfix-req@net.doit.wisc.edu Subject: Re: [ipfix-req] Content Based Sampling Message-ID: <20030321134057.A16110@net.ohio-state.edu> References: <3E5B9DF0.33FB8BAA@alcatel.com> <3E789C2F.9020609@fokus.fraunhofer.de> <20030319223115.A8515@net.ohio-state.edu> <3E79CC3E.C3DF158A@alcatel.com> <20030321130842.A15893@net.ohio-state.edu> <3E7B567D.78504723@alcatel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <3E7B567D.78504723@alcatel.com>; from mark.thibodeau@alcatel.com on Fri, Mar 21, 2003 at 01:14:21PM -0500 Precedence: bulk Sender: majordomo listserver NetFlow v9 is available from Cisco. It's common practice to use SNMP with NetFlow to query "other" information, for example to get the ifName or ifAlias for an input/output interface. Another example is to use BGP to get community and AS path information. mark On Fri, Mar 21, 2003 at 01:14:21PM -0500, Mark Thibodeau wrote: > Are you aware of any router or probe that is currently doing something like this? > > Thanks, > Mark > > Mark Fullmer wrote: > > > Yes. The template ID's have no meaning though, ie you can't tie a template > > ID back to a configuration on the exporter, where the configuration might > > include ACL's, sampling, or other attributes. > > > > All that's required is having a template id or name. Then some other > > method (SNMP, etc) can be used to query the exporter for the other > > attributes, for example the filter/access-list applied to the metering > > process used by the template. > > > > Exporting other attributes such as access lists, or even ifNames that are > > available in other ways (ie SNMP) is not a road we should go down. > > > > mark > > > > On Thu, Mar 20, 2003 at 09:12:14AM -0500, Mark Thibodeau wrote: > > > Hi Mark, > > > > > > Are you referring to Cisco-style templates? In Cisco's v9 format, there is the capability > > > for up to 64k templates. However, on a line card there may be many more ACL rules (or > > > filters). It may not be possible to have a one-to-one mapping between ACL rule and Netflow > > > template. Or, did you have some other scheme in mind? > > > > > > If communicating the filter rule is required, I agree with Tanja. Some how the rule will > > > need to be encoded in the exported packet. It could be that we just send a Rule ID. But, > > > I'm not sure how the collector will be able to retrieve the ACL rule by using the exported > > > RuleID. > > > > > > Now I'm wondering......why does the collector need to know which filter rule was used? What > > > application will it use this information for? If a user wants to know if an ACL filter is > > > being hit, they can normally look at the ACL statistics on the node. I don't see any > > > benefit of communicating this information to the collector. Do you? > > > > > > Thanks, > > > Mark > > > > > > > > > Mark Fullmer wrote: > > > > > > > I really doubt this group is going to come up with a definition for > > > > "ACL" that will get group consensus, let alone encoding it in a > > > > packet. > > > > > > > > A reasonable alternative, IMHO is to have named templates (ie > > > > "tcp-port-flows", where the name is user selectable on the > > > > exporter. > > > > > > > > mark > > > > > > > > On Wed, Mar 19, 2003 at 05:34:55PM +0100, Tanja Zseby wrote: > > > > > Hi Mark, > > > > > > > > > > content-based sampling refers to packet selection functions that take > > > > > the packet content into account. So actually it is some form of > > > > > filtering. It can also be hash-based sampling where the intention is to > > > > > achieve some pseudo random selection. > > > > > Maybe you can have a look at the psamp packet selection draft > > > > > draft-ietf-psamp-sample-tech-01.txt. There we made a first attempt to > > > > > categorize the schemes. Combined schemes (as you explained) are > > > > > explicitely allowed. > > > > > In my opinion you would need to export both, the filter rule and the > > > > > sampling scheme. > > > > > > > > > > Regards, > > > > > Tanja > > > > > > > > > > > > > > > Mark Thibodeau wrote: > > > > > > > > > > >Hi, > > > > > > > > > > > >I have some questions about the requirements for sampling. From > > > > > >requirements 8: > > > > > > > > > > > >.... > > > > > >5.2. Sampling > > > > > > > > > > > >... > > > > > > selection of one packet can for instance be triggered by its arrival > > > > > > time (time-based sampling), by its position in the flow (count-based > > > > > > sampling) or by the packet content (content-based sampling). > > > > > >.... > > > > > > > > > > > >What is meant by "content-based sampling"? Is this basically ACL > > > > > >filtering that tells you whether or not to monitor a flow? > > > > > > > > > > > >If it refers to ACL filtering, then I have some more questions. > > > > > > > > > > > >.... > > > > > >6.1. Information Model > > > > > >.... > > > > > > > > > > > > 14. if sampling is used: sampling configuration > > > > > >.... > > > > > > > > > > > >If we are using content-based sampling, what information do we want > > > > > >exported with the flow? Is it basically an ACL rule identifier? Or do > > > > > >we want to export the entire ACL rule itself? > > > > > > > > > > > >If we need to export a rule identifier or something like that, then > > > > > >there is another situation which presents itself. > > > > > > > > > > > >Let's say there are multiple rules which can cause packets to be > > > > > >monitored. If we are also doing aggregation, there is the potential for > > > > > >2 or more ACL rules to all point to the same flow record. When this > > > > > >flow record is exported, which rule identifier should it give? > > > > > > > > > > > >There is also another situation. An implementation could support > > > > > >simultaneously ACL filtering and packet sampling. For instance, only > > > > > >the flows that match a certain ACL rule will be monitored. However, > > > > > >only every 100th packet is sampled. If this combination is supported, > > > > > >what is the sampling configuration that is exported? Should we export > > > > > >the rule identifier as well as the sampling rate? > > > > > > > > > > > >Thanks, > > > > > >Mark > > > > > > > > > > > >-- > > > > > > > > > > > >**************************************************** > > > > > >* Mark Thibodeau, P Eng. > > > > > >* 670 RSP Development - Firmware Designer > > > > > >* Alcatel CID - (613) 784-5375 > > > > > >* Fax - (613) 599-3696 > > > > > >* mark.thibodeau@alcatel.com > > > > > >**************************************************** > > > > > > > > > > > > > > > > > > > > > > > >-- > > > > > >Help mailto:majordomo@net.doit.wisc.edu and say "help" in > > > > > message body > > > > > >Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > > > > >"unsubscribe ipfix" in message body > > > > > >Archive http://ipfix.doit.wisc.edu/archive/ > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Dipl.-Ing. Tanja Zseby > > > > > Fraunhofer Institute FOKUS Email: zseby@fokus.fraunhofer.de > > > > > Kaiserin-Augusta-Allee 31 Phone: +49-30-3463-7153 > > > > > D-10589 Berlin, Germany Fax: +49-30-3463-8153 > > > > > -------------------------------------------------------------------------------------- > > > > > > > > > > "Living on earth is expensive but it includes a free trip around the > > > > > sun." (Anonymous) > > > > > -------------------------------------------------------------------------------------- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Help mailto:majordomo@net.doit.wisc.edu and say "help" 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/ > > > > > > -- > > > > > > **************************************************** > > > * Mark Thibodeau, P Eng. > > > * 670 RSP Development - Firmware Designer > > > * Alcatel CID - (613) 784-5375 > > > * Fax - (613) 599-3696 > > > * mark.thibodeau@alcatel.com > > > **************************************************** > > > > > > > > > > > > -- > > > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > > "unsubscribe ipfix" in message body > > > Archive http://ipfix.doit.wisc.edu/archive/ > > -- > > **************************************************** > * Mark Thibodeau, P Eng. > * 670 RSP Development - Firmware Designer > * Alcatel CID - (613) 784-5375 > * Fax - (613) 599-3696 > * mark.thibodeau@alcatel.com > **************************************************** > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Mar 24 09:16:37 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19383 for ; Mon, 24 Mar 2003 09:16:37 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18xSGv-0001Ou-00 for ipfix-list@mil.doit.wisc.edu; Mon, 24 Mar 2003 07:45:53 -0600 Received: from kanfw1.ottawa.alcatel.ca ([192.75.23.69] helo=kanmx2.ca.alcatel.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 18xSGt-0001On-00 for ipfix-req@net.doit.wisc.edu; Mon, 24 Mar 2003 07:45:52 -0600 Received: (qmail 19033 invoked from network); 24 Mar 2003 13:48:05 -0000 Received: from unknown (HELO alcatel.com) (138.120.51.110) by kanmx2.ca.alcatel.com with SMTP; 24 Mar 2003 13:48:05 -0000 Message-ID: <3E7F0BFF.84124CDB@alcatel.com> Date: Mon, 24 Mar 2003 08:45:35 -0500 From: Mark Thibodeau X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Fullmer CC: Tanja Zseby , ipfix-req@net.doit.wisc.edu Subject: Re: [ipfix-req] Content Based Sampling References: <3E5B9DF0.33FB8BAA@alcatel.com> <3E789C2F.9020609@fokus.fraunhofer.de> <20030319223115.A8515@net.ohio-state.edu> <3E79CC3E.C3DF158A@alcatel.com> <20030321130842.A15893@net.ohio-state.edu> <3E7B567D.78504723@alcatel.com> <20030321134057.A16110@net.ohio-state.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Sorry...I think I've gotten lost in this email thread. Here is the scenario I'm thinking about: Before the metering function, flows are subjected to ACL rules (or filters). The result of the ACL lookup is an action (permit/deny) and possibly a Netflow templateID. If the action is permit, the flow is added to the flow cache. The templateID is used to determine what information to store about the flow. Many ACL rules can use the same Netflow templateID. When a flow is exported, the Netflow templateID must be indicated. AND....maybe some information about the particular ACL rule that was hit should also be indicated. The templateID can be indicated by providing a template id or name as you've described below. However, how do we provide information about the ACL rule? Are you aware of any routers that currently exported information about the ACL rule that was hit? I don't believe Cisco Netflow9 provides this information. Thanks, Mark Mark Fullmer wrote: > NetFlow v9 is available from Cisco. > > It's common practice to use SNMP with NetFlow to query "other" > information, for example to get the ifName or ifAlias for an > input/output interface. Another example is to use BGP to get > community and AS path information. > > mark > > On Fri, Mar 21, 2003 at 01:14:21PM -0500, Mark Thibodeau wrote: > > Are you aware of any router or probe that is currently doing something like this? > > > > Thanks, > > Mark > > > > Mark Fullmer wrote: > > > > > Yes. The template ID's have no meaning though, ie you can't tie a template > > > ID back to a configuration on the exporter, where the configuration might > > > include ACL's, sampling, or other attributes. > > > > > > All that's required is having a template id or name. Then some other > > > method (SNMP, etc) can be used to query the exporter for the other > > > attributes, for example the filter/access-list applied to the metering > > > process used by the template. > > > > > > Exporting other attributes such as access lists, or even ifNames that are > > > available in other ways (ie SNMP) is not a road we should go down. > > > > > > mark > > > > > > On Thu, Mar 20, 2003 at 09:12:14AM -0500, Mark Thibodeau wrote: > > > > Hi Mark, > > > > > > > > Are you referring to Cisco-style templates? In Cisco's v9 format, there is the capability > > > > for up to 64k templates. However, on a line card there may be many more ACL rules (or > > > > filters). It may not be possible to have a one-to-one mapping between ACL rule and Netflow > > > > template. Or, did you have some other scheme in mind? > > > > > > > > If communicating the filter rule is required, I agree with Tanja. Some how the rule will > > > > need to be encoded in the exported packet. It could be that we just send a Rule ID. But, > > > > I'm not sure how the collector will be able to retrieve the ACL rule by using the exported > > > > RuleID. > > > > > > > > Now I'm wondering......why does the collector need to know which filter rule was used? What > > > > application will it use this information for? If a user wants to know if an ACL filter is > > > > being hit, they can normally look at the ACL statistics on the node. I don't see any > > > > benefit of communicating this information to the collector. Do you? > > > > > > > > Thanks, > > > > Mark > > > > > > > > > > > > Mark Fullmer wrote: > > > > > > > > > I really doubt this group is going to come up with a definition for > > > > > "ACL" that will get group consensus, let alone encoding it in a > > > > > packet. > > > > > > > > > > A reasonable alternative, IMHO is to have named templates (ie > > > > > "tcp-port-flows", where the name is user selectable on the > > > > > exporter. > > > > > > > > > > mark > > > > > > > > > > On Wed, Mar 19, 2003 at 05:34:55PM +0100, Tanja Zseby wrote: > > > > > > Hi Mark, > > > > > > > > > > > > content-based sampling refers to packet selection functions that take > > > > > > the packet content into account. So actually it is some form of > > > > > > filtering. It can also be hash-based sampling where the intention is to > > > > > > achieve some pseudo random selection. > > > > > > Maybe you can have a look at the psamp packet selection draft > > > > > > draft-ietf-psamp-sample-tech-01.txt. There we made a first attempt to > > > > > > categorize the schemes. Combined schemes (as you explained) are > > > > > > explicitely allowed. > > > > > > In my opinion you would need to export both, the filter rule and the > > > > > > sampling scheme. > > > > > > > > > > > > Regards, > > > > > > Tanja > > > > > > > > > > > > > > > > > > Mark Thibodeau wrote: > > > > > > > > > > > > >Hi, > > > > > > > > > > > > > >I have some questions about the requirements for sampling. From > > > > > > >requirements 8: > > > > > > > > > > > > > >.... > > > > > > >5.2. Sampling > > > > > > > > > > > > > >... > > > > > > > selection of one packet can for instance be triggered by its arrival > > > > > > > time (time-based sampling), by its position in the flow (count-based > > > > > > > sampling) or by the packet content (content-based sampling). > > > > > > >.... > > > > > > > > > > > > > >What is meant by "content-based sampling"? Is this basically ACL > > > > > > >filtering that tells you whether or not to monitor a flow? > > > > > > > > > > > > > >If it refers to ACL filtering, then I have some more questions. > > > > > > > > > > > > > >.... > > > > > > >6.1. Information Model > > > > > > >.... > > > > > > > > > > > > > > 14. if sampling is used: sampling configuration > > > > > > >.... > > > > > > > > > > > > > >If we are using content-based sampling, what information do we want > > > > > > >exported with the flow? Is it basically an ACL rule identifier? Or do > > > > > > >we want to export the entire ACL rule itself? > > > > > > > > > > > > > >If we need to export a rule identifier or something like that, then > > > > > > >there is another situation which presents itself. > > > > > > > > > > > > > >Let's say there are multiple rules which can cause packets to be > > > > > > >monitored. If we are also doing aggregation, there is the potential for > > > > > > >2 or more ACL rules to all point to the same flow record. When this > > > > > > >flow record is exported, which rule identifier should it give? > > > > > > > > > > > > > >There is also another situation. An implementation could support > > > > > > >simultaneously ACL filtering and packet sampling. For instance, only > > > > > > >the flows that match a certain ACL rule will be monitored. However, > > > > > > >only every 100th packet is sampled. If this combination is supported, > > > > > > >what is the sampling configuration that is exported? Should we export > > > > > > >the rule identifier as well as the sampling rate? > > > > > > > > > > > > > >Thanks, > > > > > > >Mark > > > > > > > > > > > > > >-- > > > > > > > > > > > > > >**************************************************** > > > > > > >* Mark Thibodeau, P Eng. > > > > > > >* 670 RSP Development - Firmware Designer > > > > > > >* Alcatel CID - (613) 784-5375 > > > > > > >* Fax - (613) 599-3696 > > > > > > >* mark.thibodeau@alcatel.com > > > > > > >**************************************************** > > > > > > > > > > > > > > > > > > > > > > > > > > > >-- > > > > > > >Help mailto:majordomo@net.doit.wisc.edu and say "help" in > > > > > > message body > > > > > > >Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > > > > > >"unsubscribe ipfix" in message body > > > > > > >Archive http://ipfix.doit.wisc.edu/archive/ > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Dipl.-Ing. Tanja Zseby > > > > > > Fraunhofer Institute FOKUS Email: zseby@fokus.fraunhofer.de > > > > > > Kaiserin-Augusta-Allee 31 Phone: +49-30-3463-7153 > > > > > > D-10589 Berlin, Germany Fax: +49-30-3463-8153 > > > > > > -------------------------------------------------------------------------------------- > > > > > > > > > > > > "Living on earth is expensive but it includes a free trip around the > > > > > > sun." (Anonymous) > > > > > > -------------------------------------------------------------------------------------- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Help mailto:majordomo@net.doit.wisc.edu and say "help" 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/ > > > > > > > > -- > > > > > > > > **************************************************** > > > > * Mark Thibodeau, P Eng. > > > > * 670 RSP Development - Firmware Designer > > > > * Alcatel CID - (613) 784-5375 > > > > * Fax - (613) 599-3696 > > > > * mark.thibodeau@alcatel.com > > > > **************************************************** > > > > > > > > > > > > > > > > -- > > > > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > > > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > > > "unsubscribe ipfix" in message body > > > > Archive http://ipfix.doit.wisc.edu/archive/ > > > > -- > > > > **************************************************** > > * Mark Thibodeau, P Eng. > > * 670 RSP Development - Firmware Designer > > * Alcatel CID - (613) 784-5375 > > * Fax - (613) 599-3696 > > * mark.thibodeau@alcatel.com > > **************************************************** > > -- **************************************************** * Mark Thibodeau, P Eng. * 670 RSP Development - Firmware Designer * Alcatel CID - (613) 784-5375 * Fax - (613) 599-3696 * mark.thibodeau@alcatel.com **************************************************** -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Mar 25 20:12:30 2003 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13542 for ; Tue, 25 Mar 2003 20:12:29 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18xz9z-0000uq-00 for ipfix-list@mil.doit.wisc.edu; Tue, 25 Mar 2003 18:52:55 -0600 Received: from dplonka by mil.doit.wisc.edu with local (Exim 3.13 #1) id 18xz9x-0000uk-00 for ipfix@net.doit.wisc.edu; Tue, 25 Mar 2003 18:52:53 -0600 Date: Tue, 25 Mar 2003 18:52:53 -0600 From: Dave Plonka To: ipfix@net.doit.wisc.edu Subject: [ipfix] DRAFT IPFIX meeting minutes, IETF56 Message-ID: <20030325185253.A2704@doit.wisc.edu> Reply-To: plonka@doit.wisc.edu Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="wRRV7LY7NUeQGEoC" X-Mailer: Mutt 1.0.1i X-Organization: University of Wisconsin-Madison, DoIT Network Services X-Organization-Too: Wisconsin Advanced Internet Laboratory (WAIL) X-VMS-Error: %SYSTEM-E-IVSECFLG, invalid process or global section flags X-Shakespearean-Insult: Thou lumpish full-gorged miscreant Precedence: bulk Sender: majordomo listserver --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii IPFIXers, Please review the attached DRAFT minutes of the IPFIX meeting last week at IET56 in San Francisco. Please send any follow-up comments/suggestions/ corrections to the list. The minutes can also be found here: http://ipfix.doit.wisc.edu/IETF56/minutes.txt Thanks, Dave P.S. The slide shows (and also the draft minutes) are available at: http://ipfix.doit.wisc.edu/IETF56/ -- plonka@doit.wisc.edu http://net.doit.wisc.edu/~plonka ARS:N9HZF Madison, WI --wRRV7LY7NUeQGEoC Content-Type: text/plain Content-Disposition: attachment; filename="minutes.txt" DRAFT Minutes of the IP Flow Information eXport (IPFIX) WG IETF 56, San Francisco, Thursday March 20, 2003 approx. 60-80 people in attendance Reported by Dave Plonka & Nevil Brownlee (co-chairs) based on notes from scribes Greg Ruth and George Michaelson. The meeting agenda and slides are available here: http://ipfix.doit.wisc.edu/IETF56/ [please see the agenda slides there for the sequence of topics below.] -- Juergen Quittek presented the requirements draft "draft-ietf-ipfix-reqs-09.txt" and differences from -07 to -09. This draft has passed Working Group last call and has been submitted to IESG for publication as an Informational RFC. [see slides for details of changes] -- Benoit Claise presented updates to the NetFlow v9-related drafts for the protocol evaluation process. [see slides for details] -- The chairs presented the evaluation process report on behalf of the evaluation team. The results, as presented, were reviewed and approved by four of the evaluation team members (three in person, one by email). The fifth member was not present and did not respond to email. So, this report conveyed the [rough] consensus amongst the evaluation team. The evaluation team has recommended NetFlow v9 as a basis for the IPFIX protocol, the primary rationale being that: * Quantification through a candidate protocol compatibility matrix produced no significant new information since the IETF 55 meeting. * The IPFIX charter directs us to specify an IPFIX system amenable to router and instrumentation implementers and to deployment - i.e. the solution must be feasible. Furthermore, once the WG has consensus for NetFlow v9 (via mailing list) the team suggests that the following be addressed: * Sub-second timestamps * Flow-loss statistics * Clarify that the exporter ID isn't necessarily the transport source address * Openness to reliability extensions * Fail-over must be (re)considered (how reserpool may apply - see their applicability draft) * Then, specify the initial IPFIX transport be TCP The rationale for specifying TCP as the transport is to enable rapid development and deployment of IPFIX. TCP is a ubiquitous standard; DCCP and PR-SCTP are not yet standards. However, the IPFIX protocol must not rely on TCP's reliable delivery; instead it must remain compatible with unreliable protocols. Much discussion followed regarding both the selection process, about half of which was initiated by the three advocates of the CRANE, IPDR, and LFAP protocols. Below are some Questions/Comments (Q:) to which the chairs responded (A:): Q: It was not clear what the evaluation process was, or whether or not it was followed. LFAP appeared to be leading in the compatibility matrix [presented at the previous meeting]. A: (chair) As to the evaluation process, the [matrix-based] scoring revealed no clear winner. So the scoring system simply didn't resolve which protocol to use. Therefore, [the evaluation team] asked themselves what we really want the protocol to do and tried to work with that. We don't believe this is a sudden change of direction. Q: There are two main categories of candidate protocols: "general data movers" and [special-purpose] protocols. This is like comparing apples and oranges. A: (chair) Rhetorical: does the charter favor an apple or an orange? The evaluation process did not change; the evaluation team made the decision. There has been silence in the mailing list from the candidate protocol advocates for months. Q: Protocols change dramatically during the course of being prepared by a working group, on their way to IETF standard. This is what the IETF and working group process is for. [presumably meaning, get on with it. The group will change the selected protocol as necessary/appropriate. Applause from audience in response to this comment.] Q: The CRANE and IPDR folks are working on a new unified/merged proposal [which may be a better candidate]. A: (chair) We've not heard of this effort before, and this is not the prescribed way to introduce a candidate protocol into the evaluation process. If [notification] didn't happen in the [IPFIX] mailing list, then [the chairs and IETF must presume] that it didn't happen [at all]. Q: Why TCP as initial transport? Q: There are about 30 SCTP implementations out there now. Couldn't we start with SCTP? A: TCP and SCTP are the only choices right now. TCP is the obvious choice - more widely available on both operating system platforms and in language APIs. Q: NetFlow doesn't support TCP; was the goal really just to select NetFlow? Is the ability to put the protocol on different devices a (heretofore) unstated requirement? Is the intent to provide an impetus to "fix" NetFlow? A: (Area Director) The notion of "fixing" NetFlow is originally what the IESG thought [IPFIX] was going to do. However, [standardizing NetFlow] wasn't the WG's chartered goal, it was just a reasonable expectation. There was no hidden agenda. A: (chairs) Now is the time to propose "improvements" to the NetFlow proposal [as it becomes the IPFIX protocol]. [More general disagreement with the selection was expressed by the advocates for the protocols that were not selected.] Q: Is there a willingness to modify NetFlow to incorporate good features from the other candidate protocols? A: (chairs) Yes, we will change it as the IPFIX protocol, but integration of features should be limited to only those necessary to meet the IPFIX requirements. [chairs addendum for minutes: It's not necessarily relevant to our IPFIX effort whether or not Cisco's NetFlow version `n' incorporates these features/fixes. Our proposed NetFlow v9-based protocol will be a product of the IPFIX WG.] -- The chairs moved on to propose a process for going forward from the evaluation team's selection. It was proposed that Simon Leinen's evaluation ID be a starting point for the evaluation team's report. More text will be integrated stating the rationale for this decision prior to its submission to become an information RFC. Furthermore, it was proposed that a new IPFIX protocol draft be prepared by the WG, drawing details (but not content directly) from the NetFlow v9 draft. This new IPFIX protocol draft is ultimately intended to become a standards-track RFC. Also, the chairs noted that we'll need a (new) editor for the protocol ID. Interested volunteers should contact the chairs [via email to ]. -- The chairs reviewed a slightly modified document road-map, including: * IPFIX Architecture * IPFIX Data Model * IPFIX Protocol * IPFIX Applicability Q: Will we add vendor specific features [/flow-attributes]? NetFlow is template based with a flat namespace for the attribute identifiers. A: (chair) An IANA-managed flat namespace may be an advantage in terms of simplicity. (chair not an expert on NetFlow v9 proposal, so defers to others regarding TLV aspects of the protocol.) A: (others) Paraphrase: Yes, the NetFlow proposal is deficient in this respect. IPFIX needs to address the TLV issue so that a NetFlow-based IPFIX protocol would be more extensible w.r.t. new attributes. Q: Is this the time [now, in the meeting] to discuss the list of stuff that IPFIX must support? I question full the compliance of NetFlow for IPFIX features. A: (chairs) Compliance issues need to be addressed (as noted by the evaluation team [mentioned above], but we are not adding features to IPFIX requirements. At this point we want to get consensus that the suggested process is the way forward, and move discussion of specific details to the mailing list. Q: Shouldn't we merge some of the candidate protocols [rather than choosing NetFlow]? A: (chairs) We needed to select one protocol to accelerate the process. We'll use that as a basis, something that will work soon, incorporating other features only as necessary. Q: The evaluation check list was flawed: it was all or nothing (not graded, prioritized) for each requirement. Can we go back and score A-E to clarify the decision? It would make a more convincing case [for the evaluation team's decision]. A: (chairs) Do we want to go back to November 2002 with a finer grain scoring? The quantification is very difficult and problematic. Rhetorical: do we think anything will be gained by jiggering the process to justify the selection of NetFlow? There were considerations beyond the matrix of "scores", like NetFlow's wide deployment. At this point the chairs called for a show of hands, "How many support the evaluation team's finding?" ("How many disagree?") The shows of hands indicated clearly that consensus of the room was for accepting the finding and going forward. The chairs said final rough consensus will be determined from the mailing list. Also: (chairs) Now we are looking for volunteers to help write the next documents. We encourage your comments on the list. Please limit it to one comment per message so we can keep the threads straight! -- The chairs reviewed the revised WG Milestones: [see agenda slides for details] We've met some of our early milestones and some more are within reach. We will need an Applicability Statement. Tanja Zseby agreed to continue with this. August 2003 suggested for this and the protocol document IDs. -- Benoit Claise presented a slide show about the relationship between IPFIX and PSAMP based on "draft-quittek-psamp-ipfix-01". [see slides for details] -- Supratik Bhattacharyya presented a slide show on Continuous Measurent and Monitoring in an ISP backbone related to Sprint Labs document on operators' requirements: "draft-bhattacharyya-monitoring-sprint-01". [see slides for details, further information at: http://ipmon.sprint.com] Q: What kind of reliability do you need? A: (Supratik) not entirely clear - reliability is certainly useful, but not absolutely necessary. -- The meeting was adjourned with the reminder that follow-ups will happen in the mailing list and that we need to find an "issues tracking" method for the refinement/development of the IPFIX protocol. -- P.S. George Michaelson's (ggm) "live" notes instant messaging are logged here: http://www.jabber.com/chatbot/logs/conference.ietf.jabber.com/ipfix/2003-03-20.html -- $Id: minutes.txt,v 1.4 2003/03/24 16:08:34 dplonka Exp $ --wRRV7LY7NUeQGEoC-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/