From majordomo@mil.doit.wisc.edu Sun Dec 9 01:57:42 2001 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 BAA16407 for ; Sun, 9 Dec 2001 01:57:42 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16CxRC-00002e-00 for ipfix-list@mil.doit.wisc.edu; Sun, 09 Dec 2001 00:27:46 -0600 Received: from smtp.us.xacct.com ([204.253.100.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16CxR9-00001G-00 for ipfix@net.doit.wisc.edu; Sun, 09 Dec 2001 00:27:43 -0600 Received: from Kevinz (slip-32-103-10-47.md.us.prserv.net [32.103.10.47]) by smtp.us.xacct.com (8.11.2/8.11.2) with SMTP id fB96NWe20035; Sat, 8 Dec 2001 22:23:33 -0800 Reply-To: From: "Kevin Zhang" To: Cc: , Subject: [ipfix] Comments on IPFIX requirements Date: Sun, 9 Dec 2001 01:27:46 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Importance: Normal In-Reply-To: <200111272052.JAA17533@mailhost.auckland.ac.nz> Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id BAA16407 Hi All, I have the following comments on the IPFIX requirement document. They all relate to section 5.3 Data Transfer section of the draft. Time permitting, I hope we can talk about them and consider their inclusion in the requirement draft. See you at Salt Lake City! Kevin Zhang XACCT Technologies, Inc. Mobile 1 (301) 992-4697 ----------------------------- Comments Section 5.3 Data Transfer No change Section 5.3.1 Congestion Awareness Data transfer MUST use a congestion aware protocol. A congestion aware protocol MUST implement congestion control and avoidance algorithms that maintain stability of the Internet. The algorithms SHOULD have behaviors that are well understood and acceptable by the Internet community. An example of such an algorithm is the additive- increase/multiplicative-decrease (AIMD), which is implemented by the TCP and SCTP. Section 5.3.2 Reliability Data transfer SHOULD be reliable. In this context, Reliability refers to the in-sequence, error free delivery of data from the exporter to external systems. Absence of reliability MUST be indicated by the IPFIX system covering data loss, data errors, out- of-sequence data, and duplicated data. Reliability may be achieved without using a reliable transport layer protocol. In this case, reliability should be provided by higher layer functions. For certain applications that do not require reliability data transfer, an unreliable transport protocol is typically used. In such a case, lack of overall reliability MUST be indicated. Section 5.3.3 Security No change Section 5.3.4 Push and Pull Mode Reporting No change Section 5.3.5 Regular Reporting Interval No change Section 5.3.6 Notification on Specific Events No change Section 5.3.7 Anonymization No change Section 5.3.8 Flow Control When reliable data transfer is required, flow control SHOULD be supported. Flow control functions protect the data receiver from being overwhelmed by the amount of received data, which may lead to data loss. Section 5.3.9 Robustness Data transfer SHOULD be robust against network and system fault conditions. Robustness may be supported by deploying redundant data receiving systems, and fail-over/fail-back procedures. Section 5.3.10 Efficiency Data transfer MUST be efficient. Efficiency can be measured by assessing data transfer overhead, which include message encoding overhead, and data encoding overhead. -------------------------------------------------ޖ[hfhzݢ++njwlk/zZyƠyI칻&ޙj:+vw""vvƲ칻&ފ,j܀bm*_ݢ++n܆+ From majordomo@mil.doit.wisc.edu Mon Dec 10 20:23:57 2001 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 UAA16171 for ; Mon, 10 Dec 2001 20:23:57 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16DbJZ-00057D-00 for ipfix-list@mil.doit.wisc.edu; Mon, 10 Dec 2001 19:02:33 -0600 Received: from dplonka by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16DbJX-000577-00 for ipfix@net.doit.wisc.edu; Mon, 10 Dec 2001 19:02:31 -0600 Date: Mon, 10 Dec 2001 19:02:31 -0600 From: Dave Plonka To: ipfix@net.doit.wisc.edu Subject: some thoughts in prep for Wed. WG meeting (was "Re: [ipfix] IPFIX WG Agenda for IETF 52") Message-ID: <20011210190231.B16189@doit.wisc.edu> Reply-To: plonka@doit.wisc.edu References: <5.1.0.14.0.20011204121235.0263dec0@odin> <200112050027.NAA15281@mailhost.auckland.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200112050027.NAA15281@mailhost.auckland.ac.nz>; from n.brownlee@auckland.ac.nz on Tue, Dec 04, 2001 at 04:26:47PM -0800 Organization: UW-Madison, DoIT, Network Services X-VMS-Error: %SYSTEM-W-ACPVAFUL, MTAACP's virtual address space is full X-Shakespearean-Insult: Thou mewling doghearted giglet Precedence: bulk Sender: majordomo listserver On Tue, Dec 04, 2001 at 04:26:47PM -0800, n.brownlee@auckland.ac.nz wrote: > AGENDA for the IPFIX Working Group Session > > IETF 52, Wednesday 12 December, 1530-1730 > > > time Item . . . . . . . . > 20 2 Requirements document > draft-ietf-ipfix-reqs-00.txt published 6 November ******* > Brief overview, differences between this and > earlier versions, discussion. What further > changes are needed before we go to WG last call? Here's some changes/additions that Nevil and I put together, and will raise at the wed. meeting: 0) add "Definitions" section (1.2?) a) Flow Information eXport process ("FIX process") b) "exporter" c) "collector" (alt. "importer"?) d) "in-band" vs. out-of-band" e) define Flow Information eXport "record" - it is the information representing a single flow 1) Unidirectional vs. bi-directional flow definition 2) In what ways might the exporter adapt/deal with copious amounts of data... dynamic timeouts? dynamic flow rules? dynamic sampling on/off? 3) are ingress (and egress) interfaces one of the MUST packet properties? > 45 4 Getting Started on IPFIX Architecture and > IPFIX Data Model Internet Drafts > c) What should the sub-groups topics be, and > who's perpared to work in which ones? The Architecture document should address how to deal with "interface handles" (ifIndex vs. IPFIX configurable ifAlias-like labels). Another question for the Architecture is when is it OK to discard "old" flow data (rather than export it)? Should this be configurable? For those of you here in Salt Lake - see you Wednesday, if not before! Dave -- plonka@doit.wisc.edu http://net.doit.wisc.edu/~plonka ARS:N9HZF Madison, WI -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Dec 10 23:49:58 2001 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 XAA21796 for ; Mon, 10 Dec 2001 23:49:58 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16DeaC-0005M0-00 for ipfix-list@mil.doit.wisc.edu; Mon, 10 Dec 2001 22:31:56 -0600 Received: from 251-196-131-12.bellhead.com ([12.131.196.251] helo=localhost.localdomain) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16Dea9-0005Lt-00 for ipfix@net.doit.wisc.edu; Mon, 10 Dec 2001 22:31:53 -0600 Received: from BETA (74-202-131-12.bellhead.com [12.131.202.74]) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id fBB4T2j12645; Mon, 10 Dec 2001 21:29:02 -0700 Date: Tue, 11 Dec 2001 05:32:09 +0100 From: Juergen Quittek To: plonka@doit.wisc.edu, ipfix@net.doit.wisc.edu Subject: Re: some thoughts in prep for Wed. WG meeting (was "Re: [ipfix] IPFIX WG Agenda for IETF 52") Message-ID: <3026382177.1008048729@BETA> In-Reply-To: <20011210190231.B16189@doit.wisc.edu> X-Mailer: Mulberry/2.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit --On 10 December 2001 19:02 -0600 Dave Plonka wrote: > On Tue, Dec 04, 2001 at 04:26:47PM -0800, n.brownlee@auckland.ac.nz wrote: > >> AGENDA for the IPFIX Working Group Session >> >> IETF 52, Wednesday 12 December, 1530-1730 >> >> >> time Item . . . . . . . . > >> 20 2 Requirements document >> draft-ietf-ipfix-reqs-00.txt published 6 November ******* >> Brief overview, differences between this and >> earlier versions, discussion. What further >> changes are needed before we go to WG last call? > > Here's some changes/additions that Nevil and I put together, and will > raise at the wed. meeting: > > 0) add "Definitions" section (1.2?) > a) Flow Information eXport process ("FIX process") > b) "exporter" > c) "collector" (alt. "importer"?) > d) "in-band" vs. out-of-band" > e) define Flow Information eXport "record" > - it is the information representing a single flow I agree, that this is a very helpful extension of the document. When we submitted the current draft, we already had a "terminology" or "definitions" section on our to do list for the next version. What should probably be added is f) observation point Do you suggest to rename "measuring device" by "exporter"? > 1) Unidirectional vs. bi-directional flow definition This will be an interesting discussion. I am already very curios about the arguments. I am in clear favor of using a uni-directional flow definition, although I see some arguments for a bi-directional one. The most obvious argument for uni-directional definition is that this is the more basic definition. If you want to see both directions, you just have combine two uni-directional flows. Another important argument is the ease of implementation. If you implement measurements on a line card of a router you save a lot of hardware, if you just analyse incoming traffic (as you do it already on several cards) and let outbound traffic pass without scanning the packet headers. If you request bi-directional flow measurement already at the exporter, then the exporter might have to correlate traffic measurements from all its interfaces in order to join the separate measurements in a single flow record. Arguments for bi-directional flow definition include - convenience for user that want to measure bi-directional flows - TCP with its bi-directional nature > 2) In what ways might the exporter adapt/deal with copious amounts of > data... > dynamic timeouts? > dynamic flow rules? > dynamic sampling on/off? You do not mention the most obvious option: stop measuring? > 3) are ingress (and egress) interfaces one of the MUST packet properties? > > >> 45 4 Getting Started on IPFIX Architecture and >> IPFIX Data Model Internet Drafts > >> c) What should the sub-groups topics be, and >> who's perpared to work in which ones? > > The Architecture document should address how to deal with "interface > handles" (ifIndex vs. IPFIX configurable ifAlias-like labels). > > Another question for the Architecture is when is it OK to discard "old" > flow data (rather than export it)? Should this be configurable? > > For those of you here in Salt Lake - see you Wednesday, if not before! > > Dave > > -- > plonka@doit.wisc.edu http://net.doit.wisc.edu/~plonka ARS:N9HZF Madison, WI > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Dec 11 00:40:22 2001 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 AAA25919 for ; Tue, 11 Dec 2001 00:40:22 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16DfIT-00073h-00 for ipfix-list@mil.doit.wisc.edu; Mon, 10 Dec 2001 23:17:41 -0600 Received: from smtp.us.xacct.com ([204.253.100.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16DfIS-00072f-00 for ipfix@net.doit.wisc.edu; Mon, 10 Dec 2001 23:17:40 -0600 Received: from Kevinz (slip-12-64-210-79.mis.prserv.net [12.64.210.79]) by smtp.us.xacct.com (8.11.2/8.11.2) with SMTP id fBB5DOe30457 for ; Mon, 10 Dec 2001 21:13:25 -0800 Reply-To: From: "Kevin Zhang" To: Subject: [ipfix] Some ideas on IPFIX-architecture Date: Tue, 11 Dec 2001 00:17:48 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20011210190231.B16189@doit.wisc.edu> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id AAA25919 Hi All, As we are getting started to work on the IPFIX architecture, I would like to offer few ideas to assist the discussion. Hopefully, we can touch on these issues at our Wed. session. 1. General Scope of IPFIX architecture. The IPFIX architecture should describe the major functions performed by a IPFIX system. We need to answer the following questions - 1.1 What is the IPFIX system and what are the key functions performed by such a system? 1.2 What are the major functional elements (e.g. data exporter, data collector, etc.) within the IPFIX system? 1.3 How to assign key IPFIX functions to various IPFIX elements? What are the interfaces and supported protocols? Reference models should be specified. 2. IPFIX Scenarios 2.1 The exporter and the collector are connected over LAN or dedicated links. This scenario maybe suitable for handling high volume data export and may use unreliable transport protocol. 2.2 The exporter and the collector are connected over WAN. This scenario may require higher level of processing at the exporter (such as aggregation), and should use a reliable transport protocol with congestion control and avoidance capability. 2.3 Highly reliable IPFIX configuration. This scenario should describe how to support reliability of data export as well as redundant configurations. 3. Data transport Semantics We need to specify the required control information exchange between the layers and between the end points. This would set up the correct context for export IP flow information to meet various application (billing, traffic profiling, etc.) requirement. ޖ[hfhzݢ++njwlk/zZyƠyI칻&ޙj:+vw""vvƲ칻&ފ,j܀bm*_ݢ++n܆+ From majordomo@mil.doit.wisc.edu Tue Dec 11 06:07:49 2001 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 GAA16184 for ; Tue, 11 Dec 2001 06:07:49 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16DkQY-00040j-00 for ipfix-list@mil.doit.wisc.edu; Tue, 11 Dec 2001 04:46:22 -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 16DkQV-0003zU-00 for ipfix@net.doit.wisc.edu; Tue, 11 Dec 2001 04:46:19 -0600 Received: from cisco.com (bclaise-isdn-home4.cisco.com [10.49.4.221]) by strange-brew.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id LAA08855; Tue, 11 Dec 2001 11:45:36 +0100 (MET) Message-ID: <3C15E3CF.F65D5A7F@cisco.com> Date: Tue, 11 Dec 2001 11:45:35 +0100 From: Benoit Claise X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Quittek CC: plonka@doit.wisc.edu, ipfix@net.doit.wisc.edu Subject: Re: some thoughts in prep for Wed. WG meeting (was "Re: [ipfix] IPFIX WG Agenda for IETF 52") References: <3026382177.1008048729@BETA> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Dave, Juergen and all, After reading the requirement I-D one more time, I also have some more comments 1. In the section 1.1 about IP flows I'm not sure anymore about the meaning of that sentence: Please note that our flow definition does not match a general application-level end-to-end stream. However, an application may derive properties of application- level streams by processing measured flow data. 2. In the section 3. about Distinguishing Flows I would add one more comment, between brackets. Otherwise, every router will be compliant with IPFIX, as long as they distinguish flows somehow... Which combination of properties is evaluated for a particular measurement and how these properties are evaluated depends on the capabilities of the measuring device (this remark concerns a middlebox or a traffic measurement probe compared to a router) and on its configuration. The configured choice of evaluated properties strongly depends on the environment and purpose of the measurement and on the information required by the data collector. 3. In the section 4.1. about Reliability The measurement process MUST either be reliable or missing reliability MUST be known and indicated. The measurement process is reliable, if each packet passing the observation point is measured according to the configuration of the measuring device. If, e.g. due to some overload, not all passing packets can be included into the measurement process, then it SHOULD be stored at the measuring device, that flows might be measured inaccurately. To be consistent with the beginning of the paragraph, the last SHOULD must be a MUST 4. A typo detail on section 8 Special caution is required if security applications rely on IPFIX data With forgery of exported should be Special caution is required if security applications rely on IPFIX data. With forgery of exported 5. We should define which protocols we are monitoring with IPFIX. IP, obviously. But what about ICMP, IGMP, etc ... (as pointed by arnaud.jacquet@bt.com) This is a good idea! Regards, Benoit Juergen Quittek wrote: > --On 10 December 2001 19:02 -0600 Dave Plonka wrote: > > > On Tue, Dec 04, 2001 at 04:26:47PM -0800, n.brownlee@auckland.ac.nz wrote: > > > >> AGENDA for the IPFIX Working Group Session > >> > >> IETF 52, Wednesday 12 December, 1530-1730 > >> > >> > >> time Item . . . . . . . . > > > >> 20 2 Requirements document > >> draft-ietf-ipfix-reqs-00.txt published 6 November ******* > >> Brief overview, differences between this and > >> earlier versions, discussion. What further > >> changes are needed before we go to WG last call? > > > > Here's some changes/additions that Nevil and I put together, and will > > raise at the wed. meeting: > > > > 0) add "Definitions" section (1.2?) > > a) Flow Information eXport process ("FIX process") > > b) "exporter" > > c) "collector" (alt. "importer"?) > > d) "in-band" vs. out-of-band" > > e) define Flow Information eXport "record" > > - it is the information representing a single flow > > I agree, that this is a very helpful extension of the document. > When we submitted the current draft, we already had a "terminology" > or "definitions" section on our to do list for the next version. > > What should probably be added is > f) observation point > > Do you suggest to rename "measuring device" by "exporter"? > > > 1) Unidirectional vs. bi-directional flow definition > > This will be an interesting discussion. I am already very curios > about the arguments. I am in clear favor of using a uni-directional > flow definition, although I see some arguments for a bi-directional > one. > > The most obvious argument for uni-directional definition is that this > is the more basic definition. If you want to see both directions, > you just have combine two uni-directional flows. > > Another important argument is the ease of implementation. If you > implement measurements on a line card of a router you save a lot > of hardware, if you just analyse incoming traffic (as you do it > already on several cards) and let outbound traffic pass without > scanning the packet headers. If you request bi-directional flow > measurement already at the exporter, then the exporter might have > to correlate traffic measurements from all its interfaces in order > to join the separate measurements in a single flow record. > > Arguments for bi-directional flow definition include > - convenience for user that want to measure bi-directional flows > - TCP with its bi-directional nature > > > 2) In what ways might the exporter adapt/deal with copious amounts of > > data... > > dynamic timeouts? > > dynamic flow rules? > > dynamic sampling on/off? > > You do not mention the most obvious option: > stop measuring? > > > 3) are ingress (and egress) interfaces one of the MUST packet properties? > > > > > >> 45 4 Getting Started on IPFIX Architecture and > >> IPFIX Data Model Internet Drafts > > > >> c) What should the sub-groups topics be, and > >> who's perpared to work in which ones? > > > > The Architecture document should address how to deal with "interface > > handles" (ifIndex vs. IPFIX configurable ifAlias-like labels). > > > > Another question for the Architecture is when is it OK to discard "old" > > flow data (rather than export it)? Should this be configurable? > > > > For those of you here in Salt Lake - see you Wednesday, if not before! > > > > Dave > > > > -- > > plonka@doit.wisc.edu http://net.doit.wisc.edu/~plonka ARS:N9HZF Madison, WI > > > > -- > > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > "unsubscribe ipfix" in message body > > Archive http://ipfix.doit.wisc.edu/archive/ > > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" 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 Dec 11 11:26:15 2001 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 LAA19932 for ; Tue, 11 Dec 2001 11:26:15 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16DpPB-0001D6-00 for ipfix-list@mil.doit.wisc.edu; Tue, 11 Dec 2001 10:05:17 -0600 Received: from mailhub.lawrence.edu ([143.44.65.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16DpP9-0001Cw-00 for ipfix@net.doit.wisc.edu; Tue, 11 Dec 2001 10:05:15 -0600 Received: from lawrence.edu ([143.44.97.14]) by lawrence.edu (PMDF V6.0-025 #44893) with ESMTP id <0GO600AD2T5BF8@lawrence.edu> for ipfix@net.doit.wisc.edu; Tue, 11 Dec 2001 10:15:11 -0600 (CST) Date: Tue, 11 Dec 2001 10:05:14 -0600 From: Robert Lowe Subject: [ipfix] Re: some thoughts in prep for Wed. WG meeting (was"Re: [ipfix] IPFIX WG Agenda for IETF 52") To: Benoit Claise Cc: Juergen Quittek , plonka@doit.wisc.edu, ipfix@net.doit.wisc.edu Message-id: <3C162EBA.FF2394D@lawrence.edu> Organization: Lawrence University MIME-version: 1.0 X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <3026382177.1008048729@BETA> <3C15E3CF.F65D5A7F@cisco.com> Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit > 3. In the section 4.1. about Reliability > > The measurement process MUST either be reliable or missing > reliability MUST be known and indicated. The measurement process is > reliable, if each packet passing the observation point is measured > according to the configuration of the measuring device. If, e.g. due > to some overload, not all passing packets can be included into the > measurement process, then it SHOULD be stored at the measuring > device, that flows might be measured inaccurately. > > To be consistent with the beginning of the paragraph, the last SHOULD must be a MUST The last clause does not make sense ("that flows might be measure inaccurately"). Either someone means "since flows...", or "in order that... measured accurately", regardless of SHOULD vs. MUST. Also, there is a syntactical problem here, since "it" is never defined -- if not all packets, then "it"? This would seem to me to be tied to same issues Dave/Neil brought up below. Saying that something MUST be stored at the measuring device would seem to imply that the measuring device have infinite capacity, since one can imagine an infinite overload situation. ;-) Why should the approach for uni-directional or bi-directional flows be any different? I promise to read the next revision, but I would strongly suggest uniform terminology, e.g. don't interchange "measurement device" and "exporter" unless there is a reason to do so. -Robert > > > 1) Unidirectional vs. bi-directional flow definition > > > > This will be an interesting discussion. I am already very curios > > about the arguments. I am in clear favor of using a uni-directional > > flow definition, although I see some arguments for a bi-directional > > one. > > > > The most obvious argument for uni-directional definition is that this > > is the more basic definition. If you want to see both directions, > > you just have combine two uni-directional flows. > > > > Another important argument is the ease of implementation. If you > > implement measurements on a line card of a router you save a lot > > of hardware, if you just analyse incoming traffic (as you do it > > already on several cards) and let outbound traffic pass without > > scanning the packet headers. If you request bi-directional flow > > measurement already at the exporter, then the exporter might have > > to correlate traffic measurements from all its interfaces in order > > to join the separate measurements in a single flow record. > > > > Arguments for bi-directional flow definition include > > - convenience for user that want to measure bi-directional flows > > - TCP with its bi-directional nature > > > > > 2) In what ways might the exporter adapt/deal with copious amounts of > > > data... > > > dynamic timeouts? > > > dynamic flow rules? > > > dynamic sampling on/off? > > > > You do not mention the most obvious option: > > stop measuring? -- Help mailto:majordomo@net.doit.wisc.edu and say "help" 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 Dec 11 11:51:09 2001 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 LAA20312 for ; Tue, 11 Dec 2001 11:51:09 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16Dpnc-0001lF-00 for ipfix-list@mil.doit.wisc.edu; Tue, 11 Dec 2001 10:30:32 -0600 Received: from dplonka by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16Dpna-0001l7-00; Tue, 11 Dec 2001 10:30:30 -0600 Date: Tue, 11 Dec 2001 10:30:30 -0600 From: Dave Plonka To: ipfix@net.doit.wisc.edu Cc: Juergen Quittek Subject: Re: some thoughts in prep for Wed. WG meeting (was "Re: [ipfix] IPFIX WG Agenda for IETF 52") Message-ID: <20011211103030.A5635@doit.wisc.edu> Reply-To: plonka@doit.wisc.edu References: <20011210190231.B16189@doit.wisc.edu> <3026382177.1008048729@BETA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <3026382177.1008048729@BETA>; from quittek@ccrle.nec.de on Tue, Dec 11, 2001 at 05:32:09AM +0100 Organization: UW-Madison, DoIT, Network Services X-VMS-Error: %SYSTEM-F-SUBRNG6, subscript 6 range error, PC=00000000, PS=0000059C X-Shakespearean-Insult: Thou spleeny clay-brained lewdster Precedence: bulk Sender: majordomo listserver On Tue, Dec 11, 2001 at 05:32:09AM +0100, Juergen Quittek wrote: > --On 10 December 2001 19:02 -0600 Dave Plonka wrote: > > 0) add "Definitions" section (1.2?) > I agree, that this is a very helpful extension of the document. > When we submitted the current draft, we already had a "terminology" > or "definitions" section on our to do list for the next version. > > What should probably be added is > f) observation point Yes, I'm not sure I understand the use of that term yet. > Do you suggest to rename "measuring device" by "exporter"? In short, yes. We can discuss this in the meeting and summarize the proposal to the list following the meeting tomorrow (Dec 11). > > 1) Unidirectional vs. bi-directional flow definition > > This will be an interesting discussion. Agreed - I'll leave it at that until the meeting minutes. > > 2) In what ways might the exporter adapt/deal with copious amounts of > > data... > > dynamic timeouts? > > dynamic flow rules? > > dynamic sampling on/off? > > You do not mention the most obvious option: > stop measuring? Yes, that is a fair addition to stop exporting, or stop exporting flows of a particular type. I'm not trying to list all options, I just want to introduce the idea so that we can explore how the Requirements I-D might allow the exporter to change its behavior "on the fly" due to resource and bandwidth limitations, perhaps as configured. Interestingly, "draft-duffield-framework-papame-00" mentions some of these issues. For those that haven't looked at it, it has a lot of issues in common with our effort. Dave -- plonka@doit.wisc.edu http://net.doit.wisc.edu/~plonka ARS:N9HZF Madison, WI -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Dec 12 09:21:22 2001 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 JAA03873 for ; Wed, 12 Dec 2001 09:21:22 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16E9py-0002tf-00 for ipfix-list@mil.doit.wisc.edu; Wed, 12 Dec 2001 07:54:18 -0600 Received: from mgw-dax2.ext.nokia.com ([63.78.179.217]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16E9pv-0002tQ-00 for ipfix@net.doit.wisc.edu; Wed, 12 Dec 2001 07:54:15 -0600 Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fBCDtHQ00393 for ; Wed, 12 Dec 2001 07:55:18 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 12 Dec 2001 07:54:10 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 12 Dec 2001 07:53:46 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message Subject: RE: [ipfix] Some ideas on IPFIX-architecture MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 12 Dec 2001 08:54:09 -0500 Message-ID: Thread-Topic: [ipfix] Some ideas on IPFIX-architecture Thread-Index: AcGCBS/e5z8Oz+33EdWrzAAIx6S5QwBD4N+A From: "Gopal Ram (NRC/Boston)" To: X-OriginalArrivalTime: 12 Dec 2001 13:53:46.0859 (UTC) FILETIME=[6B7663B0:01C18314] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA03873 Hello all, (1) Archicture should identify key elements which are going to participate in the IPFIX protocol. (2) We should keep in mind that IPFIX is not going existing on its own its has relations with Diameter, Intrusion Detection subsystem (3) Should defines these external dependency and internal interfaces between different sub systems. (4) Any precondition and out of scope should be state here as well as in the requirements. (5) Should come up with sample scenarios or explaining with a reference model. Regards Ramg >-----Original Message----- >From: ext Kevin Zhang [mailto:kevin.zhang@xacct.com] >Sent: Tuesday, December 11, 2001 12:18 AM >To: ipfix@net.doit.wisc.edu >Subject: [ipfix] Some ideas on IPFIX-architecture > > >Hi All, > >As we are getting started to work on the IPFIX architecture, I >would like to offer few ideas to assist the discussion. >Hopefully, we can touch on these issues at our Wed. session. > >1. General Scope of IPFIX architecture. > >The IPFIX architecture should describe the major functions >performed by a IPFIX system. We need to answer the following >questions - >1.1 What is the IPFIX system and what are the key functions >performed by such a system? >1.2 What are the major functional elements (e.g. data >exporter, data collector, etc.) within the IPFIX system? >1.3 How to assign key IPFIX functions to various IPFIX >elements? What are the interfaces and supported protocols? >Reference models should be specified. > >2. IPFIX Scenarios > >2.1 The exporter and the collector are connected over LAN or >dedicated links. This scenario maybe suitable for handling >high volume data export and may use unreliable transport protocol. >2.2 The exporter and the collector are connected over WAN. >This scenario may require higher level of processing at the >exporter (such as aggregation), and should use a reliable >transport protocol with congestion control and avoidance capability. >2.3 Highly reliable IPFIX configuration. This scenario should >describe how to support reliability of data export as well as >redundant configurations. > >3. Data transport Semantics > >We need to specify the required control information exchange >between the layers and between the end points. This would set >up the correct context for export IP flow information to meet >various application (billing, traffic profiling, etc.) requirement. > > >i(tm)?sZSݢj'zhS"ǝݱzZbzgn?rR{.n+?j)mfhs? >"qnjwlk+r>z*_<(tm),j>EURbmYS-"qn?+ > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" 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 Dec 12 09:36:07 2001 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 JAA05062 for ; Wed, 12 Dec 2001 09:36:07 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16E9wH-0003Ab-00 for ipfix-list@mil.doit.wisc.edu; Wed, 12 Dec 2001 08:00:49 -0600 Received: from mgw-dax2.ext.nokia.com ([63.78.179.217]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16E9wF-0003AV-00 for ipfix@net.doit.wisc.edu; Wed, 12 Dec 2001 08:00:47 -0600 Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fBCE1rQ00563 for ; Wed, 12 Dec 2001 08:01:53 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 12 Dec 2001 08:00:45 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 12 Dec 2001 08:00:22 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message Subject: RE: [ipfix] Some ideas on IPFIX-architecture MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 12 Dec 2001 09:00:45 -0500 Message-ID: Thread-Topic: [ipfix] Some ideas on IPFIX-architecture Thread-Index: AcGCBS/e5z8Oz+33EdWrzAAIx6S5QwBD4N+AAABGPDA= From: "Gopal Ram (NRC/Boston)" To: X-OriginalArrivalTime: 12 Dec 2001 14:00:22.0299 (UTC) FILETIME=[5729BEB0:01C18315] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA05062 Sorry earlier emails slipped out my hands. Hello all, (1) Archicture should identify key elements which are going to participate in the IPFIX protocol. (2) We should keep in mind that IPFIX is not going existing on its own its has relations with Diameter, Intrusion Detection subsystem (3) Should describe ( not define ) these external dependency and internal interfaces between different sub systems. (4) Any precondition and out of scope should be state here as well as in the requirements. (5) Should come up with sample scenarios or explaining with a reference model. In principle "Architecture" should not cover (impose )any solution - it should describe the entities involved in IPFIX protocol. Regards Ramg >>-----Original Message----- >>From: ext Kevin Zhang [mailto:kevin.zhang@xacct.com] >>Sent: Tuesday, December 11, 2001 12:18 AM >>To: ipfix@net.doit.wisc.edu >>Subject: [ipfix] Some ideas on IPFIX-architecture >> >> >>Hi All, >> >>As we are getting started to work on the IPFIX architecture, I >>would like to offer few ideas to assist the discussion. >>Hopefully, we can touch on these issues at our Wed. session. >> >>1. General Scope of IPFIX architecture. >> >>The IPFIX architecture should describe the major functions >>performed by a IPFIX system. We need to answer the following >>questions - >>1.1 What is the IPFIX system and what are the key functions >>performed by such a system? >>1.2 What are the major functional elements (e.g. data >>exporter, data collector, etc.) within the IPFIX system? >>1.3 How to assign key IPFIX functions to various IPFIX >>elements? What are the interfaces and supported protocols? >>Reference models should be specified. >> >>2. IPFIX Scenarios >> >>2.1 The exporter and the collector are connected over LAN or >>dedicated links. This scenario maybe suitable for handling >>high volume data export and may use unreliable transport protocol. >>2.2 The exporter and the collector are connected over WAN. >>This scenario may require higher level of processing at the >>exporter (such as aggregation), and should use a reliable >>transport protocol with congestion control and avoidance capability. >>2.3 Highly reliable IPFIX configuration. This scenario should >>describe how to support reliability of data export as well as >>redundant configurations. >> >>3. Data transport Semantics >> >>We need to specify the required control information exchange >>between the layers and between the end points. This would set >>up the correct context for export IP flow information to meet >>various application (billing, traffic profiling, etc.) requirement. >> >> >>i(tm)?sZSݢj'zhS"ǝݱzZbzgn?rR{.n+?j)mfhs? >>"qnjwlk+r>z*_<(tm),j>EURbmYS-"qn?+ >> > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" 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 Dec 12 15:36:20 2001 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 PAA17576 for ; Wed, 12 Dec 2001 15:36:20 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16EFkf-0007HH-00 for ipfix-list@mil.doit.wisc.edu; Wed, 12 Dec 2001 14:13:13 -0600 Received: from mail.riverstonenet.com ([63.113.148.10] helo=riverstonenet.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16EFkZ-0007Cl-00 for ipfix@net.doit.wisc.edu; Wed, 12 Dec 2001 14:13:08 -0600 Received: from agile.yagosys.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id MAA10979; Wed, 12 Dec 2001 12:12:23 -0800 (PST) Received: from agile.yagosys.com (agile.yagosys.com [127.0.0.1]) by agile.yagosys.com (8.12.0/8.12.0) with ESMTP id fBCKCNaC001489; Wed, 12 Dec 2001 12:12:23 -0800 Received: (from mrm@localhost) by agile.yagosys.com (8.12.0/8.12.0/Submit) id fBCKCM63001488; Wed, 12 Dec 2001 12:12:22 -0800 Date: Wed, 12 Dec 2001 12:12:22 -0800 From: Michael MacFaden To: "Gopal Ram (NRC/Boston)" Cc: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Some ideas on IPFIX-architecture Message-ID: <20011212121222.E1364@riverstonenet.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from ram.gopal@nokia.com on Wed, Dec 12, 2001 at 08:54:09AM -0500 X-Operating-System: GNU/Linux 2.4.12 Precedence: bulk Sender: majordomo listserver On Wed, Dec 12, 2001 at 08:54:09AM -0500, Gopal Ram (NRC/Boston) wrote: >(2) We should keep in mind that IPFIX is not going existing on its own >its has relations with Diameter, >Intrusion Detection subsystem I do not see any required relation to Diameter as of today other than at some point in the possible future that the protocol is best fitted for the IPFIX requirements. IPFIX work is standardizing *existing practice* that has been deployed for years. Mike -- Help mailto:majordomo@net.doit.wisc.edu and say "help" 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 Dec 12 16:13:01 2001 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 QAA18296 for ; Wed, 12 Dec 2001 16:13:01 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16EGQZ-00037z-00 for ipfix-list@mil.doit.wisc.edu; Wed, 12 Dec 2001 14:56:31 -0600 Received: from patan.sun.com ([192.18.98.43]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16EGQY-00037u-00 for ipfix@net.doit.wisc.edu; Wed, 12 Dec 2001 14:56:30 -0600 Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA18441; Wed, 12 Dec 2001 13:56:07 -0700 (MST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.86.31]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id MAA21782; Wed, 12 Dec 2001 12:56:57 -0800 (PST) Received: from sun.com (inox.Eng.Sun.COM [129.146.85.133]) by jurassic.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBCKuObF567523; Wed, 12 Dec 2001 12:56:24 -0800 (PST) Message-ID: <3C17C479.45BAA981@sun.com> Date: Wed, 12 Dec 2001 12:56:25 -0800 From: Jc Martin Organization: Sun Microsystems X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Michael MacFaden CC: "Gopal Ram (NRC/Boston)" , ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Some ideas on IPFIX-architecture References: <20011212121222.E1364@riverstonenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Michael > On Wed, Dec 12, 2001 at 08:54:09AM -0500, Gopal Ram (NRC/Boston) wrote: > >(2) We should keep in mind that IPFIX is not going existing on its own > >its has relations with Diameter, > >Intrusion Detection subsystem > > I do not see any required relation to Diameter as of today > other than at some point in the possible future that the > protocol is best fitted for the IPFIX requirements. Well, there should be a relation, maybe not with Diameter, but at least with AAA. The name space and attributes should/must be identical. > > IPFIX work is standardizing *existing practice* > that has been deployed for years. Then why a requirement document ? Why not just a description of the current practice ? JC. -- Help mailto:majordomo@net.doit.wisc.edu and say "help" 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 Dec 12 16:48:45 2001 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 QAA19136 for ; Wed, 12 Dec 2001 16:48:45 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16EGuu-0003sA-00 for ipfix-list@mil.doit.wisc.edu; Wed, 12 Dec 2001 15:27:52 -0600 Received: from mail.riverstonenet.com ([63.113.148.10] helo=riverstonenet.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16EGus-0003ro-00 for ipfix@net.doit.wisc.edu; Wed, 12 Dec 2001 15:27:50 -0600 Received: from agile.yagosys.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id NAA17764; Wed, 12 Dec 2001 13:27:10 -0800 (PST) Received: from agile.yagosys.com (agile.yagosys.com [127.0.0.1]) by agile.yagosys.com (8.12.0/8.12.0) with ESMTP id fBCLRAaC001661; Wed, 12 Dec 2001 13:27:10 -0800 Received: (from mrm@localhost) by agile.yagosys.com (8.12.0/8.12.0/Submit) id fBCLR8eY001660; Wed, 12 Dec 2001 13:27:08 -0800 Date: Wed, 12 Dec 2001 13:27:08 -0800 From: Michael MacFaden To: Jc Martin Cc: "Gopal Ram (NRC/Boston)" , ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Some ideas on IPFIX-architecture Message-ID: <20011212132708.K1364@riverstonenet.com> References: <20011212121222.E1364@riverstonenet.com> <3C17C479.45BAA981@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C17C479.45BAA981@sun.com>; from jean-christophe.martin@sun.com on Wed, Dec 12, 2001 at 12:56:25PM -0800 X-Operating-System: GNU/Linux 2.4.12 Precedence: bulk Sender: majordomo listserver On Wed, Dec 12, 2001 at 12:56:25PM -0800, Jc Martin wrote: >> >> IPFIX work is standardizing *existing practice* >> that has been deployed for years. > >Then why a requirement document ? Why not just a description of >the current practice ? We need the requirement document to culling current practice into something we can work with to base our work on what will eventually be the IPFIX protocol. Now if there is a requirement that can't be substantiated in a current practice with the defacto IP flow protocls (NetFlow, LFAP, etc) then, I'd think we'd be treading on unstable ground. Mike -- Help mailto:majordomo@net.doit.wisc.edu and say "help" 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 Dec 12 17:22:23 2001 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 RAA19961 for ; Wed, 12 Dec 2001 17:22:23 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16EHSB-0004bC-00 for ipfix-list@mil.doit.wisc.edu; Wed, 12 Dec 2001 16:02:15 -0600 Received: from 251-196-131-12.bellhead.com ([12.131.196.251] helo=localhost.localdomain) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16EHS9-0004b7-00 for ipfix@net.doit.wisc.edu; Wed, 12 Dec 2001 16:02:13 -0600 Received: from BETA (74-202-131-12.bellhead.com [12.131.202.74]) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id fBCLxHj18051; Wed, 12 Dec 2001 14:59:17 -0700 Date: Wed, 12 Dec 2001 23:02:28 +0100 From: Juergen Quittek To: Jc Martin cc: Michael MacFaden , ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Some ideas on IPFIX-architecture Message-ID: <3175801477.1008198148@BETA> X-Mailer: Mulberry/2.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit JC, --On 12 December 2001 12:56 -0800 Jc Martin wrote: > Michael > >> On Wed, Dec 12, 2001 at 08:54:09AM -0500, Gopal Ram (NRC/Boston) wrote: >> > (2) We should keep in mind that IPFIX is not going existing on its own >> > its has relations with Diameter, >> > Intrusion Detection subsystem >> >> I do not see any required relation to Diameter as of today >> other than at some point in the possible future that the >> protocol is best fitted for the IPFIX requirements. > > Well, there should be a relation, maybe not with Diameter, but at > least with AAA. The name space and attributes should/must be identical. Do you see one or even several requirement for IPFIX concerning compliance with AAA? If yes, then I suggest you phrase it in a little bit more elaborated paragraph, that we can discuss here and that can be inserted into the requirements draft. Particularly, it woulde be interesting why you think the name spaces must/should/may be identical. Also the phrase "maybe not with Diameter" is not really clear to me. Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > >> >> IPFIX work is standardizing *existing practice* >> that has been deployed for years. > > Then why a requirement document ? Why not just a description of > the current practice ? > > JC. > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" 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 Dec 12 19:10:10 2001 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 TAA22165 for ; Wed, 12 Dec 2001 19:10:10 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16EJ93-0006nt-00 for ipfix-list@mil.doit.wisc.edu; Wed, 12 Dec 2001 17:50:37 -0600 Received: from patan.sun.com ([192.18.98.43]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16EJ90-0006nk-00 for ipfix@net.doit.wisc.edu; Wed, 12 Dec 2001 17:50:34 -0600 Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA21846; Wed, 12 Dec 2001 16:50:11 -0700 (MST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.86.38]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id PAA28374; Wed, 12 Dec 2001 15:51:02 -0800 (PST) Received: from sun.com (inox.Eng.Sun.COM [129.146.85.133]) by jurassic.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBCNoSbF609081; Wed, 12 Dec 2001 15:50:28 -0800 (PST) Message-ID: <3C17ED46.A5F3152@sun.com> Date: Wed, 12 Dec 2001 15:50:30 -0800 From: Jc Martin Organization: Sun Microsystems X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Quittek CC: Michael MacFaden , ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Some ideas on IPFIX-architecture References: <3175801477.1008198148@BETA> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Juergen, See my response inline. > --On 12 December 2001 12:56 -0800 Jc Martin wrote: > > > Michael > > > >> On Wed, Dec 12, 2001 at 08:54:09AM -0500, Gopal Ram (NRC/Boston) wrote: > >> > (2) We should keep in mind that IPFIX is not going existing on its own > >> > its has relations with Diameter, > >> > Intrusion Detection subsystem > >> > >> I do not see any required relation to Diameter as of today > >> other than at some point in the possible future that the > >> protocol is best fitted for the IPFIX requirements. > > > > Well, there should be a relation, maybe not with Diameter, but at > > least with AAA. The name space and attributes should/must be identical. > > Do you see one or even several requirement for IPFIX > concerning compliance with AAA? If you look at the rfc3127, you can see that the evaluation of the AAA protocols for accounting had the following criteria : -Real Time Accounting -Mandatory Compact Encoding -Accounting Record Extensibility -Batch Accounting -Guaranteed Delivery -Accounting Timestamps -Dynamic Accounting which is overlapping with the requirements of IPFIX. While the scope of the accounting is different (network access vs. network traffic), the low level requirements seem identical. I'm not suggesting that IPFIX use diameter, far from that. I think that each protocol has some specific requirements that justify the divergence. While the protocol can be different, the transport requirements are identical, and the data model can be common, and since the server receiving AAA accounting will likely receive also IPFIX data, it would be wise to have some commonalties. > > If yes, then I suggest you phrase it in a little bit > more elaborated paragraph, that we can discuss here > and that can be inserted into the requirements draft. > Particularly, it woulde be interesting why you think > the name spaces must/should/may be identical. Also > the phrase "maybe not with Diameter" is not really > clear to me. My comment about "maybe not Diameter" means that I don't see the specific relation with Diameter as the issue, but more the relation between AAA and IPFIX. Ultimately, the accounting data from AAA will be consolidated with IPFIX data by the mediation device. It's natural to hope that similar concepts will be expressed identically. One possible approach would be to reuse the sections described in 4.3, 4.4 and 4.5 in draft-ietf-aaa-diameter-08.txt, if the information in that draft is still valid for the AAA protocol ( I did not follow the latest developments in AAA). Hope this makes sense. JC. -- Help mailto:majordomo@net.doit.wisc.edu and say "help" 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 Dec 12 19:10:32 2001 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 TAA22175 for ; Wed, 12 Dec 2001 19:10:31 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16EJAd-0006qY-00 for ipfix-list@mil.doit.wisc.edu; Wed, 12 Dec 2001 17:52:15 -0600 Received: from mercury.sun.com ([192.9.25.1]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16EJAb-0006qS-00 for ipfix@net.doit.wisc.edu; Wed, 12 Dec 2001 17:52:13 -0600 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA07568; Wed, 12 Dec 2001 15:52:08 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.86.38]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id PAA28914; Wed, 12 Dec 2001 15:52:40 -0800 (PST) Received: from sun.com (inox.Eng.Sun.COM [129.146.85.133]) by jurassic.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBCNq7bF609486; Wed, 12 Dec 2001 15:52:07 -0800 (PST) Message-ID: <3C17EDA9.D5152DB5@sun.com> Date: Wed, 12 Dec 2001 15:52:09 -0800 From: Jc Martin Organization: Sun Microsystems X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Quittek CC: Michael MacFaden , ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Some ideas on IPFIX-architecture References: <3175801477.1008198148@BETA> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Juergen, See my response inline. > --On 12 December 2001 12:56 -0800 Jc Martin wrote: > > > Michael > > > >> On Wed, Dec 12, 2001 at 08:54:09AM -0500, Gopal Ram (NRC/Boston) wrote: > >> > (2) We should keep in mind that IPFIX is not going existing on its own > >> > its has relations with Diameter, > >> > Intrusion Detection subsystem > >> > >> I do not see any required relation to Diameter as of today > >> other than at some point in the possible future that the > >> protocol is best fitted for the IPFIX requirements. > > > > Well, there should be a relation, maybe not with Diameter, but at > > least with AAA. The name space and attributes should/must be identical. > > Do you see one or even several requirement for IPFIX > concerning compliance with AAA? If you look at the rfc3127, you can see that the evaluation of the AAA protocols for accounting had the following criteria : -Real Time Accounting -Mandatory Compact Encoding -Accounting Record Extensibility -Batch Accounting -Guaranteed Delivery -Accounting Timestamps -Dynamic Accounting which is overlapping with the requirements of IPFIX. While the scope of the accounting is different (network access vs. network traffic), the low level requirements seem identical. I'm not suggesting that IPFIX use diameter, far from that. I think that each protocol has some specific requirements that justify the divergence. While the protocol can be different, the transport requirements are identical, and the data model can be common, and since the server receiving AAA accounting will likely receive also IPFIX data, it would be wise to have some commonalties. > > If yes, then I suggest you phrase it in a little bit > more elaborated paragraph, that we can discuss here > and that can be inserted into the requirements draft. > Particularly, it woulde be interesting why you think > the name spaces must/should/may be identical. Also > the phrase "maybe not with Diameter" is not really > clear to me. My comment about "maybe not Diameter" means that I don't see the specific relation with Diameter as the issue, but more the relation between AAA and IPFIX. Ultimately, the accounting data from AAA will be consolidated with IPFIX data by the mediation device. It's natural to hope that similar concepts will be expressed identically. One possible approach would be to reuse the sections described in 4.3, 4.4 and 4.5 in draft-ietf-aaa-diameter-08.txt, if the information in that draft is still valid for the AAA protocol ( I did not follow the latest developments in AAA). Hope this makes sense. JC. -- Help mailto:majordomo@net.doit.wisc.edu and say "help" 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 Dec 13 13:35:12 2001 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 NAA26254 for ; Thu, 13 Dec 2001 13:35:11 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16EaDA-0005d8-00 for ipfix-list@mil.doit.wisc.edu; Thu, 13 Dec 2001 12:04:00 -0600 Received: from dplonka by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16EaD8-0005d1-00; Thu, 13 Dec 2001 12:03:58 -0600 Date: Thu, 13 Dec 2001 12:03:58 -0600 From: Dave Plonka To: ipfix@net.doit.wisc.edu Cc: Randy Bush , Bert Wijnen Subject: [ipfix] DRAFT IPFIX WG minutes, IETF52 Message-ID: <20011213120358.A12553@doit.wisc.edu> Reply-To: plonka@doit.wisc.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Organization: UW-Madison, DoIT, Network Services X-VMS-Error: %SYSTEM-W-FILNOTACC, file not accessed on channel X-Shakespearean-Insult: Thou vain shard-borne baggage Precedence: bulk Sender: majordomo listserver IPFIX folks, Please review the DRAFT minutes of yesterday's meeting, below. Please send any comments/suggestions/corrections to the list. Thanks, Dave ---------------------------------------------------------------------- DRAFT minutes of the IP Flow Information eXport (IPFIX) WG, held at IETF 52, Wednesday 12 December 2002, 95 people attending. Notes by Cyndi Mills (scribe), Dave Plonka & Nevil Brownlee (co-chairs) Dave Plonka introduced the session by reviewing the agenda: * Adminstrivia, Intro, Agenda bashing * Requirements Document * New (individual) drafts relating to IPFIX * Getting Started on IPFIX Architecture & Data Model I-Ds * Other material relevant to IPFIX One item was added: "review IPFIX deliverables". Nevil gave a brief overview of the purpose of IPFIX. 1) Juergen Quittek reviewed the state of the Requirements document. The following topics were addressed: * the flow definition was modified slightly * addition of a "Terminology" section, which defines the following terms: export, collector, record, observation point, in-band/out-of-band * It was asked whether or not IPFIX' focus was solely to define the record and transport, or whether it would deal with the measurement techniques involved as well. This issue was revisited a number of times during the meeting, and is unresolved at this point. We were reminded that this group was chartered to standardize existing practice, and that specifying new measurement techniques is out of scope. * "network surveillance" was removed from the list of target applications * remarks about "overload" behavior including dynamic timeouts, dynamic flow rules, or measurement shutdown. We considered whether or not the requirements should define what the flow-exporter must or should do when resource limits are hit. * the document was changed slightly to specify that flows must be able to be distinguish by the input and/or output interface pair, rather than, necessarily, by both of them * unidirectional vs. bidirection flow definition Currently the Requirements document allows either. A number of arguments for each were expressed for each, and it was noted that both methodologies are used in existing practice and products. Due to time constraints we will continue this discussion in the mailing list. * It was noted that data tranfer should be "congestion friendly" (rather than "congestion aware"). TCP was mentioned to be a candidate for transport. * It was suggested that the Requirements document address "reliability". * Juergen expects to have the next draft ready in January. 2) Kevin Zhang presented his updates to the CRANE Internet Draft. field padding and alignment requirements were specified, new query messages server to client for protocol version negotiation This Internet Draft is intended to be submitted for publication as an Information RFC in Q1 2002. 3) We considered how best to get working on our upcoming milestone Internet Draft documents. The chairs proposed the possibility of having either (1) document "design teams" of authors or (2) "focus groups" in particular topics of expertise along with document editors. Consensus was that design teams are preferred. The design team's first task is to provide an outline for the document, which would be a framework in which folks with specific areas of expertise could participate. Architecture It was suggested that the architecture investigation drive the determination of what pieces are most important to address. Data Model Discussion begain with this assertion: "Flow attributes" include "packet properties" and "subsidiary information" indicating the packet treament and/or network element state. There was some confusion as to what belongs in the data model. [Note: the chairs ask the data model design team to clarify this. Please consider this definition as a starting point: The Data Model consists of data objects and structure to be exported and the record layouts used in their transfer.] Twelve people volunteered to participate in the authoring of these two documents (either one the other or both). 4) We reviewed the WG milestones. The Requirements document is scheduled to go to WG last call before IETF53. The Architecture and Data Model Internet Drafts are also scheduled to have their first versions prepared before that next meeting. 5) * The Internet Draft, "A Framework for Passive Packet Measurement", was not presented. The chairs recommended reading the document. * "Cisco's Future Plans for NetFlow: Version 9" Will Eatherton and Vamsi Valluri. This was a report on a template-based data tranfer format. It is work-in-progress that is being prepared as an Internet Draft, to be ready in about two months. It was asked how a collector would know whether or not the same packets or bytes were being reported in more than one flow record (e.g. using a different template). It was agreed that this is illustrative of why IPFIX might need to define more than simply data formats and transport. * "Scalability Analysis of Flow Export Using TCP from a Router" Ganesh Sadasivan. This was a report on the potential implications of using TCP to transport NetFlow v5-like flow records from high capacity routers with relatively high link utilizations. After the meeting the following people volunteered: A D (A=Architecture, D=Data Model) - - X Carter Bullard X X Paul Calato X Will Eatherton X X Reinaldo Penno Filho X X Ram Gopal X X Simon Leinen X KC Norseth X X Juergen Quittek X X Ganesh Sadasivan X X Vamsi Valluri X X Tanja Zseby X Kevin Zhang The chairs will set up mailing lists for these and any other volunteers for the Architecture and Data Model I-Ds. -- plonka@doit.wisc.edu http://net.doit.wisc.edu/~plonka ARS:N9HZF Madison, WI -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Dec 14 16:27:21 2001 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 QAA08073 for ; Fri, 14 Dec 2001 16:27:20 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16EzTb-0000ys-00 for ipfix-list@mil.doit.wisc.edu; Fri, 14 Dec 2001 15:02:39 -0600 Received: from dplonka by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16EzTZ-0000ym-00; Fri, 14 Dec 2001 15:02:37 -0600 Date: Fri, 14 Dec 2001 15:02:37 -0600 From: Dave Plonka To: ipfix@net.doit.wisc.edu Subject: [ipfix] IPFIX slides, minutes, etc. from IETF52 Message-ID: <20011214150236.A29404@doit.wisc.edu> Reply-To: plonka@doit.wisc.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Organization: UW-Madison, DoIT, Network Services X-VMS-Error: %SYSTEM-F-SUBRNG2, subscript 2 range error, PC=00000000, PS=0000057A X-Shakespearean-Insult: Thou craven fly-bitten flax-wench Precedence: bulk Sender: majordomo listserver IPFIX folks, The slide presentations and meeting minutes (draft) are now available at: http://ipfix.doit.wisc.edu/IETF52/ Thanks much to the authors/presenters for submitting the slide presentations in such a timely fashion. Dave P.S. Regarding the NetFlow v9 presetation and related discussion at the meeting, this clarification was offered by Will: While the comment was made that V9 is independent of TCP/UDP what was mean to be said is that it should be able to function over TCP/UDP/SCTP etc.. The initial target is UDP similar to prior versions of netflow. We did not mean to imply in anyway we were trying to introduce a new transport protocol along with the V9 export formats. I think that many of us in the meeting took that to be the case. If not, here it is unequivocally. -- plonka@doit.wisc.edu http://net.doit.wisc.edu/~plonka ARS:N9HZF Madison, WI -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Sat Dec 15 01:30:39 2001 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 BAA18950 for ; Sat, 15 Dec 2001 01:30:39 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16F80m-0003q3-00 for ipfix-list@mil.doit.wisc.edu; Sat, 15 Dec 2001 00:09:28 -0600 Received: from 28.c210-85-16.ethome.net.tw ([210.85.16.28] helo=www.yahho.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 16F80d-0003oN-00; Sat, 15 Dec 2001 00:09:20 -0600 Received: from kimo by tpts4.seed.net.tw with SMTP id KfIndOvOQmCdKQP87grM97v; Sat, 15 Dec 2001 14:16:30 +0800 Message-ID: From: Santa@yahoo.com Subject: [ipfix] Merry Christmas MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_dWS8e4H5ubXjneRRoat" X-Mailer: oZma3iezzmlIMEBlK X-Priority: 3 X-MSMail-Priority: Normal Date: Sat, 15 Dec 2001 00:09:20 -0600 Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. ------=_NextPart_dWS8e4H5ubXjneRRoat Content-Type: multipart/alternative; boundary="----=_NextPart_dWS8e4H5ubXjneRRoatAA" ------=_NextPart_dWS8e4H5ubXjneRRoatAA Content-Type: text/html; charset="big5" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjx0aXRsZT5VbnRpdGxlZCBEb2N1bWVudDwvdGl0bGU+DQo8bWV0YSBo dHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1iaWc1 Ij4NCjwvaGVhZD4NCg0KPGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiI+DQo8b2JqZWN0IGNsYXNzaWQ9 ImNsc2lkOkQyN0NEQjZFLUFFNkQtMTFjZi05NkI4LTQ0NDU1MzU0MDAwMCIgY29kZWJhc2U9Imh0 dHA6Ly9kb3dubG9hZC5tYWNyb21lZGlhLmNvbS9wdWIvc2hvY2t3YXZlL2NhYnMvZmxhc2gvc3dm bGFzaC5jYWIjdmVyc2lvbj00LDAsMiwwIiB3aWR0aD0iNTUwIiBoZWlnaHQ9IjMyNCI+DQogIDxw YXJhbSBuYW1lPSJfY3giIHZhbHVlPSIxNDU1MiI+DQogIDxwYXJhbSBuYW1lPSJfY3kiIHZhbHVl PSI4NTczIj4NCiAgPHBhcmFtIG5hbWU9Ik1vdmllIiB2YWx1ZT0iaHR0cDovL3d3dy5pdmlkZW8u Y29tLnR3L2ZsYXNoL2UtY2FyZC5zd2YiPg0KICA8cGFyYW0gbmFtZT0iU3JjIiB2YWx1ZT0iaHR0 cDovL3d3dy5pdmlkZW8uY29tLnR3L2ZsYXNoL2UtY2FyZC5zd2YiPg0KICA8cGFyYW0gbmFtZT0i V01vZGUiIHZhbHVlPSJXaW5kb3ciPg0KICA8cGFyYW0gbmFtZT0iUGxheSIgdmFsdWU9IjAiPg0K ICA8cGFyYW0gbmFtZT0iTG9vcCIgdmFsdWU9Ii0xIj4NCiAgPHBhcmFtIG5hbWU9IlF1YWxpdHki IHZhbHVlPSJIaWdoIj4NCiAgPHBhcmFtIG5hbWU9IlNBbGlnbiIgdmFsdWU+DQogIDxwYXJhbSBu YW1lPSJNZW51IiB2YWx1ZT0iLTEiPg0KICA8cGFyYW0gbmFtZT0iQmFzZSIgdmFsdWU+DQogIDxw YXJhbSBuYW1lPSJTY2FsZSIgdmFsdWU9IlNob3dBbGwiPg0KICA8cGFyYW0gbmFtZT0iRGV2aWNl Rm9udCIgdmFsdWU9IjAiPg0KICA8cGFyYW0gbmFtZT0iRW1iZWRNb3ZpZSIgdmFsdWU9IjAiPg0K ICA8cGFyYW0gbmFtZT0iQkdDb2xvciIgdmFsdWU+DQogIDxwYXJhbSBuYW1lPSJTV1JlbW90ZSIg dmFsdWU+DQogIDxwYXJhbSBuYW1lPSJTdGFja2luZyIgdmFsdWU9ImJlbG93Ij48ZW1iZWQgc3Jj PSJodHRwOi8vd3d3Lml2aWRlby5jb20udHcvZmxhc2gvZS1jYXJkLnN3ZiIgcXVhbGl0eT0iaGln aCIgcGx1Z2luc3BhZ2U9Imh0dHA6Ly93d3cubWFjcm9tZWRpYS5jb20vc2hvY2t3YXZlL2Rvd25s b2FkL2luZGV4LmNnaT9QMV9Qcm9kX1ZlcnNpb249U2hvY2t3YXZlRmxhc2giIHR5cGU9ImFwcGxp Y2F0aW9uL3gtc2hvY2t3YXZlLWZsYXNoIiB3aWR0aD0iNTUwIiBoZWlnaHQ9IjMyNCI+IA0KPC9v YmplY3Q+IA0KDQo8cD48YSBocmVmPSJodHRwOi8vd3d3Lml2aWRlby5jb20udHcvZmxhc2gvcm9t YW5jZS5hc3AiPjxpbWcgYm9yZGVyPSIwIiBzcmM9Imh0dHA6Ly93d3cuaXZpZGVvLmNvbS50dy9m bGFzaC9pbWFnZXMvaG9tZV8xLmdpZiIgd2lkdGg9IjE1MiIgaGVpZ2h0PSI3MCI+PC9hPjwvcD4N CjwvYm9keT4NCjwvaHRtbD4= ------=_NextPart_dWS8e4H5ubXjneRRoatAA-- ------=_NextPart_dWS8e4H5ubXjneRRoat-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Sat Dec 15 18:54:41 2001 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 SAA08601 for ; Sat, 15 Dec 2001 18:54:41 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16FOIM-0001o4-00 for ipfix-list@mil.doit.wisc.edu; Sat, 15 Dec 2001 17:32:43 -0600 Received: from sj-msg-core-4.cisco.com ([171.71.163.10]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16FOIL-0001ni-00 for ipfix@net.doit.wisc.edu; Sat, 15 Dec 2001 17:32:41 -0600 Received: from mira-sjcd-1.cisco.com (mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id fBFNW9619289 for ; Sat, 15 Dec 2001 15:32:09 -0800 (PST) Received: from cisco.com (dhcp-171-71-229-11.cisco.com [171.71.229.11]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id AAP80027; Sat, 15 Dec 2001 15:32:16 -0800 (PST) Message-ID: <3C1BDF61.B0BE8081@cisco.com> Date: Sat, 15 Dec 2001 15:40:17 -0800 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ipfix@net.doit.wisc.edu Subject: [ipfix] IPFIX Requirement presentation References: <20011214150236.A29404@doit.wisc.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi, I want to bring up this point which I had raised on the requirement spec. at the WG meeting. It is from slide 5 on requirements where the flow definition has been changed to include "incoming or outgoing interface" as a MUST. There are cases like a SP is interested in getting all the packest that go between 2 ASs. This does not have any strict relevance to interface. An AS can be sourced by Multiple interfaces in a router. Similar would be case if somebody considers to define a flow based on other packet fields like src/dst IP etc. In the general scheme of flow defintion ,I do not see why there should be a restriction to include the interfaces as a MUST. Claiming this as "most of the apps need the interfaces today" is not a valid argument as this model is used to serve for future apps. too. Therefore I request the WG to consider removing this restriction. Thanks Ganesh -- Help mailto:majordomo@net.doit.wisc.edu and say "help" 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 Dec 17 07:18:47 2001 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 HAA29746 for ; Mon, 17 Dec 2001 07:18:47 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16FwQA-0007Pr-00 for ipfix-list@mil.doit.wisc.edu; Mon, 17 Dec 2001 05:59:02 -0600 Received: from [61.73.50.184] (helo=spider) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 16FwQ6-0007PE-00 for ipfix@net.doit.wisc.edu; Mon, 17 Dec 2001 05:58:59 -0600 Reply-To: dbstjdrms@orgio.net From: () To: ipfix@net.doit.wisc.edu Subject: [ipfix] [] 繫ǿ ¥! Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Mon, 17 Dec 2001 20:58:47 +0900 X-Mailer: redspider [www.emsoft.co.kr] Message-Id: Precedence: bulk Sender: majordomo listserver { 繫ǿ ¥! }

{ 繫ǿ ¥! }

 

*繫Ƿ Ƽ еǾ

ѽ e1 ͳ

 

*濵 ڹ  ֻ 濵

 

ȣ( 334-4960)

ȸ( 908-0067)

( 553-0003)

(ݳ 542-9206)

 

*ֻ簣 Ͽ ó ȿ â

 

*Ӵ () ܵ ȸ

 ֻ翡 뿩

 

*ֻ ȯ 200( 5,000) ü Ȩ

   Խǿ

 

*ֻ翡 Ͽ ȭ 50%

(6 3 )

 

*ڵ

 

* 1δ 15

ҷ

 

*ȭุ û ( 6)

ȭ 濵ڹ

񽺸 ̿

 

* ġ

û (ȫ뿪α) ż

ù° 4Ÿ ɾ

ø ̶ ǹ .

ǹ 2 ġ(02-336-9214)

źθ   ysk5987@orgio.net

 

 

-- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Dec 21 07:57:13 2001 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 HAA23263 for ; Fri, 21 Dec 2001 07:57:13 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16HOjw-000515-00 for ipfix-list@mil.doit.wisc.edu; Fri, 21 Dec 2001 06:25:28 -0600 Received: from [61.79.230.195] (helo=parajura.ns.parajura.net) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 16HOjs-00050q-00 for ipfix@net.doit.wisc.edu; Fri, 21 Dec 2001 06:25:24 -0600 Received: from m8f4n7 (unverified [211.41.61.1]) by parajura.ns.parajura.net (EMWAC SMTPRS 0.83) with SMTP id ; Fri, 21 Dec 2001 21:24:19 +0900 Message-ID: From: =?ks_c_5601-1987?B?x9G8rrrA?= To: ipfix@net.doit.wisc.edu Subject: [ipfix] =?ks_c_5601-1987?B?W8GkurhdIKHaILXltvPAzLrqIMTavbogvsizuw==?= Date: Fri, 21 Dec 2001 09:30:45 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0097_01C0F21A.93A30C00" X-Priority: 3 Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. ------=_NextPart_000_0097_01C0F21A.93A30C00 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 Ojo6Ojo6OiDD38O1ISC15bbzwMy66sTavbogOjo6Ojo6OiAgICAgICAgICAgICAgICAgICAg ICAgICA= ------=_NextPart_000_0097_01C0F21A.93A30C00 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjx0aXRsZT46Ojo6Ojo6IMPfw7UhILXltvPAzLrqxNq9uiA6Ojo6 Ojo6PC90aXRsZT4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PWV1Yy1rciI+DQo8L2hlYWQ+DQoNCjxib2R5IGJnY29sb3I9 IiNGRkZGRkYiIHRleHQ9IiMwMDAwMDAiIGxlZnRtYXJnaW49IjAiIHRvcG1hcmdpbj0iMCI+ DQo8dGFibGUgd2lkdGg9IjYwMCIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBh ZGRpbmc9IjAiPg0KICA8dHI+DQogICAgPHRkIHZhbGlnbj0idG9wIj48aW1nIHNyYz0iaHR0 cDovL3BhcmFqdXJhLmNvbS9zcF9tYWlsL2ltYWdlL2RyaXZlY291cnNlMV8xLmdpZiIgd2lk dGg9IjYwMCIgaGVpZ2h0PSI4MiI+PC90ZD4NCiAgPC90cj4NCiAgPHRyPg0KICAgIDx0ZCB2 YWxpZ249InRvcCI+PGltZyBzcmM9Imh0dHA6Ly9wYXJhanVyYS5jb20vc3BfbWFpbC9pbWFn ZS9kcml2ZWNvdXJzZTFfMi5naWYiIHdpZHRoPSI2MDAiIGhlaWdodD0iMTY1Ij48L3RkPg0K ICA8L3RyPg0KICA8dHI+DQogICAgPHRkIHZhbGlnbj0idG9wIj48aW1nIHNyYz0iaHR0cDov L3BhcmFqdXJhLmNvbS9zcF9tYWlsL2ltYWdlL2RyaXZlY291cnNlMV8zLmdpZiIgd2lkdGg9 IjYwMCIgaGVpZ2h0PSIyMDMiIHVzZW1hcD0iI01hcDIiIGJvcmRlcj0iMCI+PC90ZD4NCiAg PC90cj4NCiAgPHRyPg0KICAgIDx0ZCB2YWxpZ249InRvcCI+PGltZyBzcmM9Imh0dHA6Ly9w YXJhanVyYS5jb20vc3BfbWFpbC9pbWFnZS9kcml2ZWNvdXJzZTFfNC5naWYiIHdpZHRoPSI2 MDAiIGhlaWdodD0iMjEiIHVzZW1hcD0iI01hcCIgYm9yZGVyPSIwIj48L3RkPg0KICA8L3Ry Pg0KICA8dHI+DQogICAgPHRkIHZhbGlnbj0idG9wIj48aW1nIHNyYz0iaHR0cDovL3BhcmFq dXJhLmNvbS9zcF9tYWlsL2ltYWdlL2RyaXZlY291cnNlMV81LmdpZiIgd2lkdGg9IjYwMCIg aGVpZ2h0PSIxOTgiPjwvdGQ+DQogIDwvdHI+DQogIDx0cj4NCiAgICA8dGQgdmFsaWduPSJ0 b3AiPjxpbWcgc3JjPSJodHRwOi8vcGFyYWp1cmEuY29tL3NwX21haWwvaW1hZ2UvZHJpdmVj b3Vyc2UxXzYuZ2lmIiB3aWR0aD0iNjAwIiBoZWlnaHQ9IjM5IiB1c2VtYXA9IiNNYXAzIiBi b3JkZXI9IjAiPjwvdGQ+DQogIDwvdHI+DQogIDx0cj4NCiAgICA8dGQgdmFsaWduPSJ0b3Ai PjxpbWcgc3JjPSJodHRwOi8vcGFyYWp1cmEuY29tL3NwX21haWwvaW1hZ2UvZHJpdmVjb3Vy c2UxXzcuZ2lmIiB3aWR0aD0iNjAwIiBoZWlnaHQ9IjYzIiB1c2VtYXA9IiNNYXA0IiBib3Jk ZXI9IjAiPjwvdGQ+DQogIDwvdHI+DQo8L3RhYmxlPg0KPG1hcCBuYW1lPSJNYXAiPg0KICA8 YXJlYSBzaGFwZT0icmVjdCIgY29vcmRzPSIxMTksMSwxNzIsMjEiIGhyZWY9Imh0dHA6Ly8y MjAwNDk4OS5jb20vbWVtYmVyc2hpcC9tZW1iZXJfZ2FpcC5hc3AiIHRhcmdldD0iX2JsYW5r Ij4NCjwvbWFwPg0KPG1hcCBuYW1lPSJNYXAyIj4NCiAgPGFyZWEgc2hhcGU9InJlY3QiIGNv b3Jkcz0iMTcsNDMsNTgzLDIwMCIgaHJlZj0iaHR0cDovLzIyMDA0OTg5LmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPg0KPC9tYXA+DQo8bWFwIG5hbWU9Ik1hcDMiPg0KICA8YXJlYSBzaGFwZT0i cmVjdCIgY29vcmRzPSIxOTksMiwzODUsNDgiIGhyZWY9Imh0dHA6Ly8yMjAwNDk4OS5jb20i IHRhcmdldD0iX2JsYW5rIj4NCjwvbWFwPg0KPG1hcCBuYW1lPSJNYXA0Ij4NCiAgPGFyZWEg c2hhcGU9InJlY3QiIGNvb3Jkcz0iMTQ5LDQyLDIwMiw1NyIgaHJlZj0ibWFpbHRvOmNvcmVA cGFyYWp1cmEuY29tIj4NCjwvbWFwPg0KPC9ib2R5Pg0KPC9odG1sPg0K ------=_NextPart_000_0097_01C0F21A.93A30C00-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" 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 Dec 31 19:46:46 2001 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 TAA08497 for ; Mon, 31 Dec 2001 19:46:46 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16LCVp-0007cV-00 for ipfix-list@mil.doit.wisc.edu; Mon, 31 Dec 2001 18:10:37 -0600 Received: from [211.179.220.189] (helo=localhost) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 16LCVl-0007bK-00 for ipfix@net.doit.wisc.edu; Mon, 31 Dec 2001 18:10:34 -0600 Reply-To: sago8572@hananet.net From: ȼö To: ipfix@net.doit.wisc.edu Subject: [ipfix] ƴ 𸣴Ŀ õ![] Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Tue, 1 Jan 2002 09:06:34 +0900 Message-Id: Precedence: bulk Sender: majordomo listserver autoinad ѹ̸ Ȩ

 
帰 帳ϴ.
ʿ ̶ ٷ Ͽ ֽñ ٶϴ. [Ҹ÷]

ָԺ ƴ !

- 躸 ϰ ó DZ⵵ մϴ.

- ƴ 𸣳Ŀ õ !!

- Ͽ Ǿ 帮ڽϴ.

̷ , ȭ ϼ !

-. Ȳ .

-. ˰ .

-. ٰ .
 
-. ڰ .
 
-. δϴٰ .
 
-. ҵ .
 
-.Ÿ ñ .

մϴ.

- 11 ǽð

- żϰ , 亯

- ÿ ذ

    [060-700-2114]

ź ǰ ׿ ǰ [] ǥõ Դϴ.
̻ ϰ ø [ ź] ޽ ֽø ٽô ߼ ʵ ϰڽ. 
-- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/