From majordomo@mil.doit.wisc.edu Tue Aug 6 10:55:57 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13924 for ; Tue, 6 Aug 2002 10:55:57 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17c5RY-0004Vh-00 for ipfix-list@mil.doit.wisc.edu; Tue, 06 Aug 2002 09:36:16 -0500 Received: from dplonka by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17c5RV-0004Vb-00 for ipfix@net.doit.wisc.edu; Tue, 06 Aug 2002 09:36:13 -0500 Date: Tue, 6 Aug 2002 09:36:13 -0500 From: Dave Plonka To: ipfix@net.doit.wisc.edu Subject: [ipfix] I-D ACTION:draft-ietf-ipfix-reqs-05.txt Message-ID: <20020806093613.A16694@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-OBSOLETE_6, obsolete message 6 X-Shakespearean-Insult: Thou tottering tardy-gaited hugger-mugger Precedence: bulk Sender: majordomo listserver IPFIX folks, Below please find the announcement regarding the availability of the updated requirements draft. The following links to it now appear in the IPFIX web site index: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reqs-05.txt http://ipfix.doit.wisc.edu/req/draft-ietf-ipfix-reqs-05.txt Dave ----- Forwarded message from owner-ipfix@net.doit.wisc.edu ----- To: IETF-Announce: ; Cc: ipfix@net.doit.wisc.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipfix-reqs-05.txt Date: Fri, 02 Aug 2002 08:06:00 -0400 Sender: nsyracus@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : Requirements for IP Flow Information Export Author(s) : J. Quittek et al. Filename : draft-ietf-ipfix-reqs-05.txt Pages : 28 Date : 01-Aug-02 This memo defines requirements for the export of measured IP flow information out of routers, traffic measurement probes and middleboxes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reqs-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipfix-reqs-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipfix-reqs-05.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020801153308.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipfix-reqs-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipfix-reqs-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020801153308.I-D@ietf.org> --OtherAccess-- --NextPart-- ----- End forwarded message ----- -- plonka@doit.wisc.edu http://net.doit.wisc.edu/~plonka ARS:N9HZF Madison, WI -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Aug 6 18:55:40 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02812 for ; Tue, 6 Aug 2002 18:55:39 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17cD0x-0000Yh-00 for ipfix-list@mil.doit.wisc.edu; Tue, 06 Aug 2002 17:41:19 -0500 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17cD0u-0000Xu-00 for ipfix@net.doit.wisc.edu; Tue, 06 Aug 2002 17:41:16 -0500 Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g76MejU44641 for ; Wed, 7 Aug 2002 00:40:45 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.31] (unknown [192.168.102.31]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id A256959AD3 for ; Wed, 7 Aug 2002 00:40:43 +0200 (CEST) Date: Wed, 07 Aug 2002 00:40:40 +0200 From: Juergen Quittek To: ipfix@net.doit.wisc.edu Subject: [ipfix] changes in draft-ietf-ipfix-reqs-05.txt Message-ID: <18455717.1028680840@[192.168.102.31]> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi all, Below please find a list of changes in draft-ietf-ipfix-reqs-05.txt compared to version -04. Several further editorial modification are not listed. You can see that the list of changes is rather short and it does not include major issues anymore. I think that the document is quite stable now and mature enough for entering WG last call. 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 - Section 2.1: added reference for BGP in item 3 - changed Section 2.2, paragraph 2 to: "Note that one observation point may be a superset of several other observation points. For example one observation point can be an entire line card. This would be the superset of the individual observation points at the line card's interfaces." - Section 3.4: - replaced inrusive/non-intrisuve by active/passive - added a note on synomyms active/passive - intrusive/non-intrusive - observed/synthethic - "packet events" -> "flow records and/or notifications on specific events" - Section 4, paragraph 4: "distinguishing a flow in a particular measurement" -> "distinguishing flows". - inserted new Section 5.7. Multicast Flows: "For multicast flows containing packets replicated to multiple output interfaces, the metering process SHOULD be able to maintain discrete flow records per different output interface. For example, the metering process SHOULD be able to report an incoming multicast packet that is replicated to four output interfaces in four different flow records that differ by the output interface." - Section 6.1. Information model: - item 8. output interface (ifIndex): removed "This requirement does not apply in case of multicast flow records." - inserted new SHOULD section between MUST and MAY: "The exporting process SHOULD be able to report the following attributes for each measured flow: - and moved attribute 'multicast replication factor' from MAY section to SHOULD section (and added a sentence): "20. multicast replication factor the number of outgoing packets originating from a single incoming multicast packet. This is a dynamic property of multicast flows, that may change over time. For unicast flows it has the constant value 1." - removed attribute 'list of output interfaces for a multicast flow' from the MAY section. - Section 6.2. Data Model: "MAY be flexible" -> "MUST be flexible" - Section 7.2, item 1. (configure reporting data format): "SHOULD" -> "MUST" - section 9: "higher aggregated flows and exports the resulting flows" -> "more aggregated flow records, and exports them" -- Help mailto:majordomo@net.doit.wisc.edu and say "help" 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 Aug 6 23:24:38 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09842 for ; Tue, 6 Aug 2002 23:24:37 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17cHGB-0006ey-00 for ipfix-list@mil.doit.wisc.edu; Tue, 06 Aug 2002 22:13:19 -0500 Received: from mailhost2.auckland.ac.nz ([130.216.1.4]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17cHG7-0006eq-00 for ipfix-eval@net.doit.wisc.edu; Tue, 06 Aug 2002 22:13:15 -0500 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 PAA15222 for ; Wed, 7 Aug 2002 15:13:13 +1200 (NZST) Received: from postbox.auckland.ac.nz (postbox.auckland.ac.nz [130.216.191.126]) by mailhost.auckland.ac.nz (Mirapoint Messaging Server MOS 3.1.0.58-GA) with ESMTP id AGF37526; Wed, 7 Aug 2002 15:13:12 +1200 (NZST) Received: from localhost (hotlava.auckland.ac.nz [130.216.191.123]) by postbox.auckland.ac.nz (8.11.6/8.11.6) with ESMTP id g773DCY14570 for ; Wed, 7 Aug 2002 15:13:12 +1200 Received: from nebbiolo.itss.auckland.ac.nz (nebbiolo.itss.auckland.ac.nz [130.216.4.167]) by hotlava.auckland.ac.nz (IMP) with HTTP for ; Wed, 7 Aug 2002 15:13:12 +1200 Message-ID: <1028689992.3d50904895a77@hotlava.auckland.ac.nz> Date: Wed, 7 Aug 2002 15:13:12 +1200 From: Nevil Brownlee To: ipfix-eval@net.doit.wisc.edu Subject: [ipfix-eval] IPFIX Evaluation: update MIME-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-Originating-IP: 130.216.4.167 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hello all: At the IPFIX meeting in Yokohama we reached consensus on the evaluation process, with the following timetable: 5 July Publish Protocol Advocacy draft and Call for Submissions 15 July Work on consensus in Yokohama, agree on timetable 2 September Cutoff for Protocol Submissions to Evaluation Team Advocacy drafts published 16 October Evaluation team publishes preliminary Evaluation draft for discussion on list 2 November Evaluation draft submitted as WG draft 22 November Evaluation Draft discussed at Atlanta meeting WG last call In the days following the meeting we (Dave/Nevil/Juergen) discussed how we'd manage the publication of advocay drafts, and came up with this as a proposal: * Advocates announce themselves on the list via the IPFIX-EVAL alias, any time up to 2 September. * Advocates publish Advocay drafts themselves, as soon as they have their -00.txt ready. These drafts will be 'individual' submissions, with names like draft-author-ipfix-eval-protocol-00.txt, e.g. draft-claise-ipfix-eval-netflow-00.txt. * Discussion of the advocacy drafts on IPFIX-EVAL . Advocates may published revised versions of their advocacy drafts at any time up to 16 October. * Evaluation team publish -00.txt version of the Evaluation draft. Discussed on IPFIX-EVAL list. * Rest of timetable continues as above. So far, we have three protocols with declared advocates: CRANE Kevin Zhang LFAP v5 Paul Calato NetFlow v9 Benoit Claise We will also have an advocate for DIAMETER. If you are interested in advocating for any other protocol, please have a look at the material in http://ipfix.doit.wisc.edu/eval/ Cheers, Nevil ----------------------------------------------------------------------- Nevil Brownlee Director, Technology Development Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Aug 7 07:39:57 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13475 for ; Wed, 7 Aug 2002 07:39:52 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17cOEm-00034f-00 for ipfix-list@mil.doit.wisc.edu; Wed, 07 Aug 2002 05:40:20 -0500 Received: from mailhub.fokus.gmd.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17cOEk-00034V-00 for ipfix@net.doit.wisc.edu; Wed, 07 Aug 2002 05:40:18 -0500 Received: from fokus.gmd.de (dhcp229 [195.37.78.229]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g77AeGW13930; Wed, 7 Aug 2002 12:40:16 +0200 (MEST) Message-ID: <3D50F8BB.7060107@fokus.gmd.de> Date: Wed, 07 Aug 2002 12:38:51 +0200 From: Sebastian Zander Organization: Fraunhofer FOKUS User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: de-DE MIME-Version: 1.0 To: ipfix@net.doit.wisc.edu CC: Nevil Brownlee , Dave Plonka Subject: [ipfix] DIAMETER as IPFIX protocol candidate Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi, I will advocate the DIAMETER protocol. DIAMETER is the protocol developed by the AAA WG. The latest DIAMETER draft is: http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-12.txt In case someone from the AAA folks want to join please contact me. Anyway I will ask on the AAA list again. Cheers, Sebastian -- Sebastian Zander E-mail: zander@fokus.fhg.de FhI FOKUS / Global Networking (GloNe) Tel: +49-30-3463-7287 Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 D-10589 Berlin, Germany www.fokus.fhg.de/usr/sebastian.zander -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Sat Aug 10 01:15:01 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21153 for ; Sat, 10 Aug 2002 01:15:01 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17dOEt-0006TJ-00 for ipfix-list@mil.doit.wisc.edu; Fri, 09 Aug 2002 23:52:35 -0500 Received: from palrel12.hp.com ([156.153.255.237]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17dOEq-0006TB-00 for ipfix-eval@net.doit.wisc.edu; Fri, 09 Aug 2002 23:52:32 -0500 Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel12.hp.com (Postfix) with ESMTP id 702DAE00525; Fri, 9 Aug 2002 21:52:31 -0700 (PDT) Received: from simail.cup.hp.com (imail@sim.cup.hp.com [15.16.123.26]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id VAA26554; Fri, 9 Aug 2002 21:52:26 -0700 (PDT) Received: from cup.hp.com ([15.244.160.113]) by simail.cup.hp.com (InterMail vM.5.01.03.01 201-253-122-118-101-20010319) with ESMTP id <20020810051836.EVZW18196.simail.cup.hp.com@cup.hp.com>; Fri, 9 Aug 2002 22:18:36 -0700 Message-ID: <3D549BE8.3020709@cup.hp.com> Date: Fri, 09 Aug 2002 21:51:52 -0700 From: Jeff Meyer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: ipfix-eval@net.doit.wisc.edu Cc: protocol@ipdr.metratech.com Subject: [ipfix-eval] Streaming IPDR as a protocol candidate Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi, I will advocate the use of Streaming IPDR as a protocol candidate to address IPFIX requirements. The current draft of the protocol specification is available at: http://www.ipdr.org/documents/ipfix I will be moving this over as an IETF draft in the next week. Regards, Jeff Meyer Hewlett-Packard -- Help mailto:majordomo@net.doit.wisc.edu and say "help" 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 Aug 10 19:57:46 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20813 for ; Sat, 10 Aug 2002 19:57:45 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17dfwS-0003YZ-00 for ipfix-list@mil.doit.wisc.edu; Sat, 10 Aug 2002 18:46:44 -0500 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17dfwQ-0003Xv-00 for ipfix@net.doit.wisc.edu; Sat, 10 Aug 2002 18:46:42 -0500 Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g7ANk9U05374 for ; Sun, 11 Aug 2002 01:46:09 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.31] (unknown [192.168.102.31]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id CC4695A5A2 for ; Sun, 11 Aug 2002 01:46:06 +0200 (CEST) Date: Sun, 11 Aug 2002 01:46:04 +0200 From: Juergen Quittek To: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] changes in draft-ietf-ipfix-reqs-05.txt Message-ID: <98180265.1029030363@[192.168.102.31]> In-Reply-To: <18455717.1028680840@[192.168.102.31]> References: <18455717.1028680840@[192.168.102.31]> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi all, --On 07 August 2002 00:40 +0200 Juergen Quittek wrote: > Hi all, > > Below please find a list of changes in draft-ietf-ipfix-reqs-05.txt compared to version -04. Several further editorial modification are > not listed. > > You can see that the list of changes is rather short and it does > not include major issues anymore. I think that the document is Maybe this statement is not true yet. There is the issue raised by Carter (and supported by Benoit) on using MUST or SHOULD or MAY for the ability of the exporting process to report the output interface of a flow. Let's solve this issue first. Juergen > quite stable now and mature enough for entering WG last call. > > 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 > > > - Section 2.1: > added reference for BGP in item 3 > > - changed Section 2.2, paragraph 2 to: > "Note that one observation point may be a superset of several > other observation points. For example one observation point can > be an entire line card. This would be the superset of the > individual observation points at the line card's interfaces." > > - Section 3.4: > - replaced inrusive/non-intrisuve by active/passive > - added a note on synomyms active/passive - > intrusive/non-intrusive - observed/synthethic > - "packet events" -> "flow records and/or > notifications on specific events" > > - Section 4, paragraph 4: > "distinguishing a flow in a particular measurement" > -> "distinguishing flows". > > - inserted new Section 5.7. Multicast Flows: > "For multicast flows containing packets replicated to multiple > output interfaces, the metering process SHOULD be able to > maintain discrete flow records per different output interface. > For example, the metering process SHOULD be able to report > an incoming multicast packet that is replicated to four output > interfaces in four different flow records that differ by the > output interface." > > - Section 6.1. Information model: > - item 8. output interface (ifIndex): > removed "This requirement does not apply in case of multicast > flow records." > - inserted new SHOULD section between MUST and MAY: > "The exporting process SHOULD be able to report the following > attributes for each measured flow: > - and moved attribute 'multicast replication factor' from MAY > section to SHOULD section (and added a sentence): > "20. multicast replication factor > the number of outgoing packets originating from a single > incoming multicast packet. This is a dynamic property > of multicast flows, that may change over time. For > unicast flows it has the constant value 1." > - removed attribute 'list of output interfaces for a multicast > flow' from the MAY section. > > - Section 6.2. Data Model: > "MAY be flexible" -> "MUST be flexible" > > - Section 7.2, item 1. (configure reporting data format): > "SHOULD" -> "MUST" > > - section 9: > "higher aggregated flows and exports the resulting flows" > -> "more aggregated flow records, and exports them" > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Sat Aug 10 21:22:19 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22351 for ; Sat, 10 Aug 2002 21:22:18 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17dhHj-0005YR-00 for ipfix-list@mil.doit.wisc.edu; Sat, 10 Aug 2002 20:12:47 -0500 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17dhHh-0005Xl-00 for ipfix-req@net.doit.wisc.edu; Sat, 10 Aug 2002 20:12:45 -0500 Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g7B1BtU06848; Sun, 11 Aug 2002 03:11:55 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.31] (unknown [192.168.102.31]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 3DAEA5A5AF; Sun, 11 Aug 2002 03:11:51 +0200 (CEST) Date: Sun, 11 Aug 2002 03:11:48 +0200 From: Juergen Quittek To: Benoit Claise , Carter Bullard Cc: ipfix-req@net.doit.wisc.edu Subject: Re: [ipfix-req] Section regarding multicast flows Message-ID: <103324062.1029035508@[192.168.102.31]> In-Reply-To: <3D4682F2.40605@cisco.com> References: <3D4682F2.40605@cisco.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Carter and Benoit, --On 30 July 2002 14:13 +0200 Benoit Claise wrote: > Carter, > >> Hey Beniot, >> In cases where there are valid exceptions to a >> requirement candidate, a MUST generally converts to >> a SHOULD or OPTIONAL. One reason for this is >> you don't want to have to identify and manage >> the complete list of possible exceptions during the >> life of the RFC. You already have exceptions for >> certain types of IPFIX devices and specific types >> of traffic that don't require egress interface >> reporting. That on its own might suggest that I think there is only one exception like that in section 6.1.-8. saying that a probe does not need to have the ability of reporting the output interface. Please note that the same exception holds for the input interface. >> egress interface reporting should be OPTIONAL >> in the Data Model. But if that is not compelling, >> we may need to add more exceptions to the list than >> are already there. Since the exception is the same for input and output interface, we would consequently have to make the input interface OPTIONAL as well, if we follow your argument. >> I can think of a few more types of traffic where >> egress interface reporting may be challenging, such as >> flow reporting under flap conditions, load balanced >> traffic >> > You have 2 good examples here. > Flap conditions and load balancing affect the input interface as well as the output interface. >> and port mirrored traffic. In switches, I do not see your point concerning port mirrored traffic. >> broadcast traffic generates the same problem set as >> multicast traffic. Also many switches, when presented >> with some arp table issues, will broadcast unicast >> datagrams to all interfaces. Should the multiple egress >> interfaces be reported in this case? That condition Yes, if I configured the metering process in this way, I would expect this. However, it might not be a good idea to configure it this way. >> would persist, ideally, for only a few packets. Do >> you generate multiple flow reports, one for the >> broadcasted set of packets, and then one for the non >> broadcasted flow? Same answer. > Well, for switches (layer 2 devices) I think that we shouldn't report any flow records. > Only the layer 3 devices should. > >> >> One issue that comes up when considering multicast >> egress interface reporting is that in most vendors >> multicast implementations the multicast traffic is >> delivered to every egress interface through hardware >> broadcast, and then output filters decide whether to >> forward the packet or not. How does this generalize >> in the IPFIX egress interface reporting strategy? Wouldn'n these filters be a great location for collecting multicast flow information? They anyway maintain a list of multicast flows. The requirements suggest to collect multicast information saparately for each egress. (And it uses only SHOULD, not MUST for multicast traffic.) >> Does the IPFIX Data Model need to understand egress >> interface filtering behavior for all traffic types >> or just multicast? This heavily depends on the list of traffic types for which egress filtring is used. I guess you don't use it for TCP. >> It may be easier to just make egress interface >> reporting an OPTIONAL feature, and then see if >> any vendors can successfully implement it. This holds for most of the requirements. But following your arguments: The multicast case is not OPTIONAL, but SHOULD in the current reuqirements. So, if a vendor faces serious problems implementing it, the vendor will drop it. Here we have already what you are asking for. All other arguments apply as well to the input interface. But you ar not proposing to make this OPTIONAL. I think one important point behind your arguments is that from a router architecture point of view, the most obvious pace to locate the observation point and the metering process is at the input interface, because similar funtionality is required at this location anyway. But when doing so it is not always easy to find otu the output interface. If a vendor locates the observation points at the output interface (what I do not necessarily expect), then it might face the inverse problem of not necessarily knowing the input interface. Like Benoit below, I also would like to have more opinions on the issue how far the clearly existing requirements by metering applications should be loosened in the IPFIX requirements document because of assumed limitations of today's router architecture? Juergen >> > You've got a valid point.Why not a SHOULD? > > SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course. > > Any other opinion? > > Regards, Benoit. > >> >> >> Carter >> >> Carter Bullard >> QoSient, LLC >> 300 E. 56th Street >> Suite 18K >> New York, New York 10022 >> >> +1 212 588-9133 Phone >> +1 212 588-9134 Fax >> >> >> >>> -----Original Message----- >>> From: majordomo listserver >>> [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Benoit Claise >>> Sent: Friday, July 26, 2002 4:21 AM >>> To: ipfix-req@net.doit.wisc.edu >>> Subject: [ipfix-req] Section regarding multicast flows >>> >>> >>> >>> >>> Dave and All, >>> >>> Trying to incorporate all the proposed changes discussed both >>> at the IETF meeting and on the mailing list in the new >>> requirement draft version, >>> I think that we should add a new section on multicast >>> >>> 5.7 Multicast Flows >>> >>> For a multicast packet replicated to multiple output >>> interfaces, the metering >>> process SHOULD maintain discrete flow records per different >>> egress ifIndexes. For example an incoming multicast packet >>> that is replicated to four output interfaces would be >>> reported in four different flow records that differ by the >>> output interface. In case the metering process doesn't >>> maintain and report discrete flow records >>> per different egress ifIndexes for a multicast flow, the >>> metering process >>> SHOULD export the multicast replication factor in the flow record. >>> >>> >>> Furthermore, some extra changes are needed >>> The requirement draft was saying: >>> >>> 6.1. Information Model >>> ... >>> The exporting process MUST be able to report the >>> following attributes >>> for each measured flow: >>> ... >>> 8. output interface (ifIndex) >>> This requirement does not apply if the observation point is >>> located at a probe device. This requirement does not apply >>> in case of multicast flow records. >>> ... >>> The exporting process MAY be able to report the following >>> attributes >>> for each measured flow: >>> ... >>> 25. multicast replication factor >>> the number of outgoing packets originating from a single >>> incoming multicast packet >>> >>> 26. list of output interfaces for a multicast flow >>> >>> >>> I would propose: >>> >>> 6.1. Information Model >>> ... >>> The exporting process MUST be able to report the >>> following attributes >>> for each measured flow: >>> ... >>> 8. output interface (ifIndex) >>> This requirement does not apply if the observation point is >>> located at a probe device. _(ATTENTION: I REMOVED THE >>> LINE ABOUT MULTICAST)_ >>> ... >>> The exporting process _SHOULD_ be able to report the >>> following attributes >>> for each measured flow: >>> ... >>> X. multicast replication factor >>> The number of outgoing packets originating from a single >>> incoming multicast packet. This _multicast_ replication >>> factor SHOULD be reported, >>> but only SHOULD if the list of output interfaces for this >>> multicast >>> flow is not reported. >>> >>> _X+1. list of output interfaces for a multicast flow _(I >>> WOULD REMOVE IT >>> BECAUSE THIS IS EXPLAINED IN THE MULTICAST FLOW SECTION >>> AND THE LIMITATION >>> IN THE OUTPUT INTERFACE SECTION ABOVE IS REMOVED) >>> >>> >>> What do you think? >>> >>> Regards, Benoit >>> >>> >>> >>> >>> -- >>> Help mailto:majordomo@net.doit.wisc.edu and say "help" >>> in message body >>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>> "unsubscribe ipfix" in message body >>> Archive http://ipfix.doit.wisc.edu/archive/ >>> >>> >>> >>> >> >> >> >> -- >> Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body >> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >> "unsubscribe ipfix" in message body >> Archive http://ipfix.doit.wisc.edu/archive/ >> >> > > > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" 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 Aug 13 10:05:25 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12586 for ; Tue, 13 Aug 2002 10:05:25 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17ec1d-0001tW-00 for ipfix-list@mil.doit.wisc.edu; Tue, 13 Aug 2002 08:47:57 -0500 Received: from [64.95.122.60] (helo=RS-SC-EXC4.rs.riverstonenet.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17ec1b-0001sq-00 for ipfix-req@net.doit.wisc.edu; Tue, 13 Aug 2002 08:47:55 -0500 Received: from riverstonenet.com ([134.141.180.85]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 13 Aug 2002 06:47:20 -0700 Message-ID: <3D590D8A.7B546C0E@riverstonenet.com> Date: Tue, 13 Aug 2002 09:45:46 -0400 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Quittek CC: Benoit Claise , Carter Bullard , ipfix-req@net.doit.wisc.edu Subject: Re: [ipfix-req] Section regarding multicast flows References: <3D4682F2.40605@cisco.com> <103324062.1029035508@[192.168.102.31]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Aug 2002 13:47:21.0437 (UTC) FILETIME=[F286A8D0:01C242CF] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Conceptual issues tend to cause more problems in the future than ones of practicality. I don't see a conceptual problem here. I think the SHOULD and MUST of what data to report ought to refelect today's technology and technology of the near future. Given that, our designations for input and output interface reporting seem reasonable to me. Paul Juergen Quittek wrote: > > Carter and Benoit, > > --On 30 July 2002 14:13 +0200 Benoit Claise wrote: > > > Carter, > > > >> Hey Beniot, > >> In cases where there are valid exceptions to a > >> requirement candidate, a MUST generally converts to > >> a SHOULD or OPTIONAL. One reason for this is > >> you don't want to have to identify and manage > >> the complete list of possible exceptions during the > >> life of the RFC. You already have exceptions for > >> certain types of IPFIX devices and specific types > >> of traffic that don't require egress interface > >> reporting. That on its own might suggest that > > I think there is only one exception like that in > section 6.1.-8. saying that a probe does not need > to have the ability of reporting the output interface. > Please note that the same exception holds for the > input interface. > > >> egress interface reporting should be OPTIONAL > >> in the Data Model. But if that is not compelling, > >> we may need to add more exceptions to the list than > >> are already there. > > Since the exception is the same for input and output > interface, we would consequently have to make the input > interface OPTIONAL as well, if we follow your argument. > > >> I can think of a few more types of traffic where > >> egress interface reporting may be challenging, such as > >> flow reporting under flap conditions, load balanced > >> traffic > >> > > You have 2 good examples here. > > > > Flap conditions and load balancing affect the > input interface as well as the output interface. > > >> and port mirrored traffic. In switches, > > I do not see your point concerning port mirrored traffic. > > >> broadcast traffic generates the same problem set as > >> multicast traffic. Also many switches, when presented > >> with some arp table issues, will broadcast unicast > >> datagrams to all interfaces. Should the multiple egress > >> interfaces be reported in this case? That condition > > Yes, if I configured the metering process in this way, > I would expect this. However, it might not be a good idea > to configure it this way. > > >> would persist, ideally, for only a few packets. Do > >> you generate multiple flow reports, one for the > >> broadcasted set of packets, and then one for the non > >> broadcasted flow? > > Same answer. > > > Well, for switches (layer 2 devices) I think that we shouldn't report any flow records. > > Only the layer 3 devices should. > > > >> > >> One issue that comes up when considering multicast > >> egress interface reporting is that in most vendors > >> multicast implementations the multicast traffic is > >> delivered to every egress interface through hardware > >> broadcast, and then output filters decide whether to > >> forward the packet or not. How does this generalize > >> in the IPFIX egress interface reporting strategy? > > Wouldn'n these filters be a great location for collecting > multicast flow information? They anyway maintain a list > of multicast flows. The requirements suggest to > collect multicast information saparately for each egress. > (And it uses only SHOULD, not MUST for multicast traffic.) > > >> Does the IPFIX Data Model need to understand egress > >> interface filtering behavior for all traffic types > >> or just multicast? > > This heavily depends on the list of traffic types for > which egress filtring is used. I guess you don't use it > for TCP. > > >> It may be easier to just make egress interface > >> reporting an OPTIONAL feature, and then see if > >> any vendors can successfully implement it. > > This holds for most of the requirements. > But following your arguments: The multicast case > is not OPTIONAL, but SHOULD in the current reuqirements. > So, if a vendor faces serious problems implementing it, > the vendor will drop it. Here we have already what you > are asking for. > > All other arguments apply as well to the input interface. > But you ar not proposing to make this OPTIONAL. > > I think one important point behind your arguments is > that from a router architecture point of view, the most > obvious pace to locate the observation point and the metering > process is at the input interface, because similar funtionality > is required at this location anyway. But when doing so it is > not always easy to find otu the output interface. > > If a vendor locates the observation points at the output > interface (what I do not necessarily expect), then it might > face the inverse problem of not necessarily knowing the > input interface. > > Like Benoit below, I also would like to have more opinions > on the issue how far the clearly existing requirements by > metering applications should be loosened in the IPFIX > requirements document because of assumed limitations of > today's router architecture? > > Juergen > > >> > > You've got a valid point.Why not a SHOULD? > > > > SHOULD This word, or the adjective "RECOMMENDED", mean that there > > may exist valid reasons in particular circumstances to ignore a > > particular item, but the full implications must be understood and > > carefully weighed before choosing a different course. > > > > Any other opinion? > > > > Regards, Benoit. > > > >> > >> > >> Carter > >> > >> Carter Bullard > >> QoSient, LLC > >> 300 E. 56th Street > >> Suite 18K > >> New York, New York 10022 > >> > >> +1 212 588-9133 Phone > >> +1 212 588-9134 Fax > >> > >> > >> > >>> -----Original Message----- > >>> From: majordomo listserver > >>> [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Benoit Claise > >>> Sent: Friday, July 26, 2002 4:21 AM > >>> To: ipfix-req@net.doit.wisc.edu > >>> Subject: [ipfix-req] Section regarding multicast flows > >>> > >>> > >>> > >>> > >>> Dave and All, > >>> > >>> Trying to incorporate all the proposed changes discussed both > >>> at the IETF meeting and on the mailing list in the new > >>> requirement draft version, > >>> I think that we should add a new section on multicast > >>> > >>> 5.7 Multicast Flows > >>> > >>> For a multicast packet replicated to multiple output > >>> interfaces, the metering > >>> process SHOULD maintain discrete flow records per different > >>> egress ifIndexes. For example an incoming multicast packet > >>> that is replicated to four output interfaces would be > >>> reported in four different flow records that differ by the > >>> output interface. In case the metering process doesn't > >>> maintain and report discrete flow records > >>> per different egress ifIndexes for a multicast flow, the > >>> metering process > >>> SHOULD export the multicast replication factor in the flow record. > >>> > >>> > >>> Furthermore, some extra changes are needed > >>> The requirement draft was saying: > >>> > >>> 6.1. Information Model > >>> ... > >>> The exporting process MUST be able to report the > >>> following attributes > >>> for each measured flow: > >>> ... > >>> 8. output interface (ifIndex) > >>> This requirement does not apply if the observation point is > >>> located at a probe device. This requirement does not apply > >>> in case of multicast flow records. > >>> ... > >>> The exporting process MAY be able to report the following > >>> attributes > >>> for each measured flow: > >>> ... > >>> 25. multicast replication factor > >>> the number of outgoing packets originating from a single > >>> incoming multicast packet > >>> > >>> 26. list of output interfaces for a multicast flow > >>> > >>> > >>> I would propose: > >>> > >>> 6.1. Information Model > >>> ... > >>> The exporting process MUST be able to report the > >>> following attributes > >>> for each measured flow: > >>> ... > >>> 8. output interface (ifIndex) > >>> This requirement does not apply if the observation point is > >>> located at a probe device. _(ATTENTION: I REMOVED THE > >>> LINE ABOUT MULTICAST)_ > >>> ... > >>> The exporting process _SHOULD_ be able to report the > >>> following attributes > >>> for each measured flow: > >>> ... > >>> X. multicast replication factor > >>> The number of outgoing packets originating from a single > >>> incoming multicast packet. This _multicast_ replication > >>> factor SHOULD be reported, > >>> but only SHOULD if the list of output interfaces for this > >>> multicast > >>> flow is not reported. > >>> > >>> _X+1. list of output interfaces for a multicast flow _(I > >>> WOULD REMOVE IT > >>> BECAUSE THIS IS EXPLAINED IN THE MULTICAST FLOW SECTION > >>> AND THE LIMITATION > >>> IN THE OUTPUT INTERFACE SECTION ABOVE IS REMOVED) > >>> > >>> > >>> What do you think? > >>> > >>> Regards, Benoit > >>> > >>> > >>> > >>> > >>> -- > >>> Help mailto:majordomo@net.doit.wisc.edu and say "help" > >>> in message body > >>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > >>> "unsubscribe ipfix" in message body > >>> Archive http://ipfix.doit.wisc.edu/archive/ > >>> > >>> > >>> > >>> > >> > >> > >> > >> -- > >> Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > >> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > >> "unsubscribe ipfix" in message body > >> Archive http://ipfix.doit.wisc.edu/archive/ > >> > >> > > > > > > > > > > -- > > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > "unsubscribe ipfix" in message body > > Archive http://ipfix.doit.wisc.edu/archive/ > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Aug 15 20:56:16 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21686 for ; Thu, 15 Aug 2002 20:56:16 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17fVAt-0001PC-00 for ipfix-list@mil.doit.wisc.edu; Thu, 15 Aug 2002 19:41:11 -0500 Received: from pool-129-44-37-106.ny325.east.verizon.net ([129.44.37.106] helo=newyork.qosient.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17fVAq-0001P2-00 for ipfix-req@net.doit.wisc.edu; Thu, 15 Aug 2002 19:41:08 -0500 Received: from sphynx (sphynx [192.168.0.64]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id g7G0f2N28884; Thu, 15 Aug 2002 20:41:03 -0400 From: "Carter Bullard" To: "'Juergen Quittek'" , "'Benoit Claise'" Cc: Subject: RE: [ipfix-req] Section regarding multicast flows Date: Thu, 15 Aug 2002 20:40:54 -0400 Message-ID: <5C8959A16A71B449AE793CF52FBBED6607A431@ptah.newyork.qosient.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <5C8959A16A71B449AE793CF52FBBED6609EB5B@ptah.newyork.qosient.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Gentle people, This is pretty long, I do hope that some find it useful. Carter > >> In cases where there are valid exceptions to a > >> requirement candidate, a MUST generally converts to > >> a SHOULD or OPTIONAL. One reason for this is > >> you don't want to have to identify and manage > >> the complete list of possible exceptions during the > >> life of the RFC. You already have exceptions for > >> certain types of IPFIX devices and specific types > >> of traffic that don't require egress interface > >> reporting. That on its own might suggest that > > I think there is only one exception like that in > section 6.1.-8. saying that a probe does not need > to have the ability of reporting the output interface. > Please note that the same exception holds for the > input interface. From the perspective of a monitor that is internal to a switch or a router, the input interface identifier is historical and factual. The output interface identifier is always a predicted value, and as a result, a guess. > > >> egress interface reporting should be OPTIONAL > >> in the Data Model. But if that is not compelling, > >> we may need to add more exceptions to the list than > >> are already there. > > Since the exception is the same for input and output > interface, we would consequently have to make the input > interface OPTIONAL as well, if we follow your argument. > > >> I can think of a few more types of traffic where > >> egress interface reporting may be challenging, such as > >> flow reporting under flap conditions, load balanced > >> traffic > >> > > You have 2 good examples here. > > > > Flap conditions and load balancing affect the > input interface as well as the output interface. > > >> and port mirrored traffic. In switches, > > I do not see your point concerning port mirrored traffic. Port mirroring in modern switches is generally implemented in hardware in a half-duplex fashion. When an ingress stream of an interface is mirrored, generally, the packet is latched to the mirrored port, as it is being read, if, of course, the outgoing port can handle it. Some vendors do the same thing with egress port mirroring, hardware latching both interfaces as the packet is being serialized out of the box. There is no status indication available to indicate whether the mirror port actually received the packet, or whether the mirror interface is actually up. The point is that no monitor could 'realize' whether a particular packet was actually transmitted to a mirrored interface, given existing commercial vendor designs. I've seen customers use egress interface mirroring for fault tolerance, and for some of these, they would love for IPFIX to support "multiple egress interface flow accounting". I'm not sure that anyone will ever be able to implement what these words really mean, inside a switch. > > >> broadcast traffic generates the same problem set as multicast > >> traffic. Also many switches, when presented with some arp table > >> issues, will broadcast unicast datagrams to all interfaces. Should > >> the multiple egress interfaces be reported in this case? That > >> condition > > Yes, if I configured the metering process in this way, > I would expect this. However, it might not be a good idea > to configure it this way. Well this is the nature of datagram flows in modern switches. If you are attempting to state what a flow monitor must do in order to do a decent job, and you decide that egress interface reporting is going to be a part of that, then you should take into consideration the normal modes of operation of a modern switch/router and correctly deal with those conditions. It is not a choice of configuration. > > >> would persist, ideally, for only a few packets. Do > >> you generate multiple flow reports, one for the > >> broadcasted set of packets, and then one for the non broadcasted > >> flow? > > Same answer. > > > Well, for switches (layer 2 devices) I think that we > shouldn't report > > any flow records. Only the layer 3 devices should. > > > >> > >> One issue that comes up when considering multicast > >> egress interface reporting is that in most vendors > >> multicast implementations the multicast traffic is > >> delivered to every egress interface through hardware > broadcast, and > >> then output filters decide whether to forward the packet > or not. How > >> does this generalize in the IPFIX egress interface reporting > >> strategy? > > Wouldn'n these filters be a great location for collecting > multicast flow information? They anyway maintain a list of > multicast flows. The requirements suggest to collect > multicast information saparately for each egress. (And it > uses only SHOULD, not MUST for multicast traffic.) There is one very fundamental issue here. While the example used multicast traffic, the real issue is that switch vendors provide egress interface filtering for all network traffic. Is it better to report that a packet was intended for a particular interface, whether it was transmitted or not? Or is it better if the IPFIX monitor is implemented after all the filters and shapers, such that it doesn't see all the traffic that the router is dealing with? VLANs are almost universally enforced using egress interface filtering and there are many conditions where a switch will forward a packet to an interface that doesn't support a given VLAN, but it filters the packet, doing the right thing. Should IPFIX report that the box forwarded the flow to the interface, unaware that the packets will be filtered? Yes that seems reasonable, but you shouldn't use that record for accounting, because the device didn't really dispose of the packet in this simple fashion. > > >> Does the IPFIX Data Model need to understand egress interface > >> filtering behavior for all traffic types or just multicast? > > This heavily depends on the list of traffic types for > which egress filtring is used. I guess you don't use it > for TCP. Most vendors support filtering for specific TCP flags, say SYN packets, in their Access Control Lists and these are almost always implemented as a egress interface filter. > > >> It may be easier to just make egress interface > >> reporting an OPTIONAL feature, and then see if > >> any vendors can successfully implement it. > > This holds for most of the requirements. > But following your arguments: The multicast case > is not OPTIONAL, but SHOULD in the current reuqirements. > So, if a vendor faces serious problems implementing it, > the vendor will drop it. Here we have already what you > are asking for. I believe that reporting any interface, whether ingress or egress, should be OPTIONAL. > > All other arguments apply as well to the input interface. > But you ar not proposing to make this OPTIONAL. > > I think one important point behind your arguments is > that from a router architecture point of view, the most > obvious pace to locate the observation point and the metering > process is at the input interface, because similar > funtionality is required at this location anyway. But when > doing so it is not always easy to find otu the output interface. > > If a vendor locates the observation points at the output > interface (what I do not necessarily expect), then it might > face the inverse problem of not necessarily knowing the input > interface. If the IPFIX device is monitoring at the egress interface, then why put the egress id in every record. It won't change during the life of the monitor. Since you may not be sure of the input interface of any packet at the egress interface, why require that it be reported for any traffic? > > Like Benoit below, I also would like to have more opinions > on the issue how far the clearly existing requirements by > metering applications should be loosened in the IPFIX > requirements document because of assumed limitations of > today's router architecture? > > Juergen > > >> > > You've got a valid point.Why not a SHOULD? > > > > SHOULD This word, or the adjective "RECOMMENDED", > mean that there > > may exist valid reasons in particular circumstances > to ignore a > > particular item, but the full implications must be > understood and > > carefully weighed before choosing a different course. > > > > Any other opinion? > > > > Regards, Benoit. > > > >> > >> > >> Carter > >> > >> Carter Bullard > >> QoSient, LLC > >> 300 E. 56th Street > >> Suite 18K > >> New York, New York 10022 > >> > >> +1 212 588-9133 Phone > >> +1 212 588-9134 Fax > >> > >> > >> > >>> -----Original Message----- > >>> From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu] On > >>> Behalf Of Benoit Claise > >>> Sent: Friday, July 26, 2002 4:21 AM > >>> To: ipfix-req@net.doit.wisc.edu > >>> Subject: [ipfix-req] Section regarding multicast flows > >>> > >>> > >>> > >>> > >>> Dave and All, > >>> > >>> Trying to incorporate all the proposed changes discussed > both at the > >>> IETF meeting and on the mailing list in the new requirement draft > >>> version, I think that we should add a new section on multicast > >>> > >>> 5.7 Multicast Flows > >>> > >>> For a multicast packet replicated to multiple output > interfaces, the > >>> metering process SHOULD maintain discrete flow records > per different > >>> egress ifIndexes. For example an incoming multicast packet > >>> that is replicated to four output interfaces would be > >>> reported in four different flow records that differ by the > >>> output interface. In case the metering process doesn't > >>> maintain and report discrete flow records > >>> per different egress ifIndexes for a multicast flow, the > >>> metering process > >>> SHOULD export the multicast replication factor in the flow record. > >>> > >>> > >>> Furthermore, some extra changes are needed > >>> The requirement draft was saying: > >>> > >>> 6.1. Information Model > >>> ... > >>> The exporting process MUST be able to report the following > >>> attributes > >>> for each measured flow: > >>> ... > >>> 8. output interface (ifIndex) > >>> This requirement does not apply if the observation point is > >>> located at a probe device. This requirement does not apply > >>> in case of multicast flow records. > >>> ... > >>> The exporting process MAY be able to report the following > >>> attributes > >>> for each measured flow: > >>> ... > >>> 25. multicast replication factor > >>> the number of outgoing packets originating from a single > >>> incoming multicast packet > >>> > >>> 26. list of output interfaces for a multicast flow > >>> > >>> > >>> I would propose: > >>> > >>> 6.1. Information Model > >>> ... > >>> The exporting process MUST be able to report the following > >>> attributes > >>> for each measured flow: > >>> ... > >>> 8. output interface (ifIndex) > >>> This requirement does not apply if the observation point is > >>> located at a probe device. _(ATTENTION: I REMOVED THE > LINE ABOUT > >>> MULTICAST)_ > >>> ... > >>> The exporting process _SHOULD_ be able to report the following > >>> attributes > >>> for each measured flow: > >>> ... > >>> X. multicast replication factor > >>> The number of outgoing packets originating from a single > >>> incoming multicast packet. This _multicast_ replication factor > >>> SHOULD be reported, > >>> but only SHOULD if the list of output interfaces for this > >>> multicast > >>> flow is not reported. > >>> > >>> _X+1. list of output interfaces for a multicast flow _(I WOULD > >>> REMOVE IT > >>> BECAUSE THIS IS EXPLAINED IN THE MULTICAST FLOW > SECTION AND THE > >>> LIMITATION > >>> IN THE OUTPUT INTERFACE SECTION ABOVE IS REMOVED) > >>> > >>> > >>> What do you think? > >>> > >>> Regards, Benoit > >>> > >>> > >>> > >>> > >>> -- > >>> Help mailto:majordomo@net.doit.wisc.edu and say "help" > >>> in message body > >>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe > >>> ipfix" in message body > >>> Archive http://ipfix.doit.wisc.edu/archive/ > >>> > >>> > >>> > >>> > >> > >> > >> > >> -- > >> Help mailto:majordomo@net.doit.wisc.edu and say > "help" in message body > >> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe > >> ipfix" in message body > >> Archive http://ipfix.doit.wisc.edu/archive/ > >> > >> > > > > > > > > > > -- > > Help mailto:majordomo@net.doit.wisc.edu and say > "help" in message body > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe > > ipfix" in message body > > Archive http://ipfix.doit.wisc.edu/archive/ > > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" > in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Aug 19 13:08:03 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09691 for ; Mon, 19 Aug 2002 13:08:02 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17gplh-00027t-00 for ipfix-list@mil.doit.wisc.edu; Mon, 19 Aug 2002 11:52:41 -0500 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17gple-00027C-00 for ipfix-req@net.doit.wisc.edu; Mon, 19 Aug 2002 11:52:38 -0500 Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g7JGptU49031; Mon, 19 Aug 2002 18:51:55 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 94C9F5BA48; Mon, 19 Aug 2002 18:51:53 +0200 (CEST) Date: Mon, 19 Aug 2002 18:51:53 +0200 From: Juergen Quittek To: Carter Bullard , "'Benoit Claise'" Cc: ipfix-req@net.doit.wisc.edu Subject: RE: [ipfix-req] Section regarding multicast flows Message-ID: <37866058.1029783113@[192.168.102.164]> In-Reply-To: <5C8959A16A71B449AE793CF52FBBED6607A431@ptah.newyork.qosient.com> References: <5C8959A16A71B449AE793CF52FBBED6607A431@ptah.newyork.qosient.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi all, The discussion on reporting output/egress interfaces now has extended to reporting input/ingress interfaces for flows. Please note that the requirements document only talks about the ability to report it, and not about necessarily reporting them in each record. An argument for not having both as MUST is that in several current router architectures, it would be a big and costly effort to support both. Also our AD directed us to try to standardize "existing practice" and not to require new router architectures for IPFIX. However, there is a clear need for accurate reporting of interfaces on the user side (from which requirements are derived). Reporting on the origin and destination of a packet apparently is very important for many metering-based applications. The positions explicitly stated so far are (please correct me, if I'm wrong): - Carter proposes having both of them OPTIONAL. - Paul is fine with the current draft version: bost MUST in general, but SHOULD for egress in case of multicast. - Dave seems to have a similar opinion. - Benoit, Tanja, Sebastian, and myself think that the input/ingress interface is essential, but that for all output/egress interfaces a SHOULD would also be sufficient. Are there further opinions? Juergen --On 15 August 2002 20:40 -0400 Carter Bullard wrote: > > Gentle people, > This is pretty long, I do hope that some find it useful. > > Carter > >> >> In cases where there are valid exceptions to a >> >> requirement candidate, a MUST generally converts to >> >> a SHOULD or OPTIONAL. One reason for this is >> >> you don't want to have to identify and manage >> >> the complete list of possible exceptions during the >> >> life of the RFC. You already have exceptions for >> >> certain types of IPFIX devices and specific types >> >> of traffic that don't require egress interface >> >> reporting. That on its own might suggest that >> >> I think there is only one exception like that in >> section 6.1.-8. saying that a probe does not need >> to have the ability of reporting the output interface. >> Please note that the same exception holds for the >> input interface. > > From the perspective of a monitor that is internal > to a switch or a router, the input interface identifier > is historical and factual. The output interface > identifier is always a predicted value, and as a result, > a guess. As much a guess as packet and octet counters for outgoing traffic in mib-II? >> >> egress interface reporting should be OPTIONAL >> >> in the Data Model. But if that is not compelling, >> >> we may need to add more exceptions to the list than >> >> are already there. >> >> Since the exception is the same for input and output >> interface, we would consequently have to make the input >> interface OPTIONAL as well, if we follow your argument. >> >> >> I can think of a few more types of traffic where >> >> egress interface reporting may be challenging, such as >> >> flow reporting under flap conditions, load balanced >> >> traffic >> >> >> > You have 2 good examples here. >> > >> >> Flap conditions and load balancing affect the >> input interface as well as the output interface. >> >> >> and port mirrored traffic. In switches, >> >> I do not see your point concerning port mirrored traffic. > > Port mirroring in modern switches is generally implemented > in hardware in a half-duplex fashion. When an ingress > stream of an interface is mirrored, generally, the packet is > latched to the mirrored port, as it is being read, if, of > course, the outgoing port can handle it. Some vendors > do the same thing with egress port mirroring, hardware > latching both interfaces as the packet is being serialized > out of the box. There is no status indication available to > indicate whether the mirror port actually received the packet, > or whether the mirror interface is actually up. The point is > that no monitor could 'realize' whether a particular packet was > actually transmitted to a mirrored interface, given existing > commercial vendor designs. I've seen customers use egress > interface mirroring for fault tolerance, and for some > of these, they would love for IPFIX to support "multiple egress > interface flow accounting". I'm not sure that anyone will > ever be able to implement what these words really mean, inside a > switch. > >> >> >> broadcast traffic generates the same problem set as multicast >> >> traffic. Also many switches, when presented with some arp table >> >> issues, will broadcast unicast datagrams to all interfaces. Should >> >> the multiple egress interfaces be reported in this case? That >> >> condition >> >> Yes, if I configured the metering process in this way, >> I would expect this. However, it might not be a good idea >> to configure it this way. > > Well this is the nature of datagram flows in modern switches. > If you are attempting to state what a flow monitor must do in > order to do a decent job, and you decide that egress interface > reporting is going to be a part of that, then you should take > into consideration the normal modes of operation of a modern > switch/router and correctly deal with those conditions. It > is not a choice of configuration. Well, it is. If I do egress interface reporting, I have the choice of montoring IP only or monitoring both, IP and ARP. >> >> would persist, ideally, for only a few packets. Do >> >> you generate multiple flow reports, one for the >> >> broadcasted set of packets, and then one for the non broadcasted >> >> flow? >> >> Same answer. >> >> > Well, for switches (layer 2 devices) I think that we >> shouldn't report >> > any flow records. Only the layer 3 devices should. >> > >> >> >> >> One issue that comes up when considering multicast >> >> egress interface reporting is that in most vendors >> >> multicast implementations the multicast traffic is >> >> delivered to every egress interface through hardware >> broadcast, and >> >> then output filters decide whether to forward the packet >> or not. How >> >> does this generalize in the IPFIX egress interface reporting >> >> strategy? >> >> Wouldn'n these filters be a great location for collecting >> multicast flow information? They anyway maintain a list of >> multicast flows. The requirements suggest to collect >> multicast information saparately for each egress. (And it >> uses only SHOULD, not MUST for multicast traffic.) > > There is one very fundamental issue here. While the example > used multicast traffic, the real issue is that switch vendors > provide egress interface filtering for all network traffic. > > Is it better to report that a packet was intended for a > particular interface, whether it was transmitted or not? > Or is it better if the IPFIX monitor is implemented after > all the filters and shapers, such that it doesn't see > all the traffic that the router is dealing with? > > VLANs are almost universally enforced using egress > interface filtering and there are many conditions where > a switch will forward a packet to an interface that doesn't > support a given VLAN, but it filters the packet, doing the > right thing. Should IPFIX report that the box forwarded > the flow to the interface, unaware that the packets will > be filtered? Yes that seems reasonable, but you shouldn't > use that record for accounting, because the device didn't > really dispose of the packet in this simple fashion. > >> >> >> Does the IPFIX Data Model need to understand egress interface >> >> filtering behavior for all traffic types or just multicast? >> >> This heavily depends on the list of traffic types for >> which egress filtring is used. I guess you don't use it >> for TCP. > > Most vendors support filtering for specific TCP flags, > say SYN packets, in their Access Control Lists > and these are almost always implemented as a egress interface > filter. > >> >> >> It may be easier to just make egress interface >> >> reporting an OPTIONAL feature, and then see if >> >> any vendors can successfully implement it. >> >> This holds for most of the requirements. >> But following your arguments: The multicast case >> is not OPTIONAL, but SHOULD in the current reuqirements. >> So, if a vendor faces serious problems implementing it, >> the vendor will drop it. Here we have already what you >> are asking for. > > I believe that reporting any interface, whether ingress > or egress, should be OPTIONAL. > >> >> All other arguments apply as well to the input interface. >> But you ar not proposing to make this OPTIONAL. >> >> I think one important point behind your arguments is >> that from a router architecture point of view, the most >> obvious pace to locate the observation point and the metering >> process is at the input interface, because similar >> funtionality is required at this location anyway. But when >> doing so it is not always easy to find otu the output interface. >> >> If a vendor locates the observation points at the output >> interface (what I do not necessarily expect), then it might >> face the inverse problem of not necessarily knowing the input >> interface. > > If the IPFIX device is monitoring at the egress interface, > then why put the egress id in every record. It won't change The requirements is not at all about putting something in every packet, it is just about reporting. If the exporting process is able to report once, that all reported flows share the same output interface, then the requirement is already met. > during the life of the monitor. Since you may not be sure > of the input interface of any packet at the egress interface, > why require that it be reported for any traffic? >> >> Like Benoit below, I also would like to have more opinions >> on the issue how far the clearly existing requirements by >> metering applications should be loosened in the IPFIX >> requirements document because of assumed limitations of >> today's router architecture? >> >> Juergen >> >> >> >> > You've got a valid point.Why not a SHOULD? >> > >> > SHOULD This word, or the adjective "RECOMMENDED", >> mean that there >> > may exist valid reasons in particular circumstances >> to ignore a >> > particular item, but the full implications must be >> understood and >> > carefully weighed before choosing a different course. >> > >> > Any other opinion? >> > >> > Regards, Benoit. >> > >> >> >> >> >> >> Carter >> >> >> >> Carter Bullard >> >> QoSient, LLC >> >> 300 E. 56th Street >> >> Suite 18K >> >> New York, New York 10022 >> >> >> >> +1 212 588-9133 Phone >> >> +1 212 588-9134 Fax >> >> >> >> >> >> >> >>> -----Original Message----- >> >>> From: majordomo listserver >> [mailto:majordomo@mil.doit.wisc.edu] On >> >>> Behalf Of Benoit Claise >> >>> Sent: Friday, July 26, 2002 4:21 AM >> >>> To: ipfix-req@net.doit.wisc.edu >> >>> Subject: [ipfix-req] Section regarding multicast flows >> >>> >> >>> >> >>> >> >>> >> >>> Dave and All, >> >>> >> >>> Trying to incorporate all the proposed changes discussed >> both at the >> >>> IETF meeting and on the mailing list in the new requirement draft >> >>> version, I think that we should add a new section on multicast >> >>> >> >>> 5.7 Multicast Flows >> >>> >> >>> For a multicast packet replicated to multiple output >> interfaces, the >> >>> metering process SHOULD maintain discrete flow records >> per different >> >>> egress ifIndexes. For example an incoming multicast packet >> >>> that is replicated to four output interfaces would be >> >>> reported in four different flow records that differ by the >> >>> output interface. In case the metering process doesn't >> >>> maintain and report discrete flow records >> >>> per different egress ifIndexes for a multicast flow, the >> >>> metering process >> >>> SHOULD export the multicast replication factor in the flow record. >> >>> >> >>> >> >>> Furthermore, some extra changes are needed >> >>> The requirement draft was saying: >> >>> >> >>> 6.1. Information Model >> >>> ... >> >>> The exporting process MUST be able to report the following >> >>> attributes >> >>> for each measured flow: >> >>> ... >> >>> 8. output interface (ifIndex) >> >>> This requirement does not apply if the observation point is >> >>> located at a probe device. This requirement does not apply >> >>> in case of multicast flow records. >> >>> ... >> >>> The exporting process MAY be able to report the following >> >>> attributes >> >>> for each measured flow: >> >>> ... >> >>> 25. multicast replication factor >> >>> the number of outgoing packets originating from a single >> >>> incoming multicast packet >> >>> >> >>> 26. list of output interfaces for a multicast flow >> >>> >> >>> >> >>> I would propose: >> >>> >> >>> 6.1. Information Model >> >>> ... >> >>> The exporting process MUST be able to report the following >> >>> attributes >> >>> for each measured flow: >> >>> ... >> >>> 8. output interface (ifIndex) >> >>> This requirement does not apply if the observation point is >> >>> located at a probe device. _(ATTENTION: I REMOVED THE >> LINE ABOUT >> >>> MULTICAST)_ >> >>> ... >> >>> The exporting process _SHOULD_ be able to report the following >> >>> attributes >> >>> for each measured flow: >> >>> ... >> >>> X. multicast replication factor >> >>> The number of outgoing packets originating from a single >> >>> incoming multicast packet. This _multicast_ replication factor >> >>> SHOULD be reported, >> >>> but only SHOULD if the list of output interfaces for this >> >>> multicast >> >>> flow is not reported. >> >>> >> >>> _X+1. list of output interfaces for a multicast flow _(I WOULD >> >>> REMOVE IT >> >>> BECAUSE THIS IS EXPLAINED IN THE MULTICAST FLOW >> SECTION AND THE >> >>> LIMITATION >> >>> IN THE OUTPUT INTERFACE SECTION ABOVE IS REMOVED) >> >>> >> >>> >> >>> What do you think? >> >>> >> >>> Regards, Benoit >> >>> >> >>> >> >>> >> >>> >> >>> -- >> >>> Help mailto:majordomo@net.doit.wisc.edu and say "help" >> >>> in message body >> >>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >> "unsubscribe >> >>> ipfix" in message body >> >>> Archive http://ipfix.doit.wisc.edu/archive/ >> >>> >> >>> >> >>> >> >>> >> >> >> >> >> >> >> >> -- >> >> Help mailto:majordomo@net.doit.wisc.edu and say >> "help" in message body >> >> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >> "unsubscribe >> >> ipfix" in message body >> >> Archive http://ipfix.doit.wisc.edu/archive/ >> >> >> >> >> > >> > >> > >> > >> > -- >> > Help mailto:majordomo@net.doit.wisc.edu and say >> "help" in message body >> > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe >> > ipfix" in message body >> > Archive http://ipfix.doit.wisc.edu/archive/ >> >> >> >> -- >> Help mailto:majordomo@net.doit.wisc.edu and say "help" >> in message body >> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >> "unsubscribe ipfix" in message body >> Archive http://ipfix.doit.wisc.edu/archive/ >> >> > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Aug 23 07:36:03 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04010 for ; Fri, 23 Aug 2002 07:36:02 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17iCT1-0006zl-00 for ipfix-list@mil.doit.wisc.edu; Fri, 23 Aug 2002 06:19:03 -0500 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17iCSu-0006yg-00 for ipfix-req@net.doit.wisc.edu; Fri, 23 Aug 2002 06:18:56 -0500 Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g7NBIEU89355; Fri, 23 Aug 2002 13:18:15 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 2A2C84271B; Fri, 23 Aug 2002 13:18:12 +0200 (CEST) Date: Fri, 23 Aug 2002 13:18:12 +0200 From: Juergen Quittek To: Carter Bullard , "'Benoit Claise'" Cc: ipfix-req@net.doit.wisc.edu Subject: Reportin in and out interfaces (was: RE: [ipfix-req] Section regarding multicast flows) Message-ID: <6309182.1030108692@[192.168.102.164]> In-Reply-To: <37866058.1029783113@[192.168.102.164]> References: <37866058.1029783113@[192.168.102.164]> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi all, I have a new suggestion which might solve our reporting problem for input and output interfaces. What about keeping input interface and output interfaces in the MUST list of attributes that the exporter is capable of reporting but changing the restriction as follows? 7. input interface (ifIndex) This requirement does only apply to flows for which the input interface is included in the observation point. 8. output interface (ifIndex) This requirement does only apply to flows for which the output interface is included in the observation point. Juergen --On 19 August 2002 18:51 +0200 Juergen Quittek wrote: > Hi all, > > The discussion on reporting output/egress interfaces now has > extended to reporting input/ingress interfaces for flows. > > Please note that the requirements document only talks about > the ability to report it, and not about necessarily reporting > them in each record. > > An argument for not having both as MUST is that in several current > router architectures, it would be a big and costly effort to support > both. Also our AD directed us to try to standardize "existing > practice" and not to require new router architectures for IPFIX. > > However, there is a clear need for accurate reporting of interfaces > on the user side (from which requirements are derived). Reporting > on the origin and destination of a packet apparently is very important > for many metering-based applications. > > The positions explicitly stated so far are (please correct me, > if I'm wrong): > > - Carter proposes having both of them OPTIONAL. > - Paul is fine with the current draft version: bost MUST in general, > but SHOULD for egress in case of multicast. > - Dave seems to have a similar opinion. > - Benoit, Tanja, Sebastian, and myself think that the input/ingress > interface is essential, but that for all output/egress interfaces > a SHOULD would also be sufficient. > > Are there further opinions? > > Juergen > > > --On 15 August 2002 20:40 -0400 Carter Bullard wrote: > >> >> Gentle people, >> This is pretty long, I do hope that some find it useful. >> >> Carter >> >>> >> In cases where there are valid exceptions to a >>> >> requirement candidate, a MUST generally converts to >>> >> a SHOULD or OPTIONAL. One reason for this is >>> >> you don't want to have to identify and manage >>> >> the complete list of possible exceptions during the >>> >> life of the RFC. You already have exceptions for >>> >> certain types of IPFIX devices and specific types >>> >> of traffic that don't require egress interface >>> >> reporting. That on its own might suggest that >>> >>> I think there is only one exception like that in >>> section 6.1.-8. saying that a probe does not need >>> to have the ability of reporting the output interface. >>> Please note that the same exception holds for the >>> input interface. >> >> From the perspective of a monitor that is internal >> to a switch or a router, the input interface identifier >> is historical and factual. The output interface >> identifier is always a predicted value, and as a result, >> a guess. > > As much a guess as packet and octet counters for outgoing > traffic in mib-II? > >>> >> egress interface reporting should be OPTIONAL >>> >> in the Data Model. But if that is not compelling, >>> >> we may need to add more exceptions to the list than >>> >> are already there. >>> >>> Since the exception is the same for input and output >>> interface, we would consequently have to make the input >>> interface OPTIONAL as well, if we follow your argument. >>> >>> >> I can think of a few more types of traffic where >>> >> egress interface reporting may be challenging, such as >>> >> flow reporting under flap conditions, load balanced >>> >> traffic >>> >> >>> > You have 2 good examples here. >>> > >>> >>> Flap conditions and load balancing affect the >>> input interface as well as the output interface. >>> >>> >> and port mirrored traffic. In switches, >>> >>> I do not see your point concerning port mirrored traffic. >> >> Port mirroring in modern switches is generally implemented >> in hardware in a half-duplex fashion. When an ingress >> stream of an interface is mirrored, generally, the packet is >> latched to the mirrored port, as it is being read, if, of >> course, the outgoing port can handle it. Some vendors >> do the same thing with egress port mirroring, hardware >> latching both interfaces as the packet is being serialized >> out of the box. There is no status indication available to >> indicate whether the mirror port actually received the packet, >> or whether the mirror interface is actually up. The point is >> that no monitor could 'realize' whether a particular packet was >> actually transmitted to a mirrored interface, given existing >> commercial vendor designs. I've seen customers use egress >> interface mirroring for fault tolerance, and for some >> of these, they would love for IPFIX to support "multiple egress >> interface flow accounting". I'm not sure that anyone will >> ever be able to implement what these words really mean, inside a >> switch. >> >>> >>> >> broadcast traffic generates the same problem set as multicast >>> >> traffic. Also many switches, when presented with some arp table >>> >> issues, will broadcast unicast datagrams to all interfaces. Should >>> >> the multiple egress interfaces be reported in this case? That >>> >> condition >>> >>> Yes, if I configured the metering process in this way, >>> I would expect this. However, it might not be a good idea >>> to configure it this way. >> >> Well this is the nature of datagram flows in modern switches. >> If you are attempting to state what a flow monitor must do in >> order to do a decent job, and you decide that egress interface >> reporting is going to be a part of that, then you should take >> into consideration the normal modes of operation of a modern >> switch/router and correctly deal with those conditions. It >> is not a choice of configuration. > > Well, it is. If I do egress interface reporting, I have the > choice of montoring IP only or monitoring both, IP and ARP. > >>> >> would persist, ideally, for only a few packets. Do >>> >> you generate multiple flow reports, one for the >>> >> broadcasted set of packets, and then one for the non broadcasted >>> >> flow? >>> >>> Same answer. >>> >>> > Well, for switches (layer 2 devices) I think that we >>> shouldn't report >>> > any flow records. Only the layer 3 devices should. >>> > >>> >> >>> >> One issue that comes up when considering multicast >>> >> egress interface reporting is that in most vendors >>> >> multicast implementations the multicast traffic is >>> >> delivered to every egress interface through hardware >>> broadcast, and >>> >> then output filters decide whether to forward the packet >>> or not. How >>> >> does this generalize in the IPFIX egress interface reporting >>> >> strategy? >>> >>> Wouldn'n these filters be a great location for collecting >>> multicast flow information? They anyway maintain a list of >>> multicast flows. The requirements suggest to collect >>> multicast information saparately for each egress. (And it >>> uses only SHOULD, not MUST for multicast traffic.) >> >> There is one very fundamental issue here. While the example >> used multicast traffic, the real issue is that switch vendors >> provide egress interface filtering for all network traffic. >> >> Is it better to report that a packet was intended for a >> particular interface, whether it was transmitted or not? >> Or is it better if the IPFIX monitor is implemented after >> all the filters and shapers, such that it doesn't see >> all the traffic that the router is dealing with? >> >> VLANs are almost universally enforced using egress >> interface filtering and there are many conditions where >> a switch will forward a packet to an interface that doesn't >> support a given VLAN, but it filters the packet, doing the >> right thing. Should IPFIX report that the box forwarded >> the flow to the interface, unaware that the packets will >> be filtered? Yes that seems reasonable, but you shouldn't >> use that record for accounting, because the device didn't >> really dispose of the packet in this simple fashion. >> >>> >>> >> Does the IPFIX Data Model need to understand egress interface >>> >> filtering behavior for all traffic types or just multicast? >>> >>> This heavily depends on the list of traffic types for >>> which egress filtring is used. I guess you don't use it >>> for TCP. >> >> Most vendors support filtering for specific TCP flags, >> say SYN packets, in their Access Control Lists >> and these are almost always implemented as a egress interface >> filter. >> >>> >>> >> It may be easier to just make egress interface >>> >> reporting an OPTIONAL feature, and then see if >>> >> any vendors can successfully implement it. >>> >>> This holds for most of the requirements. >>> But following your arguments: The multicast case >>> is not OPTIONAL, but SHOULD in the current reuqirements. >>> So, if a vendor faces serious problems implementing it, >>> the vendor will drop it. Here we have already what you >>> are asking for. >> >> I believe that reporting any interface, whether ingress >> or egress, should be OPTIONAL. >> >>> >>> All other arguments apply as well to the input interface. >>> But you ar not proposing to make this OPTIONAL. >>> >>> I think one important point behind your arguments is >>> that from a router architecture point of view, the most >>> obvious pace to locate the observation point and the metering >>> process is at the input interface, because similar >>> funtionality is required at this location anyway. But when >>> doing so it is not always easy to find otu the output interface. >>> >>> If a vendor locates the observation points at the output >>> interface (what I do not necessarily expect), then it might >>> face the inverse problem of not necessarily knowing the input >>> interface. >> >> If the IPFIX device is monitoring at the egress interface, >> then why put the egress id in every record. It won't change > > The requirements is not at all about putting something in > every packet, it is just about reporting. If the exporting > process is able to report once, that all reported flows share > the same output interface, then the requirement is already met. > >> during the life of the monitor. Since you may not be sure >> of the input interface of any packet at the egress interface, >> why require that it be reported for any traffic? >>> >>> Like Benoit below, I also would like to have more opinions >>> on the issue how far the clearly existing requirements by >>> metering applications should be loosened in the IPFIX >>> requirements document because of assumed limitations of >>> today's router architecture? >>> >>> Juergen >>> >>> >> >>> > You've got a valid point.Why not a SHOULD? >>> > >>> > SHOULD This word, or the adjective "RECOMMENDED", >>> mean that there >>> > may exist valid reasons in particular circumstances >>> to ignore a >>> > particular item, but the full implications must be >>> understood and >>> > carefully weighed before choosing a different course. >>> > >>> > Any other opinion? >>> > >>> > Regards, Benoit. >>> > >>> >> >>> >> >>> >> Carter >>> >> >>> >> Carter Bullard >>> >> QoSient, LLC >>> >> 300 E. 56th Street >>> >> Suite 18K >>> >> New York, New York 10022 >>> >> >>> >> +1 212 588-9133 Phone >>> >> +1 212 588-9134 Fax >>> >> >>> >> >>> >> >>> >>> -----Original Message----- >>> >>> From: majordomo listserver >>> [mailto:majordomo@mil.doit.wisc.edu] On >>> >>> Behalf Of Benoit Claise >>> >>> Sent: Friday, July 26, 2002 4:21 AM >>> >>> To: ipfix-req@net.doit.wisc.edu >>> >>> Subject: [ipfix-req] Section regarding multicast flows >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Dave and All, >>> >>> >>> >>> Trying to incorporate all the proposed changes discussed >>> both at the >>> >>> IETF meeting and on the mailing list in the new requirement draft >>> >>> version, I think that we should add a new section on multicast >>> >>> >>> >>> 5.7 Multicast Flows >>> >>> >>> >>> For a multicast packet replicated to multiple output >>> interfaces, the >>> >>> metering process SHOULD maintain discrete flow records >>> per different >>> >>> egress ifIndexes. For example an incoming multicast packet >>> >>> that is replicated to four output interfaces would be >>> >>> reported in four different flow records that differ by the >>> >>> output interface. In case the metering process doesn't >>> >>> maintain and report discrete flow records >>> >>> per different egress ifIndexes for a multicast flow, the >>> >>> metering process >>> >>> SHOULD export the multicast replication factor in the flow record. >>> >>> >>> >>> >>> >>> Furthermore, some extra changes are needed >>> >>> The requirement draft was saying: >>> >>> >>> >>> 6.1. Information Model >>> >>> ... >>> >>> The exporting process MUST be able to report the following >>> >>> attributes >>> >>> for each measured flow: >>> >>> ... >>> >>> 8. output interface (ifIndex) >>> >>> This requirement does not apply if the observation point is >>> >>> located at a probe device. This requirement does not apply >>> >>> in case of multicast flow records. >>> >>> ... >>> >>> The exporting process MAY be able to report the following >>> >>> attributes >>> >>> for each measured flow: >>> >>> ... >>> >>> 25. multicast replication factor >>> >>> the number of outgoing packets originating from a single >>> >>> incoming multicast packet >>> >>> >>> >>> 26. list of output interfaces for a multicast flow >>> >>> >>> >>> >>> >>> I would propose: >>> >>> >>> >>> 6.1. Information Model >>> >>> ... >>> >>> The exporting process MUST be able to report the following >>> >>> attributes >>> >>> for each measured flow: >>> >>> ... >>> >>> 8. output interface (ifIndex) >>> >>> This requirement does not apply if the observation point is >>> >>> located at a probe device. _(ATTENTION: I REMOVED THE >>> LINE ABOUT >>> >>> MULTICAST)_ >>> >>> ... >>> >>> The exporting process _SHOULD_ be able to report the following >>> >>> attributes >>> >>> for each measured flow: >>> >>> ... >>> >>> X. multicast replication factor >>> >>> The number of outgoing packets originating from a single >>> >>> incoming multicast packet. This _multicast_ replication factor >>> >>> SHOULD be reported, >>> >>> but only SHOULD if the list of output interfaces for this >>> >>> multicast >>> >>> flow is not reported. >>> >>> >>> >>> _X+1. list of output interfaces for a multicast flow _(I WOULD >>> >>> REMOVE IT >>> >>> BECAUSE THIS IS EXPLAINED IN THE MULTICAST FLOW >>> SECTION AND THE >>> >>> LIMITATION >>> >>> IN THE OUTPUT INTERFACE SECTION ABOVE IS REMOVED) >>> >>> >>> >>> >>> >>> What do you think? >>> >>> >>> >>> Regards, Benoit >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> -- >>> >>> Help mailto:majordomo@net.doit.wisc.edu and say "help" >>> >>> in message body >>> >>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>> "unsubscribe >>> >>> ipfix" in message body >>> >>> Archive http://ipfix.doit.wisc.edu/archive/ >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >>> >> >>> >> >>> >> -- >>> >> Help mailto:majordomo@net.doit.wisc.edu and say >>> "help" in message body >>> >> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>> "unsubscribe >>> >> ipfix" in message body >>> >> Archive http://ipfix.doit.wisc.edu/archive/ >>> >> >>> >> >>> > >>> > >>> > >>> > >>> > -- >>> > Help mailto:majordomo@net.doit.wisc.edu and say >>> "help" in message body >>> > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe >>> > ipfix" in message body >>> > Archive http://ipfix.doit.wisc.edu/archive/ >>> >>> >>> >>> -- >>> Help mailto:majordomo@net.doit.wisc.edu and say "help" >>> in message body >>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>> "unsubscribe ipfix" in message body >>> Archive http://ipfix.doit.wisc.edu/archive/ >>> >>> >> >> > > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Aug 23 12:46:29 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11662 for ; Fri, 23 Aug 2002 12:46:24 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17iHKK-0006PY-00 for ipfix-list@mil.doit.wisc.edu; Fri, 23 Aug 2002 11:30:24 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17iHKH-0006OQ-00 for ipfix-req@net.doit.wisc.edu; Fri, 23 Aug 2002 11:30:21 -0500 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 g7NGTA728985; Fri, 23 Aug 2002 18:29:10 +0200 (CEST) Message-ID: <3D6662D5.5060902@cisco.com> Date: Fri, 23 Aug 2002 18:29:09 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020815 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juergen Quittek CC: Carter Bullard , ipfix-req@net.doit.wisc.edu Subject: Re: Reportin in and out interfaces (was: RE: [ipfix-req] Section regarding multicast flows) References: <37866058.1029783113@[192.168.102.164]> <6309182.1030108692@[192.168.102.164]> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Juergen, > Hi all, > > I have a new suggestion which might solve our reporting problem > for input and output interfaces. > > What about keeping input interface and output interfaces in the > MUST list of attributes that the exporter is capable of reporting > but changing the restriction as follows? > > 7. input interface (ifIndex) > This requirement does only apply to flows for which the > input interface is included in the observation point. But, it will always be the case? 2.2. Observation Point The observation point is a location in the network where IP packets can be observed. Examples are a line to which a probe is attached, a shared medium, such as an Ethernet-based LAN, a single port of a router, or a set of interfaces (physical or logical) of a router. If the observation point is an port (interface), yes the input interface is the observation point If the observation point is a set of ports (interfaces), yes the input interface is part of the observation point If the observation point is a line card, yes ... If the observation point is a router, yes... What do I miss? > > 8. output interface (ifIndex) > This requirement does only apply to flows for which the > output interface is included in the observation point. How are you solving that way the following issue? - multicast - load balancing issue - flap conditions You are only solving the issue of: - the output interface belongs to another line card, and we don't know (yet) what it is - the output interface is mirrored port (and it doesn't make sense to report it) Regards, Benoit. > > > > Juergen > > > --On 19 August 2002 18:51 +0200 Juergen Quittek > wrote: > >> Hi all, >> >> The discussion on reporting output/egress interfaces now has >> extended to reporting input/ingress interfaces for flows. >> >> Please note that the requirements document only talks about >> the ability to report it, and not about necessarily reporting >> them in each record. >> >> An argument for not having both as MUST is that in several current >> router architectures, it would be a big and costly effort to support >> both. Also our AD directed us to try to standardize "existing >> practice" and not to require new router architectures for IPFIX. >> >> However, there is a clear need for accurate reporting of interfaces >> on the user side (from which requirements are derived). Reporting >> on the origin and destination of a packet apparently is very important >> for many metering-based applications. >> >> The positions explicitly stated so far are (please correct me, >> if I'm wrong): >> >> - Carter proposes having both of them OPTIONAL. >> - Paul is fine with the current draft version: bost MUST in general, >> but SHOULD for egress in case of multicast. >> - Dave seems to have a similar opinion. >> - Benoit, Tanja, Sebastian, and myself think that the input/ingress >> interface is essential, but that for all output/egress interfaces >> a SHOULD would also be sufficient. >> >> Are there further opinions? >> >> Juergen >> >> >> --On 15 August 2002 20:40 -0400 Carter Bullard >> wrote: >> >>> >>> Gentle people, >>> This is pretty long, I do hope that some find it useful. >>> >>> Carter >>> >>>> >> In cases where there are valid exceptions to a >>>> >> requirement candidate, a MUST generally converts to >>>> >> a SHOULD or OPTIONAL. One reason for this is >>>> >> you don't want to have to identify and manage >>>> >> the complete list of possible exceptions during the >>>> >> life of the RFC. You already have exceptions for >>>> >> certain types of IPFIX devices and specific types >>>> >> of traffic that don't require egress interface >>>> >> reporting. That on its own might suggest that >>>> >>>> I think there is only one exception like that in >>>> section 6.1.-8. saying that a probe does not need >>>> to have the ability of reporting the output interface. >>>> Please note that the same exception holds for the >>>> input interface. >>> >>> >>> From the perspective of a monitor that is internal >>> to a switch or a router, the input interface identifier >>> is historical and factual. The output interface >>> identifier is always a predicted value, and as a result, >>> a guess. >> >> >> As much a guess as packet and octet counters for outgoing >> traffic in mib-II? >> >>>> >> egress interface reporting should be OPTIONAL >>>> >> in the Data Model. But if that is not compelling, >>>> >> we may need to add more exceptions to the list than >>>> >> are already there. >>>> >>>> Since the exception is the same for input and output >>>> interface, we would consequently have to make the input >>>> interface OPTIONAL as well, if we follow your argument. >>>> >>>> >> I can think of a few more types of traffic where >>>> >> egress interface reporting may be challenging, such as >>>> >> flow reporting under flap conditions, load balanced >>>> >> traffic >>>> >> >>>> > You have 2 good examples here. >>>> > >>>> >>>> Flap conditions and load balancing affect the >>>> input interface as well as the output interface. >>>> >>>> >> and port mirrored traffic. In switches, >>>> >>>> I do not see your point concerning port mirrored traffic. >>> >>> >>> Port mirroring in modern switches is generally implemented >>> in hardware in a half-duplex fashion. When an ingress >>> stream of an interface is mirrored, generally, the packet is >>> latched to the mirrored port, as it is being read, if, of >>> course, the outgoing port can handle it. Some vendors >>> do the same thing with egress port mirroring, hardware >>> latching both interfaces as the packet is being serialized >>> out of the box. There is no status indication available to >>> indicate whether the mirror port actually received the packet, >>> or whether the mirror interface is actually up. The point is >>> that no monitor could 'realize' whether a particular packet was >>> actually transmitted to a mirrored interface, given existing >>> commercial vendor designs. I've seen customers use egress >>> interface mirroring for fault tolerance, and for some >>> of these, they would love for IPFIX to support "multiple egress >>> interface flow accounting". I'm not sure that anyone will >>> ever be able to implement what these words really mean, inside a >>> switch. >>> >>>> >>>> >> broadcast traffic generates the same problem set as multicast >>>> >> traffic. Also many switches, when presented with some arp table >>>> >> issues, will broadcast unicast datagrams to all interfaces. Should >>>> >> the multiple egress interfaces be reported in this case? That >>>> >> condition >>>> >>>> Yes, if I configured the metering process in this way, >>>> I would expect this. However, it might not be a good idea >>>> to configure it this way. >>> >>> >>> Well this is the nature of datagram flows in modern switches. >>> If you are attempting to state what a flow monitor must do in >>> order to do a decent job, and you decide that egress interface >>> reporting is going to be a part of that, then you should take >>> into consideration the normal modes of operation of a modern >>> switch/router and correctly deal with those conditions. It >>> is not a choice of configuration. >> >> >> Well, it is. If I do egress interface reporting, I have the >> choice of montoring IP only or monitoring both, IP and ARP. >> >>>> >> would persist, ideally, for only a few packets. Do >>>> >> you generate multiple flow reports, one for the >>>> >> broadcasted set of packets, and then one for the non broadcasted >>>> >> flow? >>>> >>>> Same answer. >>>> >>>> > Well, for switches (layer 2 devices) I think that we >>>> shouldn't report >>>> > any flow records. Only the layer 3 devices should. >>>> > >>>> >> >>>> >> One issue that comes up when considering multicast >>>> >> egress interface reporting is that in most vendors >>>> >> multicast implementations the multicast traffic is >>>> >> delivered to every egress interface through hardware >>>> broadcast, and >>>> >> then output filters decide whether to forward the packet >>>> or not. How >>>> >> does this generalize in the IPFIX egress interface reporting >>>> >> strategy? >>>> >>>> Wouldn'n these filters be a great location for collecting >>>> multicast flow information? They anyway maintain a list of >>>> multicast flows. The requirements suggest to collect >>>> multicast information saparately for each egress. (And it >>>> uses only SHOULD, not MUST for multicast traffic.) >>> >>> >>> There is one very fundamental issue here. While the example >>> used multicast traffic, the real issue is that switch vendors >>> provide egress interface filtering for all network traffic. >>> >>> Is it better to report that a packet was intended for a >>> particular interface, whether it was transmitted or not? >>> Or is it better if the IPFIX monitor is implemented after >>> all the filters and shapers, such that it doesn't see >>> all the traffic that the router is dealing with? >>> >>> VLANs are almost universally enforced using egress >>> interface filtering and there are many conditions where >>> a switch will forward a packet to an interface that doesn't >>> support a given VLAN, but it filters the packet, doing the >>> right thing. Should IPFIX report that the box forwarded >>> the flow to the interface, unaware that the packets will >>> be filtered? Yes that seems reasonable, but you shouldn't >>> use that record for accounting, because the device didn't >>> really dispose of the packet in this simple fashion. >>> >>>> >>>> >> Does the IPFIX Data Model need to understand egress interface >>>> >> filtering behavior for all traffic types or just multicast? >>>> >>>> This heavily depends on the list of traffic types for >>>> which egress filtring is used. I guess you don't use it >>>> for TCP. >>> >>> >>> Most vendors support filtering for specific TCP flags, >>> say SYN packets, in their Access Control Lists >>> and these are almost always implemented as a egress interface >>> filter. >>> >>>> >>>> >> It may be easier to just make egress interface >>>> >> reporting an OPTIONAL feature, and then see if >>>> >> any vendors can successfully implement it. >>>> >>>> This holds for most of the requirements. >>>> But following your arguments: The multicast case >>>> is not OPTIONAL, but SHOULD in the current reuqirements. >>>> So, if a vendor faces serious problems implementing it, >>>> the vendor will drop it. Here we have already what you >>>> are asking for. >>> >>> >>> I believe that reporting any interface, whether ingress >>> or egress, should be OPTIONAL. >>> >>>> >>>> All other arguments apply as well to the input interface. >>>> But you ar not proposing to make this OPTIONAL. >>>> >>>> I think one important point behind your arguments is >>>> that from a router architecture point of view, the most >>>> obvious pace to locate the observation point and the metering >>>> process is at the input interface, because similar >>>> funtionality is required at this location anyway. But when >>>> doing so it is not always easy to find otu the output interface. >>>> >>>> If a vendor locates the observation points at the output >>>> interface (what I do not necessarily expect), then it might >>>> face the inverse problem of not necessarily knowing the input >>>> interface. >>> >>> >>> If the IPFIX device is monitoring at the egress interface, >>> then why put the egress id in every record. It won't change >> >> >> The requirements is not at all about putting something in >> every packet, it is just about reporting. If the exporting >> process is able to report once, that all reported flows share >> the same output interface, then the requirement is already met. >> >>> during the life of the monitor. Since you may not be sure >>> of the input interface of any packet at the egress interface, >>> why require that it be reported for any traffic? >>> >>>> >>>> Like Benoit below, I also would like to have more opinions >>>> on the issue how far the clearly existing requirements by >>>> metering applications should be loosened in the IPFIX >>>> requirements document because of assumed limitations of >>>> today's router architecture? >>>> >>>> Juergen >>>> >>>> >> >>>> > You've got a valid point.Why not a SHOULD? >>>> > >>>> > SHOULD This word, or the adjective "RECOMMENDED", >>>> mean that there >>>> > may exist valid reasons in particular circumstances >>>> to ignore a >>>> > particular item, but the full implications must be >>>> understood and >>>> > carefully weighed before choosing a different course. >>>> > >>>> > Any other opinion? >>>> > >>>> > Regards, Benoit. >>>> > >>>> >> >>>> >> >>>> >> Carter >>>> >> >>>> >> Carter Bullard >>>> >> QoSient, LLC >>>> >> 300 E. 56th Street >>>> >> Suite 18K >>>> >> New York, New York 10022 >>>> >> >>>> >> +1 212 588-9133 Phone >>>> >> +1 212 588-9134 Fax >>>> >> >>>> >> >>>> >> >>>> >>> -----Original Message----- >>>> >>> From: majordomo listserver >>>> [mailto:majordomo@mil.doit.wisc.edu] On >>>> >>> Behalf Of Benoit Claise >>>> >>> Sent: Friday, July 26, 2002 4:21 AM >>>> >>> To: ipfix-req@net.doit.wisc.edu >>>> >>> Subject: [ipfix-req] Section regarding multicast flows >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> Dave and All, >>>> >>> >>>> >>> Trying to incorporate all the proposed changes discussed >>>> both at the >>>> >>> IETF meeting and on the mailing list in the new requirement draft >>>> >>> version, I think that we should add a new section on multicast >>>> >>> >>>> >>> 5.7 Multicast Flows >>>> >>> >>>> >>> For a multicast packet replicated to multiple output >>>> interfaces, the >>>> >>> metering process SHOULD maintain discrete flow records >>>> per different >>>> >>> egress ifIndexes. For example an incoming multicast packet >>>> >>> that is replicated to four output interfaces would be >>>> >>> reported in four different flow records that differ by the >>>> >>> output interface. In case the metering process doesn't >>>> >>> maintain and report discrete flow records >>>> >>> per different egress ifIndexes for a multicast flow, the >>>> >>> metering process >>>> >>> SHOULD export the multicast replication factor in the flow record. >>>> >>> >>>> >>> >>>> >>> Furthermore, some extra changes are needed >>>> >>> The requirement draft was saying: >>>> >>> >>>> >>> 6.1. Information Model >>>> >>> ... >>>> >>> The exporting process MUST be able to report the following >>>> >>> attributes >>>> >>> for each measured flow: >>>> >>> ... >>>> >>> 8. output interface (ifIndex) >>>> >>> This requirement does not apply if the observation point is >>>> >>> located at a probe device. This requirement does not apply >>>> >>> in case of multicast flow records. >>>> >>> ... >>>> >>> The exporting process MAY be able to report the following >>>> >>> attributes >>>> >>> for each measured flow: >>>> >>> ... >>>> >>> 25. multicast replication factor >>>> >>> the number of outgoing packets originating from a single >>>> >>> incoming multicast packet >>>> >>> >>>> >>> 26. list of output interfaces for a multicast flow >>>> >>> >>>> >>> >>>> >>> I would propose: >>>> >>> >>>> >>> 6.1. Information Model >>>> >>> ... >>>> >>> The exporting process MUST be able to report the following >>>> >>> attributes >>>> >>> for each measured flow: >>>> >>> ... >>>> >>> 8. output interface (ifIndex) >>>> >>> This requirement does not apply if the observation point is >>>> >>> located at a probe device. _(ATTENTION: I REMOVED THE >>>> LINE ABOUT >>>> >>> MULTICAST)_ >>>> >>> ... >>>> >>> The exporting process _SHOULD_ be able to report the following >>>> >>> attributes >>>> >>> for each measured flow: >>>> >>> ... >>>> >>> X. multicast replication factor >>>> >>> The number of outgoing packets originating from a single >>>> >>> incoming multicast packet. This _multicast_ replication factor >>>> >>> SHOULD be reported, >>>> >>> but only SHOULD if the list of output interfaces for this >>>> >>> multicast >>>> >>> flow is not reported. >>>> >>> >>>> >>> _X+1. list of output interfaces for a multicast flow _(I WOULD >>>> >>> REMOVE IT >>>> >>> BECAUSE THIS IS EXPLAINED IN THE MULTICAST FLOW >>>> SECTION AND THE >>>> >>> LIMITATION >>>> >>> IN THE OUTPUT INTERFACE SECTION ABOVE IS REMOVED) >>>> >>> >>>> >>> >>>> >>> What do you think? >>>> >>> >>>> >>> Regards, Benoit >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> -- >>>> >>> Help mailto:majordomo@net.doit.wisc.edu and say "help" >>>> >>> in message body >>>> >>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>>> "unsubscribe >>>> >>> ipfix" in message body >>>> >>> Archive http://ipfix.doit.wisc.edu/archive/ >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >> >>>> >> >>>> >> >>>> >> -- >>>> >> Help mailto:majordomo@net.doit.wisc.edu and say >>>> "help" in message body >>>> >> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>>> "unsubscribe >>>> >> ipfix" in message body >>>> >> Archive http://ipfix.doit.wisc.edu/archive/ >>>> >> >>>> >> >>>> > >>>> > >>>> > >>>> > >>>> > -- >>>> > Help mailto:majordomo@net.doit.wisc.edu and say >>>> "help" in message body >>>> > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe >>>> > ipfix" in message body >>>> > Archive http://ipfix.doit.wisc.edu/archive/ >>>> >>>> >>>> >>>> -- >>>> Help mailto:majordomo@net.doit.wisc.edu and say "help" >>>> in message body >>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>>> "unsubscribe ipfix" in message body >>>> Archive http://ipfix.doit.wisc.edu/archive/ >>>> >>>> >>> >>> >> >> >> >> -- >> Help mailto:majordomo@net.doit.wisc.edu and say "help" in >> message body >> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >> "unsubscribe ipfix" in message body >> Archive http://ipfix.doit.wisc.edu/archive/ > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Aug 23 13:02:56 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11980 for ; Fri, 23 Aug 2002 13:02:55 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17iHd5-0006jt-00 for ipfix-list@mil.doit.wisc.edu; Fri, 23 Aug 2002 11:49:47 -0500 Received: from [64.95.122.60] (helo=RS-SC-EXC4.rs.riverstonenet.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17iHd3-0006jH-00 for ipfix-req@net.doit.wisc.edu; Fri, 23 Aug 2002 11:49:45 -0500 Received: from riverstonenet.com ([134.141.180.104]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 23 Aug 2002 09:48:51 -0700 Message-ID: <3D666710.80820C87@riverstonenet.com> Date: Fri, 23 Aug 2002 12:47:12 -0400 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Benoit Claise CC: Juergen Quittek , Carter Bullard , ipfix-req@net.doit.wisc.edu Subject: Re: Reportin in and out interfaces (was: RE: [ipfix-req] Sectionregarding multicast flows) References: <37866058.1029783113@[192.168.102.164]> <6309182.1030108692@[192.168.102.164]> <3D6662D5.5060902@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Aug 2002 16:48:52.0273 (UTC) FILETIME=[F619DA10:01C24AC4] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit If I understand correctly, if the observation point is the output interface then reporting the input interface is optional. And the other way around. If I got the packet by some other means, then neither of them are part of the observation point and thus are optional. But this still seems a little odd. Here is the definition of SHOUD from RFC 2119 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. Reading that, it sound like input and output interfaces should be SHOULD since it is not an absolute requirement. Paul Benoit Claise wrote: > > Juergen, > > > Hi all, > > > > I have a new suggestion which might solve our reporting problem > > for input and output interfaces. > > > > What about keeping input interface and output interfaces in the > > MUST list of attributes that the exporter is capable of reporting > > but changing the restriction as follows? > > > > 7. input interface (ifIndex) > > This requirement does only apply to flows for which the > > input interface is included in the observation point. > > But, it will always be the case? > > 2.2. Observation Point > The observation point is a location in the network where IP packets > can be observed. Examples are a line to which a probe is attached, a > shared medium, such as an Ethernet-based LAN, a single port of a > router, or a set of interfaces (physical or logical) of a router. > > If the observation point is an port (interface), yes the input interface > is the observation point > If the observation point is a set of ports (interfaces), yes the input > interface is part of the observation point > If the observation point is a line card, yes ... > If the observation point is a router, yes... > > What do I miss? > > > > > 8. output interface (ifIndex) > > This requirement does only apply to flows for which the > > output interface is included in the observation point. > > How are you solving that way the following issue? > - multicast > - load balancing issue > - flap conditions > > You are only solving the issue of: > - the output interface belongs to another line card, and we don't know > (yet) what it is > - the output interface is mirrored port (and it doesn't make sense to > report it) > > Regards, Benoit. > > > > > > > > > Juergen > > > > > > --On 19 August 2002 18:51 +0200 Juergen Quittek > > wrote: > > > >> Hi all, > >> > >> The discussion on reporting output/egress interfaces now has > >> extended to reporting input/ingress interfaces for flows. > >> > >> Please note that the requirements document only talks about > >> the ability to report it, and not about necessarily reporting > >> them in each record. > >> > >> An argument for not having both as MUST is that in several current > >> router architectures, it would be a big and costly effort to support > >> both. Also our AD directed us to try to standardize "existing > >> practice" and not to require new router architectures for IPFIX. > >> > >> However, there is a clear need for accurate reporting of interfaces > >> on the user side (from which requirements are derived). Reporting > >> on the origin and destination of a packet apparently is very important > >> for many metering-based applications. > >> > >> The positions explicitly stated so far are (please correct me, > >> if I'm wrong): > >> > >> - Carter proposes having both of them OPTIONAL. > >> - Paul is fine with the current draft version: bost MUST in general, > >> but SHOULD for egress in case of multicast. > >> - Dave seems to have a similar opinion. > >> - Benoit, Tanja, Sebastian, and myself think that the input/ingress > >> interface is essential, but that for all output/egress interfaces > >> a SHOULD would also be sufficient. > >> > >> Are there further opinions? > >> > >> Juergen > >> > >> > >> --On 15 August 2002 20:40 -0400 Carter Bullard > >> wrote: > >> > >>> > >>> Gentle people, > >>> This is pretty long, I do hope that some find it useful. > >>> > >>> Carter > >>> > >>>> >> In cases where there are valid exceptions to a > >>>> >> requirement candidate, a MUST generally converts to > >>>> >> a SHOULD or OPTIONAL. One reason for this is > >>>> >> you don't want to have to identify and manage > >>>> >> the complete list of possible exceptions during the > >>>> >> life of the RFC. You already have exceptions for > >>>> >> certain types of IPFIX devices and specific types > >>>> >> of traffic that don't require egress interface > >>>> >> reporting. That on its own might suggest that > >>>> > >>>> I think there is only one exception like that in > >>>> section 6.1.-8. saying that a probe does not need > >>>> to have the ability of reporting the output interface. > >>>> Please note that the same exception holds for the > >>>> input interface. > >>> > >>> > >>> From the perspective of a monitor that is internal > >>> to a switch or a router, the input interface identifier > >>> is historical and factual. The output interface > >>> identifier is always a predicted value, and as a result, > >>> a guess. > >> > >> > >> As much a guess as packet and octet counters for outgoing > >> traffic in mib-II? > >> > >>>> >> egress interface reporting should be OPTIONAL > >>>> >> in the Data Model. But if that is not compelling, > >>>> >> we may need to add more exceptions to the list than > >>>> >> are already there. > >>>> > >>>> Since the exception is the same for input and output > >>>> interface, we would consequently have to make the input > >>>> interface OPTIONAL as well, if we follow your argument. > >>>> > >>>> >> I can think of a few more types of traffic where > >>>> >> egress interface reporting may be challenging, such as > >>>> >> flow reporting under flap conditions, load balanced > >>>> >> traffic > >>>> >> > >>>> > You have 2 good examples here. > >>>> > > >>>> > >>>> Flap conditions and load balancing affect the > >>>> input interface as well as the output interface. > >>>> > >>>> >> and port mirrored traffic. In switches, > >>>> > >>>> I do not see your point concerning port mirrored traffic. > >>> > >>> > >>> Port mirroring in modern switches is generally implemented > >>> in hardware in a half-duplex fashion. When an ingress > >>> stream of an interface is mirrored, generally, the packet is > >>> latched to the mirrored port, as it is being read, if, of > >>> course, the outgoing port can handle it. Some vendors > >>> do the same thing with egress port mirroring, hardware > >>> latching both interfaces as the packet is being serialized > >>> out of the box. There is no status indication available to > >>> indicate whether the mirror port actually received the packet, > >>> or whether the mirror interface is actually up. The point is > >>> that no monitor could 'realize' whether a particular packet was > >>> actually transmitted to a mirrored interface, given existing > >>> commercial vendor designs. I've seen customers use egress > >>> interface mirroring for fault tolerance, and for some > >>> of these, they would love for IPFIX to support "multiple egress > >>> interface flow accounting". I'm not sure that anyone will > >>> ever be able to implement what these words really mean, inside a > >>> switch. > >>> > >>>> > >>>> >> broadcast traffic generates the same problem set as multicast > >>>> >> traffic. Also many switches, when presented with some arp table > >>>> >> issues, will broadcast unicast datagrams to all interfaces. Should > >>>> >> the multiple egress interfaces be reported in this case? That > >>>> >> condition > >>>> > >>>> Yes, if I configured the metering process in this way, > >>>> I would expect this. However, it might not be a good idea > >>>> to configure it this way. > >>> > >>> > >>> Well this is the nature of datagram flows in modern switches. > >>> If you are attempting to state what a flow monitor must do in > >>> order to do a decent job, and you decide that egress interface > >>> reporting is going to be a part of that, then you should take > >>> into consideration the normal modes of operation of a modern > >>> switch/router and correctly deal with those conditions. It > >>> is not a choice of configuration. > >> > >> > >> Well, it is. If I do egress interface reporting, I have the > >> choice of montoring IP only or monitoring both, IP and ARP. > >> > >>>> >> would persist, ideally, for only a few packets. Do > >>>> >> you generate multiple flow reports, one for the > >>>> >> broadcasted set of packets, and then one for the non broadcasted > >>>> >> flow? > >>>> > >>>> Same answer. > >>>> > >>>> > Well, for switches (layer 2 devices) I think that we > >>>> shouldn't report > >>>> > any flow records. Only the layer 3 devices should. > >>>> > > >>>> >> > >>>> >> One issue that comes up when considering multicast > >>>> >> egress interface reporting is that in most vendors > >>>> >> multicast implementations the multicast traffic is > >>>> >> delivered to every egress interface through hardware > >>>> broadcast, and > >>>> >> then output filters decide whether to forward the packet > >>>> or not. How > >>>> >> does this generalize in the IPFIX egress interface reporting > >>>> >> strategy? > >>>> > >>>> Wouldn'n these filters be a great location for collecting > >>>> multicast flow information? They anyway maintain a list of > >>>> multicast flows. The requirements suggest to collect > >>>> multicast information saparately for each egress. (And it > >>>> uses only SHOULD, not MUST for multicast traffic.) > >>> > >>> > >>> There is one very fundamental issue here. While the example > >>> used multicast traffic, the real issue is that switch vendors > >>> provide egress interface filtering for all network traffic. > >>> > >>> Is it better to report that a packet was intended for a > >>> particular interface, whether it was transmitted or not? > >>> Or is it better if the IPFIX monitor is implemented after > >>> all the filters and shapers, such that it doesn't see > >>> all the traffic that the router is dealing with? > >>> > >>> VLANs are almost universally enforced using egress > >>> interface filtering and there are many conditions where > >>> a switch will forward a packet to an interface that doesn't > >>> support a given VLAN, but it filters the packet, doing the > >>> right thing. Should IPFIX report that the box forwarded > >>> the flow to the interface, unaware that the packets will > >>> be filtered? Yes that seems reasonable, but you shouldn't > >>> use that record for accounting, because the device didn't > >>> really dispose of the packet in this simple fashion. > >>> > >>>> > >>>> >> Does the IPFIX Data Model need to understand egress interface > >>>> >> filtering behavior for all traffic types or just multicast? > >>>> > >>>> This heavily depends on the list of traffic types for > >>>> which egress filtring is used. I guess you don't use it > >>>> for TCP. > >>> > >>> > >>> Most vendors support filtering for specific TCP flags, > >>> say SYN packets, in their Access Control Lists > >>> and these are almost always implemented as a egress interface > >>> filter. > >>> > >>>> > >>>> >> It may be easier to just make egress interface > >>>> >> reporting an OPTIONAL feature, and then see if > >>>> >> any vendors can successfully implement it. > >>>> > >>>> This holds for most of the requirements. > >>>> But following your arguments: The multicast case > >>>> is not OPTIONAL, but SHOULD in the current reuqirements. > >>>> So, if a vendor faces serious problems implementing it, > >>>> the vendor will drop it. Here we have already what you > >>>> are asking for. > >>> > >>> > >>> I believe that reporting any interface, whether ingress > >>> or egress, should be OPTIONAL. > >>> > >>>> > >>>> All other arguments apply as well to the input interface. > >>>> But you ar not proposing to make this OPTIONAL. > >>>> > >>>> I think one important point behind your arguments is > >>>> that from a router architecture point of view, the most > >>>> obvious pace to locate the observation point and the metering > >>>> process is at the input interface, because similar > >>>> funtionality is required at this location anyway. But when > >>>> doing so it is not always easy to find otu the output interface. > >>>> > >>>> If a vendor locates the observation points at the output > >>>> interface (what I do not necessarily expect), then it might > >>>> face the inverse problem of not necessarily knowing the input > >>>> interface. > >>> > >>> > >>> If the IPFIX device is monitoring at the egress interface, > >>> then why put the egress id in every record. It won't change > >> > >> > >> The requirements is not at all about putting something in > >> every packet, it is just about reporting. If the exporting > >> process is able to report once, that all reported flows share > >> the same output interface, then the requirement is already met. > >> > >>> during the life of the monitor. Since you may not be sure > >>> of the input interface of any packet at the egress interface, > >>> why require that it be reported for any traffic? > >>> > >>>> > >>>> Like Benoit below, I also would like to have more opinions > >>>> on the issue how far the clearly existing requirements by > >>>> metering applications should be loosened in the IPFIX > >>>> requirements document because of assumed limitations of > >>>> today's router architecture? > >>>> > >>>> Juergen > >>>> > >>>> >> > >>>> > You've got a valid point.Why not a SHOULD? > >>>> > > >>>> > SHOULD This word, or the adjective "RECOMMENDED", > >>>> mean that there > >>>> > may exist valid reasons in particular circumstances > >>>> to ignore a > >>>> > particular item, but the full implications must be > >>>> understood and > >>>> > carefully weighed before choosing a different course. > >>>> > > >>>> > Any other opinion? > >>>> > > >>>> > Regards, Benoit. > >>>> > > >>>> >> > >>>> >> > >>>> >> Carter > >>>> >> > >>>> >> Carter Bullard > >>>> >> QoSient, LLC > >>>> >> 300 E. 56th Street > >>>> >> Suite 18K > >>>> >> New York, New York 10022 > >>>> >> > >>>> >> +1 212 588-9133 Phone > >>>> >> +1 212 588-9134 Fax > >>>> >> > >>>> >> > >>>> >> > >>>> >>> -----Original Message----- > >>>> >>> From: majordomo listserver > >>>> [mailto:majordomo@mil.doit.wisc.edu] On > >>>> >>> Behalf Of Benoit Claise > >>>> >>> Sent: Friday, July 26, 2002 4:21 AM > >>>> >>> To: ipfix-req@net.doit.wisc.edu > >>>> >>> Subject: [ipfix-req] Section regarding multicast flows > >>>> >>> > >>>> >>> > >>>> >>> > >>>> >>> > >>>> >>> Dave and All, > >>>> >>> > >>>> >>> Trying to incorporate all the proposed changes discussed > >>>> both at the > >>>> >>> IETF meeting and on the mailing list in the new requirement draft > >>>> >>> version, I think that we should add a new section on multicast > >>>> >>> > >>>> >>> 5.7 Multicast Flows > >>>> >>> > >>>> >>> For a multicast packet replicated to multiple output > >>>> interfaces, the > >>>> >>> metering process SHOULD maintain discrete flow records > >>>> per different > >>>> >>> egress ifIndexes. For example an incoming multicast packet > >>>> >>> that is replicated to four output interfaces would be > >>>> >>> reported in four different flow records that differ by the > >>>> >>> output interface. In case the metering process doesn't > >>>> >>> maintain and report discrete flow records > >>>> >>> per different egress ifIndexes for a multicast flow, the > >>>> >>> metering process > >>>> >>> SHOULD export the multicast replication factor in the flow record. > >>>> >>> > >>>> >>> > >>>> >>> Furthermore, some extra changes are needed > >>>> >>> The requirement draft was saying: > >>>> >>> > >>>> >>> 6.1. Information Model > >>>> >>> ... > >>>> >>> The exporting process MUST be able to report the following > >>>> >>> attributes > >>>> >>> for each measured flow: > >>>> >>> ... > >>>> >>> 8. output interface (ifIndex) > >>>> >>> This requirement does not apply if the observation point is > >>>> >>> located at a probe device. This requirement does not apply > >>>> >>> in case of multicast flow records. > >>>> >>> ... > >>>> >>> The exporting process MAY be able to report the following > >>>> >>> attributes > >>>> >>> for each measured flow: > >>>> >>> ... > >>>> >>> 25. multicast replication factor > >>>> >>> the number of outgoing packets originating from a single > >>>> >>> incoming multicast packet > >>>> >>> > >>>> >>> 26. list of output interfaces for a multicast flow > >>>> >>> > >>>> >>> > >>>> >>> I would propose: > >>>> >>> > >>>> >>> 6.1. Information Model > >>>> >>> ... > >>>> >>> The exporting process MUST be able to report the following > >>>> >>> attributes > >>>> >>> for each measured flow: > >>>> >>> ... > >>>> >>> 8. output interface (ifIndex) > >>>> >>> This requirement does not apply if the observation point is > >>>> >>> located at a probe device. _(ATTENTION: I REMOVED THE > >>>> LINE ABOUT > >>>> >>> MULTICAST)_ > >>>> >>> ... > >>>> >>> The exporting process _SHOULD_ be able to report the following > >>>> >>> attributes > >>>> >>> for each measured flow: > >>>> >>> ... > >>>> >>> X. multicast replication factor > >>>> >>> The number of outgoing packets originating from a single > >>>> >>> incoming multicast packet. This _multicast_ replication factor > >>>> >>> SHOULD be reported, > >>>> >>> but only SHOULD if the list of output interfaces for this > >>>> >>> multicast > >>>> >>> flow is not reported. > >>>> >>> > >>>> >>> _X+1. list of output interfaces for a multicast flow _(I WOULD > >>>> >>> REMOVE IT > >>>> >>> BECAUSE THIS IS EXPLAINED IN THE MULTICAST FLOW > >>>> SECTION AND THE > >>>> >>> LIMITATION > >>>> >>> IN THE OUTPUT INTERFACE SECTION ABOVE IS REMOVED) > >>>> >>> > >>>> >>> > >>>> >>> What do you think? > >>>> >>> > >>>> >>> Regards, Benoit > >>>> >>> > >>>> >>> > >>>> >>> > >>>> >>> > >>>> >>> -- > >>>> >>> Help mailto:majordomo@net.doit.wisc.edu and say "help" > >>>> >>> in message body > >>>> >>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > >>>> "unsubscribe > >>>> >>> ipfix" in message body > >>>> >>> Archive http://ipfix.doit.wisc.edu/archive/ > >>>> >>> > >>>> >>> > >>>> >>> > >>>> >>> > >>>> >> > >>>> >> > >>>> >> > >>>> >> -- > >>>> >> Help mailto:majordomo@net.doit.wisc.edu and say > >>>> "help" in message body > >>>> >> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > >>>> "unsubscribe > >>>> >> ipfix" in message body > >>>> >> Archive http://ipfix.doit.wisc.edu/archive/ > >>>> >> > >>>> >> > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > -- > >>>> > Help mailto:majordomo@net.doit.wisc.edu and say > >>>> "help" in message body > >>>> > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe > >>>> > ipfix" in message body > >>>> > Archive http://ipfix.doit.wisc.edu/archive/ > >>>> > >>>> > >>>> > >>>> -- > >>>> Help mailto:majordomo@net.doit.wisc.edu and say "help" > >>>> in message body > >>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > >>>> "unsubscribe ipfix" in message body > >>>> Archive http://ipfix.doit.wisc.edu/archive/ > >>>> > >>>> > >>> > >>> > >> > >> > >> > >> -- > >> Help mailto:majordomo@net.doit.wisc.edu and say "help" in > >> message body > >> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > >> "unsubscribe ipfix" in message body > >> Archive http://ipfix.doit.wisc.edu/archive/ > > > > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Aug 23 13:38:21 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12729 for ; Fri, 23 Aug 2002 13:38:20 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17iIFi-0007eo-00 for ipfix-list@mil.doit.wisc.edu; Fri, 23 Aug 2002 12:29:42 -0500 Received: from mailhub.fokus.gmd.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17iIFf-0007eh-00 for ipfix-req@net.doit.wisc.edu; Fri, 23 Aug 2002 12:29:39 -0500 Received: from fokus.gmd.de (dhcp229 [195.37.78.229]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g7NHTb202123 for ; Fri, 23 Aug 2002 19:29:38 +0200 (MEST) Message-ID: <3D66708C.8070307@fokus.gmd.de> Date: Fri, 23 Aug 2002 19:27:40 +0200 From: Sebastian Zander Organization: Fraunhofer FOKUS User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: de-DE MIME-Version: 1.0 To: ipfix-req@net.doit.wisc.edu Subject: [ipfix-req] add config requirement: report interval Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi, I propose to add a new requirement to the requirements draft section 7.2 (SHOULD requirement list): 5. the report interval in case the exporting process is capable of reporting in regular intervals Cheers, Sebastian -- Sebastian Zander E-mail: zander@fokus.fhg.de FhI FOKUS / Global Networking (GloNe) Tel: +49-30-3463-7287 Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 D-10589 Berlin, Germany www.fokus.fhg.de/usr/sebastian.zander -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Aug 23 15:14:11 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15043 for ; Fri, 23 Aug 2002 15:14:10 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17iJed-0001p0-00 for ipfix-list@mil.doit.wisc.edu; Fri, 23 Aug 2002 13:59:31 -0500 Received: from sj-msg-core-3.cisco.com ([171.70.157.152]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17iJea-0001oI-00 for ipfix-req@net.doit.wisc.edu; Fri, 23 Aug 2002 13:59:28 -0500 Received: from mira-sjcd-1.cisco.com (IDENT:mirapoint@mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g7NIwb41029879; Fri, 23 Aug 2002 11:58:38 -0700 (PDT) Received: from cisco.com (dhcp-171-71-126-140.cisco.com [171.71.126.140]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ADI68020; Fri, 23 Aug 2002 11:59:07 -0700 (PDT) Message-ID: <3D6685DD.4526FC7F@cisco.com> Date: Fri, 23 Aug 2002 11:58:38 -0700 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: calato@riverstonenet.com CC: Benoit Claise , Juergen Quittek , Carter Bullard , ipfix-req@net.doit.wisc.edu Subject: Re: Reportin in and out interfaces (was: RE: [ipfix-req] Sectionregarding multicast flows) References: <37866058.1029783113@[192.168.102.164]> <6309182.1030108692@[192.168.102.164]> <3D6662D5.5060902@cisco.com> <3D666710.80820C87@riverstonenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit calato@riverstonenet.com wrote: > If I understand correctly, if the observation point > is the output interface then reporting the input interface > is optional. And the other way around. Agreed. > If I got the packet > by some other means, then neither of them are part of the > observation point and thus are optional. Can give an example for the case of "some other means"? Ganesh > > > But this still seems a little odd. Here is the definition of > SHOUD from RFC 2119 > > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course. > > Reading that, it sound like input and output interfaces should > be SHOULD since it is not an absolute requirement. > > Paul > > Benoit Claise wrote: > > > > Juergen, > > > > > Hi all, > > > > > > I have a new suggestion which might solve our reporting problem > > > for input and output interfaces. > > > > > > What about keeping input interface and output interfaces in the > > > MUST list of attributes that the exporter is capable of reporting > > > but changing the restriction as follows? > > > > > > 7. input interface (ifIndex) > > > This requirement does only apply to flows for which the > > > input interface is included in the observation point. > > > > But, it will always be the case? > > > > 2.2. Observation Point > > The observation point is a location in the network where IP packets > > can be observed. Examples are a line to which a probe is attached, a > > shared medium, such as an Ethernet-based LAN, a single port of a > > router, or a set of interfaces (physical or logical) of a router. > > > > If the observation point is an port (interface), yes the input interface > > is the observation point > > If the observation point is a set of ports (interfaces), yes the input > > interface is part of the observation point > > If the observation point is a line card, yes ... > > If the observation point is a router, yes... > > > > What do I miss? > > > > > > > > 8. output interface (ifIndex) > > > This requirement does only apply to flows for which the > > > output interface is included in the observation point. > > > > How are you solving that way the following issue? > > - multicast > > - load balancing issue > > - flap conditions > > > > You are only solving the issue of: > > - the output interface belongs to another line card, and we don't know > > (yet) what it is > > - the output interface is mirrored port (and it doesn't make sense to > > report it) > > > > Regards, Benoit. > > > > > > > > > > > > > > Juergen > > > > > > > > > --On 19 August 2002 18:51 +0200 Juergen Quittek > > > wrote: > > > > > >> Hi all, > > >> > > >> The discussion on reporting output/egress interfaces now has > > >> extended to reporting input/ingress interfaces for flows. > > >> > > >> Please note that the requirements document only talks about > > >> the ability to report it, and not about necessarily reporting > > >> them in each record. > > >> > > >> An argument for not having both as MUST is that in several current > > >> router architectures, it would be a big and costly effort to support > > >> both. Also our AD directed us to try to standardize "existing > > >> practice" and not to require new router architectures for IPFIX. > > >> > > >> However, there is a clear need for accurate reporting of interfaces > > >> on the user side (from which requirements are derived). Reporting > > >> on the origin and destination of a packet apparently is very important > > >> for many metering-based applications. > > >> > > >> The positions explicitly stated so far are (please correct me, > > >> if I'm wrong): > > >> > > >> - Carter proposes having both of them OPTIONAL. > > >> - Paul is fine with the current draft version: bost MUST in general, > > >> but SHOULD for egress in case of multicast. > > >> - Dave seems to have a similar opinion. > > >> - Benoit, Tanja, Sebastian, and myself think that the input/ingress > > >> interface is essential, but that for all output/egress interfaces > > >> a SHOULD would also be sufficient. > > >> > > >> Are there further opinions? > > >> > > >> Juergen > > >> > > >> > > >> --On 15 August 2002 20:40 -0400 Carter Bullard > > >> wrote: > > >> > > >>> > > >>> Gentle people, > > >>> This is pretty long, I do hope that some find it useful. > > >>> > > >>> Carter > > >>> > > >>>> >> In cases where there are valid exceptions to a > > >>>> >> requirement candidate, a MUST generally converts to > > >>>> >> a SHOULD or OPTIONAL. One reason for this is > > >>>> >> you don't want to have to identify and manage > > >>>> >> the complete list of possible exceptions during the > > >>>> >> life of the RFC. You already have exceptions for > > >>>> >> certain types of IPFIX devices and specific types > > >>>> >> of traffic that don't require egress interface > > >>>> >> reporting. That on its own might suggest that > > >>>> > > >>>> I think there is only one exception like that in > > >>>> section 6.1.-8. saying that a probe does not need > > >>>> to have the ability of reporting the output interface. > > >>>> Please note that the same exception holds for the > > >>>> input interface. > > >>> > > >>> > > >>> From the perspective of a monitor that is internal > > >>> to a switch or a router, the input interface identifier > > >>> is historical and factual. The output interface > > >>> identifier is always a predicted value, and as a result, > > >>> a guess. > > >> > > >> > > >> As much a guess as packet and octet counters for outgoing > > >> traffic in mib-II? > > >> > > >>>> >> egress interface reporting should be OPTIONAL > > >>>> >> in the Data Model. But if that is not compelling, > > >>>> >> we may need to add more exceptions to the list than > > >>>> >> are already there. > > >>>> > > >>>> Since the exception is the same for input and output > > >>>> interface, we would consequently have to make the input > > >>>> interface OPTIONAL as well, if we follow your argument. > > >>>> > > >>>> >> I can think of a few more types of traffic where > > >>>> >> egress interface reporting may be challenging, such as > > >>>> >> flow reporting under flap conditions, load balanced > > >>>> >> traffic > > >>>> >> > > >>>> > You have 2 good examples here. > > >>>> > > > >>>> > > >>>> Flap conditions and load balancing affect the > > >>>> input interface as well as the output interface. > > >>>> > > >>>> >> and port mirrored traffic. In switches, > > >>>> > > >>>> I do not see your point concerning port mirrored traffic. > > >>> > > >>> > > >>> Port mirroring in modern switches is generally implemented > > >>> in hardware in a half-duplex fashion. When an ingress > > >>> stream of an interface is mirrored, generally, the packet is > > >>> latched to the mirrored port, as it is being read, if, of > > >>> course, the outgoing port can handle it. Some vendors > > >>> do the same thing with egress port mirroring, hardware > > >>> latching both interfaces as the packet is being serialized > > >>> out of the box. There is no status indication available to > > >>> indicate whether the mirror port actually received the packet, > > >>> or whether the mirror interface is actually up. The point is > > >>> that no monitor could 'realize' whether a particular packet was > > >>> actually transmitted to a mirrored interface, given existing > > >>> commercial vendor designs. I've seen customers use egress > > >>> interface mirroring for fault tolerance, and for some > > >>> of these, they would love for IPFIX to support "multiple egress > > >>> interface flow accounting". I'm not sure that anyone will > > >>> ever be able to implement what these words really mean, inside a > > >>> switch. > > >>> > > >>>> > > >>>> >> broadcast traffic generates the same problem set as multicast > > >>>> >> traffic. Also many switches, when presented with some arp table > > >>>> >> issues, will broadcast unicast datagrams to all interfaces. Should > > >>>> >> the multiple egress interfaces be reported in this case? That > > >>>> >> condition > > >>>> > > >>>> Yes, if I configured the metering process in this way, > > >>>> I would expect this. However, it might not be a good idea > > >>>> to configure it this way. > > >>> > > >>> > > >>> Well this is the nature of datagram flows in modern switches. > > >>> If you are attempting to state what a flow monitor must do in > > >>> order to do a decent job, and you decide that egress interface > > >>> reporting is going to be a part of that, then you should take > > >>> into consideration the normal modes of operation of a modern > > >>> switch/router and correctly deal with those conditions. It > > >>> is not a choice of configuration. > > >> > > >> > > >> Well, it is. If I do egress interface reporting, I have the > > >> choice of montoring IP only or monitoring both, IP and ARP. > > >> > > >>>> >> would persist, ideally, for only a few packets. Do > > >>>> >> you generate multiple flow reports, one for the > > >>>> >> broadcasted set of packets, and then one for the non broadcasted > > >>>> >> flow? > > >>>> > > >>>> Same answer. > > >>>> > > >>>> > Well, for switches (layer 2 devices) I think that we > > >>>> shouldn't report > > >>>> > any flow records. Only the layer 3 devices should. > > >>>> > > > >>>> >> > > >>>> >> One issue that comes up when considering multicast > > >>>> >> egress interface reporting is that in most vendors > > >>>> >> multicast implementations the multicast traffic is > > >>>> >> delivered to every egress interface through hardware > > >>>> broadcast, and > > >>>> >> then output filters decide whether to forward the packet > > >>>> or not. How > > >>>> >> does this generalize in the IPFIX egress interface reporting > > >>>> >> strategy? > > >>>> > > >>>> Wouldn'n these filters be a great location for collecting > > >>>> multicast flow information? They anyway maintain a list of > > >>>> multicast flows. The requirements suggest to collect > > >>>> multicast information saparately for each egress. (And it > > >>>> uses only SHOULD, not MUST for multicast traffic.) > > >>> > > >>> > > >>> There is one very fundamental issue here. While the example > > >>> used multicast traffic, the real issue is that switch vendors > > >>> provide egress interface filtering for all network traffic. > > >>> > > >>> Is it better to report that a packet was intended for a > > >>> particular interface, whether it was transmitted or not? > > >>> Or is it better if the IPFIX monitor is implemented after > > >>> all the filters and shapers, such that it doesn't see > > >>> all the traffic that the router is dealing with? > > >>> > > >>> VLANs are almost universally enforced using egress > > >>> interface filtering and there are many conditions where > > >>> a switch will forward a packet to an interface that doesn't > > >>> support a given VLAN, but it filters the packet, doing the > > >>> right thing. Should IPFIX report that the box forwarded > > >>> the flow to the interface, unaware that the packets will > > >>> be filtered? Yes that seems reasonable, but you shouldn't > > >>> use that record for accounting, because the device didn't > > >>> really dispose of the packet in this simple fashion. > > >>> > > >>>> > > >>>> >> Does the IPFIX Data Model need to understand egress interface > > >>>> >> filtering behavior for all traffic types or just multicast? > > >>>> > > >>>> This heavily depends on the list of traffic types for > > >>>> which egress filtring is used. I guess you don't use it > > >>>> for TCP. > > >>> > > >>> > > >>> Most vendors support filtering for specific TCP flags, > > >>> say SYN packets, in their Access Control Lists > > >>> and these are almost always implemented as a egress interface > > >>> filter. > > >>> > > >>>> > > >>>> >> It may be easier to just make egress interface > > >>>> >> reporting an OPTIONAL feature, and then see if > > >>>> >> any vendors can successfully implement it. > > >>>> > > >>>> This holds for most of the requirements. > > >>>> But following your arguments: The multicast case > > >>>> is not OPTIONAL, but SHOULD in the current reuqirements. > > >>>> So, if a vendor faces serious problems implementing it, > > >>>> the vendor will drop it. Here we have already what you > > >>>> are asking for. > > >>> > > >>> > > >>> I believe that reporting any interface, whether ingress > > >>> or egress, should be OPTIONAL. > > >>> > > >>>> > > >>>> All other arguments apply as well to the input interface. > > >>>> But you ar not proposing to make this OPTIONAL. > > >>>> > > >>>> I think one important point behind your arguments is > > >>>> that from a router architecture point of view, the most > > >>>> obvious pace to locate the observation point and the metering > > >>>> process is at the input interface, because similar > > >>>> funtionality is required at this location anyway. But when > > >>>> doing so it is not always easy to find otu the output interface. > > >>>> > > >>>> If a vendor locates the observation points at the output > > >>>> interface (what I do not necessarily expect), then it might > > >>>> face the inverse problem of not necessarily knowing the input > > >>>> interface. > > >>> > > >>> > > >>> If the IPFIX device is monitoring at the egress interface, > > >>> then why put the egress id in every record. It won't change > > >> > > >> > > >> The requirements is not at all about putting something in > > >> every packet, it is just about reporting. If the exporting > > >> process is able to report once, that all reported flows share > > >> the same output interface, then the requirement is already met. > > >> > > >>> during the life of the monitor. Since you may not be sure > > >>> of the input interface of any packet at the egress interface, > > >>> why require that it be reported for any traffic? > > >>> > > >>>> > > >>>> Like Benoit below, I also would like to have more opinions > > >>>> on the issue how far the clearly existing requirements by > > >>>> metering applications should be loosened in the IPFIX > > >>>> requirements document because of assumed limitations of > > >>>> today's router architecture? > > >>>> > > >>>> Juergen > > >>>> > > >>>> >> > > >>>> > You've got a valid point.Why not a SHOULD? > > >>>> > > > >>>> > SHOULD This word, or the adjective "RECOMMENDED", > > >>>> mean that there > > >>>> > may exist valid reasons in particular circumstances > > >>>> to ignore a > > >>>> > particular item, but the full implications must be > > >>>> understood and > > >>>> > carefully weighed before choosing a different course. > > >>>> > > > >>>> > Any other opinion? > > >>>> > > > >>>> > Regards, Benoit. > > >>>> > > > >>>> >> > > >>>> >> > > >>>> >> Carter > > >>>> >> > > >>>> >> Carter Bullard > > >>>> >> QoSient, LLC > > >>>> >> 300 E. 56th Street > > >>>> >> Suite 18K > > >>>> >> New York, New York 10022 > > >>>> >> > > >>>> >> +1 212 588-9133 Phone > > >>>> >> +1 212 588-9134 Fax > > >>>> >> > > >>>> >> > > >>>> >> > > >>>> >>> -----Original Message----- > > >>>> >>> From: majordomo listserver > > >>>> [mailto:majordomo@mil.doit.wisc.edu] On > > >>>> >>> Behalf Of Benoit Claise > > >>>> >>> Sent: Friday, July 26, 2002 4:21 AM > > >>>> >>> To: ipfix-req@net.doit.wisc.edu > > >>>> >>> Subject: [ipfix-req] Section regarding multicast flows > > >>>> >>> > > >>>> >>> > > >>>> >>> > > >>>> >>> > > >>>> >>> Dave and All, > > >>>> >>> > > >>>> >>> Trying to incorporate all the proposed changes discussed > > >>>> both at the > > >>>> >>> IETF meeting and on the mailing list in the new requirement draft > > >>>> >>> version, I think that we should add a new section on multicast > > >>>> >>> > > >>>> >>> 5.7 Multicast Flows > > >>>> >>> > > >>>> >>> For a multicast packet replicated to multiple output > > >>>> interfaces, the > > >>>> >>> metering process SHOULD maintain discrete flow records > > >>>> per different > > >>>> >>> egress ifIndexes. For example an incoming multicast packet > > >>>> >>> that is replicated to four output interfaces would be > > >>>> >>> reported in four different flow records that differ by the > > >>>> >>> output interface. In case the metering process doesn't > > >>>> >>> maintain and report discrete flow records > > >>>> >>> per different egress ifIndexes for a multicast flow, the > > >>>> >>> metering process > > >>>> >>> SHOULD export the multicast replication factor in the flow record. > > >>>> >>> > > >>>> >>> > > >>>> >>> Furthermore, some extra changes are needed > > >>>> >>> The requirement draft was saying: > > >>>> >>> > > >>>> >>> 6.1. Information Model > > >>>> >>> ... > > >>>> >>> The exporting process MUST be able to report the following > > >>>> >>> attributes > > >>>> >>> for each measured flow: > > >>>> >>> ... > > >>>> >>> 8. output interface (ifIndex) > > >>>> >>> This requirement does not apply if the observation point is > > >>>> >>> located at a probe device. This requirement does not apply > > >>>> >>> in case of multicast flow records. > > >>>> >>> ... > > >>>> >>> The exporting process MAY be able to report the following > > >>>> >>> attributes > > >>>> >>> for each measured flow: > > >>>> >>> ... > > >>>> >>> 25. multicast replication factor > > >>>> >>> the number of outgoing packets originating from a single > > >>>> >>> incoming multicast packet > > >>>> >>> > > >>>> >>> 26. list of output interfaces for a multicast flow > > >>>> >>> > > >>>> >>> > > >>>> >>> I would propose: > > >>>> >>> > > >>>> >>> 6.1. Information Model > > >>>> >>> ... > > >>>> >>> The exporting process MUST be able to report the following > > >>>> >>> attributes > > >>>> >>> for each measured flow: > > >>>> >>> ... > > >>>> >>> 8. output interface (ifIndex) > > >>>> >>> This requirement does not apply if the observation point is > > >>>> >>> located at a probe device. _(ATTENTION: I REMOVED THE > > >>>> LINE ABOUT > > >>>> >>> MULTICAST)_ > > >>>> >>> ... > > >>>> >>> The exporting process _SHOULD_ be able to report the following > > >>>> >>> attributes > > >>>> >>> for each measured flow: > > >>>> >>> ... > > >>>> >>> X. multicast replication factor > > >>>> >>> The number of outgoing packets originating from a single > > >>>> >>> incoming multicast packet. This _multicast_ replication factor > > >>>> >>> SHOULD be reported, > > >>>> >>> but only SHOULD if the list of output interfaces for this > > >>>> >>> multicast > > >>>> >>> flow is not reported. > > >>>> >>> > > >>>> >>> _X+1. list of output interfaces for a multicast flow _(I WOULD > > >>>> >>> REMOVE IT > > >>>> >>> BECAUSE THIS IS EXPLAINED IN THE MULTICAST FLOW > > >>>> SECTION AND THE > > >>>> >>> LIMITATION > > >>>> >>> IN THE OUTPUT INTERFACE SECTION ABOVE IS REMOVED) > > >>>> >>> > > >>>> >>> > > >>>> >>> What do you think? > > >>>> >>> > > >>>> >>> Regards, Benoit > > >>>> >>> > > >>>> >>> > > >>>> >>> > > >>>> >>> > > >>>> >>> -- > > >>>> >>> Help mailto:majordomo@net.doit.wisc.edu and say "help" > > >>>> >>> in message body > > >>>> >>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > >>>> "unsubscribe > > >>>> >>> ipfix" in message body > > >>>> >>> Archive http://ipfix.doit.wisc.edu/archive/ > > >>>> >>> > > >>>> >>> > > >>>> >>> > > >>>> >>> > > >>>> >> > > >>>> >> > > >>>> >> > > >>>> >> -- > > >>>> >> Help mailto:majordomo@net.doit.wisc.edu and say > > >>>> "help" in message body > > >>>> >> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > >>>> "unsubscribe > > >>>> >> ipfix" in message body > > >>>> >> Archive http://ipfix.doit.wisc.edu/archive/ > > >>>> >> > > >>>> >> > > >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>> > -- > > >>>> > Help mailto:majordomo@net.doit.wisc.edu and say > > >>>> "help" in message body > > >>>> > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe > > >>>> > ipfix" in message body > > >>>> > Archive http://ipfix.doit.wisc.edu/archive/ > > >>>> > > >>>> > > >>>> > > >>>> -- > > >>>> Help mailto:majordomo@net.doit.wisc.edu and say "help" > > >>>> in message body > > >>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > >>>> "unsubscribe ipfix" in message body > > >>>> Archive http://ipfix.doit.wisc.edu/archive/ > > >>>> > > >>>> > > >>> > > >>> > > >> > > >> > > >> > > >> -- > > >> Help mailto:majordomo@net.doit.wisc.edu and say "help" in > > >> message body > > >> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > >> "unsubscribe ipfix" in message body > > >> Archive http://ipfix.doit.wisc.edu/archive/ > > > > > > > > > > -- > > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > "unsubscribe ipfix" in message body > > Archive http://ipfix.doit.wisc.edu/archive/ > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Aug 23 16:13:36 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16429 for ; Fri, 23 Aug 2002 16:13:35 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17iKb1-0003Gy-00 for ipfix-list@mil.doit.wisc.edu; Fri, 23 Aug 2002 14:59:51 -0500 Received: from [64.95.122.60] (helo=RS-SC-EXC4.rs.riverstonenet.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17iKay-0003Gc-00 for ipfix@net.doit.wisc.edu; Fri, 23 Aug 2002 14:59:48 -0500 Received: from riverstonenet.com ([134.141.180.104]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 23 Aug 2002 12:59:03 -0700 Message-ID: <3D6693A4.3D8012B@riverstonenet.com> Date: Fri, 23 Aug 2002 15:57:24 -0400 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ipfixx Subject: [ipfix] [Fwd: Reportin in and out interfaces (was: RE: [ipfix-req] Sectionregarding multicast flows)] Content-Type: multipart/mixed; boundary="------------32A695CE8FA02A843DF848A9" X-OriginalArrivalTime: 23 Aug 2002 19:59:04.0524 (UTC) FILETIME=[885528C0:01C24ADF] Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------32A695CE8FA02A843DF848A9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Forgot to copy the list. --------------32A695CE8FA02A843DF848A9 Content-Type: message/rfc822 Content-Disposition: inline X-Mozilla-Status2: 00000000 Message-ID: <3D668A6C.467DEF73@riverstonenet.com> Date: Fri, 23 Aug 2002 15:18:04 -0400 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Ganesh Sadasivan Subject: Re: Reportin in and out interfaces (was: RE: [ipfix-req] Sectionregarding multicast flows) References: <37866058.1029783113@[192.168.102.164]> <6309182.1030108692@[192.168.102.164]> <3D6662D5.5060902@cisco.com> <3D666710.80820C87@riverstonenet.com> <3D6685DD.4526FC7F@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ganesh Sadasivan wrote: > > calato@riverstonenet.com wrote: > > > If I understand correctly, if the observation point > > is the output interface then reporting the input interface > > is optional. And the other way around. > > Agreed. > > > If I got the packet > > by some other means, then neither of them are part of the > > observation point and thus are optional. > > Can give an example for the case of "some other means"? > Ganesh I did not have one in mind but was just following the text to its logical conclusion to show that, according to the text, both are optional. > > > > > > > But this still seems a little odd. Here is the definition of > > SHOUD from RFC 2119 > > > > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there > > may exist valid reasons in particular circumstances to ignore a > > particular item, but the full implications must be understood and > > carefully weighed before choosing a different course. > > > > Reading that, it sound like input and output interfaces should > > be SHOULD since it is not an absolute requirement. > > > > Paul > > > > Benoit Claise wrote: > > > > > > Juergen, > > > > > > > Hi all, > > > > > > > > I have a new suggestion which might solve our reporting problem > > > > for input and output interfaces. > > > > > > > > What about keeping input interface and output interfaces in the > > > > MUST list of attributes that the exporter is capable of reporting > > > > but changing the restriction as follows? > > > > > > > > 7. input interface (ifIndex) > > > > This requirement does only apply to flows for which the > > > > input interface is included in the observation point. > > > > > > But, it will always be the case? > > > > > > 2.2. Observation Point > > > The observation point is a location in the network where IP packets > > > can be observed. Examples are a line to which a probe is attached, a > > > shared medium, such as an Ethernet-based LAN, a single port of a > > > router, or a set of interfaces (physical or logical) of a router. > > > > > > If the observation point is an port (interface), yes the input interface > > > is the observation point > > > If the observation point is a set of ports (interfaces), yes the input > > > interface is part of the observation point > > > If the observation point is a line card, yes ... > > > If the observation point is a router, yes... > > > > > > What do I miss? > > > > > > > > > > > 8. output interface (ifIndex) > > > > This requirement does only apply to flows for which the > > > > output interface is included in the observation point. > > > > > > How are you solving that way the following issue? > > > - multicast > > > - load balancing issue > > > - flap conditions > > > > > > You are only solving the issue of: > > > - the output interface belongs to another line card, and we don't know > > > (yet) what it is > > > - the output interface is mirrored port (and it doesn't make sense to > > > report it) > > > > > > Regards, Benoit. > > > > > > > > > > > > > > > > > > > Juergen > > > > > > > > > > > > --On 19 August 2002 18:51 +0200 Juergen Quittek > > > > wrote: > > > > > > > >> Hi all, > > > >> > > > >> The discussion on reporting output/egress interfaces now has > > > >> extended to reporting input/ingress interfaces for flows. > > > >> > > > >> Please note that the requirements document only talks about > > > >> the ability to report it, and not about necessarily reporting > > > >> them in each record. > > > >> > > > >> An argument for not having both as MUST is that in several current > > > >> router architectures, it would be a big and costly effort to support > > > >> both. Also our AD directed us to try to standardize "existing > > > >> practice" and not to require new router architectures for IPFIX. > > > >> > > > >> However, there is a clear need for accurate reporting of interfaces > > > >> on the user side (from which requirements are derived). Reporting > > > >> on the origin and destination of a packet apparently is very important > > > >> for many metering-based applications. > > > >> > > > >> The positions explicitly stated so far are (please correct me, > > > >> if I'm wrong): > > > >> > > > >> - Carter proposes having both of them OPTIONAL. > > > >> - Paul is fine with the current draft version: bost MUST in general, > > > >> but SHOULD for egress in case of multicast. > > > >> - Dave seems to have a similar opinion. > > > >> - Benoit, Tanja, Sebastian, and myself think that the input/ingress > > > >> interface is essential, but that for all output/egress interfaces > > > >> a SHOULD would also be sufficient. > > > >> > > > >> Are there further opinions? > > > >> > > > >> Juergen > > > >> > > > >> > > > >> --On 15 August 2002 20:40 -0400 Carter Bullard > > > >> wrote: > > > >> > > > >>> > > > >>> Gentle people, > > > >>> This is pretty long, I do hope that some find it useful. > > > >>> > > > >>> Carter > > > >>> > > > >>>> >> In cases where there are valid exceptions to a > > > >>>> >> requirement candidate, a MUST generally converts to > > > >>>> >> a SHOULD or OPTIONAL. One reason for this is > > > >>>> >> you don't want to have to identify and manage > > > >>>> >> the complete list of possible exceptions during the > > > >>>> >> life of the RFC. You already have exceptions for > > > >>>> >> certain types of IPFIX devices and specific types > > > >>>> >> of traffic that don't require egress interface > > > >>>> >> reporting. That on its own might suggest that > > > >>>> > > > >>>> I think there is only one exception like that in > > > >>>> section 6.1.-8. saying that a probe does not need > > > >>>> to have the ability of reporting the output interface. > > > >>>> Please note that the same exception holds for the > > > >>>> input interface. > > > >>> > > > >>> > > > >>> From the perspective of a monitor that is internal > > > >>> to a switch or a router, the input interface identifier > > > >>> is historical and factual. The output interface > > > >>> identifier is always a predicted value, and as a result, > > > >>> a guess. > > > >> > > > >> > > > >> As much a guess as packet and octet counters for outgoing > > > >> traffic in mib-II? > > > >> > > > >>>> >> egress interface reporting should be OPTIONAL > > > >>>> >> in the Data Model. But if that is not compelling, > > > >>>> >> we may need to add more exceptions to the list than > > > >>>> >> are already there. > > > >>>> > > > >>>> Since the exception is the same for input and output > > > >>>> interface, we would consequently have to make the input > > > >>>> interface OPTIONAL as well, if we follow your argument. > > > >>>> > > > >>>> >> I can think of a few more types of traffic where > > > >>>> >> egress interface reporting may be challenging, such as > > > >>>> >> flow reporting under flap conditions, load balanced > > > >>>> >> traffic > > > >>>> >> > > > >>>> > You have 2 good examples here. > > > >>>> > > > > >>>> > > > >>>> Flap conditions and load balancing affect the > > > >>>> input interface as well as the output interface. > > > >>>> > > > >>>> >> and port mirrored traffic. In switches, > > > >>>> > > > >>>> I do not see your point concerning port mirrored traffic. > > > >>> > > > >>> > > > >>> Port mirroring in modern switches is generally implemented > > > >>> in hardware in a half-duplex fashion. When an ingress > > > >>> stream of an interface is mirrored, generally, the packet is > > > >>> latched to the mirrored port, as it is being read, if, of > > > >>> course, the outgoing port can handle it. Some vendors > > > >>> do the same thing with egress port mirroring, hardware > > > >>> latching both interfaces as the packet is being serialized > > > >>> out of the box. There is no status indication available to > > > >>> indicate whether the mirror port actually received the packet, > > > >>> or whether the mirror interface is actually up. The point is > > > >>> that no monitor could 'realize' whether a particular packet was > > > >>> actually transmitted to a mirrored interface, given existing > > > >>> commercial vendor designs. I've seen customers use egress > > > >>> interface mirroring for fault tolerance, and for some > > > >>> of these, they would love for IPFIX to support "multiple egress > > > >>> interface flow accounting". I'm not sure that anyone will > > > >>> ever be able to implement what these words really mean, inside a > > > >>> switch. > > > >>> > > > >>>> > > > >>>> >> broadcast traffic generates the same problem set as multicast > > > >>>> >> traffic. Also many switches, when presented with some arp table > > > >>>> >> issues, will broadcast unicast datagrams to all interfaces. Should > > > >>>> >> the multiple egress interfaces be reported in this case? That > > > >>>> >> condition > > > >>>> > > > >>>> Yes, if I configured the metering process in this way, > > > >>>> I would expect this. However, it might not be a good idea > > > >>>> to configure it this way. > > > >>> > > > >>> > > > >>> Well this is the nature of datagram flows in modern switches. > > > >>> If you are attempting to state what a flow monitor must do in > > > >>> order to do a decent job, and you decide that egress interface > > > >>> reporting is going to be a part of that, then you should take > > > >>> into consideration the normal modes of operation of a modern > > > >>> switch/router and correctly deal with those conditions. It > > > >>> is not a choice of configuration. > > > >> > > > >> > > > >> Well, it is. If I do egress interface reporting, I have the > > > >> choice of montoring IP only or monitoring both, IP and ARP. > > > >> > > > >>>> >> would persist, ideally, for only a few packets. Do > > > >>>> >> you generate multiple flow reports, one for the > > > >>>> >> broadcasted set of packets, and then one for the non broadcasted > > > >>>> >> flow? > > > >>>> > > > >>>> Same answer. > > > >>>> > > > >>>> > Well, for switches (layer 2 devices) I think that we > > > >>>> shouldn't report > > > >>>> > any flow records. Only the layer 3 devices should. > > > >>>> > > > > >>>> >> > > > >>>> >> One issue that comes up when considering multicast > > > >>>> >> egress interface reporting is that in most vendors > > > >>>> >> multicast implementations the multicast traffic is > > > >>>> >> delivered to every egress interface through hardware > > > >>>> broadcast, and > > > >>>> >> then output filters decide whether to forward the packet > > > >>>> or not. How > > > >>>> >> does this generalize in the IPFIX egress interface reporting > > > >>>> >> strategy? > > > >>>> > > > >>>> Wouldn'n these filters be a great location for collecting > > > >>>> multicast flow information? They anyway maintain a list of > > > >>>> multicast flows. The requirements suggest to collect > > > >>>> multicast information saparately for each egress. (And it > > > >>>> uses only SHOULD, not MUST for multicast traffic.) > > > >>> > > > >>> > > > >>> There is one very fundamental issue here. While the example > > > >>> used multicast traffic, the real issue is that switch vendors > > > >>> provide egress interface filtering for all network traffic. > > > >>> > > > >>> Is it better to report that a packet was intended for a > > > >>> particular interface, whether it was transmitted or not? > > > >>> Or is it better if the IPFIX monitor is implemented after > > > >>> all the filters and shapers, such that it doesn't see > > > >>> all the traffic that the router is dealing with? > > > >>> > > > >>> VLANs are almost universally enforced using egress > > > >>> interface filtering and there are many conditions where > > > >>> a switch will forward a packet to an interface that doesn't > > > >>> support a given VLAN, but it filters the packet, doing the > > > >>> right thing. Should IPFIX report that the box forwarded > > > >>> the flow to the interface, unaware that the packets will > > > >>> be filtered? Yes that seems reasonable, but you shouldn't > > > >>> use that record for accounting, because the device didn't > > > >>> really dispose of the packet in this simple fashion. > > > >>> > > > >>>> > > > >>>> >> Does the IPFIX Data Model need to understand egress interface > > > >>>> >> filtering behavior for all traffic types or just multicast? > > > >>>> > > > >>>> This heavily depends on the list of traffic types for > > > >>>> which egress filtring is used. I guess you don't use it > > > >>>> for TCP. > > > >>> > > > >>> > > > >>> Most vendors support filtering for specific TCP flags, > > > >>> say SYN packets, in their Access Control Lists > > > >>> and these are almost always implemented as a egress interface > > > >>> filter. > > > >>> > > > >>>> > > > >>>> >> It may be easier to just make egress interface > > > >>>> >> reporting an OPTIONAL feature, and then see if > > > >>>> >> any vendors can successfully implement it. > > > >>>> > > > >>>> This holds for most of the requirements. > > > >>>> But following your arguments: The multicast case > > > >>>> is not OPTIONAL, but SHOULD in the current reuqirements. > > > >>>> So, if a vendor faces serious problems implementing it, > > > >>>> the vendor will drop it. Here we have already what you > > > >>>> are asking for. > > > >>> > > > >>> > > > >>> I believe that reporting any interface, whether ingress > > > >>> or egress, should be OPTIONAL. > > > >>> > > > >>>> > > > >>>> All other arguments apply as well to the input interface. > > > >>>> But you ar not proposing to make this OPTIONAL. > > > >>>> > > > >>>> I think one important point behind your arguments is > > > >>>> that from a router architecture point of view, the most > > > >>>> obvious pace to locate the observation point and the metering > > > >>>> process is at the input interface, because similar > > > >>>> funtionality is required at this location anyway. But when > > > >>>> doing so it is not always easy to find otu the output interface. > > > >>>> > > > >>>> If a vendor locates the observation points at the output > > > >>>> interface (what I do not necessarily expect), then it might > > > >>>> face the inverse problem of not necessarily knowing the input > > > >>>> interface. > > > >>> > > > >>> > > > >>> If the IPFIX device is monitoring at the egress interface, > > > >>> then why put the egress id in every record. It won't change > > > >> > > > >> > > > >> The requirements is not at all about putting something in > > > >> every packet, it is just about reporting. If the exporting > > > >> process is able to report once, that all reported flows share > > > >> the same output interface, then the requirement is already met. > > > >> > > > >>> during the life of the monitor. Since you may not be sure > > > >>> of the input interface of any packet at the egress interface, > > > >>> why require that it be reported for any traffic? > > > >>> > > > >>>> > > > >>>> Like Benoit below, I also would like to have more opinions > > > >>>> on the issue how far the clearly existing requirements by > > > >>>> metering applications should be loosened in the IPFIX > > > >>>> requirements document because of assumed limitations of > > > >>>> today's router architecture? > > > >>>> > > > >>>> Juergen > > > >>>> > > > >>>> >> > > > >>>> > You've got a valid point.Why not a SHOULD? > > > >>>> > > > > >>>> > SHOULD This word, or the adjective "RECOMMENDED", > > > >>>> mean that there > > > >>>> > may exist valid reasons in particular circumstances > > > >>>> to ignore a > > > >>>> > particular item, but the full implications must be > > > >>>> understood and > > > >>>> > carefully weighed before choosing a different course. > > > >>>> > > > > >>>> > Any other opinion? > > > >>>> > > > > >>>> > Regards, Benoit. > > > >>>> > > > > >>>> >> > > > >>>> >> > > > >>>> >> Carter > > > >>>> >> > > > >>>> >> Carter Bullard > > > >>>> >> QoSient, LLC > > > >>>> >> 300 E. 56th Street > > > >>>> >> Suite 18K > > > >>>> >> New York, New York 10022 > > > >>>> >> > > > >>>> >> +1 212 588-9133 Phone > > > >>>> >> +1 212 588-9134 Fax > > > >>>> >> > > > >>>> >> > > > >>>> >> > > > >>>> >>> -----Original Message----- > > > >>>> >>> From: majordomo listserver > > > >>>> [mailto:majordomo@mil.doit.wisc.edu] On > > > >>>> >>> Behalf Of Benoit Claise > > > >>>> >>> Sent: Friday, July 26, 2002 4:21 AM > > > >>>> >>> To: ipfix-req@net.doit.wisc.edu > > > >>>> >>> Subject: [ipfix-req] Section regarding multicast flows > > > >>>> >>> > > > >>>> >>> > > > >>>> >>> > > > >>>> >>> > > > >>>> >>> Dave and All, > > > >>>> >>> > > > >>>> >>> Trying to incorporate all the proposed changes discussed > > > >>>> both at the > > > >>>> >>> IETF meeting and on the mailing list in the new requirement draft > > > >>>> >>> version, I think that we should add a new section on multicast > > > >>>> >>> > > > >>>> >>> 5.7 Multicast Flows > > > >>>> >>> > > > >>>> >>> For a multicast packet replicated to multiple output > > > >>>> interfaces, the > > > >>>> >>> metering process SHOULD maintain discrete flow records > > > >>>> per different > > > >>>> >>> egress ifIndexes. For example an incoming multicast packet > > > >>>> >>> that is replicated to four output interfaces would be > > > >>>> >>> reported in four different flow records that differ by the > > > >>>> >>> output interface. In case the metering process doesn't > > > >>>> >>> maintain and report discrete flow records > > > >>>> >>> per different egress ifIndexes for a multicast flow, the > > > >>>> >>> metering process > > > >>>> >>> SHOULD export the multicast replication factor in the flow record. > > > >>>> >>> > > > >>>> >>> > > > >>>> >>> Furthermore, some extra changes are needed > > > >>>> >>> The requirement draft was saying: > > > >>>> >>> > > > >>>> >>> 6.1. Information Model > > > >>>> >>> ... > > > >>>> >>> The exporting process MUST be able to report the following > > > >>>> >>> attributes > > > >>>> >>> for each measured flow: > > > >>>> >>> ... > > > >>>> >>> 8. output interface (ifIndex) > > > >>>> >>> This requirement does not apply if the observation point is > > > >>>> >>> located at a probe device. This requirement does not apply > > > >>>> >>> in case of multicast flow records. > > > >>>> >>> ... > > > >>>> >>> The exporting process MAY be able to report the following > > > >>>> >>> attributes > > > >>>> >>> for each measured flow: > > > >>>> >>> ... > > > >>>> >>> 25. multicast replication factor > > > >>>> >>> the number of outgoing packets originating from a single > > > >>>> >>> incoming multicast packet > > > >>>> >>> > > > >>>> >>> 26. list of output interfaces for a multicast flow > > > >>>> >>> > > > >>>> >>> > > > >>>> >>> I would propose: > > > >>>> >>> > > > >>>> >>> 6.1. Information Model > > > >>>> >>> ... > > > >>>> >>> The exporting process MUST be able to report the following > > > >>>> >>> attributes > > > >>>> >>> for each measured flow: > > > >>>> >>> ... > > > >>>> >>> 8. output interface (ifIndex) > > > >>>> >>> This requirement does not apply if the observation point is > > > >>>> >>> located at a probe device. _(ATTENTION: I REMOVED THE > > > >>>> LINE ABOUT > > > >>>> >>> MULTICAST)_ > > > >>>> >>> ... > > > >>>> >>> The exporting process _SHOULD_ be able to report the following > > > >>>> >>> attributes > > > >>>> >>> for each measured flow: > > > >>>> >>> ... > > > >>>> >>> X. multicast replication factor > > > >>>> >>> The number of outgoing packets originating from a single > > > >>>> >>> incoming multicast packet. This _multicast_ replication factor > > > >>>> >>> SHOULD be reported, > > > >>>> >>> but only SHOULD if the list of output interfaces for this > > > >>>> >>> multicast > > > >>>> >>> flow is not reported. > > > >>>> >>> > > > >>>> >>> _X+1. list of output interfaces for a multicast flow _(I WOULD > > > >>>> >>> REMOVE IT > > > >>>> >>> BECAUSE THIS IS EXPLAINED IN THE MULTICAST FLOW > > > >>>> SECTION AND THE > > > >>>> >>> LIMITATION > > > >>>> >>> IN THE OUTPUT INTERFACE SECTION ABOVE IS REMOVED) > > > >>>> >>> > > > >>>> >>> > > > >>>> >>> What do you think? > > > >>>> >>> > > > >>>> >>> Regards, Benoit > > > >>>> >>> > > > >>>> >>> > > > >>>> >>> > > > >>>> >>> > > > >>>> >>> -- > > > >>>> >>> Help mailto:majordomo@net.doit.wisc.edu and say "help" > > > >>>> >>> in message body > > > >>>> >>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > > >>>> "unsubscribe > > > >>>> >>> ipfix" in message body > > > >>>> >>> Archive http://ipfix.doit.wisc.edu/archive/ > > > >>>> >>> > > > >>>> >>> > > > >>>> >>> > > > >>>> >>> > > > >>>> >> > > > >>>> >> > > > >>>> >> > > > >>>> >> -- > > > >>>> >> Help mailto:majordomo@net.doit.wisc.edu and say > > > >>>> "help" in message body > > > >>>> >> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > > >>>> "unsubscribe > > > >>>> >> ipfix" in message body > > > >>>> >> Archive http://ipfix.doit.wisc.edu/archive/ > > > >>>> >> > > > >>>> >> > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> > -- > > > >>>> > Help mailto:majordomo@net.doit.wisc.edu and say > > > >>>> "help" in message body > > > >>>> > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe > > > >>>> > ipfix" in message body > > > >>>> > Archive http://ipfix.doit.wisc.edu/archive/ > > > >>>> > > > >>>> > > > >>>> > > > >>>> -- > > > >>>> Help mailto:majordomo@net.doit.wisc.edu and say "help" > > > >>>> in message body > > > >>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > > >>>> "unsubscribe ipfix" in message body > > > >>>> Archive http://ipfix.doit.wisc.edu/archive/ > > > >>>> > > > >>>> > > > >>> > > > >>> > > > >> > > > >> > > > >> > > > >> -- > > > >> Help mailto:majordomo@net.doit.wisc.edu and say "help" in > > > >> message body > > > >> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > > >> "unsubscribe ipfix" in message body > > > >> Archive http://ipfix.doit.wisc.edu/archive/ > > > > > > > > > > > > > > -- > > > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > > "unsubscribe ipfix" in message body > > > Archive http://ipfix.doit.wisc.edu/archive/ > > > > -- > > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > "unsubscribe ipfix" in message body > > Archive http://ipfix.doit.wisc.edu/archive/ --------------32A695CE8FA02A843DF848A9-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" 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 Aug 23 16:19:47 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16612 for ; Fri, 23 Aug 2002 16:19:47 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17iKm7-0003Xe-00 for ipfix-list@mil.doit.wisc.edu; Fri, 23 Aug 2002 15:11:19 -0500 Received: from login.caida.org ([192.172.226.78]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17iKm5-0003XW-00 for ipfix-req@net.doit.wisc.edu; Fri, 23 Aug 2002 15:11:17 -0500 Received: from login.caida.org (localhost [127.0.0.1]) by login.caida.org (8.12.1/8.12.1) with ESMTP id g7NKAvRg025984 (version=TLSv1/SSLv3 cipher=EDH-DSS-DES-CBC3-SHA bits=168 verify=NO); Fri, 23 Aug 2002 13:10:57 -0700 (PDT) Received: (from dmoore@localhost) by login.caida.org (8.12.1/8.12.1/Submit) id g7NKAvVL025983; Fri, 23 Aug 2002 13:10:57 -0700 (PDT) Date: Fri, 23 Aug 2002 13:10:56 -0700 From: David Moore To: Ganesh Sadasivan Cc: calato@riverstonenet.com, Benoit Claise , Juergen Quittek , Carter Bullard , ipfix-req@net.doit.wisc.edu Subject: Re: Reportin in and out interfaces (was: RE: [ipfix-req] Sectionregarding multicast flows) Message-ID: <20020823131056.Z66212@login.caida.org> References: <37866058.1029783113@[192.168.102.164]> <6309182.1030108692@[192.168.102.164]> <3D6662D5.5060902@cisco.com> <3D666710.80820C87@riverstonenet.com> <3D6685DD.4526FC7F@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D6685DD.4526FC7F@cisco.com> User-Agent: Mutt/1.3.23i Precedence: bulk Sender: majordomo listserver On Fri, Aug 23, 2002 at 11:58:38AM -0700, Ganesh Sadasivan wrote: > > If I got the packet > > by some other means, then neither of them are part of the > > observation point and thus are optional. > > Can give an example for the case of "some other means"? Passive tap in middle of a physical link. -- Help mailto:majordomo@net.doit.wisc.edu and say "help" 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 Aug 27 12:36:18 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00934 for ; Tue, 27 Aug 2002 12:36:18 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17jj87-0005DZ-00 for ipfix-list@mil.doit.wisc.edu; Tue, 27 Aug 2002 11:23:47 -0500 Received: from mailhost2.auckland.ac.nz ([130.216.191.4]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17jj84-0005DK-00 for ipfix@net.doit.wisc.edu; Tue, 27 Aug 2002 11:23:44 -0500 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 EAA06216 for ; Wed, 28 Aug 2002 04:23:36 +1200 (NZST) Received: from postbox.auckland.ac.nz (postbox.auckland.ac.nz [130.216.191.126]) by mailhost.auckland.ac.nz (Mirapoint Messaging Server MOS 3.2.0-GA) with ESMTP id AGW12011; Wed, 28 Aug 2002 04:23:36 +1200 (NZST) Received: from localhost (hotlava.auckland.ac.nz [130.216.191.123]) by postbox.auckland.ac.nz (8.11.6/8.11.6) with ESMTP id g7RGNZv15304 for ; Wed, 28 Aug 2002 04:23:36 +1200 Received: from dyn52.caida.org (dyn52.caida.org [192.172.226.52]) by hotlava.auckland.ac.nz (IMP) with HTTP for ; Wed, 28 Aug 2002 04:23:35 +1200 Message-ID: <1030465415.3d6ba7877fe79@hotlava.auckland.ac.nz> Date: Wed, 28 Aug 2002 04:23:35 +1200 From: Nevil Brownlee To: ipfix@net.doit.wisc.edu Subject: [ipfix] IPFIX protocol evaluation: candidate protocols MIME-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-Originating-IP: 192.172.226.52 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hello all: So far we have advocates for five candidate protocols. They are shown below as: Protocol Advocate Date announced documents describing the protocol .......................................................... CRANE Kevin Zhang 18 Jul draft-kzhang-crane-protocol-04.txt DIAMETER Sebastian Zander 7 Aug draft-ietf-aaa-diameter-12.txt LFAP v5.0 Paul Calato 30 Jul draft-riverstone-lfap-01.txt, and draft-riverstone-lfap-data-01.txt NetFlow v9 Benoit Claise 18 Jul draft-bclaise-netflow-9-00.txt Streaming IPDR Jeff Meyer 9 Aug http://www.ipdr.org/documents/ipfix (submitted to internet-drafts, 20 Aug as draft-meyer-ipdr-streaming-00.txt) Closing date for declaring advocates is 2 Sep 02, i.e. this coming Monday. After that no more protocols will be considered in the IPFIX evaluation. The IPFIX Requirements draft has only one issue for which we still need consensus, i.e. the reporting of in and out interfaces. I'd really like to get the requirements draft through last call; since this topic turns out to be so intertwined with implementation issues, we sidestep it for now, and simply leave the requirement vague. In other words, I suggest we just say "SHOULD report output and input interfaces," and leave it to the protocol advocates to say how their respective protocols handle such reporting. Cheers, Nevil ----------------------------------------------------------------------- Nevil Brownlee Director, Technology Development Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Aug 27 12:58:55 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01884 for ; Tue, 27 Aug 2002 12:58:54 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17jjXe-0005qC-00 for ipfix-list@mil.doit.wisc.edu; Tue, 27 Aug 2002 11:50:10 -0500 Received: from [64.95.122.60] (helo=RS-SC-EXC4.rs.riverstonenet.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17jjXc-0005pL-00 for ipfix@net.doit.wisc.edu; Tue, 27 Aug 2002 11:50:09 -0500 Received: from riverstonenet.com ([134.141.180.96]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 27 Aug 2002 09:49:36 -0700 Message-ID: <3D6BAD3C.F00B1B11@riverstonenet.com> Date: Tue, 27 Aug 2002 12:47:56 -0400 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Nevil Brownlee CC: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] IPFIX protocol evaluation: candidate protocols References: <1030465415.3d6ba7877fe79@hotlava.auckland.ac.nz> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Aug 2002 16:49:36.0808 (UTC) FILETIME=[BA4C5A80:01C24DE9] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Nevil Brownlee wrote: > > Hello all: > > So far we have advocates for five candidate protocols. They are > shown below as: > > Protocol Advocate Date announced > documents describing the protocol > .......................................................... > > CRANE Kevin Zhang 18 Jul > draft-kzhang-crane-protocol-04.txt > > DIAMETER Sebastian Zander 7 Aug > draft-ietf-aaa-diameter-12.txt > > LFAP v5.0 Paul Calato 30 Jul > draft-riverstone-lfap-01.txt, and > draft-riverstone-lfap-data-01.txt > > NetFlow v9 Benoit Claise 18 Jul > draft-bclaise-netflow-9-00.txt > > Streaming IPDR Jeff Meyer 9 Aug > http://www.ipdr.org/documents/ipfix > (submitted to internet-drafts, 20 Aug as > draft-meyer-ipdr-streaming-00.txt) > > Closing date for declaring advocates is 2 Sep 02, i.e. this > coming Monday. After that no more protocols will be considered > in the IPFIX evaluation. > > The IPFIX Requirements draft has only one issue for which we still > need consensus, i.e. the reporting of in and out interfaces. > I'd really like to get the requirements draft through last call; > since this topic turns out to be so intertwined with implementation > issues, we sidestep it for now, and simply leave the requirement vague. > In other words, I suggest we just say "SHOULD report output and input > interfaces," and leave it to the protocol advocates to say how their > respective protocols handle such reporting. Here is the issue with that, the protocols mainly discuss exchange of data and not processing/sematnics. LFAP for example, can report none, one or both. IPFIX is putting the much needed semantics around the data exchange. Hopefully we can come to consensus shortly on this issue. > > Cheers, Nevil > > ----------------------------------------------------------------------- > Nevil Brownlee Director, Technology Development > Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland > FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand > > ------------------------------------------------- > This mail sent through IMP: http://horde.org/imp/ > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" 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 Aug 27 13:43:02 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03485 for ; Tue, 27 Aug 2002 13:43:02 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17jk2b-0006Zs-00 for ipfix-list@mil.doit.wisc.edu; Tue, 27 Aug 2002 12:22:09 -0500 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17jk2Z-0006Yu-00 for ipfix@net.doit.wisc.edu; Tue, 27 Aug 2002 12:22:07 -0500 Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g7RHLVU19563; Tue, 27 Aug 2002 19:21:31 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id DC1054BBEC; Tue, 27 Aug 2002 19:21:29 +0200 (CEST) Date: Tue, 27 Aug 2002 19:21:29 +0200 From: Juergen Quittek To: Nevil Brownlee , ipfix@net.doit.wisc.edu Subject: Re: [ipfix] IPFIX protocol evaluation: candidate protocols Message-ID: <34519125.1030476089@[192.168.102.164]> In-Reply-To: <1030465415.3d6ba7877fe79@hotlava.auckland.ac.nz> References: <1030465415.3d6ba7877fe79@hotlava.auckland.ac.nz> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Nevil, We (the authors of the requirements draft) just finished editing a new version of the requirements document. Sebastian did a great job in very carefully reviewing each sentence. His comments and comments by others lead to 28 minor editorial changes, 12 fixed typos, and the following non-trivial changes: 1. We moved the requirement for time synchronization (Section 5.5.) from SHOULD to MUST and explained how this MUST can be met with little effort. We replaced the original Section 5.5. Time Synchronization Metering processes and collecting processes SHOULD be time- synchronized with each other. Using NTP or GPS are possible ways of achieving this. However selecting a method for time synchronization is not in the scope of this document. by 5.5. Time Synchronization It MUST be possible to synchronize timestamps generated by a metering process with Coordinated Universal Time (UTC). Note that the possibility of synchronizing timestamps of each single metering process with UTC implies the possibility of synchronizing timestamps generated by different metering processes. Note that this does not necessarily imply that timestamps generated by the metering process are UTC timestamps. For example, this requirement can be met by using local system clock values as timestamps and adding an additional timestamp when exporting a report to a collecting process. Then the collecting process can synchronize the timestamps by calculating the offset between UTC and the system clock of the metering process. 2. We moved (as suggested by Paul) in Section 6.1. the MUST attributes "input interface" and "output interface" from MUST to SHOULD: "7. input interface (ifIndex)" -> "18. input interface (ifIndex)". "8. output interface (ifIndex)" -> "19. output interface (ifIndex)". 3. We removed in Section 6.1. the MUST attribute "13. if BGP is supported at the observation point: BGP AS number" and instead appended to the end of section 6.1.: "In addition, the exporting process MAY be able to report attributes related to inter-autonomous system routing of a flow, for example by reporting BGP Autonoumous System numbers." 4. We added another configuration requirement to Section 7.2. (as suggested by Sebastian on the mailing list): "3. the reporting interval This requirement only applies if the exporting process supports reporting in regular intervals." [For the advocates: Changes 2. and 3. imply renumbering of items in Section 6.1. Change 4. implies renumbering of items in Section 7.2.] Currently, we are all proof-reading the new version which we will hopefully finish soon. I will send a preview to the advocates, because they probably are already heavily working on getting their drafts finished by Monday. Cheers, Juergen --On 28 August 2002 04:23 +1200 Nevil Brownlee wrote: > > Hello all: > > So far we have advocates for five candidate protocols. They are > shown below as: > > Protocol Advocate Date announced > documents describing the protocol > .......................................................... > > CRANE Kevin Zhang 18 Jul > draft-kzhang-crane-protocol-04.txt > > DIAMETER Sebastian Zander 7 Aug > draft-ietf-aaa-diameter-12.txt > > LFAP v5.0 Paul Calato 30 Jul > draft-riverstone-lfap-01.txt, and > draft-riverstone-lfap-data-01.txt > > NetFlow v9 Benoit Claise 18 Jul > draft-bclaise-netflow-9-00.txt > > Streaming IPDR Jeff Meyer 9 Aug > http://www.ipdr.org/documents/ipfix > (submitted to internet-drafts, 20 Aug as > draft-meyer-ipdr-streaming-00.txt) > > Closing date for declaring advocates is 2 Sep 02, i.e. this > coming Monday. After that no more protocols will be considered > in the IPFIX evaluation. > > The IPFIX Requirements draft has only one issue for which we still > need consensus, i.e. the reporting of in and out interfaces. > I'd really like to get the requirements draft through last call; > since this topic turns out to be so intertwined with implementation > issues, we sidestep it for now, and simply leave the requirement vague. > In other words, I suggest we just say "SHOULD report output and input > interfaces," and leave it to the protocol advocates to say how their > respective protocols handle such reporting. > > Cheers, Nevil > > ----------------------------------------------------------------------- > Nevil Brownlee Director, Technology Development > Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland > FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand > > ------------------------------------------------- > This mail sent through IMP: http://horde.org/imp/ > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" 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 Aug 27 15:00:54 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07354 for ; Tue, 27 Aug 2002 15:00:54 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17jlR4-0000s4-00 for ipfix-list@mil.doit.wisc.edu; Tue, 27 Aug 2002 13:51:30 -0500 Received: from [64.95.122.60] (helo=RS-SC-EXC4.rs.riverstonenet.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17jlR3-0000re-00 for ipfix-req@net.doit.wisc.edu; Tue, 27 Aug 2002 13:51:29 -0500 Received: from riverstonenet.com ([134.141.180.96]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 27 Aug 2002 11:50:57 -0700 Message-ID: <3D6BC9AD.CAC153C8@riverstonenet.com> Date: Tue, 27 Aug 2002 14:49:17 -0400 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: req Subject: [ipfix-req] IPFIX Requirements Questions Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Aug 2002 18:50:57.0963 (UTC) FILETIME=[AE346FB0:01C24DFA] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit As I work on the advocates document some questions have come to mind on the requirements document. 4.3 Distinguishing flows using Transport Header Fields In the case of fragmented packets there are no port numbers. Are we saying flow state information MUST be maintained? In general, it is not clear from the document what the requirements are for fragmented packets. 4.4 MPLS Label In the case of dynamic LSP's the label is not useful. Why require distinguishing flows based on label. What can be done with that information? 5.3 Overload Behavior This section needs to be re-worked a little. Some of the MUST's impose undue burden on the device. 1. Must distinguish flow records before and after the behavior change. In the case where the behavior is to drop overflow flows, why do we need to distinguish flows. Perhaps I misunderstood something. 2. All flows from previous behavior MUST be terminated. Again, if I simply dropped excess flows why terminate all existing ones. This will likely cause more overflow as the get reestablished. This also seems to go to far towards implementation. 3. Meeting process MUST NOT merge previous records. I think what we are trying to say is flows with a different definition MUST be distinguishable. How that is done is not part of the requirements doc. 5.4 Timestamps Time stamps to not always mapped to the first packet and last packet. In many cases, the end timestamp is merely when the flow timed out and has nothing to do with when the last packet was seen. Allowing both semantics may be useful. A re-wording like this... The metering process MUST be able to generate timestamps for the start and end of a flow. The metering process MAY also provide timestamps for the first and the last observed packet of a flow. The timestamp resolution MUST be at least the one of the sysUpTime [RFC1213], which is one centisecond. Note - this does not mandate 2 timestamp fields for a flow. You could have one element for each meaning (e.g. Flow-start-time, first-packet-time, flow-start-and-first-packet-time) and use the one with the desired meaning. 6.1 information Model 9 Packet Counter 10 Byte counter As mentioned earlier, for fragments this requires state information? If there is no state info, then what flow are the counted towards? 13 BGP AS number Is this the AS number for the observation point, the source/destination address in the packet or some combination? 14. MPLS Label As stated earlier, in the case of dynamic LSP's the label has no meaning. 21 multicast replication number The document stated this can change over the life of the flow. But no mention of what happens when it changes. Is that a new flow? If not, what meaning does it have when reported? What can I do with it? 6.2 Data Model What about allowing Vendors to add information independently? Some data to be transported may be vendor specific and never make it into the IPFIX spec. 8.3 Several Collecting Processes No mention is made when reporting to several devices of ensuring the duplicate data does not cause a double counting problem. 9. Special Device Considerations I'm not sure of the meaning for the following... ... Please note that here, the observation point of a single flow cannot exceed the set of most fine-granular observation points linked to a single metering process, because only the metering process can merge packets observed at different fine- granular observation points to a joint flow. ... Also the locations of metering processes are not of any relevance for this document (in contrast to the locations of observation points and the exporting processes). Paul -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Aug 27 15:40:29 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09190 for ; Tue, 27 Aug 2002 15:40:29 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17jm20-0001pp-00 for ipfix-list@mil.doit.wisc.edu; Tue, 27 Aug 2002 14:29:40 -0500 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17jm1y-0001pB-00 for ipfix-req@net.doit.wisc.edu; Tue, 27 Aug 2002 14:29:38 -0500 Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g7RJT7U21301; Tue, 27 Aug 2002 21:29:07 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 764C44D858; Tue, 27 Aug 2002 21:29:06 +0200 (CEST) Date: Tue, 27 Aug 2002 21:29:06 +0200 From: Juergen Quittek To: calato@riverstonenet.com, req Subject: Re: [ipfix-req] IPFIX Requirements Questions Message-ID: <42174623.1030483746@[192.168.102.164]> In-Reply-To: <3D6BC9AD.CAC153C8@riverstonenet.com> References: <3D6BC9AD.CAC153C8@riverstonenet.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit --On 27 August 2002 14:49 -0400 calato@riverstonenet.com wrote: > > As I work on the advocates document some questions > have come to mind on the requirements document. > > 4.3 Distinguishing flows using Transport Header Fields > > In the case of fragmented packets there are > no port numbers. Are we saying flow state information > MUST be maintained? In general, it is not clear from No, the requirements document does not say so. > the document what the requirements are for fragmented > packets. I think the requirements should not include a requirement for keeping state of fragmented packets. Would you like to see an explicit statement on that? This would be a NO NEED FOR statement :-) > 4.4 MPLS Label > > In the case of dynamic LSP's the label is not useful. > Why require distinguishing flows based on label. > What can be done with that information? Well, for each attribute there are situations where it does not make sense to use it for distinguishing flows. But being able to distinguish flows by label seems to be useful to me in general. > 5.3 Overload Behavior > > This section needs to be re-worked a little. Some > of the MUST's impose undue burden on the device. > > 1. Must distinguish flow records before and after the > behavior change. > > In the case where the behavior is to drop > overflow flows, why do we need to distinguish > flows. Perhaps I misunderstood something. > > > 2. All flows from previous behavior MUST be terminated. > > > Again, if I simply dropped excess flows why terminate > all existing ones. This will likely cause more overflow > as the get reestablished. This also seems to go to > far towards implementation. I agree. > 3. Meeting process MUST NOT merge previous records. > > > > I think what we are trying to say is flows with a different > definition MUST be distinguishable. How that is done is not > part of the requirements doc. Also agreed. However, it is not just different definition, but also different measurement technique, different sampling rate, etc. We need to express this intended requirement it in a better way. > 5.4 Timestamps > > Time stamps to not always mapped to the first packet and last > packet. In many cases, the end timestamp is merely when > the flow timed out and has nothing to do with when the > last packet was seen. Allowing both semantics may be useful. > A re-wording like this... > > > The metering process MUST be able to generate timestamps for the > start and end of a flow. The metering process MAY also provide > timestamps for the first and the last observed packet > of a flow. The timestamp resolution MUST be at least the one of > the sysUpTime [RFC1213], which is one centisecond. > > Note - this does not mandate 2 timestamp fields for a flow. You > could have one element for each meaning (e.g. Flow-start-time, > first-packet-time, flow-start-and-first-packet-time) and use > the one with the desired meaning. You just added a MAY requirement for the timeout timestamp. We can do this, but everything you mention was already possible without this additional requirement. It was just required that the metering process can provide these timestamps (if configured so). Whether or not they are exported and whether or not other timestamps are exported was already left open by the requirements. > 6.1 information Model > > 9 Packet Counter > 10 Byte counter > > As mentioned earlier, for fragments this > requires state information? If there is no > state info, then what flow are the counted > towards? Do you suggest to include a requirement for keeping fragment state info? > 13 BGP AS number > > Is this the AS number for the observation point, the > source/destination address in the packet or some > combination? This is already revised in the upcoming version. This MUST requirement is removed and replaced by a MAY requirement on source address AS#, destination address AS#, and next hop AS#. > 14. MPLS Label > > As stated earlier, in the case of dynamic LSP's the > label has no meaning. Yes, but here the general ability of reporting it is required. > 21 multicast replication number > > The document stated this can change over the life > of the flow. But no mention of what happens when > it changes. Is that a new flow? If not, what meaning > does it have when reported? What can I do with it? Whether or not it is a new flow when the factor changes depends on the used flow definition. In the revision we added a phrase that computation of the factor must be clearly define (factor of last observed packet, mean value, ...). However, from the applications we could not derive a clear preference for one or the other definition. Therefore, the precise definiton is left to the concrete protocol. > 6.2 Data Model > > What about allowing Vendors to add information independently? > Some data to be transported may be vendor specific and never > make it into the IPFIX spec. I don't see how the requirements forbid this. > 8.3 Several Collecting Processes > > No mention is made when reporting to several devices > of ensuring the duplicate data does not cause a double > counting problem. We discussed this issue, but did not find a clear requirement for avoiding this or for providing means for avoiding this. One problem is that the collecting process is completely out of scope. Do you have an idea? > 9. Special Device Considerations > > I'm not sure of the meaning for the following... > > ... > > Please note that here, the observation > point of a single flow cannot exceed the set of most fine-granular > observation points linked to a single metering process, because only > the metering process can merge packets observed at different fine- > granular observation points to a joint flow. When merging flow records already exported from the first level metering systems, you might create new aggregated flows for which also the "observation point" gets aggregated. The resulting one might include all first level observation points. > > ... > > Also the > locations of metering processes are not of any relevance for this > document (in contrast to the locations of observation points and the > exporting processes). Well what's the question here. We care about where packets are observed, not about where they are processed and converted into fow records. Juergen > > Paul > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Aug 27 16:06:17 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10531 for ; Tue, 27 Aug 2002 16:06:17 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17jmSn-0002Qb-00 for ipfix-list@mil.doit.wisc.edu; Tue, 27 Aug 2002 14:57:21 -0500 Received: from dplonka by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17jmSl-0002QU-00 for ipfix@net.doit.wisc.edu; Tue, 27 Aug 2002 14:57:19 -0500 Date: Tue, 27 Aug 2002 14:57:19 -0500 From: Dave Plonka To: ipfix@net.doit.wisc.edu Subject: [ipfix] IETF administrivia: Nomcom call for volunteers Message-ID: <20020827145719.C21059@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-DEVNOTDISM, device not dismounted X-Shakespearean-Insult: Thou jarring pottle-deep flax-wench Precedence: bulk Sender: majordomo listserver IPFIX participants, I'm forwarding the announcement below on behalf of the sender, who is not a subscriber of our list. ----- Forwarded message from owner-ipfix@net.doit.wisc.edu ----- From: Phil Roberts To: IETF WG Participants: ; Subject: Nomcom call for volunteers Date: Tue, 27 Aug 2002 14:44:44 -0400 Sender: scoya@cnri.reston.va.us The members of the IESG and IAB and the IETF chair are selected by a nominations committee made up of volunteers from the IETF community. The nominations committee is now in the process of being formed and volunteers are being accepted until Sep 6. Please see (http://www.ietf.org/nomcom/msg19765.html) for information if you are interested in volunteering to be on the nominations committee. ----- End forwarded message ----- -- plonka@doit.wisc.edu http://net.doit.wisc.edu/~plonka ARS:N9HZF Madison, WI -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Aug 27 20:40:02 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18837 for ; Tue, 27 Aug 2002 20:40:02 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17jqhA-0000zs-00 for ipfix-list@mil.doit.wisc.edu; Tue, 27 Aug 2002 19:28:28 -0500 Received: from [64.95.122.60] (helo=RS-SC-EXC4.rs.riverstonenet.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17jqh8-0000z8-00 for ipfix-req@net.doit.wisc.edu; Tue, 27 Aug 2002 19:28:26 -0500 Received: from riverstonenet.com ([134.141.180.96]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 27 Aug 2002 17:27:52 -0700 Message-ID: <3D6C18A3.764A46B9@riverstonenet.com> Date: Tue, 27 Aug 2002 20:26:11 -0400 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Quittek CC: req Subject: Re: [ipfix-req] IPFIX Requirements Questions References: <3D6BC9AD.CAC153C8@riverstonenet.com> <42174623.1030483746@[192.168.102.164]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Aug 2002 00:27:52.0836 (UTC) FILETIME=[BF354440:01C24E29] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Juergen Quittek wrote: > > --On 27 August 2002 14:49 -0400 calato@riverstonenet.com wrote: > > > > > As I work on the advocates document some questions > > have come to mind on the requirements document. > > > > 4.3 Distinguishing flows using Transport Header Fields > > > > In the case of fragmented packets there are > > no port numbers. Are we saying flow state information > > MUST be maintained? In general, it is not clear from > > No, the requirements document does not say so. > > > the document what the requirements are for fragmented > > packets. > > I think the requirements should not include a requirement for > keeping state of fragmented packets. Would you like to see > an explicit statement on that? This would be a NO NEED FOR > statement :-) I think we need to be explicit. Most people will think of fragements as being counted in the same flow as the first packet not as 2 differernt flows. > > > 4.4 MPLS Label > > > > In the case of dynamic LSP's the label is not useful. > > Why require distinguishing flows based on label. > > What can be done with that information? > > Well, for each attribute there are situations where it does not make > sense to use it for distinguishing flows. But being able to distinguish > flows by label seems to be useful to me in general. Then why not include things like VPI/VCI for ATM or other L2.5 tunnels? Why does MPLS get special consideration? Also, I may be wrong here but I beleive the primary use of MPLS will be with dynamic LSP's so the label has little meaning the majority of time. At best it would be a MAY requirement, not a MUST. If we are going to go this way, which I am against, then we should also include FEC. At least that would be more meaningful information in the case of dynamic LSPs. > > > 5.3 Overload Behavior > > > > This section needs to be re-worked a little. Some > > of the MUST's impose undue burden on the device. > > > > 1. Must distinguish flow records before and after the > > behavior change. > > > > In the case where the behavior is to drop > > overflow flows, why do we need to distinguish > > flows. Perhaps I misunderstood something. > > > > > > 2. All flows from previous behavior MUST be terminated. > > > > > > Again, if I simply dropped excess flows why terminate > > all existing ones. This will likely cause more overflow > > as the get reestablished. This also seems to go to > > far towards implementation. > > I agree. > > > 3. Meeting process MUST NOT merge previous records. > > > > > > > > I think what we are trying to say is flows with a different > > definition MUST be distinguishable. How that is done is not > > part of the requirements doc. > > Also agreed. However, it is not just different definition, but also > different measurement technique, different sampling rate, etc. > > We need to express this intended requirement it in a better way. Agreed. What this points out to me is that we do not have a term that refers to the set of information that is the flow definition. We touch on it in section 2.1 when discussing the flow definition itself, in section 2.3 when discussing classifying and then again in section 4 when discussing distinguishing flows. What about a new term "Distinguishing Properties" or "Flow Properties"? Its definition would be The set of fields, functions and parameters (e.g. sampling rate) used to map packets to flows. Then we can say each flow MUST be able to be mapped to its "Distinguishing properties". This would cover changing behavior due to overload, configuration changes, etc... Thoughts? > > > 5.4 Timestamps > > > > Time stamps to not always mapped to the first packet and last > > packet. In many cases, the end timestamp is merely when > > the flow timed out and has nothing to do with when the > > last packet was seen. Allowing both semantics may be useful. > > A re-wording like this... > > > > > > The metering process MUST be able to generate timestamps for the > > start and end of a flow. The metering process MAY also provide > > timestamps for the first and the last observed packet > > of a flow. The timestamp resolution MUST be at least the one of > > the sysUpTime [RFC1213], which is one centisecond. > > > > Note - this does not mandate 2 timestamp fields for a flow. You > > could have one element for each meaning (e.g. Flow-start-time, > > first-packet-time, flow-start-and-first-packet-time) and use > > the one with the desired meaning. > > You just added a MAY requirement for the timeout timestamp. We can do this, > but everything you mention was already possible without this additional > requirement. It was just required that the metering process can provide > these timestamps (if configured so). Whether or not they are exported > and whether or not other timestamps are exported was already left open > by the requirements. I disagree. I'm not talking about what is exported, I talking about semantics. The req doc currently ties the timestamp event to packet observation. All metering processes will know when they created and deleted a flow. They may or may not know when the first or last packet was observed. The typical example of this is last packet. In many platforms the first packet is processed by the CPU and creates a hardware entry. The rest of the packets are processed and counted in hardware and thus there is no timestamp available, just a count. All that is known is when the flow was artifically timed out. A weaker argument can be made for first packet observed. There may be a known significant delay from packet observation to timestamp. In this case the metering process can report the time at which it created the flow but not first packet time. Weak I know. > > > 6.1 information Model > > > > 9 Packet Counter > > 10 Byte counter > > > > As mentioned earlier, for fragments this > > requires state information? If there is no > > state info, then what flow are the counted > > towards? > > Do you suggest to include a requirement for keeping fragment state info? A MAY is as far as I would go. There may certainly be probes that have this capability. We should have a requirement that says fragment counting MUST be clearly defined. > > > 13 BGP AS number > > > > Is this the AS number for the observation point, the > > source/destination address in the packet or some > > combination? > > This is already revised in the upcoming version. This MUST requirement > is removed and replaced by a MAY requirement on source address AS#, > destination address AS#, and next hop AS#. Great. > > > 14. MPLS Label > > > > As stated earlier, in the case of dynamic LSP's the > > label has no meaning. > > Yes, but here the general ability of reporting it is required. > > > 21 multicast replication number > > > > The document stated this can change over the life > > of the flow. But no mention of what happens when > > it changes. Is that a new flow? If not, what meaning > > does it have when reported? What can I do with it? > > Whether or not it is a new flow when the factor changes depends on the > used flow definition. In the revision we added a phrase that computation > of the factor must be clearly define (factor of last observed packet, > mean value, ...). However, from the applications we could not derive a > clear preference for one or the other definition. Therefore, the precise > definiton is left to the concrete protocol. Agreed. > > > 6.2 Data Model > > > > What about allowing Vendors to add information independently? > > Some data to be transported may be vendor specific and never > > make it into the IPFIX spec. > > I don't see how the requirements forbid this. The only reason I'm calling this out is "extensible protocol" usually means future changes to the protocol can be added without breaking existing applications. The vendor specific extensions allow extenstions without modifying the protocol, without breaking existing server and without stepping on other verndor's extensions. > > > 8.3 Several Collecting Processes > > > > No mention is made when reporting to several devices > > of ensuring the duplicate data does not cause a double > > counting problem. > > We discussed this issue, but did not find a clear requirement for > avoiding this or for providing means for avoiding this. I don't understand. Double counting would surely cause problems for many if not all of the applications. > One problem > is that the collecting process is completely out of scope. We are opening the door by allowing data to be sent to multiple Collectors. I think it would be difficult and perhaps even impossible, without protocol support. But I'm open to ideas on how it could be accomplished without protocol support. > Do you have an idea? For example, in LFAP a Flow ID, timestamp and message ID uniquely identifies flow information. So the Collector could use that to weed out duplicate data. How and when would be out of scope. But the means is defined by the protocol. > > > 9. Special Device Considerations > > > > I'm not sure of the meaning for the following... > > > > ... > > > > Please note that here, the observation > > point of a single flow cannot exceed the set of most fine-granular > > observation points linked to a single metering process, because only > > the metering process can merge packets observed at different fine- > > granular observation points to a joint flow. > > When merging flow records already exported from the first level metering > systems, you might create new aggregated flows for which also the "observation > point" gets aggregated. The resulting one might include all first level > observation points. > I still don't get it. Let me think about it. > > > > ... > > > > Also the > > locations of metering processes are not of any relevance for this > > document (in contrast to the locations of observation points and the > > exporting processes). > > Well what's the question here. We care about where packets are observed, > not about where they are processed and converted into fow records. Ahh. Now I get it. > > Juergen > > > > Paul > > > > -- > > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > "unsubscribe ipfix" in message body > > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Aug 28 03:54:10 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19968 for ; Wed, 28 Aug 2002 03:54:09 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17jxT0-00035c-00 for ipfix-list@mil.doit.wisc.edu; Wed, 28 Aug 2002 02:42:18 -0500 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17jxSy-000353-00 for ipfix-req@net.doit.wisc.edu; Wed, 28 Aug 2002 02:42:16 -0500 Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g7S7fiU32010; Wed, 28 Aug 2002 09:41:45 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id A885A58719; Wed, 28 Aug 2002 09:41:43 +0200 (CEST) Date: Wed, 28 Aug 2002 09:45:14 +0200 From: Juergen Quittek To: calato@riverstonenet.com Cc: req Subject: fragmented packets (was: Re: [ipfix-req] IPFIX Requirements Questions) Message-ID: <1785807.1030527914@[192.168.102.164]> In-Reply-To: <3D6C18A3.764A46B9@riverstonenet.com> References: <3D6C18A3.764A46B9@riverstonenet.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Paul, --On 27 August 2002 20:26 -0400 calato@riverstonenet.com wrote: > Juergen Quittek wrote: >> >> --On 27 August 2002 14:49 -0400 calato@riverstonenet.com wrote: >> >> > >> > As I work on the advocates document some questions >> > have come to mind on the requirements document. >> > >> > 4.3 Distinguishing flows using Transport Header Fields >> > >> > In the case of fragmented packets there are >> > no port numbers. Are we saying flow state information >> > MUST be maintained? In general, it is not clear from >> >> No, the requirements document does not say so. >> >> > the document what the requirements are for fragmented >> > packets. >> >> I think the requirements should not include a requirement for >> keeping state of fragmented packets. Would you like to see >> an explicit statement on that? This would be a NO NEED FOR >> statement :-) > > I think we need to be explicit. Most people will think > of fragements as being counted in the same flow as the > first packet not as 2 differernt flows. I see. Waht about adding a new subsection to Section "5. Metering Process": 5.8. Packet Fragmentation In case of IP packet fragmentation, only one fragment of a single packet might contain sufficient information for classifying the packet correctly. The metering process MAY keep state of IP packet fragmentation in order to map fragments that do not contain sufficient header information correctly to flows. [...] >> > 6.1 information Model >> > >> > 9 Packet Counter >> > 10 Byte counter >> > >> > As mentioned earlier, for fragments this >> > requires state information? If there is no >> > state info, then what flow are the counted >> > towards? >> >> Do you suggest to include a requirement for keeping fragment state info? > > > A MAY is as far as I would go. There may certainly be probes > that have this capability. We should have a requirement that > says fragment counting MUST be clearly defined. OK. Currently, we have 9. packet counter If a packet is fragmented, each fragment is counted as an individual packet. 10. byte counter Which bytes of a packet are counted MUST be defined exactly. What about appending The behavior of the byte counter in case of IP packet fragmentation MUST be clearly defined. ? Please note that we also have in the MAY attributes section 26. fragmented packet counter counter of all packets for which the fragmented bit is set in the IP header Juergen -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Aug 28 04:37:43 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20874 for ; Wed, 28 Aug 2002 04:37:42 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17jyBd-0004Da-00 for ipfix-list@mil.doit.wisc.edu; Wed, 28 Aug 2002 03:28:25 -0500 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17jyBb-0004Cl-00 for ipfix-req@net.doit.wisc.edu; Wed, 28 Aug 2002 03:28:23 -0500 Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g7S8RrU34521; Wed, 28 Aug 2002 10:27:53 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 0217A5D7A4; Wed, 28 Aug 2002 10:27:52 +0200 (CEST) Date: Wed, 28 Aug 2002 10:27:52 +0200 From: Juergen Quittek To: calato@riverstonenet.com Cc: req Subject: MPLS label (was:Re: [ipfix-req] IPFIX Requirements Questions) Message-ID: <4553948.1030530472@[192.168.102.164]> In-Reply-To: <3D6C18A3.764A46B9@riverstonenet.com> References: <3D6C18A3.764A46B9@riverstonenet.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Paul, --On 27 August 2002 20:26 -0400 calato@riverstonenet.com wrote: [...] >> > 4.4 MPLS Label >> > >> > In the case of dynamic LSP's the label is not useful. >> > Why require distinguishing flows based on label. >> > What can be done with that information? >> >> Well, for each attribute there are situations where it does not make >> sense to use it for distinguishing flows. But being able to distinguish >> flows by label seems to be useful to me in general. > > > Then why not include things like VPI/VCI for ATM > or other L2.5 tunnels? Why does MPLS get special > consideration? In general I see your point, although MPLS appears to be closer related to IP than plain ATM. > Also, I may be wrong here but I beleive the primary > use of MPLS will be with dynamic LSP's so the label > has little meaning the majority of time. At best > it would be a MAY requirement, not a MUST. For me, metering on a per-LSP basis is highly benefitial for the operation of MPLS networks, even in the case of dynamic label assignment. The LSR MIB already offers this kind of performance information, but I think it also fits well into IPFIX. > If we are going to go this way, which I am > against, then we should also include FEC. At least > that would be more meaningful information in the > case of dynamic LSPs. This could be useful, but the FEC is a higher level information that is not available in many cases. Also we would need a good model for FEC information. Juergen -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Aug 28 06:47:20 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23280 for ; Wed, 28 Aug 2002 06:47:19 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17jzz4-0000GT-00 for ipfix-list@mil.doit.wisc.edu; Wed, 28 Aug 2002 05:23:34 -0500 Received: from mailhub.fokus.gmd.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17jzz3-0000GO-00 for ipfix-req@net.doit.wisc.edu; Wed, 28 Aug 2002 05:23:33 -0500 Received: from fokus.gmd.de (dhcp229 [195.37.78.229]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g7SANQ705088; Wed, 28 Aug 2002 12:23:26 +0200 (MEST) Message-ID: <3D6CA423.3020900@fokus.gmd.de> Date: Wed, 28 Aug 2002 12:21:23 +0200 From: Sebastian Zander Organization: Fraunhofer FOKUS User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: de-DE MIME-Version: 1.0 To: calato@riverstonenet.com CC: Juergen Quittek , req Subject: Re: [ipfix-req] IPFIX Requirements Questions References: <3D6BC9AD.CAC153C8@riverstonenet.com> <42174623.1030483746@[192.168.102.164]> <3D6C18A3.764A46B9@riverstonenet.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Paul, sorry for dropping in but I have some comments below. calato@riverstonenet.com wrote: > Juergen Quittek wrote: > >>--On 27 August 2002 14:49 -0400 calato@riverstonenet.com wrote: >> >> >>>As I work on the advocates document some questions >>>have come to mind on the requirements document. >>> >>>4.3 Distinguishing flows using Transport Header Fields >>> >>> In the case of fragmented packets there are >>> no port numbers. Are we saying flow state information >>> MUST be maintained? In general, it is not clear from >>> >>No, the requirements document does not say so. >> >> >>> the document what the requirements are for fragmented >>> packets. >>> >>I think the requirements should not include a requirement for >>keeping state of fragmented packets. Would you like to see >>an explicit statement on that? This would be a NO NEED FOR >>statement :-) >> > > I think we need to be explicit. Most people will think > of fragements as being counted in the same flow as the > first packet not as 2 differernt flows. Good point! According to the current draft the fragments after the first would not be counted at all (in case you match on >L3) unless there would be a more general rule matching the fragments and then they appear in a different flow. The current draft requires a packet counter which counts all fragments per flow so it seems to require keeping flow state which is not so easy I guess. In case there is no state the notion of the packet counter is that if we filter on L3 we can count L3 packets (including fragments) and if we filter on above that we can only count L4 packets (first fragments). That also impacts the byte count because if we filter on above L4 we won't get the correct byte count for the flow. >>>5.4 Timestamps >>> >>> Time stamps to not always mapped to the first packet and last >>> packet. In many cases, the end timestamp is merely when >>> the flow timed out and has nothing to do with when the >>> last packet was seen. Allowing both semantics may be useful. >>> A re-wording like this... >>> >>> >>> The metering process MUST be able to generate timestamps for the >>> start and end of a flow. The metering process MAY also provide >>> timestamps for the first and the last observed packet >>> of a flow. The timestamp resolution MUST be at least the one of >>> the sysUpTime [RFC1213], which is one centisecond. >>> >>> Note - this does not mandate 2 timestamp fields for a flow. You >>> could have one element for each meaning (e.g. Flow-start-time, >>> first-packet-time, flow-start-and-first-packet-time) and use >>> the one with the desired meaning. >>> >>You just added a MAY requirement for the timeout timestamp. We can do this, >>but everything you mention was already possible without this additional >>requirement. It was just required that the metering process can provide >>these timestamps (if configured so). Whether or not they are exported >>and whether or not other timestamps are exported was already left open >>by the requirements. >> > > I disagree. I'm not talking about what is exported, I talking > about semantics. The req doc currently ties the timestamp event > to packet observation. All metering processes will know > when they created and deleted a flow. They may or may not > know when the first or last packet was observed. > > The typical example of this is last packet. In many platforms > the first packet is processed by the CPU and creates a hardware entry. > The rest of the packets are processed and counted in hardware > and thus there is no timestamp available, just a count. All > that is known is when the flow was artifically timed out. > > A weaker argument can be made for first packet observed. There > may be a known significant delay from packet observation to timestamp. > In this case the metering process can report the time at which it > created the flow but not first packet time. Weak I know. I agree that we have to look at current practice but I have the feeling that we get more and more vague just to support any existing thing. The requirements are driven by applications. Lets look at accounting. I am wondering how IPFIX information can be used for accounting when - there are no correct stop timestamps (there are no requirements on the flow timeout) - there are no requirements on the report time (when are reports send) (e.g. it is not required to export information at/after flow end) - there is no timestamp required in interim flow records - byte counters may not be correct (in case of port filtering and fragmentation) Well forget about the last one but with the first three we basically do not comply to the req of the AAA WG for accounting. If the MUST requirement of the current draft is a problem for a lot of current hardware then at least the requirement should be reduced to a SHOULD and not a MAY. >>>6.2 Data Model >>> >>> What about allowing Vendors to add information independently? >>> Some data to be transported may be vendor specific and never >>> make it into the IPFIX spec. >>> >>I don't see how the requirements forbid this. >> > > The only reason I'm calling this out is "extensible protocol" > usually means future changes to the protocol can be added > without breaking existing applications. The vendor > specific extensions allow extenstions without modifying the > protocol, without breaking existing server and without stepping > on other verndor's extensions. I don't think this belongs to the req draft. But certainly in the spec. > >>>8.3 Several Collecting Processes >>> >>> No mention is made when reporting to several devices >>> of ensuring the duplicate data does not cause a double >>> counting problem. >>> >>We discussed this issue, but did not find a clear requirement for >>avoiding this or for providing means for avoiding this. >> > > I don't understand. Double counting would surely cause > problems for many if not all of the applications. > > > >>One problem >>is that the collecting process is completely out of scope. >> > > We are opening the door by allowing data to be sent to > multiple Collectors. I think it would be difficult and > perhaps even impossible, without protocol support. But > I'm open to ideas on how it could be accomplished without > protocol support. > > >>Do you have an idea? >> > > For example, in LFAP a Flow ID, timestamp and message ID > uniquely identifies flow information. So the Collector could > use that to weed out duplicate data. How and when would be > out of scope. But the means is defined by the protocol. I support to include duplicate detection as a requirement in the draft but without suggestion a specific solution. That should be left for the spec. Cheers, Sebastian -- Sebastian Zander E-mail: zander@fokus.fhg.de FhI FOKUS / Global Networking (GloNe) Tel: +49-30-3463-7287 Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 D-10589 Berlin, Germany www.fokus.fhg.de/usr/sebastian.zander -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Aug 28 08:03:25 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25762 for ; Wed, 28 Aug 2002 08:03:24 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17k1Nm-00035n-00 for ipfix-list@mil.doit.wisc.edu; Wed, 28 Aug 2002 06:53:10 -0500 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17k1Nk-00034p-00 for ipfix-req@net.doit.wisc.edu; Wed, 28 Aug 2002 06:53:08 -0500 Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g7SBqbU45011; Wed, 28 Aug 2002 13:52:37 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 2F5E95D872; Wed, 28 Aug 2002 13:52:36 +0200 (CEST) Date: Wed, 28 Aug 2002 13:52:36 +0200 From: Juergen Quittek To: calato@riverstonenet.com Cc: req Subject: overload behavior (was: Re: [ipfix-req] IPFIX Requirements Questions) Message-ID: <16837340.1030542756@[192.168.102.164]> In-Reply-To: <3D6C18A3.764A46B9@riverstonenet.com> References: <3D6C18A3.764A46B9@riverstonenet.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Paul, --On 27 August 2002 20:26 -0400 calato@riverstonenet.com wrote: [...] >> > 5.3 Overload Behavior >> > >> > This section needs to be re-worked a little. Some >> > of the MUST's impose undue burden on the device. >> > >> > 1. Must distinguish flow records before and after the >> > behavior change. >> > >> > In the case where the behavior is to drop >> > overflow flows, why do we need to distinguish >> > flows. Perhaps I misunderstood something. >> > >> > >> > 2. All flows from previous behavior MUST be terminated. >> > >> > >> > Again, if I simply dropped excess flows why terminate >> > all existing ones. This will likely cause more overflow >> > as the get reestablished. This also seems to go to >> > far towards implementation. >> >> I agree. >> >> > 3. Meeting process MUST NOT merge previous records. >> > >> > >> > >> > I think what we are trying to say is flows with a different >> > definition MUST be distinguishable. How that is done is not >> > part of the requirements doc. >> >> Also agreed. However, it is not just different definition, but also >> different measurement technique, different sampling rate, etc. >> >> We need to express this intended requirement it in a better way. > > Agreed. > > What this points out to me is that we do not have a term > that refers to the set of information that is the flow > definition. We touch on it in section 2.1 when discussing > the flow definition itself, in section 2.3 when discussing > classifying and then again in section 4 when discussing > distinguishing flows. > > What about a new term "Distinguishing Properties" or > "Flow Properties"? Its definition would be > > The set of fields, functions and parameters (e.g. sampling > rate) used to map packets to flows. > > Then we can say each flow MUST be able to be mapped to its > "Distinguishing properties". > > This would cover changing behavior due to overload, configuration > changes, etc... > > Thoughts? I think the mistake in the current version of the text is that it asks on separating flows before and after the metering process was modified. It is indepenedent of whether the individual flows are affected or not. I think it is sufficient to fix this. The current text is Overload behavior is not restricted to the four options listed above. But in case the overload behavior has an impact on the metering process or the exporting process, the overload behavior MUST be clearly defined and the collecting process MUST be able to distinguish the flow records exported before and after the metering process behavior change: in case of any change of the meter's behavior, all flow records metered by the previous behavior MUST be terminated and exported according to the configuration of the exporting process. The metering process MUST not merge the flow records generated with the new behavior with the flow records generated with the previous behavior. I suggest to replace it by Overload behavior is not restricted to the four options listed above. But in case the overload behavior induces a change of the behavior of metering process and/or the exporting process, the following requirements must be met for all flows affected by the change of behavior: - The overload behavior MUST be clearly defined. - For each flows affected by the change, its record MUST be terminated at the time of change. - For each flow affected by the change, the collecting process MUST be able to determine whether the corresponding exported flow record was created before or after the change of behavior. Juergen -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Aug 28 08:19:47 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26678 for ; Wed, 28 Aug 2002 08:19:46 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17k1fJ-0003aI-00 for ipfix-list@mil.doit.wisc.edu; Wed, 28 Aug 2002 07:11:17 -0500 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17k1fH-0003ZN-00 for ipfix-req@net.doit.wisc.edu; Wed, 28 Aug 2002 07:11:15 -0500 Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g7SCAbU45513; Wed, 28 Aug 2002 14:10:37 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id DAE545D890; Wed, 28 Aug 2002 14:10:35 +0200 (CEST) Date: Wed, 28 Aug 2002 14:10:36 +0200 From: Juergen Quittek To: Sebastian Zander , calato@riverstonenet.com Cc: req Subject: duplicated flow records (was: Re: [ipfix-req] IPFIX Requirements Questions) Message-ID: <17917774.1030543836@[192.168.102.164]> In-Reply-To: <3D6CA423.3020900@fokus.gmd.de> References: <3D6CA423.3020900@fokus.gmd.de> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Sebastian, --On 28 August 2002 12:21 +0200 Sebastian Zander wrote: > > >>>8.3 Several Collecting Processes >>>> >>>> No mention is made when reporting to several devices >>>> of ensuring the duplicate data does not cause a double >>>> counting problem. >>>> >>> We discussed this issue, but did not find a clear requirement for >>> avoiding this or for providing means for avoiding this. >>> >> >> I don't understand. Double counting would surely cause >> problems for many if not all of the applications. >> >> >> >>> One problem >>> is that the collecting process is completely out of scope. >>> >> >> We are opening the door by allowing data to be sent to >> multiple Collectors. I think it would be difficult and >> perhaps even impossible, without protocol support. But >> I'm open to ideas on how it could be accomplished without >> protocol support. >> >> >>> Do you have an idea? >>> >> >> For example, in LFAP a Flow ID, timestamp and message ID >> uniquely identifies flow information. So the Collector could >> use that to weed out duplicate data. How and when would be >> out of scope. But the means is defined by the protocol. > I support to include duplicate detection as a requirement in the draft > but without suggestion a specific solution. That should be left for > > the spec. > Could you (or anyone else) suggest where to extend the requirements document and what text to insert? It looks like this would be a requirement for the exporting process. Juergen -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Aug 28 09:20:03 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28687 for ; Wed, 28 Aug 2002 09:20:03 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17k2Z9-0004yo-00 for ipfix-list@mil.doit.wisc.edu; Wed, 28 Aug 2002 08:08:59 -0500 Received: from [64.95.122.60] (helo=RS-SC-EXC4.rs.riverstonenet.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17k2Z8-0004y5-00 for ipfix-req@net.doit.wisc.edu; Wed, 28 Aug 2002 08:08:58 -0500 Received: from riverstonenet.com ([134.141.180.100]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 28 Aug 2002 06:08:26 -0700 Message-ID: <3D6CCAE5.1BF2C42D@riverstonenet.com> Date: Wed, 28 Aug 2002 09:06:45 -0400 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Quittek CC: req Subject: Re: fragmented packets (was: Re: [ipfix-req] IPFIX Requirements Questions) References: <3D6C18A3.764A46B9@riverstonenet.com> <1785807.1030527914@[192.168.102.164]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Aug 2002 13:08:26.0689 (UTC) FILETIME=[FF1AA310:01C24E93] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Juergen Quittek wrote: > > Hi Paul, > > --On 27 August 2002 20:26 -0400 calato@riverstonenet.com wrote: > > > Juergen Quittek wrote: > >> > >> --On 27 August 2002 14:49 -0400 calato@riverstonenet.com wrote: > >> > >> > > >> > As I work on the advocates document some questions > >> > have come to mind on the requirements document. > >> > > >> > 4.3 Distinguishing flows using Transport Header Fields > >> > > >> > In the case of fragmented packets there are > >> > no port numbers. Are we saying flow state information > >> > MUST be maintained? In general, it is not clear from > >> > >> No, the requirements document does not say so. > >> > >> > the document what the requirements are for fragmented > >> > packets. > >> > >> I think the requirements should not include a requirement for > >> keeping state of fragmented packets. Would you like to see > >> an explicit statement on that? This would be a NO NEED FOR > >> statement :-) > > > > I think we need to be explicit. Most people will think > > of fragements as being counted in the same flow as the > > first packet not as 2 differernt flows. > > I see. Waht about adding a new subsection to Section "5. Metering > Process": > > 5.8. Packet Fragmentation > > In case of IP packet fragmentation, only one fragment of a single > packet might contain sufficient information for classifying the > packet correctly. The metering process MAY keep state of > IP packet fragmentation in order to map fragments that do not > contain sufficient header information correctly to flows. How about a slight re-wording... In case of IP datagram fragmentation, only the first fragment might contain sufficient information for classifying the packet correctly. The metering process MAY keep state of IP fragmentation in order to map fragments without sufficient header information to the same flow as the first fragmented packet. > > [...] > > >> > 6.1 information Model > >> > > >> > 9 Packet Counter > >> > 10 Byte counter > >> > > >> > As mentioned earlier, for fragments this > >> > requires state information? If there is no > >> > state info, then what flow are the counted > >> > towards? > >> > >> Do you suggest to include a requirement for keeping fragment state info? > > > > > > A MAY is as far as I would go. There may certainly be probes > > that have this capability. We should have a requirement that > > says fragment counting MUST be clearly defined. > > OK. Currently, we have > > 9. packet counter > If a packet is fragmented, each fragment is counted as an > individual packet. > 10. byte counter > Which bytes of a packet are counted MUST be defined exactly. > > What about appending > > The behavior of the byte counter in case of IP packet > fragmentation MUST be clearly defined. With the new section on fragmentation I think we can eliminate any mention of it on the counters. > ? > > Please note that we also have in the MAY attributes section > > 26. fragmented packet counter > counter of all packets for which the fragmented bit is set in > the IP header I'm not sure why this was added. If you want that info, make the IP fragment bit part of the flow definition. > > Juergen -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Aug 28 09:29:17 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29107 for ; Wed, 28 Aug 2002 09:29:16 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17k2kS-0005Ku-00 for ipfix-list@mil.doit.wisc.edu; Wed, 28 Aug 2002 08:20:41 -0500 Received: from [64.95.122.60] (helo=RS-SC-EXC4.rs.riverstonenet.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17k2kN-0005K6-00 for ipfix-req@net.doit.wisc.edu; Wed, 28 Aug 2002 08:20:35 -0500 Received: from riverstonenet.com ([134.141.180.100]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 28 Aug 2002 06:20:03 -0700 Message-ID: <3D6CCD9E.DFD45743@riverstonenet.com> Date: Wed, 28 Aug 2002 09:18:22 -0400 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Quittek CC: req Subject: Re: MPLS label (was:Re: [ipfix-req] IPFIX Requirements Questions) References: <3D6C18A3.764A46B9@riverstonenet.com> <4553948.1030530472@[192.168.102.164]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Aug 2002 13:20:04.0280 (UTC) FILETIME=[9EE69380:01C24E95] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Juergen Quittek wrote: > > Hi Paul, > > --On 27 August 2002 20:26 -0400 calato@riverstonenet.com wrote: > > [...] > > >> > 4.4 MPLS Label > >> > > >> > In the case of dynamic LSP's the label is not useful. > >> > Why require distinguishing flows based on label. > >> > What can be done with that information? > >> > >> Well, for each attribute there are situations where it does not make > >> sense to use it for distinguishing flows. But being able to distinguish > >> flows by label seems to be useful to me in general. > > > > > > Then why not include things like VPI/VCI for ATM > > or other L2.5 tunnels? Why does MPLS get special > > consideration? > > In general I see your point, although MPLS appears to be closer > related to IP than plain ATM. Why? I can take and ATM PVC and use it as a tunnel for IP traffic just like MPLS. > > > Also, I may be wrong here but I beleive the primary > > use of MPLS will be with dynamic LSP's so the label > > has little meaning the majority of time. At best > > it would be a MAY requirement, not a MUST. > > For me, metering on a per-LSP basis is highly benefitial for the > operation of MPLS networks, even in the case of dynamic label > assignment. The LSR MIB already offers this kind of performance > information, but I think it also fits well into IPFIX. Are you talking about metering LSP's themselves or metering IP flows traveling through an LSP? Assuming you are talking about the latter, what can be done with the label information? If the flow F1 had label 57 and F2 had label 57 you don't even know if it is the same LSP. > > > If we are going to go this way, which I am > > against, then we should also include FEC. At least > > that would be more meaningful information in the > > case of dynamic LSPs. > > This could be useful, but the FEC is a higher level information > that is not available in many cases. Also we would need a good model > for FEC information. If the device knows the label it knows the FEC. There are some concrete FEC definitions now and we can always add more as they materialize. > > Juergen -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Aug 28 09:58:13 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00274 for ; Wed, 28 Aug 2002 09:58:13 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17k336-0005nA-00 for ipfix-list@mil.doit.wisc.edu; Wed, 28 Aug 2002 08:39:56 -0500 Received: from [64.95.122.60] (helo=RS-SC-EXC4.rs.riverstonenet.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17k333-0005m8-00 for ipfix-req@net.doit.wisc.edu; Wed, 28 Aug 2002 08:39:53 -0500 Received: from riverstonenet.com ([134.141.180.100]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 28 Aug 2002 06:39:19 -0700 Message-ID: <3D6CD222.CAC66D82@riverstonenet.com> Date: Wed, 28 Aug 2002 09:37:38 -0400 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Sebastian Zander CC: Juergen Quittek , req Subject: Re: [ipfix-req] IPFIX Requirements Questions References: <3D6BC9AD.CAC153C8@riverstonenet.com> <42174623.1030483746@[192.168.102.164]> <3D6C18A3.764A46B9@riverstonenet.com> <3D6CA423.3020900@fokus.gmd.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Aug 2002 13:39:19.0990 (UTC) FILETIME=[4FC1ED60:01C24E98] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Sebastian Zander wrote: > > Hi Paul, > > sorry for dropping in but I have some comments below. > > calato@riverstonenet.com wrote: > > > Juergen Quittek wrote: > > > >>--On 27 August 2002 14:49 -0400 calato@riverstonenet.com wrote: > >> > >> > >>>As I work on the advocates document some questions > >>>have come to mind on the requirements document. > >>> > >>>4.3 Distinguishing flows using Transport Header Fields > >>> > >>> In the case of fragmented packets there are > >>> no port numbers. Are we saying flow state information > >>> MUST be maintained? In general, it is not clear from > >>> > >>No, the requirements document does not say so. > >> > >> > >>> the document what the requirements are for fragmented > >>> packets. > >>> > >>I think the requirements should not include a requirement for > >>keeping state of fragmented packets. Would you like to see > >>an explicit statement on that? This would be a NO NEED FOR > >>statement :-) > >> > > > > I think we need to be explicit. Most people will think > > of fragements as being counted in the same flow as the > > first packet not as 2 differernt flows. > > Good point! According to the current draft the fragments after the > first would not be counted at all (in case you match on >L3) unless > there would be a more general rule matching the fragments and then > they appear in a different flow. The current draft requires a packet > counter which counts all fragments per flow so it seems to require > keeping flow state which is not so easy I guess. In case there is > no state the notion of the packet counter is that if we filter on > L3 we can count L3 packets (including fragments) and if we filter on > above that we can only count L4 packets (first fragments). That also > impacts the byte count because if we filter on above L4 we won't get > the correct byte count for the flow. > > >>>5.4 Timestamps > >>> > >>> Time stamps to not always mapped to the first packet and last > >>> packet. In many cases, the end timestamp is merely when > >>> the flow timed out and has nothing to do with when the > >>> last packet was seen. Allowing both semantics may be useful. > >>> A re-wording like this... > >>> > >>> > >>> The metering process MUST be able to generate timestamps for the > >>> start and end of a flow. The metering process MAY also provide > >>> timestamps for the first and the last observed packet > >>> of a flow. The timestamp resolution MUST be at least the one of > >>> the sysUpTime [RFC1213], which is one centisecond. > >>> > >>> Note - this does not mandate 2 timestamp fields for a flow. You > >>> could have one element for each meaning (e.g. Flow-start-time, > >>> first-packet-time, flow-start-and-first-packet-time) and use > >>> the one with the desired meaning. > >>> > >>You just added a MAY requirement for the timeout timestamp. We can do this, > >>but everything you mention was already possible without this additional > >>requirement. It was just required that the metering process can provide > >>these timestamps (if configured so). Whether or not they are exported > >>and whether or not other timestamps are exported was already left open > >>by the requirements. > >> > > > > I disagree. I'm not talking about what is exported, I talking > > about semantics. The req doc currently ties the timestamp event > > to packet observation. All metering processes will know > > when they created and deleted a flow. They may or may not > > know when the first or last packet was observed. > > > > The typical example of this is last packet. In many platforms > > the first packet is processed by the CPU and creates a hardware entry. > > The rest of the packets are processed and counted in hardware > > and thus there is no timestamp available, just a count. All > > that is known is when the flow was artifically timed out. > > > > A weaker argument can be made for first packet observed. There > > may be a known significant delay from packet observation to timestamp. > > In this case the metering process can report the time at which it > > created the flow but not first packet time. Weak I know. > > > I agree that we have to look at current practice but I have the feeling that > we get more and more vague just to support any existing thing. The requirements > are driven by applications. Lets look at accounting. I am wondering how IPFIX > information can be used for accounting when > > - there are no correct stop timestamps (there are no requirements on > the flow timeout) I don't think that is the case. If you report a flow end and the flow timeout period is 10 seconds, that will be close enough for most applications, even accounting. > > - there are no requirements on the report time (when are reports send) > (e.g. it is not required to export information at/after flow end) Good point. Maybe we need some text on report time. The exporting process MUST be able to report on flow start and end within a configurable time limit. > - there is no timestamp required in interim flow records I'm not sure I follow here. There is a SHOULD requirement for regular reporting. > - byte counters may not be correct (in case of port filtering and fragmentation) > > Well forget about the last one but with the first three we basically do not > comply to the req of the AAA WG for accounting. > > If the MUST requirement of the current draft is a problem for a lot of current > hardware then at least the requirement should be reduced to a SHOULD and not > a MAY. In this particular case I believe the definition is the problem, not the current hardware. I can't imagine any hardware ever timestamping every packet. > > >>>6.2 Data Model > >>> > >>> What about allowing Vendors to add information independently? > >>> Some data to be transported may be vendor specific and never > >>> make it into the IPFIX spec. > >>> > >>I don't see how the requirements forbid this. > >> > > > > The only reason I'm calling this out is "extensible protocol" > > usually means future changes to the protocol can be added > > without breaking existing applications. The vendor > > specific extensions allow extenstions without modifying the > > protocol, without breaking existing server and without stepping > > on other verndor's extensions. > > I don't think this belongs to the req draft. But certainly in the > spec. Agreed. > > > > > >>>8.3 Several Collecting Processes > >>> > >>> No mention is made when reporting to several devices > >>> of ensuring the duplicate data does not cause a double > >>> counting problem. > >>> > >>We discussed this issue, but did not find a clear requirement for > >>avoiding this or for providing means for avoiding this. > >> > > > > I don't understand. Double counting would surely cause > > problems for many if not all of the applications. > > > > > > > >>One problem > >>is that the collecting process is completely out of scope. > >> > > > > We are opening the door by allowing data to be sent to > > multiple Collectors. I think it would be difficult and > > perhaps even impossible, without protocol support. But > > I'm open to ideas on how it could be accomplished without > > protocol support. > > > > > >>Do you have an idea? > >> > > > > For example, in LFAP a Flow ID, timestamp and message ID > > uniquely identifies flow information. So the Collector could > > use that to weed out duplicate data. How and when would be > > out of scope. But the means is defined by the protocol. > > I support to include duplicate detection as a requirement in the draft > > but without suggestion a specific solution. That should be left for > > the spec. > > Cheers, > > Sebastian > > -- > Sebastian Zander E-mail: zander@fokus.fhg.de > FhI FOKUS / Global Networking (GloNe) Tel: +49-30-3463-7287 > Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 > D-10589 Berlin, Germany www.fokus.fhg.de/usr/sebastian.zander -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Aug 28 10:14:08 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00964 for ; Wed, 28 Aug 2002 10:14:08 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17k3KT-0006Dr-00 for ipfix-list@mil.doit.wisc.edu; Wed, 28 Aug 2002 08:57:53 -0500 Received: from [64.95.122.60] (helo=RS-SC-EXC4.rs.riverstonenet.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17k3KR-0006D5-00 for ipfix-req@net.doit.wisc.edu; Wed, 28 Aug 2002 08:57:51 -0500 Received: from riverstonenet.com ([134.141.180.100]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 28 Aug 2002 06:57:19 -0700 Message-ID: <3D6CD65A.C52F4654@riverstonenet.com> Date: Wed, 28 Aug 2002 09:55:38 -0400 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Quittek CC: req Subject: Re: overload behavior (was: Re: [ipfix-req] IPFIX Requirements Questions) References: <3D6C18A3.764A46B9@riverstonenet.com> <16837340.1030542756@[192.168.102.164]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Aug 2002 13:57:20.0214 (UTC) FILETIME=[D39F0760:01C24E9A] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Juergen Quittek wrote: > > Hi Paul, > > --On 27 August 2002 20:26 -0400 calato@riverstonenet.com wrote: > > [...] > > >> > 5.3 Overload Behavior > >> > > >> > This section needs to be re-worked a little. Some > >> > of the MUST's impose undue burden on the device. > >> > > >> > 1. Must distinguish flow records before and after the > >> > behavior change. > >> > > >> > In the case where the behavior is to drop > >> > overflow flows, why do we need to distinguish > >> > flows. Perhaps I misunderstood something. > >> > > >> > > >> > 2. All flows from previous behavior MUST be terminated. > >> > > >> > > >> > Again, if I simply dropped excess flows why terminate > >> > all existing ones. This will likely cause more overflow > >> > as the get reestablished. This also seems to go to > >> > far towards implementation. > >> > >> I agree. > >> > >> > 3. Meeting process MUST NOT merge previous records. > >> > > >> > > >> > > >> > I think what we are trying to say is flows with a different > >> > definition MUST be distinguishable. How that is done is not > >> > part of the requirements doc. > >> > >> Also agreed. However, it is not just different definition, but also > >> different measurement technique, different sampling rate, etc. > >> > >> We need to express this intended requirement it in a better way. > > > > Agreed. > > > > What this points out to me is that we do not have a term > > that refers to the set of information that is the flow > > definition. We touch on it in section 2.1 when discussing > > the flow definition itself, in section 2.3 when discussing > > classifying and then again in section 4 when discussing > > distinguishing flows. > > > > What about a new term "Distinguishing Properties" or > > "Flow Properties"? Its definition would be > > > > The set of fields, functions and parameters (e.g. sampling > > rate) used to map packets to flows. > > > > Then we can say each flow MUST be able to be mapped to its > > "Distinguishing properties". > > > > This would cover changing behavior due to overload, configuration > > changes, etc... > > > > Thoughts? > > I think the mistake in the current version of the text is that it > asks on separating flows before and after the metering process was > modified. It is indepenedent of whether the individual flows are > affected or not. I think it is sufficient to fix this. You side stepped my main 2 issues here. 1. We need a definition for the set of functions, fields and parameters use to map packets to flows. If it is there and I missed it, let me know. 2. We need a requirement that allows the Collecting device to map flows to the set of functions, fields and parameters used to create the flow. > > The current text is > > Overload behavior is not restricted to the four options listed above. > But in case the overload behavior has an impact on the metering > process or the exporting process, the overload behavior MUST be > clearly defined and the collecting process MUST be able to > distinguish the flow records exported before and after the metering > process behavior change: in case of any change of the meter's > behavior, all flow records metered by the previous behavior MUST be > terminated and exported according to the configuration of the > exporting process. The metering process MUST not merge the flow > records generated with the new behavior with the flow records > generated with the previous behavior. > > I suggest to replace it by > > Overload behavior is not restricted to the four options listed above. > But in case the overload behavior induces a change of the behavior of > metering process and/or the exporting process, the following requirements > must be met for all flows affected by the change of behavior: > - The overload behavior MUST be clearly defined. Agreed. > - For each flows affected by the change, its record MUST be terminated > at the time of change. This seems like implementation detail. Maybe I want to leave them in tact and when the overload situation is resolved I can start adding to the counter again. > - For each flow affected by the change, the collecting process MUST be > able to determine whether the corresponding exported flow record was > created before or after the change of behavior. I believe that if we address the 2 issues discussed earlier these would no longer be needed. > > Juergen -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Aug 28 10:30:17 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01782 for ; Wed, 28 Aug 2002 10:30:17 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17k3h9-0006rL-00 for ipfix-list@mil.doit.wisc.edu; Wed, 28 Aug 2002 09:21:19 -0500 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17k3h5-0006qT-00 for ipfix-req@net.doit.wisc.edu; Wed, 28 Aug 2002 09:21:15 -0500 Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g7SEKiU51426; Wed, 28 Aug 2002 16:20:44 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id EDFE153B96; Wed, 28 Aug 2002 16:20:42 +0200 (CEST) Date: Wed, 28 Aug 2002 16:20:43 +0200 From: Juergen Quittek To: calato@riverstonenet.com Cc: req Subject: Re: fragmented packets (was: Re: [ipfix-req] IPFIX Requirements Questions) Message-ID: <25723999.1030551643@[192.168.102.164]> In-Reply-To: <3D6CCAE5.1BF2C42D@riverstonenet.com> References: <3D6CCAE5.1BF2C42D@riverstonenet.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Paul, --On 28 August 2002 09:06 -0400 calato@riverstonenet.com wrote: > Juergen Quittek wrote: >> >> Hi Paul, >> >> --On 27 August 2002 20:26 -0400 calato@riverstonenet.com wrote: >> >> > Juergen Quittek wrote: >> >> >> >> --On 27 August 2002 14:49 -0400 calato@riverstonenet.com wrote: >> >> >> >> > >> >> > As I work on the advocates document some questions >> >> > have come to mind on the requirements document. >> >> > >> >> > 4.3 Distinguishing flows using Transport Header Fields >> >> > >> >> > In the case of fragmented packets there are >> >> > no port numbers. Are we saying flow state information >> >> > MUST be maintained? In general, it is not clear from >> >> >> >> No, the requirements document does not say so. >> >> >> >> > the document what the requirements are for fragmented >> >> > packets. >> >> >> >> I think the requirements should not include a requirement for >> >> keeping state of fragmented packets. Would you like to see >> >> an explicit statement on that? This would be a NO NEED FOR >> >> statement :-) >> > >> > I think we need to be explicit. Most people will think >> > of fragements as being counted in the same flow as the >> > first packet not as 2 differernt flows. >> >> I see. Waht about adding a new subsection to Section "5. Metering >> Process": >> >> 5.8. Packet Fragmentation >> >> In case of IP packet fragmentation, only one fragment of a single >> packet might contain sufficient information for classifying the >> packet correctly. The metering process MAY keep state of >> IP packet fragmentation in order to map fragments that do not >> contain sufficient header information correctly to flows. > > How about a slight re-wording... > > In case of IP datagram fragmentation, only the first fragment might > contain sufficient information for classifying the packet correctly. > The metering process MAY keep state of IP fragmentation in order to > map fragments without sufficient header information to the same > flow as the first fragmented packet. Initially I also wanted to phrase like this. But it's IP. And fragments might get re-ordered. The first fragment of a packet that is observed, is not necessarily the fragment containing the TCP/UDP header. Now, if you say "first", it is not clear whether you mean the fragment with the first bytes of the IP payload or the first fragment observed at the observation point. Your last sentence seems to assume that the first observed packet is the one with the first bytes of the payload. >> [...] >> >> >> > 6.1 information Model >> >> > >> >> > 9 Packet Counter >> >> > 10 Byte counter >> >> > >> >> > As mentioned earlier, for fragments this >> >> > requires state information? If there is no >> >> > state info, then what flow are the counted >> >> > towards? >> >> >> >> Do you suggest to include a requirement for keeping fragment state info? >> > >> > >> > A MAY is as far as I would go. There may certainly be probes >> > that have this capability. We should have a requirement that >> > says fragment counting MUST be clearly defined. >> >> OK. Currently, we have >> >> 9. packet counter >> If a packet is fragmented, each fragment is counted as an >> individual packet. >> 10. byte counter >> Which bytes of a packet are counted MUST be defined exactly. >> >> What about appending >> >> The behavior of the byte counter in case of IP packet >> fragmentation MUST be clearly defined. > > With the new section on fragmentation I think we can > eliminate any mention of it on the counters. The new section of the fragmentation is a MAY requirement. But for understamding the behavior of the byte counter you MUST know whether or not the option is implemented. >> ? >> >> Please note that we also have in the MAY attributes section >> >> 26. fragmented packet counter >> counter of all packets for which the fragmented bit is set in >> the IP header > > I'm not sure why this was added. If you want that info, > make the IP fragment bit part of the flow definition. Do you suggest to remove it? Anyone else? Juergen -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Aug 28 10:39:09 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02103 for ; Wed, 28 Aug 2002 10:39:08 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17k3qI-00077L-00 for ipfix-list@mil.doit.wisc.edu; Wed, 28 Aug 2002 09:30:46 -0500 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17k3qG-00076i-00 for ipfix-req@net.doit.wisc.edu; Wed, 28 Aug 2002 09:30:44 -0500 Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g7SEUCU52080; Wed, 28 Aug 2002 16:30:12 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id EAD4E4DB56; Wed, 28 Aug 2002 16:30:11 +0200 (CEST) Date: Wed, 28 Aug 2002 16:30:12 +0200 From: Juergen Quittek To: calato@riverstonenet.com Cc: req Subject: Re: MPLS label (was:Re: [ipfix-req] IPFIX Requirements Questions) Message-ID: <26292857.1030552212@[192.168.102.164]> In-Reply-To: <3D6CCD9E.DFD45743@riverstonenet.com> References: <3D6CCD9E.DFD45743@riverstonenet.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Paul, --On 28 August 2002 09:18 -0400 calato@riverstonenet.com wrote: > Juergen Quittek wrote: >> >> Hi Paul, >> >> --On 27 August 2002 20:26 -0400 calato@riverstonenet.com wrote: >> >> [...] >> >> >> > 4.4 MPLS Label >> >> > >> >> > In the case of dynamic LSP's the label is not useful. >> >> > Why require distinguishing flows based on label. >> >> > What can be done with that information? >> >> >> >> Well, for each attribute there are situations where it does not make >> >> sense to use it for distinguishing flows. But being able to distinguish >> >> flows by label seems to be useful to me in general. >> > >> > >> > Then why not include things like VPI/VCI for ATM >> > or other L2.5 tunnels? Why does MPLS get special >> > consideration? >> >> In general I see your point, although MPLS appears to be closer >> related to IP than plain ATM. > > Why? I can take and ATM PVC and use it as a tunnel for > IP traffic just like MPLS. Yes, but MPLS integrates with IP forwarcing when using CR-LDP or RSVP-TE. Also you can use MPLS as "glue" between IP and ATM. >> > Also, I may be wrong here but I beleive the primary >> > use of MPLS will be with dynamic LSP's so the label >> > has little meaning the majority of time. At best >> > it would be a MAY requirement, not a MUST. >> >> For me, metering on a per-LSP basis is highly benefitial for the >> operation of MPLS networks, even in the case of dynamic label >> assignment. The LSR MIB already offers this kind of performance >> information, but I think it also fits well into IPFIX. > > Are you talking about metering LSP's themselves or > metering IP flows traveling through an LSP? I'm talking about metering LSPs and about observing which flow maps into which LSP. > Assuming you are talking about the latter, what can be done > with the label information? If the flow F1 had label 57 > and F2 had label 57 you don't even know if it is the > same LSP. You are right. I would also need interface information. >> >> > If we are going to go this way, which I am >> > against, then we should also include FEC. At least >> > that would be more meaningful information in the >> > case of dynamic LSPs. >> >> This could be useful, but the FEC is a higher level information >> that is not available in many cases. Also we would need a good model >> for FEC information. > > If the device knows the label it knows the FEC. There are > some concrete FEC definitions now and we can always add more > as they materialize. All you need for an LSP are entries in insegment table, outsegment table and switching table. How does the device know anything about the FEC if the LSP was explicitly setup by a management system that added entries to these tables. Juergen -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Aug 28 10:49:33 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02592 for ; Wed, 28 Aug 2002 10:49:32 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17k3zb-0007Jn-00 for ipfix-list@mil.doit.wisc.edu; Wed, 28 Aug 2002 09:40:23 -0500 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17k3zZ-0007J5-00 for ipfix-req@net.doit.wisc.edu; Wed, 28 Aug 2002 09:40:21 -0500 Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g7SEdoU52493; Wed, 28 Aug 2002 16:39:50 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 6CDDC5D8B5; Wed, 28 Aug 2002 16:39:49 +0200 (CEST) Date: Wed, 28 Aug 2002 16:39:49 +0200 From: Juergen Quittek To: calato@riverstonenet.com Cc: req Subject: Re: overload behavior (was: Re: [ipfix-req] IPFIX Requirements Questions) Message-ID: <26869946.1030552789@[192.168.102.164]> In-Reply-To: <3D6CD65A.C52F4654@riverstonenet.com> References: <3D6CD65A.C52F4654@riverstonenet.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Paul, --On 28 August 2002 09:55 -0400 calato@riverstonenet.com wrote: > Juergen Quittek wrote: >> >> Hi Paul, >> >> --On 27 August 2002 20:26 -0400 calato@riverstonenet.com wrote: >> >> [...] >> >> >> > 5.3 Overload Behavior >> >> > >> >> > This section needs to be re-worked a little. Some >> >> > of the MUST's impose undue burden on the device. >> >> > >> >> > 1. Must distinguish flow records before and after the >> >> > behavior change. >> >> > >> >> > In the case where the behavior is to drop >> >> > overflow flows, why do we need to distinguish >> >> > flows. Perhaps I misunderstood something. >> >> > >> >> > >> >> > 2. All flows from previous behavior MUST be terminated. >> >> > >> >> > >> >> > Again, if I simply dropped excess flows why terminate >> >> > all existing ones. This will likely cause more overflow >> >> > as the get reestablished. This also seems to go to >> >> > far towards implementation. >> >> >> >> I agree. >> >> >> >> > 3. Meeting process MUST NOT merge previous records. >> >> > >> >> > >> >> > >> >> > I think what we are trying to say is flows with a different >> >> > definition MUST be distinguishable. How that is done is not >> >> > part of the requirements doc. >> >> >> >> Also agreed. However, it is not just different definition, but also >> >> different measurement technique, different sampling rate, etc. >> >> >> >> We need to express this intended requirement it in a better way. >> > >> > Agreed. >> > >> > What this points out to me is that we do not have a term >> > that refers to the set of information that is the flow >> > definition. We touch on it in section 2.1 when discussing >> > the flow definition itself, in section 2.3 when discussing >> > classifying and then again in section 4 when discussing >> > distinguishing flows. >> > >> > What about a new term "Distinguishing Properties" or >> > "Flow Properties"? Its definition would be >> > >> > The set of fields, functions and parameters (e.g. sampling >> > rate) used to map packets to flows. >> > >> > Then we can say each flow MUST be able to be mapped to its >> > "Distinguishing properties". >> > >> > This would cover changing behavior due to overload, configuration >> > changes, etc... >> > >> > Thoughts? >> >> I think the mistake in the current version of the text is that it >> asks on separating flows before and after the metering process was >> modified. It is indepenedent of whether the individual flows are >> affected or not. I think it is sufficient to fix this. > > > You side stepped my main 2 issues here. > > 1. We need a definition for the set of functions, > fields and parameters use to map packets to flows. > If it is there and I missed it, let me know. > > 2. We need a requirement that allows the Collecting > device to map flows to the set of functions, > fields and parameters used to create the flow. My intention was not to side step them, but to answer on the portion of your comment on which I already made up my mind already. On this issue I still have to think some more. >> >> The current text is >> >> Overload behavior is not restricted to the four options listed above. >> But in case the overload behavior has an impact on the metering >> process or the exporting process, the overload behavior MUST be >> clearly defined and the collecting process MUST be able to >> distinguish the flow records exported before and after the metering >> process behavior change: in case of any change of the meter's >> behavior, all flow records metered by the previous behavior MUST be >> terminated and exported according to the configuration of the >> exporting process. The metering process MUST not merge the flow >> records generated with the new behavior with the flow records >> generated with the previous behavior. >> >> I suggest to replace it by >> >> Overload behavior is not restricted to the four options listed above. >> But in case the overload behavior induces a change of the behavior of >> metering process and/or the exporting process, the following requirements >> must be met for all flows affected by the change of behavior: >> - The overload behavior MUST be clearly defined. > > Agreed. > >> - For each flows affected by the change, its record MUST be terminated >> at the time of change. > > This seems like implementation detail. Maybe I want to leave > them in tact and when the overload situation is resolved I can > start adding to the counter again. I don't think this would be a good idea, because it might not be clear to the collector that you ignored all packets for some time. This seems to be a very unreliable behavior. However, you still might be right. Very often it is hard to distinguish between the real requirement and a particular implementation meeting that requirement. In this case I am not sure. >> - For each flow affected by the change, the collecting process MUST be >> able to determine whether the corresponding exported flow record was >> created before or after the change of behavior. > > I believe that if we address the 2 issues discussed earlier > these would no longer be needed. Would be fine. Juergen -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Aug 28 11:03:17 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03084 for ; Wed, 28 Aug 2002 11:03:17 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17k4DB-0007ag-00 for ipfix-list@mil.doit.wisc.edu; Wed, 28 Aug 2002 09:54:25 -0500 Received: from [64.95.122.60] (helo=RS-SC-EXC4.rs.riverstonenet.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17k4D9-0007a1-00 for ipfix-req@net.doit.wisc.edu; Wed, 28 Aug 2002 09:54:23 -0500 Received: from riverstonenet.com ([134.141.180.100]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 28 Aug 2002 07:53:51 -0700 Message-ID: <3D6CE39A.AFD0F9C5@riverstonenet.com> Date: Wed, 28 Aug 2002 10:52:10 -0400 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Quittek CC: req Subject: Re: MPLS label (was:Re: [ipfix-req] IPFIX Requirements Questions) References: <3D6CCD9E.DFD45743@riverstonenet.com> <26292857.1030552212@[192.168.102.164]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Aug 2002 14:53:52.0232 (UTC) FILETIME=[B96BE680:01C24EA2] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Juergen Quittek wrote: > > Hi Paul, > > --On 28 August 2002 09:18 -0400 calato@riverstonenet.com wrote: > > > Juergen Quittek wrote: > >> > >> Hi Paul, > >> > >> --On 27 August 2002 20:26 -0400 calato@riverstonenet.com wrote: > >> > >> [...] > >> > >> >> > 4.4 MPLS Label > >> >> > > >> >> > In the case of dynamic LSP's the label is not useful. > >> >> > Why require distinguishing flows based on label. > >> >> > What can be done with that information? > >> >> > >> >> Well, for each attribute there are situations where it does not make > >> >> sense to use it for distinguishing flows. But being able to distinguish > >> >> flows by label seems to be useful to me in general. > >> > > >> > > >> > Then why not include things like VPI/VCI for ATM > >> > or other L2.5 tunnels? Why does MPLS get special > >> > consideration? > >> > >> In general I see your point, although MPLS appears to be closer > >> related to IP than plain ATM. > > > > Why? I can take and ATM PVC and use it as a tunnel for > > IP traffic just like MPLS. > > Yes, but MPLS integrates with IP forwarcing when using CR-LDP > or RSVP-TE. Also you can use MPLS as "glue" between IP and ATM. I don't understand your argument here. Both technologies are viable solutions and exist in the market today. If one is included, so should the other. > > >> > Also, I may be wrong here but I beleive the primary > >> > use of MPLS will be with dynamic LSP's so the label > >> > has little meaning the majority of time. At best > >> > it would be a MAY requirement, not a MUST. > >> > >> For me, metering on a per-LSP basis is highly benefitial for the > >> operation of MPLS networks, even in the case of dynamic label > >> assignment. The LSR MIB already offers this kind of performance > >> information, but I think it also fits well into IPFIX. > > > > Are you talking about metering LSP's themselves or > > metering IP flows traveling through an LSP? > > I'm talking about metering LSPs and about observing which flow maps > into which LSP. I'm a little confused. I thought we were only doing IP flows. Are we now including MPLS flows (LSPs)? > > > Assuming you are talking about the latter, what can be done > > with the label information? If the flow F1 had label 57 > > and F2 had label 57 you don't even know if it is the > > same LSP. > > You are right. I would also need interface information. OK. So now I have F1, I1 and L57 and then F2, I1 and L57. I still don't know if it is the same LSP. > > >> > >> > If we are going to go this way, which I am > >> > against, then we should also include FEC. At least > >> > that would be more meaningful information in the > >> > case of dynamic LSPs. > >> > >> This could be useful, but the FEC is a higher level information > >> that is not available in many cases. Also we would need a good model > >> for FEC information. > > > > If the device knows the label it knows the FEC. There are > > some concrete FEC definitions now and we can always add more > > as they materialize. > > All you need for an LSP are entries in insegment table, outsegment table > and switching table. How does the device know anything about the FEC if the > LSP was explicitly setup by a management system that added entries to these > tables. Let me make sure I understand. Some external management station received the FEC and programmed the device? If that is the case then you are correct. However, wont many deployments have the 2 functions on one device? If so, then reporting FEC is at least a MAY requirement. > > Juergen -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Aug 28 11:45:32 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05140 for ; Wed, 28 Aug 2002 11:45:31 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17k4qm-0004zt-00 for ipfix-list@mil.doit.wisc.edu; Wed, 28 Aug 2002 10:35:20 -0500 Received: from smtp.slac.stanford.edu ([134.79.18.80]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17k4qj-0004zV-00 for ipfix-req@net.doit.wisc.edu; Wed, 28 Aug 2002 10:35:17 -0500 Received: from CONVERSION-DAEMON.smtp.slac.stanford.edu by smtp.slac.stanford.edu (PMDF V6.1-1 #37665) id <0H1K009018MSTG@smtp.slac.stanford.edu> for ipfix-req@net.doit.wisc.edu; Wed, 28 Aug 2002 08:35:16 -0700 (PDT) Received: from smtpserv1.slac.stanford.edu (smtpserv1.slac.stanford.edu [134.79.18.81]) by smtp.slac.stanford.edu (PMDF V6.1-1 #37665) with ESMTP id <0H1K0088R8MSM5@smtp.slac.stanford.edu>; Wed, 28 Aug 2002 08:35:16 -0700 (PDT) Received: from ATREUS.slac.stanford.edu ([134.79.18.84]) by smtpserv1.slac.stanford.edu (PMDF V6.1 #37665) with ESMTP id <0H1K00JAZ8MSUZ@smtpserv1.slac.stanford.edu>; Wed, 28 Aug 2002 08:35:16 -0700 (PDT) Received: by ATREUS.slac.stanford.edu with Internet Mail Service (5.5.2653.19) id ; Wed, 28 Aug 2002 08:34:24 -0700 Content-return: allowed Date: Wed, 28 Aug 2002 08:34:15 -0700 From: "Logg, Connie A." Subject: RE: fragmented packets (was: Re: [ipfix-req] IPFIX Requirements Q uestions) To: "'calato@riverstonenet.com'" , Juergen Quittek Cc: req Message-id: <2846497B437BF84BAD1A4CC407418D26D13B0C@exchange1.slac.stanford.edu> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7BIT I would certainly like to see fragmented packets some how identified with the first packet. I have an algorithm for processing netflow data that works "most of the time" for extracting these for my netflow analysis, but most of the time is not really good enough. Our AFS traffic is an example. We really would like to be able to accurately quantify the AFS traffic, as we have a lot of it. For high utilizations, the algorithm breaks down, as it also does when there are more than one AFS transaction going on at a time. Connie Logg - Network Analyst - 650-926-2879 Stanford Linear Accelerator Center MS 97; 2575 SandHill Road; Menlo Park CA 94025 "Happiness is found along the way, not at the end of the road" -----Original Message----- From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] Sent: Wednesday, August 28, 2002 6:07 AM To: Juergen Quittek Cc: req Subject: Re: fragmented packets (was: Re: [ipfix-req] IPFIX Requirements Questions) Juergen Quittek wrote: > > Hi Paul, > > --On 27 August 2002 20:26 -0400 calato@riverstonenet.com wrote: > > > Juergen Quittek wrote: > >> > >> --On 27 August 2002 14:49 -0400 calato@riverstonenet.com wrote: > >> > >> > > >> > As I work on the advocates document some questions > >> > have come to mind on the requirements document. > >> > > >> > 4.3 Distinguishing flows using Transport Header Fields > >> > > >> > In the case of fragmented packets there are > >> > no port numbers. Are we saying flow state information > >> > MUST be maintained? In general, it is not clear from > >> > >> No, the requirements document does not say so. > >> > >> > the document what the requirements are for fragmented > >> > packets. > >> > >> I think the requirements should not include a requirement for > >> keeping state of fragmented packets. Would you like to see > >> an explicit statement on that? This would be a NO NEED FOR > >> statement :-) > > > > I think we need to be explicit. Most people will think > > of fragements as being counted in the same flow as the > > first packet not as 2 differernt flows. > > I see. Waht about adding a new subsection to Section "5. Metering > Process": > > 5.8. Packet Fragmentation > > In case of IP packet fragmentation, only one fragment of a single > packet might contain sufficient information for classifying the > packet correctly. The metering process MAY keep state of > IP packet fragmentation in order to map fragments that do not > contain sufficient header information correctly to flows. How about a slight re-wording... In case of IP datagram fragmentation, only the first fragment might contain sufficient information for classifying the packet correctly. The metering process MAY keep state of IP fragmentation in order to map fragments without sufficient header information to the same flow as the first fragmented packet. > > [...] > > >> > 6.1 information Model > >> > > >> > 9 Packet Counter > >> > 10 Byte counter > >> > > >> > As mentioned earlier, for fragments this > >> > requires state information? If there is no > >> > state info, then what flow are the counted > >> > towards? > >> > >> Do you suggest to include a requirement for keeping fragment state info? > > > > > > A MAY is as far as I would go. There may certainly be probes > > that have this capability. We should have a requirement that > > says fragment counting MUST be clearly defined. > > OK. Currently, we have > > 9. packet counter > If a packet is fragmented, each fragment is counted as an > individual packet. > 10. byte counter > Which bytes of a packet are counted MUST be defined exactly. > > What about appending > > The behavior of the byte counter in case of IP packet > fragmentation MUST be clearly defined. With the new section on fragmentation I think we can eliminate any mention of it on the counters. > ? > > Please note that we also have in the MAY attributes section > > 26. fragmented packet counter > counter of all packets for which the fragmented bit is set in > the IP header I'm not sure why this was added. If you want that info, make the IP fragment bit part of the flow definition. > > Juergen -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Aug 28 11:58:46 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06161 for ; Wed, 28 Aug 2002 11:58:46 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17k4yx-0006hP-00 for ipfix-list@mil.doit.wisc.edu; Wed, 28 Aug 2002 10:43:47 -0500 Received: from [64.95.122.60] (helo=RS-SC-EXC4.rs.riverstonenet.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17k4yu-0006bS-00 for ipfix-req@net.doit.wisc.edu; Wed, 28 Aug 2002 10:43:44 -0500 Received: from riverstonenet.com ([134.141.180.100]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 28 Aug 2002 08:43:12 -0700 Message-ID: <3D6CEF2B.5D246254@riverstonenet.com> Date: Wed, 28 Aug 2002 11:41:31 -0400 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: req Subject: [Fwd: fragmented packets (was: Re: [ipfix-req] IPFIX Requirements Questions)] Content-Type: multipart/mixed; boundary="------------AC25A8CBFE9211D6854D1D10" X-OriginalArrivalTime: 28 Aug 2002 15:43:13.0117 (UTC) FILETIME=[9E3F18D0:01C24EA9] Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------AC25A8CBFE9211D6854D1D10 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sorry, forgot to CC the list again. --------------AC25A8CBFE9211D6854D1D10 Content-Type: message/rfc822 Content-Disposition: inline X-Mozilla-Status2: 00000000 Message-ID: <3D6CE003.CEEE3985@riverstonenet.com> Date: Wed, 28 Aug 2002 10:36:51 -0400 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Quittek Subject: Re: fragmented packets (was: Re: [ipfix-req] IPFIX Requirements Questions) References: <3D6CCAE5.1BF2C42D@riverstonenet.com> <25723999.1030551643@[192.168.102.164]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Juergen Quittek wrote: > > Hi Paul, > > --On 28 August 2002 09:06 -0400 calato@riverstonenet.com wrote: > > > Juergen Quittek wrote: > >> > >> Hi Paul, > >> > >> --On 27 August 2002 20:26 -0400 calato@riverstonenet.com wrote: > >> > >> > Juergen Quittek wrote: > >> >> > >> >> --On 27 August 2002 14:49 -0400 calato@riverstonenet.com wrote: > >> >> > >> >> > > >> >> > As I work on the advocates document some questions > >> >> > have come to mind on the requirements document. > >> >> > > >> >> > 4.3 Distinguishing flows using Transport Header Fields > >> >> > > >> >> > In the case of fragmented packets there are > >> >> > no port numbers. Are we saying flow state information > >> >> > MUST be maintained? In general, it is not clear from > >> >> > >> >> No, the requirements document does not say so. > >> >> > >> >> > the document what the requirements are for fragmented > >> >> > packets. > >> >> > >> >> I think the requirements should not include a requirement for > >> >> keeping state of fragmented packets. Would you like to see > >> >> an explicit statement on that? This would be a NO NEED FOR > >> >> statement :-) > >> > > >> > I think we need to be explicit. Most people will think > >> > of fragements as being counted in the same flow as the > >> > first packet not as 2 differernt flows. > >> > >> I see. Waht about adding a new subsection to Section "5. Metering > >> Process": > >> > >> 5.8. Packet Fragmentation > >> > >> In case of IP packet fragmentation, only one fragment of a single > >> packet might contain sufficient information for classifying the > >> packet correctly. The metering process MAY keep state of > >> IP packet fragmentation in order to map fragments that do not > >> contain sufficient header information correctly to flows. > > > > How about a slight re-wording... > > > > In case of IP datagram fragmentation, only the first fragment might > > contain sufficient information for classifying the packet correctly. > > The metering process MAY keep state of IP fragmentation in order to > > map fragments without sufficient header information to the same > > flow as the first fragmented packet. > > Initially I also wanted to phrase like this. But it's IP. And fragments > might get re-ordered. The first fragment of a packet that is observed, > is not necessarily the fragment containing the TCP/UDP header. > > Now, if you say "first", it is not clear whether you mean the fragment > with the first bytes of the IP payload or the first fragment observed > at the observation point. Your last sentence seems to assume that the > first observed packet is the one with the first bytes of the payload. GOod point. How about this... In case of IP datagram fragmentation, only one fragment contains sufficient information to fully classify the packet. The metering process MAY keep state of IP fragmentation in order to map fragments without sufficient header information to the same flow as the fully classified fragmented packet. > > >> [...] > >> > >> >> > 6.1 information Model > >> >> > > >> >> > 9 Packet Counter > >> >> > 10 Byte counter > >> >> > > >> >> > As mentioned earlier, for fragments this > >> >> > requires state information? If there is no > >> >> > state info, then what flow are the counted > >> >> > towards? > >> >> > >> >> Do you suggest to include a requirement for keeping fragment state info? > >> > > >> > > >> > A MAY is as far as I would go. There may certainly be probes > >> > that have this capability. We should have a requirement that > >> > says fragment counting MUST be clearly defined. > >> > >> OK. Currently, we have > >> > >> 9. packet counter > >> If a packet is fragmented, each fragment is counted as an > >> individual packet. > >> 10. byte counter > >> Which bytes of a packet are counted MUST be defined exactly. > >> > >> What about appending > >> > >> The behavior of the byte counter in case of IP packet > >> fragmentation MUST be clearly defined. > > > > With the new section on fragmentation I think we can > > eliminate any mention of it on the counters. > > The new section of the fragmentation is a MAY requirement. But for > understamding the behavior of the byte counter you MUST know whether > or not the option is implemented. I assumed the clearly defined byte counter meant whether or not you include the ethernet header, the IP header, the CRC, etc... The counters will count bytes and packets that map to the same flow. It doesn't matter if it is a fragment or not. So I see this as a flow mapping issue only, not a counter issue. > > >> ? > >> > >> Please note that we also have in the MAY attributes section > >> > >> 26. fragmented packet counter > >> counter of all packets for which the fragmented bit is set in > >> the IP header > > > > I'm not sure why this was added. If you want that info, > > make the IP fragment bit part of the flow definition. > > Do you suggest to remove it? Anyone else? Yes. I suggest we remove it. > > Juergen --------------AC25A8CBFE9211D6854D1D10-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" 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 Aug 28 12:03:16 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06430 for ; Wed, 28 Aug 2002 12:03:14 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17k53f-0007eO-00 for ipfix-list@mil.doit.wisc.edu; Wed, 28 Aug 2002 10:48:39 -0500 Received: from [64.95.122.60] (helo=RS-SC-EXC4.rs.riverstonenet.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17k53c-0007UA-00 for ipfix-req@net.doit.wisc.edu; Wed, 28 Aug 2002 10:48:36 -0500 Received: from riverstonenet.com ([134.141.180.100]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 28 Aug 2002 08:48:04 -0700 Message-ID: <3D6CF04F.5D40A9DF@riverstonenet.com> Date: Wed, 28 Aug 2002 11:46:23 -0400 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: req Subject: [Fwd: fragmented packets (was: Re: [ipfix-req] IPFIX Requirements Questions)] Content-Type: multipart/mixed; boundary="------------D71818F884131D564C6B5309" X-OriginalArrivalTime: 28 Aug 2002 15:48:04.0919 (UTC) FILETIME=[4C2C8C70:01C24EAA] Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------D71818F884131D564C6B5309 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit OK. So I need to learn how to hit reply all :-( --------------D71818F884131D564C6B5309 Content-Type: message/rfc822 Content-Disposition: inline X-Mozilla-Status2: 00000000 Message-ID: <3D6CEED0.9D536A47@riverstonenet.com> Date: Wed, 28 Aug 2002 11:40:00 -0400 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Quittek Subject: Re: fragmented packets (was: Re: [ipfix-req] IPFIX Requirements Questions) References: <3D6CE003.CEEE3985@riverstonenet.com> <27453075.1030553372@[192.168.102.164]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Juergen Quittek wrote: > > Hi Paul: > > --On 28 August 2002 10:36 -0400 calato@riverstonenet.com wrote: > > > Juergen Quittek wrote: > >> > >> Hi Paul, > >> > >> --On 28 August 2002 09:06 -0400 calato@riverstonenet.com wrote: > >> > >> > Juergen Quittek wrote: > >> >> > >> >> Hi Paul, > >> >> > >> >> --On 27 August 2002 20:26 -0400 calato@riverstonenet.com wrote: > >> >> > >> >> > Juergen Quittek wrote: > >> >> >> > >> >> >> --On 27 August 2002 14:49 -0400 calato@riverstonenet.com wrote: > >> >> >> > >> >> >> > > >> >> >> > As I work on the advocates document some questions > >> >> >> > have come to mind on the requirements document. > >> >> >> > > >> >> >> > 4.3 Distinguishing flows using Transport Header Fields > >> >> >> > > >> >> >> > In the case of fragmented packets there are > >> >> >> > no port numbers. Are we saying flow state information > >> >> >> > MUST be maintained? In general, it is not clear from > >> >> >> > >> >> >> No, the requirements document does not say so. > >> >> >> > >> >> >> > the document what the requirements are for fragmented > >> >> >> > packets. > >> >> >> > >> >> >> I think the requirements should not include a requirement for > >> >> >> keeping state of fragmented packets. Would you like to see > >> >> >> an explicit statement on that? This would be a NO NEED FOR > >> >> >> statement :-) > >> >> > > >> >> > I think we need to be explicit. Most people will think > >> >> > of fragements as being counted in the same flow as the > >> >> > first packet not as 2 differernt flows. > >> >> > >> >> I see. Waht about adding a new subsection to Section "5. Metering > >> >> Process": > >> >> > >> >> 5.8. Packet Fragmentation > >> >> > >> >> In case of IP packet fragmentation, only one fragment of a single > >> >> packet might contain sufficient information for classifying the > >> >> packet correctly. The metering process MAY keep state of > >> >> IP packet fragmentation in order to map fragments that do not > >> >> contain sufficient header information correctly to flows. > >> > > >> > How about a slight re-wording... > >> > > >> > In case of IP datagram fragmentation, only the first fragment might > >> > contain sufficient information for classifying the packet correctly. > >> > The metering process MAY keep state of IP fragmentation in order to > >> > map fragments without sufficient header information to the same > >> > flow as the first fragmented packet. > >> > >> Initially I also wanted to phrase like this. But it's IP. And fragments > >> might get re-ordered. The first fragment of a packet that is observed, > >> is not necessarily the fragment containing the TCP/UDP header. > >> > >> Now, if you say "first", it is not clear whether you mean the fragment > >> with the first bytes of the IP payload or the first fragment observed > >> at the observation point. Your last sentence seems to assume that the > >> first observed packet is the one with the first bytes of the payload. > > > > GOod point. How about this... > > > > > > In case of IP datagram fragmentation, only one fragment contains > > sufficient information to fully classify the packet. The metering > > process MAY keep state of IP fragmentation in order to > > map fragments without sufficient header information to the same > > flow as the fully classified fragmented packet. > > > > Fine, with one exception: > > In case of IP datagram fragmentation, _it might be that_ only > one fragment contains sufficient ... > > If you just classify by IP addresses, fragmentation is not a problem. Yeah, I thought of that caveat. But so as not to loose the main idea I chose "fully classify". I agree it pushes the caveat to the background. However, I think if the main idea is understood, the caveat becomes clear. what about this... In case of IP datagram fragmentation and depending on the classificaiton scheme, only one fragment contains sufficient information to classify the packet. > > > > > > >> > >> >> [...] > >> >> > >> >> >> > 6.1 information Model > >> >> >> > > >> >> >> > 9 Packet Counter > >> >> >> > 10 Byte counter > >> >> >> > > >> >> >> > As mentioned earlier, for fragments this > >> >> >> > requires state information? If there is no > >> >> >> > state info, then what flow are the counted > >> >> >> > towards? > >> >> >> > >> >> >> Do you suggest to include a requirement for keeping fragment state info? > >> >> > > >> >> > > >> >> > A MAY is as far as I would go. There may certainly be probes > >> >> > that have this capability. We should have a requirement that > >> >> > says fragment counting MUST be clearly defined. > >> >> > >> >> OK. Currently, we have > >> >> > >> >> 9. packet counter > >> >> If a packet is fragmented, each fragment is counted as an > >> >> individual packet. > >> >> 10. byte counter > >> >> Which bytes of a packet are counted MUST be defined exactly. > >> >> > >> >> What about appending > >> >> > >> >> The behavior of the byte counter in case of IP packet > >> >> fragmentation MUST be clearly defined. > >> > > >> > With the new section on fragmentation I think we can > >> > eliminate any mention of it on the counters. > >> > >> The new section of the fragmentation is a MAY requirement. But for > >> understamding the behavior of the byte counter you MUST know whether > >> or not the option is implemented. > > > > I assumed the clearly defined byte counter meant whether > > or not you include the ethernet header, the IP header, > > the CRC, etc... > > > > The counters will count bytes and packets that map to > > the same flow. It doesn't matter if it is a fragment or not. > > So I see this as a flow mapping issue only, not a counter issue. > > Now, I see. Agreed. > > >> > >> >> ? > >> >> > >> >> Please note that we also have in the MAY attributes section > >> >> > >> >> 26. fragmented packet counter > >> >> counter of all packets for which the fragmented bit is set in > >> >> the IP header > >> > > >> > I'm not sure why this was added. If you want that info, > >> > make the IP fragment bit part of the flow definition. > >> > >> Do you suggest to remove it? Anyone else? > > > > Yes. I suggest we remove it. > > Fine with me. > > Juergen --------------D71818F884131D564C6B5309-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" 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 Aug 28 12:32:22 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08027 for ; Wed, 28 Aug 2002 12:32:22 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17k5Ys-0003nP-00 for ipfix-list@mil.doit.wisc.edu; Wed, 28 Aug 2002 11:20:54 -0500 Received: from login.caida.org ([192.172.226.78]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17k5Yo-0003nF-00 for ipfix-req@net.doit.wisc.edu; Wed, 28 Aug 2002 11:20:50 -0500 Received: from login.caida.org (localhost [127.0.0.1]) by login.caida.org (8.12.1/8.12.1) with ESMTP id g7SGKkRg011920 (version=TLSv1/SSLv3 cipher=EDH-DSS-DES-CBC3-SHA bits=168 verify=NO); Wed, 28 Aug 2002 09:20:47 -0700 (PDT) Received: (from dmoore@localhost) by login.caida.org (8.12.1/8.12.1/Submit) id g7SGKkA3011919; Wed, 28 Aug 2002 09:20:46 -0700 (PDT) Date: Wed, 28 Aug 2002 09:20:46 -0700 From: David Moore To: calato@riverstonenet.com Cc: Juergen Quittek , req Subject: Re: [ipfix-req] IPFIX Requirements Questions Message-ID: <20020828092046.W66212@login.caida.org> References: <3D6BC9AD.CAC153C8@riverstonenet.com> <42174623.1030483746@[192.168.102.164]> <3D6C18A3.764A46B9@riverstonenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D6C18A3.764A46B9@riverstonenet.com> User-Agent: Mutt/1.3.23i Precedence: bulk Sender: majordomo listserver On Tue, Aug 27, 2002 at 08:26:11PM -0400, calato@riverstonenet.com wrote: > I disagree. I'm not talking about what is exported, I talking > about semantics. The req doc currently ties the timestamp event > to packet observation. All metering processes will know > when they created and deleted a flow. They may or may not > know when the first or last packet was observed. > > The typical example of this is last packet. In many platforms > the first packet is processed by the CPU and creates a hardware entry. > The rest of the packets are processed and counted in hardware > and thus there is no timestamp available, just a count. All > that is known is when the flow was artifically timed out. Is this because there is no clock available to the hardware? -- Help mailto:majordomo@net.doit.wisc.edu and say "help" 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 Aug 28 12:39:38 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08215 for ; Wed, 28 Aug 2002 12:39:37 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17k5gY-0003zO-00 for ipfix-list@mil.doit.wisc.edu; Wed, 28 Aug 2002 11:28:50 -0500 Received: from [64.95.122.60] (helo=RS-SC-EXC4.rs.riverstonenet.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17k5gV-0003yY-00 for ipfix-req@net.doit.wisc.edu; Wed, 28 Aug 2002 11:28:47 -0500 Received: from riverstonenet.com ([134.141.180.100]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 28 Aug 2002 09:28:15 -0700 Message-ID: <3D6CF9BA.C2986079@riverstonenet.com> Date: Wed, 28 Aug 2002 12:26:34 -0400 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Quittek CC: req Subject: Re: fragmented packets (was: Re: [ipfix-req] IPFIX Requirements Questions) References: <3D6CEED0.9D536A47@riverstonenet.com> <32759305.1030558678@[192.168.102.164]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Aug 2002 16:28:16.0013 (UTC) FILETIME=[E94C4BD0:01C24EAF] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Juergen Quittek wrote: > > Paul, > > --On 28 August 2002 11:40 -0400 calato@riverstonenet.com wrote: > > > Juergen Quittek wrote: > >> > >> Hi Paul: > >> > >> --On 28 August 2002 10:36 -0400 calato@riverstonenet.com wrote: > >> > >> > Juergen Quittek wrote: > >> >> > >> >> Hi Paul, > >> >> > >> >> --On 28 August 2002 09:06 -0400 calato@riverstonenet.com wrote: > >> >> > >> >> > Juergen Quittek wrote: > >> >> >> > >> >> >> Hi Paul, > >> >> >> > >> >> >> --On 27 August 2002 20:26 -0400 calato@riverstonenet.com wrote: > >> >> >> > >> >> >> > Juergen Quittek wrote: > >> >> >> >> > >> >> >> >> --On 27 August 2002 14:49 -0400 calato@riverstonenet.com wrote: > >> >> >> >> > >> >> >> >> > > >> >> >> >> > As I work on the advocates document some questions > >> >> >> >> > have come to mind on the requirements document. > >> >> >> >> > > >> >> >> >> > 4.3 Distinguishing flows using Transport Header Fields > >> >> >> >> > > >> >> >> >> > In the case of fragmented packets there are > >> >> >> >> > no port numbers. Are we saying flow state information > >> >> >> >> > MUST be maintained? In general, it is not clear from > >> >> >> >> > >> >> >> >> No, the requirements document does not say so. > >> >> >> >> > >> >> >> >> > the document what the requirements are for fragmented > >> >> >> >> > packets. > >> >> >> >> > >> >> >> >> I think the requirements should not include a requirement for > >> >> >> >> keeping state of fragmented packets. Would you like to see > >> >> >> >> an explicit statement on that? This would be a NO NEED FOR > >> >> >> >> statement :-) > >> >> >> > > >> >> >> > I think we need to be explicit. Most people will think > >> >> >> > of fragements as being counted in the same flow as the > >> >> >> > first packet not as 2 differernt flows. > >> >> >> > >> >> >> I see. Waht about adding a new subsection to Section "5. Metering > >> >> >> Process": > >> >> >> > >> >> >> 5.8. Packet Fragmentation > >> >> >> > >> >> >> In case of IP packet fragmentation, only one fragment of a single > >> >> >> packet might contain sufficient information for classifying the > >> >> >> packet correctly. The metering process MAY keep state of > >> >> >> IP packet fragmentation in order to map fragments that do not > >> >> >> contain sufficient header information correctly to flows. > >> >> > > >> >> > How about a slight re-wording... > >> >> > > >> >> > In case of IP datagram fragmentation, only the first fragment might > >> >> > contain sufficient information for classifying the packet correctly. > >> >> > The metering process MAY keep state of IP fragmentation in order to > >> >> > map fragments without sufficient header information to the same > >> >> > flow as the first fragmented packet. > >> >> > >> >> Initially I also wanted to phrase like this. But it's IP. And fragments > >> >> might get re-ordered. The first fragment of a packet that is observed, > >> >> is not necessarily the fragment containing the TCP/UDP header. > >> >> > >> >> Now, if you say "first", it is not clear whether you mean the fragment > >> >> with the first bytes of the IP payload or the first fragment observed > >> >> at the observation point. Your last sentence seems to assume that the > >> >> first observed packet is the one with the first bytes of the payload. > >> > > >> > GOod point. How about this... > >> > > >> > > >> > In case of IP datagram fragmentation, only one fragment contains > >> > sufficient information to fully classify the packet. The metering > >> > process MAY keep state of IP fragmentation in order to > >> > map fragments without sufficient header information to the same > >> > flow as the fully classified fragmented packet. > >> > > >> > >> Fine, with one exception: > >> > >> In case of IP datagram fragmentation, _it might be that_ only > >> one fragment contains sufficient ... > >> > >> If you just classify by IP addresses, fragmentation is not a problem. > > > > Yeah, I thought of that caveat. But so as not to loose > > the main idea I chose "fully classify". I agree it pushes > > the caveat to the background. However, I think if the > > main idea is understood, the caveat becomes clear. > > > > what about this... > > In case of IP datagram fragmentation and depending > > on the classificaiton scheme, only one fragment contains > > sufficient information to classify the packet. > > Sounds much better. However, if you say "depending on ...", I would > rather use "might contain" instead of "contains". > > What about > > In case of IP datagram fragmentation, for many typical > classification schemes, only one fragment contains > sufficient information to classify the packet. Perfect! Paul > > Juergen > > > >> > >> > > >> > > >> >> > >> >> >> [...] > >> >> >> > >> >> >> >> > 6.1 information Model > >> >> >> >> > > >> >> >> >> > 9 Packet Counter > >> >> >> >> > 10 Byte counter > >> >> >> >> > > >> >> >> >> > As mentioned earlier, for fragments this > >> >> >> >> > requires state information? If there is no > >> >> >> >> > state info, then what flow are the counted > >> >> >> >> > towards? > >> >> >> >> > >> >> >> >> Do you suggest to include a requirement for keeping fragment state info? > >> >> >> > > >> >> >> > > >> >> >> > A MAY is as far as I would go. There may certainly be probes > >> >> >> > that have this capability. We should have a requirement that > >> >> >> > says fragment counting MUST be clearly defined. > >> >> >> > >> >> >> OK. Currently, we have > >> >> >> > >> >> >> 9. packet counter > >> >> >> If a packet is fragmented, each fragment is counted as an > >> >> >> individual packet. > >> >> >> 10. byte counter > >> >> >> Which bytes of a packet are counted MUST be defined exactly. > >> >> >> > >> >> >> What about appending > >> >> >> > >> >> >> The behavior of the byte counter in case of IP packet > >> >> >> fragmentation MUST be clearly defined. > >> >> > > >> >> > With the new section on fragmentation I think we can > >> >> > eliminate any mention of it on the counters. > >> >> > >> >> The new section of the fragmentation is a MAY requirement. But for > >> >> understamding the behavior of the byte counter you MUST know whether > >> >> or not the option is implemented. > >> > > >> > I assumed the clearly defined byte counter meant whether > >> > or not you include the ethernet header, the IP header, > >> > the CRC, etc... > >> > > >> > The counters will count bytes and packets that map to > >> > the same flow. It doesn't matter if it is a fragment or not. > >> > So I see this as a flow mapping issue only, not a counter issue. > >> > >> Now, I see. Agreed. > >> > >> >> > >> >> >> ? > >> >> >> > >> >> >> Please note that we also have in the MAY attributes section > >> >> >> > >> >> >> 26. fragmented packet counter > >> >> >> counter of all packets for which the fragmented bit is set in > >> >> >> the IP header > >> >> > > >> >> > I'm not sure why this was added. If you want that info, > >> >> > make the IP fragment bit part of the flow definition. > >> >> > >> >> Do you suggest to remove it? Anyone else? > >> > > >> > Yes. I suggest we remove it. > >> > >> Fine with me. > >> > >> Juergen -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Aug 28 12:43:40 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08375 for ; Wed, 28 Aug 2002 12:43:39 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17k5hP-00041u-00 for ipfix-list@mil.doit.wisc.edu; Wed, 28 Aug 2002 11:29:43 -0500 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17k5hM-0003zs-00 for ipfix-req@net.doit.wisc.edu; Wed, 28 Aug 2002 11:29:40 -0500 Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g7SGT9U56319; Wed, 28 Aug 2002 18:29:09 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 634344BD88; Wed, 28 Aug 2002 18:29:08 +0200 (CEST) Date: Wed, 28 Aug 2002 18:29:08 +0200 From: Juergen Quittek To: "Logg, Connie A." , "'calato@riverstonenet.com'" Cc: req Subject: RE: fragmented packets (was: Re: [ipfix-req] IPFIX Requirements Q uestions) Message-ID: <33429198.1030559348@[192.168.102.164]> In-Reply-To: <2846497B437BF84BAD1A4CC407418D26D13B0C@exchange1.slac.stanford.edu> References: <2846497B437BF84BAD1A4CC407418D26D13B0C@exchange1.slac.stanford.edu> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Connie, I have a again the same comment for you: The first fragment of a packet that is observed, is not necessarily the fragment containing the TCP/UDP header. IP allows packet re-ordering. The fragment containing the first bytes of the IP payload may travel slower through the network than the other fragments. Juergen --On 28 August 2002 08:34 -0700 "Logg, Connie A." wrote: > I would certainly like to see fragmented packets some how identified with > the first packet. I have an algorithm for processing netflow data that works > "most of the time" for extracting these for my netflow analysis, but most of the time > is not really good enough. Our AFS traffic is an example. We really would like to be > able to accurately quantify the AFS traffic, as we have a lot of it. For high > utilizations, the algorithm breaks down, as it also does when there are more than one > AFS transaction going on at a time. > > Connie Logg - Network Analyst - 650-926-2879 > Stanford Linear Accelerator Center > MS 97; 2575 SandHill Road; Menlo Park CA 94025 > "Happiness is found along the way, not at the end of the road" > > -----Original Message----- > From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] > Sent: Wednesday, August 28, 2002 6:07 AM > To: Juergen Quittek > Cc: req > Subject: Re: fragmented packets (was: Re: [ipfix-req] IPFIX Requirements > Questions) > > > Juergen Quittek wrote: >> >> Hi Paul, >> >> --On 27 August 2002 20:26 -0400 calato@riverstonenet.com wrote: >> >> > Juergen Quittek wrote: >> >> >> >> --On 27 August 2002 14:49 -0400 calato@riverstonenet.com wrote: >> >> >> >> > >> >> > As I work on the advocates document some questions >> >> > have come to mind on the requirements document. >> >> > >> >> > 4.3 Distinguishing flows using Transport Header Fields >> >> > >> >> > In the case of fragmented packets there are >> >> > no port numbers. Are we saying flow state information >> >> > MUST be maintained? In general, it is not clear from >> >> >> >> No, the requirements document does not say so. >> >> >> >> > the document what the requirements are for fragmented >> >> > packets. >> >> >> >> I think the requirements should not include a requirement for >> >> keeping state of fragmented packets. Would you like to see >> >> an explicit statement on that? This would be a NO NEED FOR >> >> statement :-) >> > >> > I think we need to be explicit. Most people will think >> > of fragements as being counted in the same flow as the >> > first packet not as 2 differernt flows. >> >> I see. Waht about adding a new subsection to Section "5. Metering >> Process": >> >> 5.8. Packet Fragmentation >> >> In case of IP packet fragmentation, only one fragment of a single >> packet might contain sufficient information for classifying the >> packet correctly. The metering process MAY keep state of >> IP packet fragmentation in order to map fragments that do not >> contain sufficient header information correctly to flows. > > How about a slight re-wording... > > In case of IP datagram fragmentation, only the first fragment might > contain sufficient information for classifying the packet correctly. > The metering process MAY keep state of IP fragmentation in order to > map fragments without sufficient header information to the same > flow as the first fragmented packet. > >> >> [...] >> >> >> > 6.1 information Model >> >> > >> >> > 9 Packet Counter >> >> > 10 Byte counter >> >> > >> >> > As mentioned earlier, for fragments this >> >> > requires state information? If there is no >> >> > state info, then what flow are the counted >> >> > towards? >> >> >> >> Do you suggest to include a requirement for keeping fragment state info? >> > >> > >> > A MAY is as far as I would go. There may certainly be probes >> > that have this capability. We should have a requirement that >> > says fragment counting MUST be clearly defined. >> >> OK. Currently, we have >> >> 9. packet counter >> If a packet is fragmented, each fragment is counted as an >> individual packet. >> 10. byte counter >> Which bytes of a packet are counted MUST be defined exactly. >> >> What about appending >> >> The behavior of the byte counter in case of IP packet >> fragmentation MUST be clearly defined. > > With the new section on fragmentation I think we can > eliminate any mention of it on the counters. > >> ? >> >> Please note that we also have in the MAY attributes section >> >> 26. fragmented packet counter >> counter of all packets for which the fragmented bit is set in >> the IP header > > I'm not sure why this was added. If you want that info, > make the IP fragment bit part of the flow definition. > >> >> Juergen > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Aug 28 12:43:52 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08402 for ; Wed, 28 Aug 2002 12:43:52 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17k5k9-00047w-00 for ipfix-list@mil.doit.wisc.edu; Wed, 28 Aug 2002 11:32:33 -0500 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17k5k0-00046n-00 for ipfix-req@net.doit.wisc.edu; Wed, 28 Aug 2002 11:32:29 -0500 Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g7SGVsU56405 for ; Wed, 28 Aug 2002 18:31:54 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 36D6D5D802 for ; Wed, 28 Aug 2002 18:31:53 +0200 (CEST) Date: Wed, 28 Aug 2002 18:31:52 +0200 From: Juergen Quittek To: ipfix-req@net.doit.wisc.edu Subject: Re: fragmented packets (was: Re: [ipfix-req] IPFIX Requirements Questions) (fwd) Message-ID: <33593114.1030559512@[192.168.102.164]> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========33598742==========" Precedence: bulk Sender: majordomo listserver --==========33598742========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 7bit ... and here's my reply to Paul's second forwarded message. Juergen ---------- Forwarded Message ---------- Date: 28 August 2002 18:17 +0200 From: Juergen Quittek To: calato@riverstonenet.com Subject: Re: fragmented packets (was: Re: [ipfix-req] IPFIX Requirements Questions) Paul, --On 28 August 2002 11:40 -0400 calato@riverstonenet.com wrote: > Juergen Quittek wrote: >> >> Hi Paul: >> >> --On 28 August 2002 10:36 -0400 calato@riverstonenet.com wrote: >> >> > Juergen Quittek wrote: >> >> >> >> Hi Paul, >> >> >> >> --On 28 August 2002 09:06 -0400 calato@riverstonenet.com wrote: >> >> >> >> > Juergen Quittek wrote: >> >> >> >> >> >> Hi Paul, >> >> >> >> >> >> --On 27 August 2002 20:26 -0400 calato@riverstonenet.com wrote: >> >> >> >> >> >> > Juergen Quittek wrote: >> >> >> >> >> >> >> >> --On 27 August 2002 14:49 -0400 calato@riverstonenet.com wrote: >> >> >> >> >> >> >> >> > >> >> >> >> > As I work on the advocates document some questions >> >> >> >> > have come to mind on the requirements document. >> >> >> >> > >> >> >> >> > 4.3 Distinguishing flows using Transport Header Fields >> >> >> >> > >> >> >> >> > In the case of fragmented packets there are >> >> >> >> > no port numbers. Are we saying flow state information >> >> >> >> > MUST be maintained? In general, it is not clear from >> >> >> >> >> >> >> >> No, the requirements document does not say so. >> >> >> >> >> >> >> >> > the document what the requirements are for fragmented >> >> >> >> > packets. >> >> >> >> >> >> >> >> I think the requirements should not include a requirement for >> >> >> >> keeping state of fragmented packets. Would you like to see >> >> >> >> an explicit statement on that? This would be a NO NEED FOR >> >> >> >> statement :-) >> >> >> > >> >> >> > I think we need to be explicit. Most people will think >> >> >> > of fragements as being counted in the same flow as the >> >> >> > first packet not as 2 differernt flows. >> >> >> >> >> >> I see. Waht about adding a new subsection to Section "5. Metering >> >> >> Process": >> >> >> >> >> >> 5.8. Packet Fragmentation >> >> >> >> >> >> In case of IP packet fragmentation, only one fragment of a single >> >> >> packet might contain sufficient information for classifying the >> >> >> packet correctly. The metering process MAY keep state of >> >> >> IP packet fragmentation in order to map fragments that do not >> >> >> contain sufficient header information correctly to flows. >> >> > >> >> > How about a slight re-wording... >> >> > >> >> > In case of IP datagram fragmentation, only the first fragment might >> >> > contain sufficient information for classifying the packet correctly. >> >> > The metering process MAY keep state of IP fragmentation in order to >> >> > map fragments without sufficient header information to the same >> >> > flow as the first fragmented packet. >> >> >> >> Initially I also wanted to phrase like this. But it's IP. And fragments >> >> might get re-ordered. The first fragment of a packet that is observed, >> >> is not necessarily the fragment containing the TCP/UDP header. >> >> >> >> Now, if you say "first", it is not clear whether you mean the fragment >> >> with the first bytes of the IP payload or the first fragment observed >> >> at the observation point. Your last sentence seems to assume that the >> >> first observed packet is the one with the first bytes of the payload. >> > >> > GOod point. How about this... >> > >> > >> > In case of IP datagram fragmentation, only one fragment contains >> > sufficient information to fully classify the packet. The metering >> > process MAY keep state of IP fragmentation in order to >> > map fragments without sufficient header information to the same >> > flow as the fully classified fragmented packet. >> > >> >> Fine, with one exception: >> >> In case of IP datagram fragmentation, _it might be that_ only >> one fragment contains sufficient ... >> >> If you just classify by IP addresses, fragmentation is not a problem. > > Yeah, I thought of that caveat. But so as not to loose > the main idea I chose "fully classify". I agree it pushes > the caveat to the background. However, I think if the > main idea is understood, the caveat becomes clear. > > what about this... > In case of IP datagram fragmentation and depending > on the classificaiton scheme, only one fragment contains > sufficient information to classify the packet. Sounds much better. However, if you say "depending on ...", I would rather use "might contain" instead of "contains". What about In case of IP datagram fragmentation, for many typical classification schemes, only one fragment contains sufficient information to classify the packet. Juergen > >> >> > >> > >> >> >> >> >> [...] >> >> >> >> >> >> >> > 6.1 information Model >> >> >> >> > >> >> >> >> > 9 Packet Counter >> >> >> >> > 10 Byte counter >> >> >> >> > >> >> >> >> > As mentioned earlier, for fragments this >> >> >> >> > requires state information? If there is no >> >> >> >> > state info, then what flow are the counted >> >> >> >> > towards? >> >> >> >> >> >> >> >> Do you suggest to include a requirement for keeping fragment state info? >> >> >> > >> >> >> > >> >> >> > A MAY is as far as I would go. There may certainly be probes >> >> >> > that have this capability. We should have a requirement that >> >> >> > says fragment counting MUST be clearly defined. >> >> >> >> >> >> OK. Currently, we have >> >> >> >> >> >> 9. packet counter >> >> >> If a packet is fragmented, each fragment is counted as an >> >> >> individual packet. >> >> >> 10. byte counter >> >> >> Which bytes of a packet are counted MUST be defined exactly. >> >> >> >> >> >> What about appending >> >> >> >> >> >> The behavior of the byte counter in case of IP packet >> >> >> fragmentation MUST be clearly defined. >> >> > >> >> > With the new section on fragmentation I think we can >> >> > eliminate any mention of it on the counters. >> >> >> >> The new section of the fragmentation is a MAY requirement. But for >> >> understamding the behavior of the byte counter you MUST know whether >> >> or not the option is implemented. >> > >> > I assumed the clearly defined byte counter meant whether >> > or not you include the ethernet header, the IP header, >> > the CRC, etc... >> > >> > The counters will count bytes and packets that map to >> > the same flow. It doesn't matter if it is a fragment or not. >> > So I see this as a flow mapping issue only, not a counter issue. >> >> Now, I see. Agreed. >> >> >> >> >> >> ? >> >> >> >> >> >> Please note that we also have in the MAY attributes section >> >> >> >> >> >> 26. fragmented packet counter >> >> >> counter of all packets for which the fragmented bit is set in >> >> >> the IP header >> >> > >> >> > I'm not sure why this was added. If you want that info, >> >> > make the IP fragment bit part of the flow definition. >> >> >> >> Do you suggest to remove it? Anyone else? >> > >> > Yes. I suggest we remove it. >> >> Fine with me. >> >> Juergen ---------- End Forwarded Message ---------- --==========33598742========== Content-Type: message/rfc822; name="Re: fragmented packets (was: Re: [ipfix-req] IPFIX Requirements Questions)" Date: Wed, 28 Aug 2002 18:17:58 +0200 From: Juergen Quittek To: calato@riverstonenet.com Subject: Re: fragmented packets (was: Re: [ipfix-req] IPFIX Requirements Questions) Message-ID: <32759305.1030558678@[192.168.102.164]> In-Reply-To: <3D6CEED0.9D536A47@riverstonenet.com> References: <3D6CEED0.9D536A47@riverstonenet.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; FORMAT=flowed Content-Disposition: inline Content-Transfer-Encoding: 7bit Paul, --On 28 August 2002 11:40 -0400 calato@riverstonenet.com wrote: > Juergen Quittek wrote: >> >> Hi Paul: >> >> --On 28 August 2002 10:36 -0400 calato@riverstonenet.com wrote: >> >> > Juergen Quittek wrote: >> >> >> >> Hi Paul, >> >> >> >> --On 28 August 2002 09:06 -0400 calato@riverstonenet.com wrote: >> >> >> >> > Juergen Quittek wrote: >> >> >> >> >> >> Hi Paul, >> >> >> >> >> >> --On 27 August 2002 20:26 -0400 calato@riverstonenet.com wrote: >> >> >> >> >> >> > Juergen Quittek wrote: >> >> >> >> >> >> >> >> --On 27 August 2002 14:49 -0400 calato@riverstonenet.com wrote: >> >> >> >> >> >> >> >> > >> >> >> >> > As I work on the advocates document some questions >> >> >> >> > have come to mind on the requirements document. >> >> >> >> > >> >> >> >> > 4.3 Distinguishing flows using Transport Header Fields >> >> >> >> > >> >> >> >> > In the case of fragmented packets there are >> >> >> >> > no port numbers. Are we saying flow state information >> >> >> >> > MUST be maintained? In general, it is not clear from >> >> >> >> >> >> >> >> No, the requirements document does not say so. >> >> >> >> >> >> >> >> > the document what the requirements are for fragmented >> >> >> >> > packets. >> >> >> >> >> >> >> >> I think the requirements should not include a requirement for >> >> >> >> keeping state of fragmented packets. Would you like to see >> >> >> >> an explicit statement on that? This would be a NO NEED FOR >> >> >> >> statement :-) >> >> >> > >> >> >> > I think we need to be explicit. Most people will think >> >> >> > of fragements as being counted in the same flow as the >> >> >> > first packet not as 2 differernt flows. >> >> >> >> >> >> I see. Waht about adding a new subsection to Section "5. Metering >> >> >> Process": >> >> >> >> >> >> 5.8. Packet Fragmentation >> >> >> >> >> >> In case of IP packet fragmentation, only one fragment of a single >> >> >> packet might contain sufficient information for classifying the >> >> >> packet correctly. The metering process MAY keep state of >> >> >> IP packet fragmentation in order to map fragments that do not >> >> >> contain sufficient header information correctly to flows. >> >> > >> >> > How about a slight re-wording... >> >> > >> >> > In case of IP datagram fragmentation, only the first fragment might >> >> > contain sufficient information for classifying the packet correctly. >> >> > The metering process MAY keep state of IP fragmentation in order to >> >> > map fragments without sufficient header information to the same >> >> > flow as the first fragmented packet. >> >> >> >> Initially I also wanted to phrase like this. But it's IP. And fragments >> >> might get re-ordered. The first fragment of a packet that is observed, >> >> is not necessarily the fragment containing the TCP/UDP header. >> >> >> >> Now, if you say "first", it is not clear whether you mean the fragment >> >> with the first bytes of the IP payload or the first fragment observed >> >> at the observation point. Your last sentence seems to assume that the >> >> first observed packet is the one with the first bytes of the payload. >> > >> > GOod point. How about this... >> > >> > >> > In case of IP datagram fragmentation, only one fragment contains >> > sufficient information to fully classify the packet. The metering >> > process MAY keep state of IP fragmentation in order to >> > map fragments without sufficient header information to the same >> > flow as the fully classified fragmented packet. >> > >> >> Fine, with one exception: >> >> In case of IP datagram fragmentation, _it might be that_ only >> one fragment contains sufficient ... >> >> If you just classify by IP addresses, fragmentation is not a problem. > > Yeah, I thought of that caveat. But so as not to loose > the main idea I chose "fully classify". I agree it pushes > the caveat to the background. However, I think if the > main idea is understood, the caveat becomes clear. > > what about this... > In case of IP datagram fragmentation and depending > on the classificaiton scheme, only one fragment contains > sufficient information to classify the packet. Sounds much better. However, if you say "depending on ...", I would rather use "might contain" instead of "contains". What about In case of IP datagram fragmentation, for many typical classification schemes, only one fragment contains sufficient information to classify the packet. Juergen > >> >> > >> > >> >> >> >> >> [...] >> >> >> >> >> >> >> > 6.1 information Model >> >> >> >> > >> >> >> >> > 9 Packet Counter >> >> >> >> > 10 Byte counter >> >> >> >> > >> >> >> >> > As mentioned earlier, for fragments this >> >> >> >> > requires state information? If there is no >> >> >> >> > state info, then what flow are the counted >> >> >> >> > towards? >> >> >> >> >> >> >> >> Do you suggest to include a requirement for keeping fragment state info? >> >> >> > >> >> >> > >> >> >> > A MAY is as far as I would go. There may certainly be probes >> >> >> > that have this capability. We should have a requirement that >> >> >> > says fragment counting MUST be clearly defined. >> >> >> >> >> >> OK. Currently, we have >> >> >> >> >> >> 9. packet counter >> >> >> If a packet is fragmented, each fragment is counted as an >> >> >> individual packet. >> >> >> 10. byte counter >> >> >> Which bytes of a packet are counted MUST be defined exactly. >> >> >> >> >> >> What about appending >> >> >> >> >> >> The behavior of the byte counter in case of IP packet >> >> >> fragmentation MUST be clearly defined. >> >> > >> >> > With the new section on fragmentation I think we can >> >> > eliminate any mention of it on the counters. >> >> >> >> The new section of the fragmentation is a MAY requirement. But for >> >> understamding the behavior of the byte counter you MUST know whether >> >> or not the option is implemented. >> > >> > I assumed the clearly defined byte counter meant whether >> > or not you include the ethernet header, the IP header, >> > the CRC, etc... >> > >> > The counters will count bytes and packets that map to >> > the same flow. It doesn't matter if it is a fragment or not. >> > So I see this as a flow mapping issue only, not a counter issue. >> >> Now, I see. Agreed. >> >> >> >> >> >> ? >> >> >> >> >> >> Please note that we also have in the MAY attributes section >> >> >> >> >> >> 26. fragmented packet counter >> >> >> counter of all packets for which the fragmented bit is set in >> >> >> the IP header >> >> > >> >> > I'm not sure why this was added. If you want that info, >> >> > make the IP fragment bit part of the flow definition. >> >> >> >> Do you suggest to remove it? Anyone else? >> > >> > Yes. I suggest we remove it. >> >> Fine with me. >> >> Juergen --==========33598742==========-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" 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 Aug 28 12:51:28 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08778 for ; Wed, 28 Aug 2002 12:51:27 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17k5jA-00046N-00 for ipfix-list@mil.doit.wisc.edu; Wed, 28 Aug 2002 11:31:32 -0500 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17k5j8-00045U-00 for ipfix-req@net.doit.wisc.edu; Wed, 28 Aug 2002 11:31:30 -0500 Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g7SGUwU56354 for ; Wed, 28 Aug 2002 18:30:58 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id AC9D05D802 for ; Wed, 28 Aug 2002 18:30:57 +0200 (CEST) Date: Wed, 28 Aug 2002 18:30:57 +0200 From: Juergen Quittek To: ipfix-req@net.doit.wisc.edu Subject: Re: fragmented packets (was: Re: [ipfix-req] IPFIX Requirements Questions) (fwd) Message-ID: <33537584.1030559457@[192.168.102.164]> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========33568646==========" Precedence: bulk Sender: majordomo listserver --==========33568646========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 7bit Here is my reply to Paul's first message. ---------- Forwarded Message ---------- Date: 28 August 2002 16:49 +0200 From: Juergen Quittek To: calato@riverstonenet.com Subject: Re: fragmented packets (was: Re: [ipfix-req] IPFIX Requirements Questions) Hi Paul: --On 28 August 2002 10:36 -0400 calato@riverstonenet.com wrote: > Juergen Quittek wrote: >> >> Hi Paul, >> >> --On 28 August 2002 09:06 -0400 calato@riverstonenet.com wrote: >> >> > Juergen Quittek wrote: >> >> >> >> Hi Paul, >> >> >> >> --On 27 August 2002 20:26 -0400 calato@riverstonenet.com wrote: >> >> >> >> > Juergen Quittek wrote: >> >> >> >> >> >> --On 27 August 2002 14:49 -0400 calato@riverstonenet.com wrote: >> >> >> >> >> >> > >> >> >> > As I work on the advocates document some questions >> >> >> > have come to mind on the requirements document. >> >> >> > >> >> >> > 4.3 Distinguishing flows using Transport Header Fields >> >> >> > >> >> >> > In the case of fragmented packets there are >> >> >> > no port numbers. Are we saying flow state information >> >> >> > MUST be maintained? In general, it is not clear from >> >> >> >> >> >> No, the requirements document does not say so. >> >> >> >> >> >> > the document what the requirements are for fragmented >> >> >> > packets. >> >> >> >> >> >> I think the requirements should not include a requirement for >> >> >> keeping state of fragmented packets. Would you like to see >> >> >> an explicit statement on that? This would be a NO NEED FOR >> >> >> statement :-) >> >> > >> >> > I think we need to be explicit. Most people will think >> >> > of fragements as being counted in the same flow as the >> >> > first packet not as 2 differernt flows. >> >> >> >> I see. Waht about adding a new subsection to Section "5. Metering >> >> Process": >> >> >> >> 5.8. Packet Fragmentation >> >> >> >> In case of IP packet fragmentation, only one fragment of a single >> >> packet might contain sufficient information for classifying the >> >> packet correctly. The metering process MAY keep state of >> >> IP packet fragmentation in order to map fragments that do not >> >> contain sufficient header information correctly to flows. >> > >> > How about a slight re-wording... >> > >> > In case of IP datagram fragmentation, only the first fragment might >> > contain sufficient information for classifying the packet correctly. >> > The metering process MAY keep state of IP fragmentation in order to >> > map fragments without sufficient header information to the same >> > flow as the first fragmented packet. >> >> Initially I also wanted to phrase like this. But it's IP. And fragments >> might get re-ordered. The first fragment of a packet that is observed, >> is not necessarily the fragment containing the TCP/UDP header. >> >> Now, if you say "first", it is not clear whether you mean the fragment >> with the first bytes of the IP payload or the first fragment observed >> at the observation point. Your last sentence seems to assume that the >> first observed packet is the one with the first bytes of the payload. > > GOod point. How about this... > > > In case of IP datagram fragmentation, only one fragment contains > sufficient information to fully classify the packet. The metering > process MAY keep state of IP fragmentation in order to > map fragments without sufficient header information to the same > flow as the fully classified fragmented packet. > Fine, with one exception: In case of IP datagram fragmentation, _it might be that_ only one fragment contains sufficient ... If you just classify by IP addresses, fragmentation is not a problem. > > >> >> >> [...] >> >> >> >> >> > 6.1 information Model >> >> >> > >> >> >> > 9 Packet Counter >> >> >> > 10 Byte counter >> >> >> > >> >> >> > As mentioned earlier, for fragments this >> >> >> > requires state information? If there is no >> >> >> > state info, then what flow are the counted >> >> >> > towards? >> >> >> >> >> >> Do you suggest to include a requirement for keeping fragment state info? >> >> > >> >> > >> >> > A MAY is as far as I would go. There may certainly be probes >> >> > that have this capability. We should have a requirement that >> >> > says fragment counting MUST be clearly defined. >> >> >> >> OK. Currently, we have >> >> >> >> 9. packet counter >> >> If a packet is fragmented, each fragment is counted as an >> >> individual packet. >> >> 10. byte counter >> >> Which bytes of a packet are counted MUST be defined exactly. >> >> >> >> What about appending >> >> >> >> The behavior of the byte counter in case of IP packet >> >> fragmentation MUST be clearly defined. >> > >> > With the new section on fragmentation I think we can >> > eliminate any mention of it on the counters. >> >> The new section of the fragmentation is a MAY requirement. But for >> understamding the behavior of the byte counter you MUST know whether >> or not the option is implemented. > > I assumed the clearly defined byte counter meant whether > or not you include the ethernet header, the IP header, > the CRC, etc... > > The counters will count bytes and packets that map to > the same flow. It doesn't matter if it is a fragment or not. > So I see this as a flow mapping issue only, not a counter issue. Now, I see. Agreed. >> >> >> ? >> >> >> >> Please note that we also have in the MAY attributes section >> >> >> >> 26. fragmented packet counter >> >> counter of all packets for which the fragmented bit is set in >> >> the IP header >> > >> > I'm not sure why this was added. If you want that info, >> > make the IP fragment bit part of the flow definition. >> >> Do you suggest to remove it? Anyone else? > > Yes. I suggest we remove it. Fine with me. Juergen ---------- End Forwarded Message ---------- --==========33568646========== Content-Type: message/rfc822; name="Re: fragmented packets (was: Re: [ipfix-req] IPFIX Requirements Questions)" Date: Wed, 28 Aug 2002 16:49:32 +0200 From: Juergen Quittek To: calato@riverstonenet.com Subject: Re: fragmented packets (was: Re: [ipfix-req] IPFIX Requirements Questions) Message-ID: <27453075.1030553372@[192.168.102.164]> In-Reply-To: <3D6CE003.CEEE3985@riverstonenet.com> References: <3D6CE003.CEEE3985@riverstonenet.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; FORMAT=flowed Content-Disposition: inline Content-Transfer-Encoding: 7bit Hi Paul: --On 28 August 2002 10:36 -0400 calato@riverstonenet.com wrote: > Juergen Quittek wrote: >> >> Hi Paul, >> >> --On 28 August 2002 09:06 -0400 calato@riverstonenet.com wrote: >> >> > Juergen Quittek wrote: >> >> >> >> Hi Paul, >> >> >> >> --On 27 August 2002 20:26 -0400 calato@riverstonenet.com wrote: >> >> >> >> > Juergen Quittek wrote: >> >> >> >> >> >> --On 27 August 2002 14:49 -0400 calato@riverstonenet.com wrote: >> >> >> >> >> >> > >> >> >> > As I work on the advocates document some questions >> >> >> > have come to mind on the requirements document. >> >> >> > >> >> >> > 4.3 Distinguishing flows using Transport Header Fields >> >> >> > >> >> >> > In the case of fragmented packets there are >> >> >> > no port numbers. Are we saying flow state information >> >> >> > MUST be maintained? In general, it is not clear from >> >> >> >> >> >> No, the requirements document does not say so. >> >> >> >> >> >> > the document what the requirements are for fragmented >> >> >> > packets. >> >> >> >> >> >> I think the requirements should not include a requirement for >> >> >> keeping state of fragmented packets. Would you like to see >> >> >> an explicit statement on that? This would be a NO NEED FOR >> >> >> statement :-) >> >> > >> >> > I think we need to be explicit. Most people will think >> >> > of fragements as being counted in the same flow as the >> >> > first packet not as 2 differernt flows. >> >> >> >> I see. Waht about adding a new subsection to Section "5. Metering >> >> Process": >> >> >> >> 5.8. Packet Fragmentation >> >> >> >> In case of IP packet fragmentation, only one fragment of a single >> >> packet might contain sufficient information for classifying the >> >> packet correctly. The metering process MAY keep state of >> >> IP packet fragmentation in order to map fragments that do not >> >> contain sufficient header information correctly to flows. >> > >> > How about a slight re-wording... >> > >> > In case of IP datagram fragmentation, only the first fragment might >> > contain sufficient information for classifying the packet correctly. >> > The metering process MAY keep state of IP fragmentation in order to >> > map fragments without sufficient header information to the same >> > flow as the first fragmented packet. >> >> Initially I also wanted to phrase like this. But it's IP. And fragments >> might get re-ordered. The first fragment of a packet that is observed, >> is not necessarily the fragment containing the TCP/UDP header. >> >> Now, if you say "first", it is not clear whether you mean the fragment >> with the first bytes of the IP payload or the first fragment observed >> at the observation point. Your last sentence seems to assume that the >> first observed packet is the one with the first bytes of the payload. > > GOod point. How about this... > > > In case of IP datagram fragmentation, only one fragment contains > sufficient information to fully classify the packet. The metering > process MAY keep state of IP fragmentation in order to > map fragments without sufficient header information to the same > flow as the fully classified fragmented packet. > Fine, with one exception: In case of IP datagram fragmentation, _it might be that_ only one fragment contains sufficient ... If you just classify by IP addresses, fragmentation is not a problem. > > >> >> >> [...] >> >> >> >> >> > 6.1 information Model >> >> >> > >> >> >> > 9 Packet Counter >> >> >> > 10 Byte counter >> >> >> > >> >> >> > As mentioned earlier, for fragments this >> >> >> > requires state information? If there is no >> >> >> > state info, then what flow are the counted >> >> >> > towards? >> >> >> >> >> >> Do you suggest to include a requirement for keeping fragment state info? >> >> > >> >> > >> >> > A MAY is as far as I would go. There may certainly be probes >> >> > that have this capability. We should have a requirement that >> >> > says fragment counting MUST be clearly defined. >> >> >> >> OK. Currently, we have >> >> >> >> 9. packet counter >> >> If a packet is fragmented, each fragment is counted as an >> >> individual packet. >> >> 10. byte counter >> >> Which bytes of a packet are counted MUST be defined exactly. >> >> >> >> What about appending >> >> >> >> The behavior of the byte counter in case of IP packet >> >> fragmentation MUST be clearly defined. >> > >> > With the new section on fragmentation I think we can >> > eliminate any mention of it on the counters. >> >> The new section of the fragmentation is a MAY requirement. But for >> understamding the behavior of the byte counter you MUST know whether >> or not the option is implemented. > > I assumed the clearly defined byte counter meant whether > or not you include the ethernet header, the IP header, > the CRC, etc... > > The counters will count bytes and packets that map to > the same flow. It doesn't matter if it is a fragment or not. > So I see this as a flow mapping issue only, not a counter issue. Now, I see. Agreed. >> >> >> ? >> >> >> >> Please note that we also have in the MAY attributes section >> >> >> >> 26. fragmented packet counter >> >> counter of all packets for which the fragmented bit is set in >> >> the IP header >> > >> > I'm not sure why this was added. If you want that info, >> > make the IP fragment bit part of the flow definition. >> >> Do you suggest to remove it? Anyone else? > > Yes. I suggest we remove it. Fine with me. Juergen --==========33568646==========-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" 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 Aug 28 15:30:00 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15275 for ; Wed, 28 Aug 2002 15:29:59 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17k8Hv-0000Cl-00 for ipfix-list@mil.doit.wisc.edu; Wed, 28 Aug 2002 14:15:35 -0500 Received: from smtp.slac.stanford.edu ([134.79.18.80]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17k8Hs-0000CU-00 for ipfix-req@net.doit.wisc.edu; Wed, 28 Aug 2002 14:15:33 -0500 Received: from CONVERSION-DAEMON.smtp.slac.stanford.edu by smtp.slac.stanford.edu (PMDF V6.1-1 #37665) id <0H1K00B01BBGZH@smtp.slac.stanford.edu> for ipfix-req@net.doit.wisc.edu; Wed, 28 Aug 2002 09:33:17 -0700 (PDT) Received: from smtpserv1.slac.stanford.edu (smtpserv1.slac.stanford.edu [134.79.18.81]) by smtp.slac.stanford.edu (PMDF V6.1-1 #37665) with ESMTP id <0H1K008N9BBGM5@smtp.slac.stanford.edu>; Wed, 28 Aug 2002 09:33:16 -0700 (PDT) Received: from ATREUS.slac.stanford.edu ([134.79.18.84]) by smtpserv1.slac.stanford.edu (PMDF V6.1 #37665) with ESMTP id <0H1K0005RBBG28@smtpserv1.slac.stanford.edu>; Wed, 28 Aug 2002 09:33:16 -0700 (PDT) Received: by ATREUS.slac.stanford.edu with Internet Mail Service (5.5.2653.19) id ; Wed, 28 Aug 2002 09:32:24 -0700 Content-return: allowed Date: Wed, 28 Aug 2002 09:32:24 -0700 From: "Logg, Connie A." Subject: RE: fragmented packets (was: Re: [ipfix-req] IPFIX Requirements Q uestions) To: "'Juergen Quittek'" , "'calato@riverstonenet.com'" Cc: req Message-id: <2846497B437BF84BAD1A4CC407418D26D13B14@exchange1.slac.stanford.edu> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7BIT Ok..Ah yes..I gorgot again....I know that does happen sometimes..Such is life. I have never seen it, but them I have not looked at each and every netflow record. Thanks for the reminder. -----Original Message----- From: Juergen Quittek [mailto:quittek@ccrle.nec.de] Sent: Wednesday, August 28, 2002 9:29 AM To: Logg, Connie A.; 'calato@riverstonenet.com' Cc: req Subject: RE: fragmented packets (was: Re: [ipfix-req] IPFIX Requirements Q uestions) Connie, I have a again the same comment for you: The first fragment of a packet that is observed, is not necessarily the fragment containing the TCP/UDP header. IP allows packet re-ordering. The fragment containing the first bytes of the IP payload may travel slower through the network than the other fragments. Juergen --On 28 August 2002 08:34 -0700 "Logg, Connie A." wrote: > I would certainly like to see fragmented packets some how identified with > the first packet. I have an algorithm for processing netflow data that works > "most of the time" for extracting these for my netflow analysis, but most of the time > is not really good enough. Our AFS traffic is an example. We really would like to be > able to accurately quantify the AFS traffic, as we have a lot of it. For high > utilizations, the algorithm breaks down, as it also does when there are more than one > AFS transaction going on at a time. > > Connie Logg - Network Analyst - 650-926-2879 > Stanford Linear Accelerator Center > MS 97; 2575 SandHill Road; Menlo Park CA 94025 > "Happiness is found along the way, not at the end of the road" > > -----Original Message----- > From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] > Sent: Wednesday, August 28, 2002 6:07 AM > To: Juergen Quittek > Cc: req > Subject: Re: fragmented packets (was: Re: [ipfix-req] IPFIX Requirements > Questions) > > > Juergen Quittek wrote: >> >> Hi Paul, >> >> --On 27 August 2002 20:26 -0400 calato@riverstonenet.com wrote: >> >> > Juergen Quittek wrote: >> >> >> >> --On 27 August 2002 14:49 -0400 calato@riverstonenet.com wrote: >> >> >> >> > >> >> > As I work on the advocates document some questions >> >> > have come to mind on the requirements document. >> >> > >> >> > 4.3 Distinguishing flows using Transport Header Fields >> >> > >> >> > In the case of fragmented packets there are >> >> > no port numbers. Are we saying flow state information >> >> > MUST be maintained? In general, it is not clear from >> >> >> >> No, the requirements document does not say so. >> >> >> >> > the document what the requirements are for fragmented >> >> > packets. >> >> >> >> I think the requirements should not include a requirement for >> >> keeping state of fragmented packets. Would you like to see >> >> an explicit statement on that? This would be a NO NEED FOR >> >> statement :-) >> > >> > I think we need to be explicit. Most people will think >> > of fragements as being counted in the same flow as the >> > first packet not as 2 differernt flows. >> >> I see. Waht about adding a new subsection to Section "5. Metering >> Process": >> >> 5.8. Packet Fragmentation >> >> In case of IP packet fragmentation, only one fragment of a single >> packet might contain sufficient information for classifying the >> packet correctly. The metering process MAY keep state of >> IP packet fragmentation in order to map fragments that do not >> contain sufficient header information correctly to flows. > > How about a slight re-wording... > > In case of IP datagram fragmentation, only the first fragment might > contain sufficient information for classifying the packet correctly. > The metering process MAY keep state of IP fragmentation in order to > map fragments without sufficient header information to the same > flow as the first fragmented packet. > >> >> [...] >> >> >> > 6.1 information Model >> >> > >> >> > 9 Packet Counter >> >> > 10 Byte counter >> >> > >> >> > As mentioned earlier, for fragments this >> >> > requires state information? If there is no >> >> > state info, then what flow are the counted >> >> > towards? >> >> >> >> Do you suggest to include a requirement for keeping fragment state info? >> > >> > >> > A MAY is as far as I would go. There may certainly be probes >> > that have this capability. We should have a requirement that >> > says fragment counting MUST be clearly defined. >> >> OK. Currently, we have >> >> 9. packet counter >> If a packet is fragmented, each fragment is counted as an >> individual packet. >> 10. byte counter >> Which bytes of a packet are counted MUST be defined exactly. >> >> What about appending >> >> The behavior of the byte counter in case of IP packet >> fragmentation MUST be clearly defined. > > With the new section on fragmentation I think we can > eliminate any mention of it on the counters. > >> ? >> >> Please note that we also have in the MAY attributes section >> >> 26. fragmented packet counter >> counter of all packets for which the fragmented bit is set in >> the IP header > > I'm not sure why this was added. If you want that info, > make the IP fragment bit part of the flow definition. > >> >> Juergen > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Aug 29 05:48:52 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14289 for ; Thu, 29 Aug 2002 05:48:52 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17kLc6-0004LM-00 for ipfix-list@mil.doit.wisc.edu; Thu, 29 Aug 2002 04:29:18 -0500 Received: from central.switch.ch ([130.59.4.1]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17kLc4-0004Kg-00 for ipfix-req@net.doit.wisc.edu; Thu, 29 Aug 2002 04:29:17 -0500 Received: from babar ([130.59.4.2] helo=babar.switch.ch) by central.switch.ch with esmtp (Exim 3.20 #1) id 17kLbX-0007N9-00; Thu, 29 Aug 2002 11:28:43 +0200 Received: from babar.switch.ch (localhost [IPv6:::1]) by babar.switch.ch (8.12.2+Sun/8.12.2) with ESMTP id g7T9Sg6o016788; Thu, 29 Aug 2002 11:28:42 +0200 (MEST) Received: (from leinen@localhost) by babar.switch.ch (8.12.2+Sun/8.12.2/Submit) id g7T9SbcW016785; Thu, 29 Aug 2002 11:28:37 +0200 (MEST) X-Authentication-Warning: babar.switch.ch: leinen set sender to simon@limmat.switch.ch using -f To: Juergen Quittek Cc: "Logg, Connie A." , "'calato@riverstonenet.com'" , req Subject: Re: fragmented packets (was: Re: [ipfix-req] IPFIX Requirements Q uestions) References: <2846497B437BF84BAD1A4CC407418D26D13B0C@exchange1.slac.stanford.edu> <33429198.1030559348@[192.168.102.164]> X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7,F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR` From: Simon Leinen In-Reply-To: <33429198.1030559348@[192.168.102.164]> Date: 29 Aug 2002 11:28:36 +0200 Message-ID: Lines: 31 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.90 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Precedence: bulk Sender: majordomo listserver On Wed, 28 Aug 2002 18:29:08 +0200, Juergen Quittek said: > The first fragment of a packet that is observed, is not necessarily > the fragment containing the TCP/UDP header. IP allows packet > re-ordering. The fragment containing the first bytes of the IP > payload may travel slower through the network than the other > fragments. Not only that, the source may not even send the first bytes of an oversize datagram as the first fragment. Notably Linux sends fragments from the end of the datagram towards the start. The standards apparently don't mandate a specific order of the fragments - that would be of limited use anyway since IP doesn't guarantee in-order delivery. Sending the last part of the packet first has the advantage that, if the fragments do happen to arrive in order, the receiver immediately learns the total size of the datagram, and can allocate buffer space accordingly. Anyway, I think caching of fragmented packets just cannot be done efficiently, and that we should certainly not enforce it in IPFIX. This does have the implication that malicious users can "hide" their higher-layer information (e.g. TCP/UDP port numbers) by intentionally fragmenting packets just after the IP header. That's a limitation I can personally live with (note that this is also a problem for stateless packet filters that try to filter based on higher-layer information). -- Simon Leinen simon@babar.switch.ch SWITCH http://www.switch.ch/misc/leinen/ Computers hate being anthropomorphized. -- Help mailto:majordomo@net.doit.wisc.edu and say "help" 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 Aug 29 06:04:48 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14487 for ; Thu, 29 Aug 2002 06:04:47 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17kM0y-0005Ks-00 for ipfix-list@mil.doit.wisc.edu; Thu, 29 Aug 2002 04:55:00 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17kM0w-0005Jm-00 for ipfix-req@net.doit.wisc.edu; Thu, 29 Aug 2002 04:54:58 -0500 Received: from cisco.com (dhcp-peg3-vl30-144-254-7-78.cisco.com [144.254.7.78]) by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id g7T9sD725396; Thu, 29 Aug 2002 11:54:13 +0200 (CEST) Message-ID: <3D6DEF45.80700@cisco.com> Date: Thu, 29 Aug 2002 11:54:13 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020815 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juergen Quittek CC: calato@riverstonenet.com, req Subject: Re: overload behavior (was: Re: [ipfix-req] IPFIX Requirements Questions) References: <3D6CD65A.C52F4654@riverstonenet.com> <26869946.1030552789@[192.168.102.164]> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Paul, [let me take the latest email on this thread] > Hi Paul, > > --On 28 August 2002 09:55 -0400 calato@riverstonenet.com wrote: > >> Juergen Quittek wrote: >> >>> >>> Hi Paul, >>> >>> --On 27 August 2002 20:26 -0400 calato@riverstonenet.com wrote: >>> >>> [...] >>> >>> >> > 5.3 Overload Behavior >>> >> > >>> >> > This section needs to be re-worked a little. Some >>> >> > of the MUST's impose undue burden on the device. >>> >> > >>> >> > 1. Must distinguish flow records before and after the >>> >> > behavior change. >>> >> > >>> >> > In the case where the behavior is to drop >>> >> > overflow flows, why do we need to distinguish >>> >> > flows. Perhaps I misunderstood something. >> An example (somehow already discussed below) is: 1. you do sampling 1/100. 2. for whatever reason, you drop overflow flows (or you decide to change the sampling rate) 3. the new sampling rate is now 1/200 4. the collector must know that. >>> >>> >> > >>> >> > >>> >> > 2. All flows from previous behavior MUST be terminated. >>> >> > >>> >> > >>> >> > Again, if I simply dropped excess flows why >>> terminate >>> >> > all existing ones. This will likely cause more >>> overflow >>> >> > as the get reestablished. This also seems to go to >>> >> > far towards implementation. >>> >> >>> >> I agree. >>> >> >>> >> > 3. Meeting process MUST NOT merge previous records. >>> >> > >>> >> > >>> >> > >>> >> > I think what we are trying to say is flows with a >>> different >>> >> > definition MUST be distinguishable. How that is done is not >>> >> > part of the requirements doc. >> Agreed. It was actually the goal of the sentence "the overload behavior MUST be clearly defined and the collecting process MUST be able to distinguish the flow records exported before and after the metering process behavior change" Because, in my view, dropping the overflows flows is changing the "definition" of the flow, as you wrote Paul wrote it in "flows with a different definition MUST be distinguishable" >>> >>> >> >>> >> Also agreed. However, it is not just different definition, but also >>> >> different measurement technique, different sampling rate, etc. >>> >> >>> >> We need to express this intended requirement it in a better way. >>> > >>> > Agreed. >>> > >>> > What this points out to me is that we do not have a term >>> > that refers to the set of information that is the flow >>> > definition. We touch on it in section 2.1 when discussing >>> > the flow definition itself, in section 2.3 when discussing >>> > classifying and then again in section 4 when discussing >>> > distinguishing flows. >>> > >>> > What about a new term "Distinguishing Properties" or >>> > "Flow Properties"? Its definition would be >>> > >>> > The set of fields, functions and parameters (e.g. >>> sampling >>> > rate) used to map packets to flows. >>> > >>> > Then we can say each flow MUST be able to be mapped to its >>> > "Distinguishing properties". >>> > >>> > This would cover changing behavior due to overload, >>> configuration >>> > changes, etc... >>> > >>> > Thoughts? >> >>> >>> >>> I think the mistake in the current version of the text is that it >>> asks on separating flows before and after the metering process was >>> modified. It is indepenedent of whether the individual flows are >>> affected or not. I think it is sufficient to fix this. >> >> >> >> You side stepped my main 2 issues here. >> >> 1. We need a definition for the set of functions, >> fields and parameters use to map packets to flows. >> If it is there and I missed it, let me know. >> >> 2. We need a requirement that allows the Collecting >> device to map flows to the set of functions, >> fields and parameters used to create the flow. > > > My intention was not to side step them, but to answer on the portion > of your comment on which I already made up my mind already. On this issue > I still have to think some more. > >>> >>> The current text is >>> >>> Overload behavior is not restricted to the four options listed >>> above. >>> But in case the overload behavior has an impact on the metering >>> process or the exporting process, the overload behavior MUST be >>> clearly defined and the collecting process MUST be able to >>> distinguish the flow records exported before and after the metering >>> process behavior change: in case of any change of the meter's >>> behavior, all flow records metered by the previous behavior MUST be >>> terminated and exported according to the configuration of the >>> exporting process. The metering process MUST not merge the flow >>> records generated with the new behavior with the flow records >>> generated with the previous behavior. >>> >>> I suggest to replace it by >>> >>> Overload behavior is not restricted to the four options listed >>> above. >>> But in case the overload behavior induces a change of the >>> behavior of >>> metering process and/or the exporting process, the following >>> requirements >>> must be met for all flows affected by the change of behavior: >>> - The overload behavior MUST be clearly defined. >> >> >> Agreed. >> >>> - For each flows affected by the change, its record MUST be >>> terminated >>> at the time of change. >> >> >> This seems like implementation detail. Maybe I want to leave >> them in tact and when the overload situation is resolved I can >> start adding to the counter again. > > > I don't think this would be a good idea, because it might not be clear > to the collector that you ignored all packets for some time. This seems > to be a very unreliable behavior. Agreed with Juergen on that one. In my example: 1. you do sampling 1/100. 2. for whatever reason, you drop overflow flows (or you decide to change the sampling rate) 3. the new sampling rate is now 1/200 4. the collector must know that. How would the collector be able to distinguish the 2 series of flow records. If for example you want to multiply the first serie usage by 100 and the second serie by 200? Regards, Benoit. > > > However, you still might be right. Very often it is hard to distinguish > between the real requirement and a particular implementation meeting > that requirement. In this case I am not sure. > >>> - For each flow affected by the change, the collecting process >>> MUST be >>> able to determine whether the corresponding exported flow >>> record was >>> created before or after the change of behavior. >> >> >> I believe that if we address the 2 issues discussed earlier >> these would no longer be needed. > > > Would be fine. > > Juergen > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in > message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Aug 29 06:25:46 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14793 for ; Thu, 29 Aug 2002 06:25:45 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17kMLC-0006cp-00 for ipfix-list@mil.doit.wisc.edu; Thu, 29 Aug 2002 05:15:54 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17kMLA-0006bx-00 for ipfix-req@net.doit.wisc.edu; Thu, 29 Aug 2002 05:15:52 -0500 Received: from cisco.com (dhcp-peg3-vl30-144-254-7-78.cisco.com [144.254.7.78]) by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id g7TAFD711092; Thu, 29 Aug 2002 12:15:13 +0200 (CEST) Message-ID: <3D6DF431.60800@cisco.com> Date: Thu, 29 Aug 2002 12:15:13 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020815 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juergen Quittek CC: calato@riverstonenet.com, req Subject: Re: fragmented packets (was: Re: [ipfix-req] IPFIX Requirements Questions) References: <3D6CCAE5.1BF2C42D@riverstonenet.com> <25723999.1030551643@[192.168.102.164]> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Paul and Juergen, > Hi Paul, > > --On 28 August 2002 09:06 -0400 calato@riverstonenet.com wrote: > >> Juergen Quittek wrote: >> >>> >>> Hi Paul, >>> >>> --On 27 August 2002 20:26 -0400 calato@riverstonenet.com wrote: >>> >>> > Juergen Quittek wrote: >>> >> >>> >> --On 27 August 2002 14:49 -0400 calato@riverstonenet.com wrote: >>> >> >>> >> > >>> >> > As I work on the advocates document some questions >>> >> > have come to mind on the requirements document. >>> >> > >>> >> > 4.3 Distinguishing flows using Transport Header Fields >>> >> > >>> >> > In the case of fragmented packets there are >>> >> > no port numbers. Are we saying flow state information >>> >> > MUST be maintained? In general, it is not clear from >>> >> >>> >> No, the requirements document does not say so. >>> >> >>> >> > the document what the requirements are for fragmented >>> >> > packets. >>> >> >>> >> I think the requirements should not include a requirement for >>> >> keeping state of fragmented packets. Would you like to see >>> >> an explicit statement on that? This would be a NO NEED FOR >>> >> statement :-) >>> > >>> > I think we need to be explicit. Most people will think >>> > of fragements as being counted in the same flow as the >>> > first packet not as 2 differernt flows. >>> >>> I see. Waht about adding a new subsection to Section "5. Metering >>> Process": >>> >>> 5.8. Packet Fragmentation >>> >>> In case of IP packet fragmentation, only one fragment of a single >>> packet might contain sufficient information for classifying the >>> packet correctly. The metering process MAY keep state of >>> IP packet fragmentation in order to map fragments that do not >>> contain sufficient header information correctly to flows. >> >> >> How about a slight re-wording... >> >> In case of IP datagram fragmentation, only the first fragment might >> contain sufficient information for classifying the packet correctly. >> The metering process MAY keep state of IP fragmentation in order to >> map fragments without sufficient header information to the same >> flow as the first fragmented packet. > > > Initially I also wanted to phrase like this. But it's IP. And fragments > might get re-ordered. The first fragment of a packet that is observed, > is not necessarily the fragment containing the TCP/UDP header. > > Now, if you say "first", it is not clear whether you mean the fragment > with the first bytes of the IP payload or the first fragment observed > at the observation point. Your last sentence seems to assume that the > first observed packet is the one with the first bytes of the payload. Why not merge your 2 texts: In case of IP packet fragmentation, only one fragment of the initial packet might contain sufficient information for classifying the packet correctly. Note that this fragment is the first one generated by the router imposing the fragmentation, but might not be the first one observed by the IPFIX device, due reordering reasons. The metering process MAY keep state of IP packet fragmentation in order to map fragments that do not contain sufficient header information correctly to flows. > > >>> [...] >>> >>> >> > 6.1 information Model >>> >> > >>> >> > 9 Packet Counter >>> >> > 10 Byte counter >>> >> > >>> >> > As mentioned earlier, for fragments this >>> >> > requires state information? If there is no >>> >> > state info, then what flow are the counted >>> >> > towards? >>> >> >>> >> Do you suggest to include a requirement for keeping fragment >>> state info? >>> > >>> > >>> > A MAY is as far as I would go. There may certainly be probes >>> > that have this capability. We should have a requirement that >>> > says fragment counting MUST be clearly defined. >>> >>> OK. Currently, we have >>> >>> 9. packet counter >>> If a packet is fragmented, each fragment is counted as an >>> individual packet. >>> 10. byte counter >>> Which bytes of a packet are counted MUST be defined exactly. >>> >>> What about appending >>> >>> The behavior of the byte counter in case of IP packet >>> fragmentation MUST be clearly defined. >> >> >> With the new section on fragmentation I think we can >> eliminate any mention of it on the counters. > > > The new section of the fragmentation is a MAY requirement. But for > understamding the behavior of the byte counter you MUST know whether > or not the option is implemented. So, haven't we enough with "The behavior of the byte and packet counters in case of IP packet fragmentation MUST be clearly defined."? We need the packet counter in the sentence above: to know if the flow state information is maintained for fragemented packets > > >>> ? >>> >>> Please note that we also have in the MAY attributes section >>> >>> 26. fragmented packet counter >>> counter of all packets for which the fragmented bit is set in >>> the IP header >> >> >> I'm not sure why this was added. If you want that info, >> make the IP fragment bit part of the flow definition. > It makes sense. Regards, Benoit >> > > Do you suggest to remove it? Anyone else? > > > Juergen > > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in > message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Aug 29 06:56:20 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15242 for ; Thu, 29 Aug 2002 06:56:20 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17kMnr-0007gj-00 for ipfix-list@mil.doit.wisc.edu; Thu, 29 Aug 2002 05:45:31 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17kMno-0007fD-00 for ipfix-req@net.doit.wisc.edu; Thu, 29 Aug 2002 05:45:29 -0500 Received: from cisco.com (dhcp-peg3-vl30-144-254-7-78.cisco.com [144.254.7.78]) by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id g7TAil704382; Thu, 29 Aug 2002 12:44:47 +0200 (CEST) Message-ID: <3D6DFB1F.7030802@cisco.com> Date: Thu, 29 Aug 2002 12:44:47 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020815 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simon Leinen CC: Juergen Quittek , "Logg, Connie A." , "'calato@riverstonenet.com'" , req Subject: Re: fragmented packets (was: Re: [ipfix-req] IPFIX Requirements Q uestions) References: <2846497B437BF84BAD1A4CC407418D26D13B0C@exchange1.slac.stanford.edu> <33429198.1030559348@[192.168.102.164]> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Simon, >On Wed, 28 Aug 2002 18:29:08 +0200, Juergen Quittek said: > > >>The first fragment of a packet that is observed, is not necessarily >>the fragment containing the TCP/UDP header. IP allows packet >>re-ordering. The fragment containing the first bytes of the IP >>payload may travel slower through the network than the other >>fragments. >> >> > >Not only that, the source may not even send the first bytes of an >oversize datagram as the first fragment. Notably Linux sends >fragments from the end of the datagram towards the start. The >standards apparently don't mandate a specific order of the fragments - >that would be of limited use anyway since IP doesn't guarantee >in-order delivery. > RFC 791: The first portion of the data is placed in the first new internet datagram, and the total length field is set to the length of the first datagram. > Sending the last part of the packet first has the >advantage that, if the fragments do happen to arrive in order, the >receiver immediately learns the total size of the datagram, and can >allocate buffer space accordingly. > >Anyway, I think caching of fragmented packets just cannot be done >efficiently, and that we should certainly not enforce it in IPFIX. > Agreed. Regards, Benoit. > >This does have the implication that malicious users can "hide" their >higher-layer information (e.g. TCP/UDP port numbers) by intentionally >fragmenting packets just after the IP header. That's a limitation I >can personally live with (note that this is also a problem for >stateless packet filters that try to filter based on higher-layer >information). > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" 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 Aug 29 07:21:07 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15867 for ; Thu, 29 Aug 2002 07:21:07 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17kNCn-0000e3-00 for ipfix-list@mil.doit.wisc.edu; Thu, 29 Aug 2002 06:11:17 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17kNCk-0000cs-00 for ipfix-req@net.doit.wisc.edu; Thu, 29 Aug 2002 06:11:14 -0500 Received: from cisco.com (dhcp-peg3-vl30-144-254-7-78.cisco.com [144.254.7.78]) by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id g7TBAY723675; Thu, 29 Aug 2002 13:10:34 +0200 (CEST) Message-ID: <3D6E012A.6010804@cisco.com> Date: Thu, 29 Aug 2002 13:10:34 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020815 X-Accept-Language: en-us, en MIME-Version: 1.0 To: calato@riverstonenet.com CC: Juergen Quittek , req Subject: Re: MPLS label (was:Re: [ipfix-req] IPFIX Requirements Questions) References: <3D6CCD9E.DFD45743@riverstonenet.com> <26292857.1030552212@[192.168.102.164]> <3D6CE39A.AFD0F9C5@riverstonenet.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi, >Juergen Quittek wrote: > > >>Hi Paul, >> >>--On 28 August 2002 09:18 -0400 calato@riverstonenet.com wrote: >> >> >> >>>Juergen Quittek wrote: >>> >>> >>>>Hi Paul, >>>> >>>>--On 27 August 2002 20:26 -0400 calato@riverstonenet.com wrote: >>>> >>>>[...] >>>> >>>> >>>> >>>>>>>4.4 MPLS Label >>>>>>> >>>>>>> In the case of dynamic LSP's the label is not useful. >>>>>>> Why require distinguishing flows based on label. >>>>>>> What can be done with that information? >>>>>>> >>>>>>> >>>>>>Well, for each attribute there are situations where it does not make >>>>>>sense to use it for distinguishing flows. But being able to distinguish >>>>>>flows by label seems to be useful to me in general. >>>>>> >>>>>> >>>>> Then why not include things like VPI/VCI for ATM >>>>> or other L2.5 tunnels? Why does MPLS get special >>>>> consideration? >>>>> >>>>> >>>>In general I see your point, although MPLS appears to be closer >>>>related to IP than plain ATM. >>>> >>>> >>> Why? I can take and ATM PVC and use it as a tunnel for >>> IP traffic just like MPLS. >>> >>> >>Yes, but MPLS integrates with IP forwarcing when using CR-LDP >>or RSVP-TE. Also you can use MPLS as "glue" between IP and ATM. >> >> > > I don't understand your argument here. Both technologies > are viable solutions and exist in the market today. > If one is included, so should the other. > > > >>>>> Also, I may be wrong here but I beleive the primary >>>>> use of MPLS will be with dynamic LSP's so the label >>>>> has little meaning the majority of time. At best >>>>> it would be a MAY requirement, not a MUST. >>>>> >>>>> >>>>For me, metering on a per-LSP basis is highly benefitial for the >>>>operation of MPLS networks, even in the case of dynamic label >>>>assignment. The LSR MIB already offers this kind of performance >>>>information, but I think it also fits well into IPFIX. >>>> >>>> >>> Are you talking about metering LSP's themselves or >>> metering IP flows traveling through an LSP? >>> >>> >>I'm talking about metering LSPs and about observing which flow maps >>into which LSP. >> >> > > > I'm a little confused. I thought we were only doing IP > flows. Are we now including MPLS flows (LSPs)? > > > >>> Assuming you are talking about the latter, what can be done >>> with the label information? If the flow F1 had label 57 >>> and F2 had label 57 you don't even know if it is the >>> same LSP. >>> >>> >>You are right. I would also need interface information. >> >> > > OK. So now I have F1, I1 and L57 and then F2, I1 and L57. > I still don't know if it is the same LSP. > > > >>>>> If we are going to go this way, which I am >>>>> against, then we should also include FEC. At least >>>>> that would be more meaningful information in the >>>>> case of dynamic LSPs. >>>>> >>>>> >>>>This could be useful, but the FEC is a higher level information >>>>that is not available in many cases. Also we would need a good model >>>>for FEC information. >>>> >>>> >>> If the device knows the label it knows the FEC. There are >>> some concrete FEC definitions now and we can always add more >>> as they materialize. >>> >>> >>All you need for an LSP are entries in insegment table, outsegment table >>and switching table. How does the device know anything about the FEC if the >>LSP was explicitly setup by a management system that added entries to these >>tables. >> >> > > Let me make sure I understand. Some external management > station received the FEC and programmed the device? If > that is the case then you are correct. However, wont many > deployments have the 2 functions on one device? If so, > then reporting FEC is at least a MAY requirement. > I have to admit that I haven't been thinking too much in the draft about MPLS. I agree now that it makes more sense to report the FEC than the MPLS label, since the label has got a local significance But this is not in contradiction with what is in the draft! 4.4. MPLS Label If the observation point is located at a device supporting Multiprotocol Label Switching (MPLS, see [RFC3031]) then the metering process MUST be able to separate flows by the MPLS label. And SHOU:LD report the FEC Regards, Benoit. > > > >> Juergen >> >> > >-- >Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body >Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >"unsubscribe ipfix" in message body >Archive http://ipfix.doit.wisc.edu/archive/ > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Aug 29 10:35:35 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24185 for ; Thu, 29 Aug 2002 10:35:35 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17kQDr-0005UA-00 for ipfix-list@mil.doit.wisc.edu; Thu, 29 Aug 2002 09:24:35 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17kQDp-0005TZ-00 for ipfix-req@net.doit.wisc.edu; Thu, 29 Aug 2002 09:24:33 -0500 Received: from cisco.com (dhcp-peg3-vl30-144-254-7-78.cisco.com [144.254.7.78]) by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id g7TENW721749; Thu, 29 Aug 2002 16:23:32 +0200 (CEST) Message-ID: <3D6E2E64.7060902@cisco.com> Date: Thu, 29 Aug 2002 16:23:32 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020815 X-Accept-Language: en-us, en MIME-Version: 1.0 To: calato@riverstonenet.com CC: Sebastian Zander , Juergen Quittek , req Subject: Re: [ipfix-req] IPFIX Requirements Questions (timestamps) References: <3D6BC9AD.CAC153C8@riverstonenet.com> <42174623.1030483746@[192.168.102.164]> <3D6C18A3.764A46B9@riverstonenet.com> <3D6CA423.3020900@fokus.gmd.de> <3D6CD222.CAC66D82@riverstonenet.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit All, [taking the latest email on this thread ... hopefully because there are so many emails] >>>>>5.4 Timestamps >>>>> >>>>> Time stamps to not always mapped to the first packet and last >>>>> packet. In many cases, the end timestamp is merely when >>>>> the flow timed out and has nothing to do with when the >>>>> last packet was seen. Allowing both semantics may be useful. >>>>> A re-wording like this... >>>>> >>>>> >>>>> The metering process MUST be able to generate timestamps for the >>>>> start and end of a flow. The metering process MAY also provide >>>>> timestamps for the first and the last observed packet >>>>> of a flow. The timestamp resolution MUST be at least the one of >>>>> the sysUpTime [RFC1213], which is one centisecond. >>>>> >>>>> Note - this does not mandate 2 timestamp fields for a flow. You >>>>> could have one element for each meaning (e.g. Flow-start-time, >>>>> first-packet-time, flow-start-and-first-packet-time) and use >>>>> the one with the desired meaning. >>>>> >>>>> >>>>> >>>>You just added a MAY requirement for the timeout timestamp. We can do this, >>>>but everything you mention was already possible without this additional >>>>requirement. It was just required that the metering process can provide >>>>these timestamps (if configured so). Whether or not they are exported >>>>and whether or not other timestamps are exported was already left open >>>>by the requirements. >>>> >>>> >>>> >>> I disagree. I'm not talking about what is exported, I talking >>> about semantics. The req doc currently ties the timestamp event >>> to packet observation. All metering processes will know >>> when they created and deleted a flow. They may or may not >>> know when the first or last packet was observed. >>> >>> The typical example of this is last packet. In many platforms >>> the first packet is processed by the CPU and creates a hardware entry. >>> The rest of the packets are processed and counted in hardware >>> and thus there is no timestamp available, just a count. All >>> that is known is when the flow was artifically timed out. >>> The timestamp of the last packet observed is what we need for accounting and not when the flow expires from the cache. In our implementation, we create the timestamp of the last packet observed in the flow. We do this in hardware and obvioulsy in software on the smaller platforms. Regards, Benoit. >>> >>> A weaker argument can be made for first packet observed. There >>> may be a known significant delay from packet observation to timestamp. >>> In this case the metering process can report the time at which it >>> created the flow but not first packet time. Weak I know. >>> >>> >>I agree that we have to look at current practice but I have the feeling that >>we get more and more vague just to support any existing thing. The requirements >>are driven by applications. Lets look at accounting. I am wondering how IPFIX >>information can be used for accounting when >> >>- there are no correct stop timestamps (there are no requirements on >> the flow timeout) >> >> > > I don't think that is the case. If you report a flow end > and the flow timeout period is 10 seconds, that will be > close enough for most applications, even accounting. > > > >>- there are no requirements on the report time (when are reports send) >> (e.g. it is not required to export information at/after flow end) >> >> > > Good point. Maybe we need some text on report time. > > The exporting process MUST be able to report on flow > start and end within a configurable time limit. > > > > >>- there is no timestamp required in interim flow records >> >> > > I'm not sure I follow here. There is a SHOULD requirement > for regular reporting. > > > >>- byte counters may not be correct (in case of port filtering and fragmentation) >> >>Well forget about the last one but with the first three we basically do not >>comply to the req of the AAA WG for accounting. >> >>If the MUST requirement of the current draft is a problem for a lot of current >>hardware then at least the requirement should be reduced to a SHOULD and not >>a MAY. >> >> > > In this particular case I believe the definition is the > problem, not the current hardware. I can't imagine any > hardware ever timestamping every packet. > > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" 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 Aug 29 10:46:03 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24751 for ; Thu, 29 Aug 2002 10:46:03 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17kQPO-0005qS-00 for ipfix-list@mil.doit.wisc.edu; Thu, 29 Aug 2002 09:36:30 -0500 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17kQPL-0005pp-00 for ipfix-req@net.doit.wisc.edu; Thu, 29 Aug 2002 09:36:27 -0500 Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g7TEZcU90844; Thu, 29 Aug 2002 16:35:38 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 01AA24D330; Thu, 29 Aug 2002 16:35:36 +0200 (CEST) Date: Thu, 29 Aug 2002 16:35:35 +0200 From: Juergen Quittek To: Benoit Claise , calato@riverstonenet.com Cc: req Subject: Re: MPLS label (was:Re: [ipfix-req] IPFIX Requirements Questions) Message-ID: <34028240.1030638935@[192.168.102.164]> In-Reply-To: <3D6E012A.6010804@cisco.com> References: <3D6E012A.6010804@cisco.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Benoit, -- Benoit Claise wrote on 29 August 2002 13:10 +0200: > Hi, > >> Juergen Quittek wrote: >> >> >>> Hi Paul, >>> >>> --On 28 August 2002 09:18 -0400 calato@riverstonenet.com wrote: >>> >>> >>> >>>> Juergen Quittek wrote: >>>> >>>> >>>>> Hi Paul, >>>>> >>>>> --On 27 August 2002 20:26 -0400 calato@riverstonenet.com wrote: >>>>> >>>>> [...] >>>>> >>>>> >>>>> >>>>>>>> 4.4 MPLS Label >>>>>>>> >>>>>>>> In the case of dynamic LSP's the label is not useful. >>>>>>>> Why require distinguishing flows based on label. >>>>>>>> What can be done with that information? >>>>>>>> >>>>>>>> >>>>>>> Well, for each attribute there are situations where it does not make >>>>>>> sense to use it for distinguishing flows. But being able to distinguish >>>>>>> flows by label seems to be useful to me in general. >>>>>>> >>>>>>> >>>>>> Then why not include things like VPI/VCI for ATM >>>>>> or other L2.5 tunnels? Why does MPLS get special >>>>>> consideration? >>>>>> >>>>>> >>>>> In general I see your point, although MPLS appears to be closer >>>>> related to IP than plain ATM. >>>>> >>>>> >>>> Why? I can take and ATM PVC and use it as a tunnel for >>>> IP traffic just like MPLS. >>>> >>>> >>> Yes, but MPLS integrates with IP forwarcing when using CR-LDP >>> or RSVP-TE. Also you can use MPLS as "glue" between IP and ATM. >>> >>> >> >> I don't understand your argument here. Both technologies >> are viable solutions and exist in the market today. >> If one is included, so should the other. >> >> >> >>>>>> Also, I may be wrong here but I beleive the primary >>>>>> use of MPLS will be with dynamic LSP's so the label >>>>>> has little meaning the majority of time. At best >>>>>> it would be a MAY requirement, not a MUST. >>>>>> >>>>>> >>>>> For me, metering on a per-LSP basis is highly benefitial for the >>>>> operation of MPLS networks, even in the case of dynamic label >>>>> assignment. The LSR MIB already offers this kind of performance >>>>> information, but I think it also fits well into IPFIX. >>>>> >>>>> >>>> Are you talking about metering LSP's themselves or >>>> metering IP flows traveling through an LSP? >>>> >>>> >>> I'm talking about metering LSPs and about observing which flow maps >>> into which LSP. >>> >>> >> >> >> I'm a little confused. I thought we were only doing IP >> flows. Are we now including MPLS flows (LSPs)? >> >> >> >>>> Assuming you are talking about the latter, what can be done >>>> with the label information? If the flow F1 had label 57 >>>> and F2 had label 57 you don't even know if it is the >>>> same LSP. >>>> >>>> >>> You are right. I would also need interface information. >>> >>> >> >> OK. So now I have F1, I1 and L57 and then F2, I1 and L57. >> I still don't know if it is the same LSP. >> >> >> >>>>>> If we are going to go this way, which I am >>>>>> against, then we should also include FEC. At least >>>>>> that would be more meaningful information in the >>>>>> case of dynamic LSPs. >>>>>> >>>>>> >>>>> This could be useful, but the FEC is a higher level information >>>>> that is not available in many cases. Also we would need a good model >>>>> for FEC information. >>>>> >>>>> >>>> If the device knows the label it knows the FEC. There are >>>> some concrete FEC definitions now and we can always add more >>>> as they materialize. >>>> >>>> >>> All you need for an LSP are entries in insegment table, outsegment table >>> and switching table. How does the device know anything about the FEC if the >>> LSP was explicitly setup by a management system that added entries to these >>> tables. >>> >>> >> >> Let me make sure I understand. Some external management >> station received the FEC and programmed the device? If >> that is the case then you are correct. However, wont many >> deployments have the 2 functions on one device? If so, >> then reporting FEC is at least a MAY requirement. >> > I have to admit that I haven't been thinking too much in the draft about MPLS. > I agree now that it makes more sense to report the FEC than the MPLS label, since the label has got a local significance > > But this is not in contradiction with what is in the draft! > > 4.4. MPLS Label > > If the observation point is located at a device supporting > Multiprotocol Label Switching (MPLS, see [RFC3031]) then the metering > process MUST be able to separate flows by the MPLS label. > > And SHOU:LD report the FEC Here in Section 4 we are talking about separating flows. Do we want to separate flows by the FEC also? Or are you suggesting to add the FEC to the list of SHOULD attributes in Section 6.1? Juergen > > Regards, Benoit. > >> >> >> >>> Juergen >>> >>> >> >> -- >> Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body >> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >> "unsubscribe ipfix" in message body >> Archive http://ipfix.doit.wisc.edu/archive/ >> >> > > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Aug 29 11:32:20 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27102 for ; Thu, 29 Aug 2002 11:32:19 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17kR56-0006nE-00 for ipfix-list@mil.doit.wisc.edu; Thu, 29 Aug 2002 10:19:36 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17kR52-0006mg-00 for ipfix-req@net.doit.wisc.edu; Thu, 29 Aug 2002 10:19:32 -0500 Received: from cisco.com (dhcp-peg3-vl30-144-254-7-78.cisco.com [144.254.7.78]) by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id g7TFIq718377; Thu, 29 Aug 2002 17:18:52 +0200 (CEST) Message-ID: <3D6E3B5C.90404@cisco.com> Date: Thu, 29 Aug 2002 17:18:52 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020815 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juergen Quittek CC: calato@riverstonenet.com, req Subject: Re: MPLS label (was:Re: [ipfix-req] IPFIX Requirements Questions) References: <3D6E012A.6010804@cisco.com> <34028240.1030638935@[192.168.102.164]> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Juergen Quittek wrote: > Hi Benoit, > > -- Benoit Claise wrote on 29 August 2002 13:10 +0200: > >> Hi, >> >>> Juergen Quittek wrote: >>> >>> >>>> Hi Paul, >>>> >>>> --On 28 August 2002 09:18 -0400 calato@riverstonenet.com wrote: >>>> >>>> >>>> >>>>> Juergen Quittek wrote: >>>>> >>>>> >>>>>> Hi Paul, >>>>>> >>>>>> --On 27 August 2002 20:26 -0400 calato@riverstonenet.com wrote: >>>>>> >>>>>> [...] >>>>>> >>>>>> >>>>>> >>>>>>>>> 4.4 MPLS Label >>>>>>>>> >>>>>>>>> In the case of dynamic LSP's the label is not useful. >>>>>>>>> Why require distinguishing flows based on label. >>>>>>>>> What can be done with that information? >>>>>>>>> >>>>>>>>> >>>>>>>> Well, for each attribute there are situations where it does not >>>>>>>> make >>>>>>>> sense to use it for distinguishing flows. But being able to >>>>>>>> distinguish >>>>>>>> flows by label seems to be useful to me in general. >>>>>>>> >>>>>>>> >>>>>>> Then why not include things like VPI/VCI for ATM >>>>>>> or other L2.5 tunnels? Why does MPLS get special >>>>>>> consideration? >>>>>>> >>>>>>> >>>>>> In general I see your point, although MPLS appears to be closer >>>>>> related to IP than plain ATM. >>>>>> >>>>>> >>>>> Why? I can take and ATM PVC and use it as a tunnel for >>>>> IP traffic just like MPLS. >>>>> >>>>> >>>> Yes, but MPLS integrates with IP forwarcing when using CR-LDP >>>> or RSVP-TE. Also you can use MPLS as "glue" between IP and ATM. >>>> >>>> >>> >>> I don't understand your argument here. Both technologies >>> are viable solutions and exist in the market today. >>> If one is included, so should the other. >>> >>> >>> >>>>>>> Also, I may be wrong here but I beleive the primary >>>>>>> use of MPLS will be with dynamic LSP's so the label >>>>>>> has little meaning the majority of time. At best >>>>>>> it would be a MAY requirement, not a MUST. >>>>>>> >>>>>>> >>>>>> For me, metering on a per-LSP basis is highly benefitial for the >>>>>> operation of MPLS networks, even in the case of dynamic label >>>>>> assignment. The LSR MIB already offers this kind of performance >>>>>> information, but I think it also fits well into IPFIX. >>>>>> >>>>>> >>>>> Are you talking about metering LSP's themselves or >>>>> metering IP flows traveling through an LSP? >>>>> >>>>> >>>> I'm talking about metering LSPs and about observing which flow maps >>>> into which LSP. >>>> >>>> >>> >>> >>> I'm a little confused. I thought we were only doing IP >>> flows. Are we now including MPLS flows (LSPs)? >>> >>> >>> >>>>> Assuming you are talking about the latter, what can be done >>>>> with the label information? If the flow F1 had label 57 >>>>> and F2 had label 57 you don't even know if it is the >>>>> same LSP. >>>>> >>>>> >>>> You are right. I would also need interface information. >>>> >>>> >>> >>> OK. So now I have F1, I1 and L57 and then F2, I1 and L57. >>> I still don't know if it is the same LSP. >>> >>> >>> >>>>>>> If we are going to go this way, which I am >>>>>>> against, then we should also include FEC. At least >>>>>>> that would be more meaningful information in the >>>>>>> case of dynamic LSPs. >>>>>>> >>>>>>> >>>>>> This could be useful, but the FEC is a higher level information >>>>>> that is not available in many cases. Also we would need a good model >>>>>> for FEC information. >>>>>> >>>>>> >>>>> If the device knows the label it knows the FEC. There are >>>>> some concrete FEC definitions now and we can always add more >>>>> as they materialize. >>>>> >>>>> >>>> All you need for an LSP are entries in insegment table, outsegment >>>> table >>>> and switching table. How does the device know anything about the >>>> FEC if the >>>> LSP was explicitly setup by a management system that added entries >>>> to these >>>> tables. >>>> >>>> >>> >>> Let me make sure I understand. Some external management >>> station received the FEC and programmed the device? If >>> that is the case then you are correct. However, wont many >>> deployments have the 2 functions on one device? If so, >>> then reporting FEC is at least a MAY requirement. >>> >> I have to admit that I haven't been thinking too much in the draft >> about MPLS. >> I agree now that it makes more sense to report the FEC than the MPLS >> label, since the label has got a local significance >> >> But this is not in contradiction with what is in the draft! >> >> 4.4. MPLS Label >> >> If the observation point is located at a device supporting >> Multiprotocol Label Switching (MPLS, see [RFC3031]) then the metering >> process MUST be able to separate flows by the MPLS label. >> >> And SHOU:LD report the FEC > > > Here in Section 4 we are talking about separating flows. > Do we want to separate flows by the FEC also? As there is a matching Label -> FEC, we can still separate by Label > > Or are you suggesting to add the FEC to the list of SHOULD > attributes in Section 6.1? And yes: SHOULD report the FEC in Section 6.1 Regards, Benoit. > > > Juergen > >> >> Regards, Benoit. >> >>> >>> >>> >>>> Juergen >>>> >>>> >>> >>> -- >>> Help mailto:majordomo@net.doit.wisc.edu and say "help" in >>> message body >>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>> "unsubscribe ipfix" in message body >>> Archive http://ipfix.doit.wisc.edu/archive/ >>> >>> >> >> >> > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Aug 29 12:59:54 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01745 for ; Thu, 29 Aug 2002 12:59:53 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17kSVT-0001Hh-00 for ipfix-list@mil.doit.wisc.edu; Thu, 29 Aug 2002 11:50:55 -0500 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17kSVQ-0001Gs-00 for ipfix-eval@net.doit.wisc.edu; Thu, 29 Aug 2002 11:50:53 -0500 Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g7TGoJU94561; Thu, 29 Aug 2002 18:50:19 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 0D0B05DA83; Thu, 29 Aug 2002 18:50:15 +0200 (CEST) Date: Thu, 29 Aug 2002 18:50:15 +0200 From: Juergen Quittek To: Nevil Brownlee , ipfix-eval@net.doit.wisc.edu Subject: reminder (was Re: [ipfix-eval] IPFIX Evaluation: update) Message-ID: <42108338.1030647015@[192.168.102.164]> In-Reply-To: <1028689992.3d50904895a77@hotlava.auckland.ac.nz> References: <1028689992.3d50904895a77@hotlava.auckland.ac.nz> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Dear protocol advocates: -- Nevil Brownlee wrote on 07 August 2002 15:13 +1200: > Hello all: > > At the IPFIX meeting in Yokohama we reached consensus on the evaluation > process, with the following timetable: > > 5 July Publish Protocol Advocacy draft and Call for Submissions > > 15 July Work on consensus in Yokohama, agree on timetable > > 2 September Cutoff for Protocol Submissions to Evaluation Team > Advocacy drafts published Please do not miss the cutoff date for the protocol evaluation drafts on next Monday. 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 -- Help mailto:majordomo@net.doit.wisc.edu and say "help" 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 Aug 29 14:24:54 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05621 for ; Thu, 29 Aug 2002 14:24:54 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17kToz-0003Lc-00 for ipfix-list@mil.doit.wisc.edu; Thu, 29 Aug 2002 13:15:09 -0500 Received: from mgw-dax2.ext.nokia.com ([63.78.179.217]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17kTox-0003LV-00 for ipfix-eval@net.doit.wisc.edu; Thu, 29 Aug 2002 13:15:07 -0500 Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g7TIFKM26868 for ; Thu, 29 Aug 2002 13:15:20 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 29 Aug 2002 13:15:02 -0500 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 29 Aug 2002 13:13:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: reminder (was Re: [ipfix-eval] IPFIX Evaluation: update) Date: Thu, 29 Aug 2002 14:13:58 -0400 Message-ID: Thread-Topic: reminder (was Re: [ipfix-eval] IPFIX Evaluation: update) Thread-Index: AcJPfSQXxQH8rPr/SUOM6lbqUu2FbwACbuWA From: To: Cc: , X-OriginalArrivalTime: 29 Aug 2002 18:13:58.0990 (UTC) FILETIME=[D86B86E0:01C24F87] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA05621 Hello Juergen, The 2 September is cut-off date for "protocol submission" and not "protocol evaluation" document. Regards Ramg > -----Original Message----- > From: ext Juergen Quittek [mailto:quittek@ccrle.nec.de] > Sent: Thursday, August 29, 2002 12:50 PM > To: Nevil Brownlee; ipfix-eval@net.doit.wisc.edu > Subject: reminder (was Re: [ipfix-eval] IPFIX Evaluation: update) > > > Dear protocol advocates: > > -- Nevil Brownlee wrote on 07 August 2002 15:13 +1200: > > > Hello all: > > > > At the IPFIX meeting in Yokohama we reached consensus on > the evaluation > > process, with the following timetable: > > > > 5 July Publish Protocol Advocacy draft and Call > for Submissions > > > > 15 July Work on consensus in Yokohama, agree on timetable > > > > 2 September Cutoff for Protocol Submissions to Evaluation Team > > Advocacy drafts published > > Please do not miss the cutoff date for the protocol > evaluation drafts on next Monday. > > 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 > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" > 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 Aug 29 15:47:08 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08525 for ; Thu, 29 Aug 2002 15:47:08 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17kV5j-0005G2-00 for ipfix-list@mil.doit.wisc.edu; Thu, 29 Aug 2002 14:36:31 -0500 Received: from [64.95.122.60] (helo=RS-SC-EXC4.rs.riverstonenet.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17kV5h-0005Fm-00 for ipfix-req@net.doit.wisc.edu; Thu, 29 Aug 2002 14:36:30 -0500 Received: from riverstonenet.com ([134.141.180.76]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 29 Aug 2002 12:35:57 -0700 Message-ID: <3D6E7738.F8E9E429@riverstonenet.com> Date: Thu, 29 Aug 2002 15:34:16 -0400 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Benoit Claise CC: Juergen Quittek , req Subject: Re: overload behavior (was: Re: [ipfix-req] IPFIX Requirements Questions) References: <3D6CD65A.C52F4654@riverstonenet.com> <26869946.1030552789@[192.168.102.164]> <3D6DEF45.80700@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Aug 2002 19:35:57.0817 (UTC) FILETIME=[4C44F690:01C24F93] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Benoit Claise wrote: > > Paul, > > [let me take the latest email on this thread] > > > Hi Paul, > > > > --On 28 August 2002 09:55 -0400 calato@riverstonenet.com wrote: > > > >> Juergen Quittek wrote: > >> > >>> > >>> Hi Paul, > >>> > >>> --On 27 August 2002 20:26 -0400 calato@riverstonenet.com wrote: > >>> > >>> [...] > >>> > >>> >> > 5.3 Overload Behavior > >>> >> > > >>> >> > This section needs to be re-worked a little. Some > >>> >> > of the MUST's impose undue burden on the device. > >>> >> > > >>> >> > 1. Must distinguish flow records before and after the > >>> >> > behavior change. > >>> >> > > >>> >> > In the case where the behavior is to drop > >>> >> > overflow flows, why do we need to distinguish > >>> >> > flows. Perhaps I misunderstood something. > >> > An example (somehow already discussed below) is: > 1. you do sampling 1/100. > 2. for whatever reason, you drop overflow flows (or you decide to change > the sampling rate) > 3. the new sampling rate is now 1/200 > 4. the collector must know that. I agree with your example. However, I have a different example where it is not necessary. But, according to the document I MUST distinguish the flow records. The requirements go to far in mandating behavior for all overload solutions. I think Juergen agreed on this particular point. How to rectify it is still unclear. I chose one way and Juergen another. We still need further discussion. > > >>> > >>> >> > > >>> >> > > >>> >> > 2. All flows from previous behavior MUST be terminated. > >>> >> > > >>> >> > > >>> >> > Again, if I simply dropped excess flows why > >>> terminate > >>> >> > all existing ones. This will likely cause more > >>> overflow > >>> >> > as the get reestablished. This also seems to go to > >>> >> > far towards implementation. > >>> >> > >>> >> I agree. > >>> >> > >>> >> > 3. Meeting process MUST NOT merge previous records. > >>> >> > > >>> >> > > >>> >> > > >>> >> > I think what we are trying to say is flows with a > >>> different > >>> >> > definition MUST be distinguishable. How that is done is not > >>> >> > part of the requirements doc. > >> > Agreed. It was actually the goal of the sentence "the overload behavior > MUST be > clearly defined and the collecting process MUST be able to > distinguish the flow records exported before and after the metering > process behavior change" > Because, in my view, dropping the overflows flows is changing the > "definition" of the flow, as you wrote Paul wrote it in "flows with a > different definition MUST be distinguishable" Dropping is not a change for all flow definitions. In fact sampling is the only definition I can think of which is affected by dropping. > > >>> > >>> >> > >>> >> Also agreed. However, it is not just different definition, but also > >>> >> different measurement technique, different sampling rate, etc. > >>> >> > >>> >> We need to express this intended requirement it in a better way. > >>> > > >>> > Agreed. > >>> > > >>> > What this points out to me is that we do not have a term > >>> > that refers to the set of information that is the flow > >>> > definition. We touch on it in section 2.1 when discussing > >>> > the flow definition itself, in section 2.3 when discussing > >>> > classifying and then again in section 4 when discussing > >>> > distinguishing flows. > >>> > > >>> > What about a new term "Distinguishing Properties" or > >>> > "Flow Properties"? Its definition would be > >>> > > >>> > The set of fields, functions and parameters (e.g. > >>> sampling > >>> > rate) used to map packets to flows. > >>> > > >>> > Then we can say each flow MUST be able to be mapped to its > >>> > "Distinguishing properties". > >>> > > >>> > This would cover changing behavior due to overload, > >>> configuration > >>> > changes, etc... > >>> > > >>> > Thoughts? > >> > >>> > >>> > >>> I think the mistake in the current version of the text is that it > >>> asks on separating flows before and after the metering process was > >>> modified. It is indepenedent of whether the individual flows are > >>> affected or not. I think it is sufficient to fix this. > >> > >> > >> > >> You side stepped my main 2 issues here. > >> > >> 1. We need a definition for the set of functions, > >> fields and parameters use to map packets to flows. > >> If it is there and I missed it, let me know. > >> > >> 2. We need a requirement that allows the Collecting > >> device to map flows to the set of functions, > >> fields and parameters used to create the flow. > > > > > > My intention was not to side step them, but to answer on the portion > > of your comment on which I already made up my mind already. On this issue > > I still have to think some more. > > > >>> > >>> The current text is > >>> > >>> Overload behavior is not restricted to the four options listed > >>> above. > >>> But in case the overload behavior has an impact on the metering > >>> process or the exporting process, the overload behavior MUST be > >>> clearly defined and the collecting process MUST be able to > >>> distinguish the flow records exported before and after the metering > >>> process behavior change: in case of any change of the meter's > >>> behavior, all flow records metered by the previous behavior MUST be > >>> terminated and exported according to the configuration of the > >>> exporting process. The metering process MUST not merge the flow > >>> records generated with the new behavior with the flow records > >>> generated with the previous behavior. > >>> > >>> I suggest to replace it by > >>> > >>> Overload behavior is not restricted to the four options listed > >>> above. > >>> But in case the overload behavior induces a change of the > >>> behavior of > >>> metering process and/or the exporting process, the following > >>> requirements > >>> must be met for all flows affected by the change of behavior: > >>> - The overload behavior MUST be clearly defined. > >> > >> > >> Agreed. > >> > >>> - For each flows affected by the change, its record MUST be > >>> terminated > >>> at the time of change. > >> > >> > >> This seems like implementation detail. Maybe I want to leave > >> them in tact and when the overload situation is resolved I can > >> start adding to the counter again. > > > > > > I don't think this would be a good idea, because it might not be clear > > to the collector that you ignored all packets for some time. This seems > > to be a very unreliable behavior. > > Agreed with Juergen on that one. > In my example: > 1. you do sampling 1/100. > 2. for whatever reason, you drop overflow flows (or you decide to change > the sampling rate) > 3. the new sampling rate is now 1/200 > 4. the collector must know that. > > How would the collector be able to distinguish the 2 series of flow > records. If for example you want to multiply the first serie usage by > 100 and the second serie by 200? I agree sampling is a special case where the sampled pool is a piece of key information and thus can be considered part of the definition. In the example I gave suppose I switch to a coarse grained flow definition but there are still a few thousand of them. Then the overload situation is over and I go back to my fine grained definition. Overload happens again and now I have to set up all those flows again at the worst possible time. Paul > > Regards, Benoit. > > > > > > > However, you still might be right. Very often it is hard to distinguish > > between the real requirement and a particular implementation meeting > > that requirement. In this case I am not sure. > > > >>> - For each flow affected by the change, the collecting process > >>> MUST be > >>> able to determine whether the corresponding exported flow > >>> record was > >>> created before or after the change of behavior. > >> > >> > >> I believe that if we address the 2 issues discussed earlier > >> these would no longer be needed. > > > > > > Would be fine. > > > > Juergen > > > > > > -- > > Help mailto:majordomo@net.doit.wisc.edu and say "help" in > > message body > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > "unsubscribe ipfix" in message body > > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Aug 29 15:48:56 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08572 for ; Thu, 29 Aug 2002 15:48:56 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17kV8r-0005Ia-00 for ipfix-list@mil.doit.wisc.edu; Thu, 29 Aug 2002 14:39:45 -0500 Received: from [64.95.122.60] (helo=RS-SC-EXC4.rs.riverstonenet.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17kV8o-0005I4-00 for ipfix-req@net.doit.wisc.edu; Thu, 29 Aug 2002 14:39:42 -0500 Received: from riverstonenet.com ([134.141.180.76]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 29 Aug 2002 12:39:10 -0700 Message-ID: <3D6E77F9.FB5E16F9@riverstonenet.com> Date: Thu, 29 Aug 2002 15:37:29 -0400 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Benoit Claise CC: Juergen Quittek , req Subject: Re: fragmented packets (was: Re: [ipfix-req] IPFIX Requirements Questions) References: <3D6CCAE5.1BF2C42D@riverstonenet.com> <25723999.1030551643@[192.168.102.164]> <3D6DF431.60800@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Aug 2002 19:39:10.0899 (UTC) FILETIME=[BF5AF030:01C24F93] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Benoit Claise wrote: > > Paul and Juergen, > > > Hi Paul, > > > > --On 28 August 2002 09:06 -0400 calato@riverstonenet.com wrote: > > > >> Juergen Quittek wrote: > >> > >>> > >>> Hi Paul, > >>> > >>> --On 27 August 2002 20:26 -0400 calato@riverstonenet.com wrote: > >>> > >>> > Juergen Quittek wrote: > >>> >> > >>> >> --On 27 August 2002 14:49 -0400 calato@riverstonenet.com wrote: > >>> >> > >>> >> > > >>> >> > As I work on the advocates document some questions > >>> >> > have come to mind on the requirements document. > >>> >> > > >>> >> > 4.3 Distinguishing flows using Transport Header Fields > >>> >> > > >>> >> > In the case of fragmented packets there are > >>> >> > no port numbers. Are we saying flow state information > >>> >> > MUST be maintained? In general, it is not clear from > >>> >> > >>> >> No, the requirements document does not say so. > >>> >> > >>> >> > the document what the requirements are for fragmented > >>> >> > packets. > >>> >> > >>> >> I think the requirements should not include a requirement for > >>> >> keeping state of fragmented packets. Would you like to see > >>> >> an explicit statement on that? This would be a NO NEED FOR > >>> >> statement :-) > >>> > > >>> > I think we need to be explicit. Most people will think > >>> > of fragements as being counted in the same flow as the > >>> > first packet not as 2 differernt flows. > >>> > >>> I see. Waht about adding a new subsection to Section "5. Metering > >>> Process": > >>> > >>> 5.8. Packet Fragmentation > >>> > >>> In case of IP packet fragmentation, only one fragment of a single > >>> packet might contain sufficient information for classifying the > >>> packet correctly. The metering process MAY keep state of > >>> IP packet fragmentation in order to map fragments that do not > >>> contain sufficient header information correctly to flows. > >> > >> > >> How about a slight re-wording... > >> > >> In case of IP datagram fragmentation, only the first fragment might > >> contain sufficient information for classifying the packet correctly. > >> The metering process MAY keep state of IP fragmentation in order to > >> map fragments without sufficient header information to the same > >> flow as the first fragmented packet. > > > > > > Initially I also wanted to phrase like this. But it's IP. And fragments > > might get re-ordered. The first fragment of a packet that is observed, > > is not necessarily the fragment containing the TCP/UDP header. > > > > Now, if you say "first", it is not clear whether you mean the fragment > > with the first bytes of the IP payload or the first fragment observed > > at the observation point. Your last sentence seems to assume that the > > first observed packet is the one with the first bytes of the payload. > > Why not merge your 2 texts: > > In case of IP packet fragmentation, only one fragment of the initial > packet might contain sufficient information for classifying the > packet correctly. Note that this fragment is the first one generated > by the router imposing the fragmentation, but might not be the first > one observed by the IPFIX device, due reordering reasons. > The metering process MAY keep state of IP packet fragmentation > in order to map fragments that do not contain sufficient header > information correctly to flows. > Juergen suggested a merged text. Are you suggesting an alternative? > > > > > >>> [...] > >>> > >>> >> > 6.1 information Model > >>> >> > > >>> >> > 9 Packet Counter > >>> >> > 10 Byte counter > >>> >> > > >>> >> > As mentioned earlier, for fragments this > >>> >> > requires state information? If there is no > >>> >> > state info, then what flow are the counted > >>> >> > towards? > >>> >> > >>> >> Do you suggest to include a requirement for keeping fragment > >>> state info? > >>> > > >>> > > >>> > A MAY is as far as I would go. There may certainly be probes > >>> > that have this capability. We should have a requirement that > >>> > says fragment counting MUST be clearly defined. > >>> > >>> OK. Currently, we have > >>> > >>> 9. packet counter > >>> If a packet is fragmented, each fragment is counted as an > >>> individual packet. > >>> 10. byte counter > >>> Which bytes of a packet are counted MUST be defined exactly. > >>> > >>> What about appending > >>> > >>> The behavior of the byte counter in case of IP packet > >>> fragmentation MUST be clearly defined. > >> > >> > >> With the new section on fragmentation I think we can > >> eliminate any mention of it on the counters. > > > > > > The new section of the fragmentation is a MAY requirement. But for > > understamding the behavior of the byte counter you MUST know whether > > or not the option is implemented. > > So, haven't we enough with "The behavior of the byte and packet counters > in case of IP packet > fragmentation MUST be clearly defined."? > We need the packet counter in the sentence above: to know if the flow > state information is maintained for fragemented packets > > > > > > >>> ? > >>> > >>> Please note that we also have in the MAY attributes section > >>> > >>> 26. fragmented packet counter > >>> counter of all packets for which the fragmented bit is set in > >>> the IP header > >> > >> > >> I'm not sure why this was added. If you want that info, > >> make the IP fragment bit part of the flow definition. > > > It makes sense. > > Regards, Benoit > > >> > > > > Do you suggest to remove it? Anyone else? > > > > > > > Juergen > > > > > > > > -- > > Help mailto:majordomo@net.doit.wisc.edu and say "help" in > > message body > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > "unsubscribe ipfix" in message body > > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Aug 29 15:54:48 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08755 for ; Thu, 29 Aug 2002 15:54:47 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17kVEr-0005Wu-00 for ipfix-list@mil.doit.wisc.edu; Thu, 29 Aug 2002 14:45:57 -0500 Received: from [64.95.122.60] (helo=RS-SC-EXC4.rs.riverstonenet.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17kVEq-0005Vh-00 for ipfix-req@net.doit.wisc.edu; Thu, 29 Aug 2002 14:45:56 -0500 Received: from riverstonenet.com ([134.141.180.76]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 29 Aug 2002 12:45:24 -0700 Message-ID: <3D6E796C.8B1B0782@riverstonenet.com> Date: Thu, 29 Aug 2002 15:43:40 -0400 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Benoit Claise CC: Juergen Quittek , req Subject: Re: MPLS label (was:Re: [ipfix-req] IPFIX Requirements Questions) References: <3D6CCD9E.DFD45743@riverstonenet.com> <26292857.1030552212@[192.168.102.164]> <3D6CE39A.AFD0F9C5@riverstonenet.com> <3D6E012A.6010804@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Aug 2002 19:45:24.0922 (UTC) FILETIME=[9E4A51A0:01C24F94] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Benoit Claise wrote: > > Hi, > > >Juergen Quittek wrote: > > > > > >>Hi Paul, > >> > >>--On 28 August 2002 09:18 -0400 calato@riverstonenet.com wrote: > >> > >> > >> > >>>Juergen Quittek wrote: > >>> > >>> > >>>>Hi Paul, > >>>> > >>>>--On 27 August 2002 20:26 -0400 calato@riverstonenet.com wrote: > >>>> > >>>>[...] > >>>> > >>>> > >>>> > >>>>>>>4.4 MPLS Label > >>>>>>> > >>>>>>> In the case of dynamic LSP's the label is not useful. > >>>>>>> Why require distinguishing flows based on label. > >>>>>>> What can be done with that information? > >>>>>>> > >>>>>>> > >>>>>>Well, for each attribute there are situations where it does not make > >>>>>>sense to use it for distinguishing flows. But being able to distinguish > >>>>>>flows by label seems to be useful to me in general. > >>>>>> > >>>>>> > >>>>> Then why not include things like VPI/VCI for ATM > >>>>> or other L2.5 tunnels? Why does MPLS get special > >>>>> consideration? > >>>>> > >>>>> > >>>>In general I see your point, although MPLS appears to be closer > >>>>related to IP than plain ATM. > >>>> > >>>> > >>> Why? I can take and ATM PVC and use it as a tunnel for > >>> IP traffic just like MPLS. > >>> > >>> > >>Yes, but MPLS integrates with IP forwarcing when using CR-LDP > >>or RSVP-TE. Also you can use MPLS as "glue" between IP and ATM. > >> > >> > > > > I don't understand your argument here. Both technologies > > are viable solutions and exist in the market today. > > If one is included, so should the other. > > > > > > > >>>>> Also, I may be wrong here but I beleive the primary > >>>>> use of MPLS will be with dynamic LSP's so the label > >>>>> has little meaning the majority of time. At best > >>>>> it would be a MAY requirement, not a MUST. > >>>>> > >>>>> > >>>>For me, metering on a per-LSP basis is highly benefitial for the > >>>>operation of MPLS networks, even in the case of dynamic label > >>>>assignment. The LSR MIB already offers this kind of performance > >>>>information, but I think it also fits well into IPFIX. > >>>> > >>>> > >>> Are you talking about metering LSP's themselves or > >>> metering IP flows traveling through an LSP? > >>> > >>> > >>I'm talking about metering LSPs and about observing which flow maps > >>into which LSP. > >> > >> > > > > > > I'm a little confused. I thought we were only doing IP > > flows. Are we now including MPLS flows (LSPs)? > > > > > > > >>> Assuming you are talking about the latter, what can be done > >>> with the label information? If the flow F1 had label 57 > >>> and F2 had label 57 you don't even know if it is the > >>> same LSP. > >>> > >>> > >>You are right. I would also need interface information. > >> > >> > > > > OK. So now I have F1, I1 and L57 and then F2, I1 and L57. > > I still don't know if it is the same LSP. > > > > > > > >>>>> If we are going to go this way, which I am > >>>>> against, then we should also include FEC. At least > >>>>> that would be more meaningful information in the > >>>>> case of dynamic LSPs. > >>>>> > >>>>> > >>>>This could be useful, but the FEC is a higher level information > >>>>that is not available in many cases. Also we would need a good model > >>>>for FEC information. > >>>> > >>>> > >>> If the device knows the label it knows the FEC. There are > >>> some concrete FEC definitions now and we can always add more > >>> as they materialize. > >>> > >>> > >>All you need for an LSP are entries in insegment table, outsegment table > >>and switching table. How does the device know anything about the FEC if the > >>LSP was explicitly setup by a management system that added entries to these > >>tables. > >> > >> > > > > Let me make sure I understand. Some external management > > station received the FEC and programmed the device? If > > that is the case then you are correct. However, wont many > > deployments have the 2 functions on one device? If so, > > then reporting FEC is at least a MAY requirement. > > > I have to admit that I haven't been thinking too much in the draft about > MPLS. > I agree now that it makes more sense to report the FEC than the MPLS > label, since the label has got a local significance > > But this is not in contradiction with what is in the draft! I still don't understand how the label can be used. What about ATM-AAL5? > > 4.4. MPLS Label > > If the observation point is located at a device supporting > Multiprotocol Label Switching (MPLS, see [RFC3031]) then the metering > process MUST be able to separate flows by the MPLS label. > > And SHOU:LD report the FEC Did you mean "report" or "separate"? I think for it to be useful it must be able to separate flows by it. > > Regards, Benoit. > > > > > > > > >> Juergen > >> > >> > > > >-- > >Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > >Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > >"unsubscribe ipfix" in message body > >Archive http://ipfix.doit.wisc.edu/archive/ > > > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Aug 29 15:55:29 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08776 for ; Thu, 29 Aug 2002 15:55:28 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17kVEv-0005X8-00 for ipfix-list@mil.doit.wisc.edu; Thu, 29 Aug 2002 14:46:01 -0500 Received: from sj-msg-core-2.cisco.com ([171.69.24.11]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17kVEs-0005Vp-00 for ipfix-req@net.doit.wisc.edu; Thu, 29 Aug 2002 14:45:58 -0500 Received: from mira-sjcd-1.cisco.com (IDENT:mirapoint@mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g7TJjKds027694; Thu, 29 Aug 2002 12:45:20 -0700 (PDT) Received: from cisco.com (dhcp-171-71-137-31.cisco.com [171.71.137.31]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ADK37985; Thu, 29 Aug 2002 12:45:43 -0700 (PDT) Message-ID: <3D6E79CC.D9912474@cisco.com> Date: Thu, 29 Aug 2002 12:45:16 -0700 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: calato@riverstonenet.com, Benoit Claise , Juergen Quittek , Carter Bullard , ipfix-req@net.doit.wisc.edu Subject: Re: Reportin in and out interfaces (was: RE: [ipfix-req] Sectionregarding multicast flows) References: <37866058.1029783113@[192.168.102.164]> <6309182.1030108692@[192.168.102.164]> <3D6662D5.5060902@cisco.com> <3D666710.80820C87@riverstonenet.com> <3D6685DD.4526FC7F@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Ganesh Sadasivan wrote: > calato@riverstonenet.com wrote: > > > If I understand correctly, if the observation point > > is the output interface then reporting the input interface > > is optional. And the other way around. > > Agreed. > > > If I got the packet > > by some other means, then neither of them are part of the > > observation point and thus are optional. > > Can give an example for the case of "some other means"? > Ganesh Going by the definition of section 2.2 of requirement spec, a flow should necessarily be associated with an observation point. It could be as coarse as the device. Ganesh > > > > > > > > But this still seems a little odd. Here is the definition of > > SHOUD from RFC 2119 > > > > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there > > may exist valid reasons in particular circumstances to ignore a > > particular item, but the full implications must be understood and > > carefully weighed before choosing a different course. > > > > Reading that, it sound like input and output interfaces should > > be SHOULD since it is not an absolute requirement. > > > > Paul > > > > Benoit Claise wrote: > > > > > > Juergen, > > > > > > > Hi all, > > > > > > > > I have a new suggestion which might solve our reporting problem > > > > for input and output interfaces. > > > > > > > > What about keeping input interface and output interfaces in the > > > > MUST list of attributes that the exporter is capable of reporting > > > > but changing the restriction as follows? > > > > > > > > 7. input interface (ifIndex) > > > > This requirement does only apply to flows for which the > > > > input interface is included in the observation point. > > > > > > But, it will always be the case? > > > > > > 2.2. Observation Point > > > The observation point is a location in the network where IP packets > > > can be observed. Examples are a line to which a probe is attached, a > > > shared medium, such as an Ethernet-based LAN, a single port of a > > > router, or a set of interfaces (physical or logical) of a router. > > > > > > If the observation point is an port (interface), yes the input interface > > > is the observation point > > > If the observation point is a set of ports (interfaces), yes the input > > > interface is part of the observation point > > > If the observation point is a line card, yes ... > > > If the observation point is a router, yes... > > > > > > What do I miss? > > > > > > > > > > > 8. output interface (ifIndex) > > > > This requirement does only apply to flows for which the > > > > output interface is included in the observation point. > > > > > > How are you solving that way the following issue? > > > - multicast > > > - load balancing issue > > > - flap conditions > > > > > > You are only solving the issue of: > > > - the output interface belongs to another line card, and we don't know > > > (yet) what it is > > > - the output interface is mirrored port (and it doesn't make sense to > > > report it) > > > > > > Regards, Benoit. > > > > > > > > > > > > > > > > > > > Juergen > > > > > > > > > > > > --On 19 August 2002 18:51 +0200 Juergen Quittek > > > > wrote: > > > > > > > >> Hi all, > > > >> > > > >> The discussion on reporting output/egress interfaces now has > > > >> extended to reporting input/ingress interfaces for flows. > > > >> > > > >> Please note that the requirements document only talks about > > > >> the ability to report it, and not about necessarily reporting > > > >> them in each record. > > > >> > > > >> An argument for not having both as MUST is that in several current > > > >> router architectures, it would be a big and costly effort to support > > > >> both. Also our AD directed us to try to standardize "existing > > > >> practice" and not to require new router architectures for IPFIX. > > > >> > > > >> However, there is a clear need for accurate reporting of interfaces > > > >> on the user side (from which requirements are derived). Reporting > > > >> on the origin and destination of a packet apparently is very important > > > >> for many metering-based applications. > > > >> > > > >> The positions explicitly stated so far are (please correct me, > > > >> if I'm wrong): > > > >> > > > >> - Carter proposes having both of them OPTIONAL. > > > >> - Paul is fine with the current draft version: bost MUST in general, > > > >> but SHOULD for egress in case of multicast. > > > >> - Dave seems to have a similar opinion. > > > >> - Benoit, Tanja, Sebastian, and myself think that the input/ingress > > > >> interface is essential, but that for all output/egress interfaces > > > >> a SHOULD would also be sufficient. > > > >> > > > >> Are there further opinions? > > > >> > > > >> Juergen > > > >> > > > >> > > > >> --On 15 August 2002 20:40 -0400 Carter Bullard > > > >> wrote: > > > >> > > > >>> > > > >>> Gentle people, > > > >>> This is pretty long, I do hope that some find it useful. > > > >>> > > > >>> Carter > > > >>> > > > >>>> >> In cases where there are valid exceptions to a > > > >>>> >> requirement candidate, a MUST generally converts to > > > >>>> >> a SHOULD or OPTIONAL. One reason for this is > > > >>>> >> you don't want to have to identify and manage > > > >>>> >> the complete list of possible exceptions during the > > > >>>> >> life of the RFC. You already have exceptions for > > > >>>> >> certain types of IPFIX devices and specific types > > > >>>> >> of traffic that don't require egress interface > > > >>>> >> reporting. That on its own might suggest that > > > >>>> > > > >>>> I think there is only one exception like that in > > > >>>> section 6.1.-8. saying that a probe does not need > > > >>>> to have the ability of reporting the output interface. > > > >>>> Please note that the same exception holds for the > > > >>>> input interface. > > > >>> > > > >>> > > > >>> From the perspective of a monitor that is internal > > > >>> to a switch or a router, the input interface identifier > > > >>> is historical and factual. The output interface > > > >>> identifier is always a predicted value, and as a result, > > > >>> a guess. > > > >> > > > >> > > > >> As much a guess as packet and octet counters for outgoing > > > >> traffic in mib-II? > > > >> > > > >>>> >> egress interface reporting should be OPTIONAL > > > >>>> >> in the Data Model. But if that is not compelling, > > > >>>> >> we may need to add more exceptions to the list than > > > >>>> >> are already there. > > > >>>> > > > >>>> Since the exception is the same for input and output > > > >>>> interface, we would consequently have to make the input > > > >>>> interface OPTIONAL as well, if we follow your argument. > > > >>>> > > > >>>> >> I can think of a few more types of traffic where > > > >>>> >> egress interface reporting may be challenging, such as > > > >>>> >> flow reporting under flap conditions, load balanced > > > >>>> >> traffic > > > >>>> >> > > > >>>> > You have 2 good examples here. > > > >>>> > > > > >>>> > > > >>>> Flap conditions and load balancing affect the > > > >>>> input interface as well as the output interface. > > > >>>> > > > >>>> >> and port mirrored traffic. In switches, > > > >>>> > > > >>>> I do not see your point concerning port mirrored traffic. > > > >>> > > > >>> > > > >>> Port mirroring in modern switches is generally implemented > > > >>> in hardware in a half-duplex fashion. When an ingress > > > >>> stream of an interface is mirrored, generally, the packet is > > > >>> latched to the mirrored port, as it is being read, if, of > > > >>> course, the outgoing port can handle it. Some vendors > > > >>> do the same thing with egress port mirroring, hardware > > > >>> latching both interfaces as the packet is being serialized > > > >>> out of the box. There is no status indication available to > > > >>> indicate whether the mirror port actually received the packet, > > > >>> or whether the mirror interface is actually up. The point is > > > >>> that no monitor could 'realize' whether a particular packet was > > > >>> actually transmitted to a mirrored interface, given existing > > > >>> commercial vendor designs. I've seen customers use egress > > > >>> interface mirroring for fault tolerance, and for some > > > >>> of these, they would love for IPFIX to support "multiple egress > > > >>> interface flow accounting". I'm not sure that anyone will > > > >>> ever be able to implement what these words really mean, inside a > > > >>> switch. > > > >>> > > > >>>> > > > >>>> >> broadcast traffic generates the same problem set as multicast > > > >>>> >> traffic. Also many switches, when presented with some arp table > > > >>>> >> issues, will broadcast unicast datagrams to all interfaces. Should > > > >>>> >> the multiple egress interfaces be reported in this case? That > > > >>>> >> condition > > > >>>> > > > >>>> Yes, if I configured the metering process in this way, > > > >>>> I would expect this. However, it might not be a good idea > > > >>>> to configure it this way. > > > >>> > > > >>> > > > >>> Well this is the nature of datagram flows in modern switches. > > > >>> If you are attempting to state what a flow monitor must do in > > > >>> order to do a decent job, and you decide that egress interface > > > >>> reporting is going to be a part of that, then you should take > > > >>> into consideration the normal modes of operation of a modern > > > >>> switch/router and correctly deal with those conditions. It > > > >>> is not a choice of configuration. > > > >> > > > >> > > > >> Well, it is. If I do egress interface reporting, I have the > > > >> choice of montoring IP only or monitoring both, IP and ARP. > > > >> > > > >>>> >> would persist, ideally, for only a few packets. Do > > > >>>> >> you generate multiple flow reports, one for the > > > >>>> >> broadcasted set of packets, and then one for the non broadcasted > > > >>>> >> flow? > > > >>>> > > > >>>> Same answer. > > > >>>> > > > >>>> > Well, for switches (layer 2 devices) I think that we > > > >>>> shouldn't report > > > >>>> > any flow records. Only the layer 3 devices should. > > > >>>> > > > > >>>> >> > > > >>>> >> One issue that comes up when considering multicast > > > >>>> >> egress interface reporting is that in most vendors > > > >>>> >> multicast implementations the multicast traffic is > > > >>>> >> delivered to every egress interface through hardware > > > >>>> broadcast, and > > > >>>> >> then output filters decide whether to forward the packet > > > >>>> or not. How > > > >>>> >> does this generalize in the IPFIX egress interface reporting > > > >>>> >> strategy? > > > >>>> > > > >>>> Wouldn'n these filters be a great location for collecting > > > >>>> multicast flow information? They anyway maintain a list of > > > >>>> multicast flows. The requirements suggest to collect > > > >>>> multicast information saparately for each egress. (And it > > > >>>> uses only SHOULD, not MUST for multicast traffic.) > > > >>> > > > >>> > > > >>> There is one very fundamental issue here. While the example > > > >>> used multicast traffic, the real issue is that switch vendors > > > >>> provide egress interface filtering for all network traffic. > > > >>> > > > >>> Is it better to report that a packet was intended for a > > > >>> particular interface, whether it was transmitted or not? > > > >>> Or is it better if the IPFIX monitor is implemented after > > > >>> all the filters and shapers, such that it doesn't see > > > >>> all the traffic that the router is dealing with? > > > >>> > > > >>> VLANs are almost universally enforced using egress > > > >>> interface filtering and there are many conditions where > > > >>> a switch will forward a packet to an interface that doesn't > > > >>> support a given VLAN, but it filters the packet, doing the > > > >>> right thing. Should IPFIX report that the box forwarded > > > >>> the flow to the interface, unaware that the packets will > > > >>> be filtered? Yes that seems reasonable, but you shouldn't > > > >>> use that record for accounting, because the device didn't > > > >>> really dispose of the packet in this simple fashion. > > > >>> > > > >>>> > > > >>>> >> Does the IPFIX Data Model need to understand egress interface > > > >>>> >> filtering behavior for all traffic types or just multicast? > > > >>>> > > > >>>> This heavily depends on the list of traffic types for > > > >>>> which egress filtring is used. I guess you don't use it > > > >>>> for TCP. > > > >>> > > > >>> > > > >>> Most vendors support filtering for specific TCP flags, > > > >>> say SYN packets, in their Access Control Lists > > > >>> and these are almost always implemented as a egress interface > > > >>> filter. > > > >>> > > > >>>> > > > >>>> >> It may be easier to just make egress interface > > > >>>> >> reporting an OPTIONAL feature, and then see if > > > >>>> >> any vendors can successfully implement it. > > > >>>> > > > >>>> This holds for most of the requirements. > > > >>>> But following your arguments: The multicast case > > > >>>> is not OPTIONAL, but SHOULD in the current reuqirements. > > > >>>> So, if a vendor faces serious problems implementing it, > > > >>>> the vendor will drop it. Here we have already what you > > > >>>> are asking for. > > > >>> > > > >>> > > > >>> I believe that reporting any interface, whether ingress > > > >>> or egress, should be OPTIONAL. > > > >>> > > > >>>> > > > >>>> All other arguments apply as well to the input interface. > > > >>>> But you ar not proposing to make this OPTIONAL. > > > >>>> > > > >>>> I think one important point behind your arguments is > > > >>>> that from a router architecture point of view, the most > > > >>>> obvious pace to locate the observation point and the metering > > > >>>> process is at the input interface, because similar > > > >>>> funtionality is required at this location anyway. But when > > > >>>> doing so it is not always easy to find otu the output interface. > > > >>>> > > > >>>> If a vendor locates the observation points at the output > > > >>>> interface (what I do not necessarily expect), then it might > > > >>>> face the inverse problem of not necessarily knowing the input > > > >>>> interface. > > > >>> > > > >>> > > > >>> If the IPFIX device is monitoring at the egress interface, > > > >>> then why put the egress id in every record. It won't change > > > >> > > > >> > > > >> The requirements is not at all about putting something in > > > >> every packet, it is just about reporting. If the exporting > > > >> process is able to report once, that all reported flows share > > > >> the same output interface, then the requirement is already met. > > > >> > > > >>> during the life of the monitor. Since you may not be sure > > > >>> of the input interface of any packet at the egress interface, > > > >>> why require that it be reported for any traffic? > > > >>> > > > >>>> > > > >>>> Like Benoit below, I also would like to have more opinions > > > >>>> on the issue how far the clearly existing requirements by > > > >>>> metering applications should be loosened in the IPFIX > > > >>>> requirements document because of assumed limitations of > > > >>>> today's router architecture? > > > >>>> > > > >>>> Juergen > > > >>>> > > > >>>> >> > > > >>>> > You've got a valid point.Why not a SHOULD? > > > >>>> > > > > >>>> > SHOULD This word, or the adjective "RECOMMENDED", > > > >>>> mean that there > > > >>>> > may exist valid reasons in particular circumstances > > > >>>> to ignore a > > > >>>> > particular item, but the full implications must be > > > >>>> understood and > > > >>>> > carefully weighed before choosing a different course. > > > >>>> > > > > >>>> > Any other opinion? > > > >>>> > > > > >>>> > Regards, Benoit. > > > >>>> > > > > >>>> >> > > > >>>> >> > > > >>>> >> Carter > > > >>>> >> > > > >>>> >> Carter Bullard > > > >>>> >> QoSient, LLC > > > >>>> >> 300 E. 56th Street > > > >>>> >> Suite 18K > > > >>>> >> New York, New York 10022 > > > >>>> >> > > > >>>> >> +1 212 588-9133 Phone > > > >>>> >> +1 212 588-9134 Fax > > > >>>> >> > > > >>>> >> > > > >>>> >> > > > >>>> >>> -----Original Message----- > > > >>>> >>> From: majordomo listserver > > > >>>> [mailto:majordomo@mil.doit.wisc.edu] On > > > >>>> >>> Behalf Of Benoit Claise > > > >>>> >>> Sent: Friday, July 26, 2002 4:21 AM > > > >>>> >>> To: ipfix-req@net.doit.wisc.edu > > > >>>> >>> Subject: [ipfix-req] Section regarding multicast flows > > > >>>> >>> > > > >>>> >>> > > > >>>> >>> > > > >>>> >>> > > > >>>> >>> Dave and All, > > > >>>> >>> > > > >>>> >>> Trying to incorporate all the proposed changes discussed > > > >>>> both at the > > > >>>> >>> IETF meeting and on the mailing list in the new requirement draft > > > >>>> >>> version, I think that we should add a new section on multicast > > > >>>> >>> > > > >>>> >>> 5.7 Multicast Flows > > > >>>> >>> > > > >>>> >>> For a multicast packet replicated to multiple output > > > >>>> interfaces, the > > > >>>> >>> metering process SHOULD maintain discrete flow records > > > >>>> per different > > > >>>> >>> egress ifIndexes. For example an incoming multicast packet > > > >>>> >>> that is replicated to four output interfaces would be > > > >>>> >>> reported in four different flow records that differ by the > > > >>>> >>> output interface. In case the metering process doesn't > > > >>>> >>> maintain and report discrete flow records > > > >>>> >>> per different egress ifIndexes for a multicast flow, the > > > >>>> >>> metering process > > > >>>> >>> SHOULD export the multicast replication factor in the flow record. > > > >>>> >>> > > > >>>> >>> > > > >>>> >>> Furthermore, some extra changes are needed > > > >>>> >>> The requirement draft was saying: > > > >>>> >>> > > > >>>> >>> 6.1. Information Model > > > >>>> >>> ... > > > >>>> >>> The exporting process MUST be able to report the following > > > >>>> >>> attributes > > > >>>> >>> for each measured flow: > > > >>>> >>> ... > > > >>>> >>> 8. output interface (ifIndex) > > > >>>> >>> This requirement does not apply if the observation point is > > > >>>> >>> located at a probe device. This requirement does not apply > > > >>>> >>> in case of multicast flow records. > > > >>>> >>> ... > > > >>>> >>> The exporting process MAY be able to report the following > > > >>>> >>> attributes > > > >>>> >>> for each measured flow: > > > >>>> >>> ... > > > >>>> >>> 25. multicast replication factor > > > >>>> >>> the number of outgoing packets originating from a single > > > >>>> >>> incoming multicast packet > > > >>>> >>> > > > >>>> >>> 26. list of output interfaces for a multicast flow > > > >>>> >>> > > > >>>> >>> > > > >>>> >>> I would propose: > > > >>>> >>> > > > >>>> >>> 6.1. Information Model > > > >>>> >>> ... > > > >>>> >>> The exporting process MUST be able to report the following > > > >>>> >>> attributes > > > >>>> >>> for each measured flow: > > > >>>> >>> ... > > > >>>> >>> 8. output interface (ifIndex) > > > >>>> >>> This requirement does not apply if the observation point is > > > >>>> >>> located at a probe device. _(ATTENTION: I REMOVED THE > > > >>>> LINE ABOUT > > > >>>> >>> MULTICAST)_ > > > >>>> >>> ... > > > >>>> >>> The exporting process _SHOULD_ be able to report the following > > > >>>> >>> attributes > > > >>>> >>> for each measured flow: > > > >>>> >>> ... > > > >>>> >>> X. multicast replication factor > > > >>>> >>> The number of outgoing packets originating from a single > > > >>>> >>> incoming multicast packet. This _multicast_ replication factor > > > >>>> >>> SHOULD be reported, > > > >>>> >>> but only SHOULD if the list of output interfaces for this > > > >>>> >>> multicast > > > >>>> >>> flow is not reported. > > > >>>> >>> > > > >>>> >>> _X+1. list of output interfaces for a multicast flow _(I WOULD > > > >>>> >>> REMOVE IT > > > >>>> >>> BECAUSE THIS IS EXPLAINED IN THE MULTICAST FLOW > > > >>>> SECTION AND THE > > > >>>> >>> LIMITATION > > > >>>> >>> IN THE OUTPUT INTERFACE SECTION ABOVE IS REMOVED) > > > >>>> >>> > > > >>>> >>> > > > >>>> >>> What do you think? > > > >>>> >>> > > > >>>> >>> Regards, Benoit > > > >>>> >>> > > > >>>> >>> > > > >>>> >>> > > > >>>> >>> > > > >>>> >>> -- > > > >>>> >>> Help mailto:majordomo@net.doit.wisc.edu and say "help" > > > >>>> >>> in message body > > > >>>> >>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > > >>>> "unsubscribe > > > >>>> >>> ipfix" in message body > > > >>>> >>> Archive http://ipfix.doit.wisc.edu/archive/ > > > >>>> >>> > > > >>>> >>> > > > >>>> >>> > > > >>>> >>> > > > >>>> >> > > > >>>> >> > > > >>>> >> > > > >>>> >> -- > > > >>>> >> Help mailto:majordomo@net.doit.wisc.edu and say > > > >>>> "help" in message body > > > >>>> >> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > > >>>> "unsubscribe > > > >>>> >> ipfix" in message body > > > >>>> >> Archive http://ipfix.doit.wisc.edu/archive/ > > > >>>> >> > > > >>>> >> > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> > -- > > > >>>> > Help mailto:majordomo@net.doit.wisc.edu and say > > > >>>> "help" in message body > > > >>>> > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe > > > >>>> > ipfix" in message body > > > >>>> > Archive http://ipfix.doit.wisc.edu/archive/ > > > >>>> > > > >>>> > > > >>>> > > > >>>> -- > > > >>>> Help mailto:majordomo@net.doit.wisc.edu and say "help" > > > >>>> in message body > > > >>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > > >>>> "unsubscribe ipfix" in message body > > > >>>> Archive http://ipfix.doit.wisc.edu/archive/ > > > >>>> > > > >>>> > > > >>> > > > >>> > > > >> > > > >> > > > >> > > > >> -- > > > >> Help mailto:majordomo@net.doit.wisc.edu and say "help" in > > > >> message body > > > >> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > > >> "unsubscribe ipfix" in message body > > > >> Archive http://ipfix.doit.wisc.edu/archive/ > > > > > > > > > > > > > > -- > > > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > > "unsubscribe ipfix" in message body > > > Archive http://ipfix.doit.wisc.edu/archive/ > > > > -- > > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > "unsubscribe ipfix" in message body > > Archive http://ipfix.doit.wisc.edu/archive/ > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Aug 29 16:03:27 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09131 for ; Thu, 29 Aug 2002 16:03:27 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17kVMS-0005kI-00 for ipfix-list@mil.doit.wisc.edu; Thu, 29 Aug 2002 14:53:48 -0500 Received: from [64.95.122.60] (helo=RS-SC-EXC4.rs.riverstonenet.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17kVMO-0005ja-00 for ipfix-req@net.doit.wisc.edu; Thu, 29 Aug 2002 14:53:44 -0500 Received: from riverstonenet.com ([134.141.180.76]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 29 Aug 2002 12:53:12 -0700 Message-ID: <3D6E7B3F.6EF78048@riverstonenet.com> Date: Thu, 29 Aug 2002 15:51:27 -0400 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Benoit Claise CC: Juergen Quittek , req Subject: Re: MPLS label (was:Re: [ipfix-req] IPFIX Requirements Questions) References: <3D6E012A.6010804@cisco.com> <34028240.1030638935@[192.168.102.164]> <3D6E3B5C.90404@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Aug 2002 19:53:12.0743 (UTC) FILETIME=[B5222370:01C24F95] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Benoit Claise wrote: > > Juergen Quittek wrote: > > > Hi Benoit, > > > > -- Benoit Claise wrote on 29 August 2002 13:10 +0200: > > > >> Hi, > >> > >>> Juergen Quittek wrote: > >>> > >>> > >>>> Hi Paul, > >>>> > >>>> --On 28 August 2002 09:18 -0400 calato@riverstonenet.com wrote: > >>>> > >>>> > >>>> > >>>>> Juergen Quittek wrote: > >>>>> > >>>>> > >>>>>> Hi Paul, > >>>>>> > >>>>>> --On 27 August 2002 20:26 -0400 calato@riverstonenet.com wrote: > >>>>>> > >>>>>> [...] > >>>>>> > >>>>>> > >>>>>> > >>>>>>>>> 4.4 MPLS Label > >>>>>>>>> > >>>>>>>>> In the case of dynamic LSP's the label is not useful. > >>>>>>>>> Why require distinguishing flows based on label. > >>>>>>>>> What can be done with that information? > >>>>>>>>> > >>>>>>>>> > >>>>>>>> Well, for each attribute there are situations where it does not > >>>>>>>> make > >>>>>>>> sense to use it for distinguishing flows. But being able to > >>>>>>>> distinguish > >>>>>>>> flows by label seems to be useful to me in general. > >>>>>>>> > >>>>>>>> > >>>>>>> Then why not include things like VPI/VCI for ATM > >>>>>>> or other L2.5 tunnels? Why does MPLS get special > >>>>>>> consideration? > >>>>>>> > >>>>>>> > >>>>>> In general I see your point, although MPLS appears to be closer > >>>>>> related to IP than plain ATM. > >>>>>> > >>>>>> > >>>>> Why? I can take and ATM PVC and use it as a tunnel for > >>>>> IP traffic just like MPLS. > >>>>> > >>>>> > >>>> Yes, but MPLS integrates with IP forwarcing when using CR-LDP > >>>> or RSVP-TE. Also you can use MPLS as "glue" between IP and ATM. > >>>> > >>>> > >>> > >>> I don't understand your argument here. Both technologies > >>> are viable solutions and exist in the market today. > >>> If one is included, so should the other. > >>> > >>> > >>> > >>>>>>> Also, I may be wrong here but I beleive the primary > >>>>>>> use of MPLS will be with dynamic LSP's so the label > >>>>>>> has little meaning the majority of time. At best > >>>>>>> it would be a MAY requirement, not a MUST. > >>>>>>> > >>>>>>> > >>>>>> For me, metering on a per-LSP basis is highly benefitial for the > >>>>>> operation of MPLS networks, even in the case of dynamic label > >>>>>> assignment. The LSR MIB already offers this kind of performance > >>>>>> information, but I think it also fits well into IPFIX. > >>>>>> > >>>>>> > >>>>> Are you talking about metering LSP's themselves or > >>>>> metering IP flows traveling through an LSP? > >>>>> > >>>>> > >>>> I'm talking about metering LSPs and about observing which flow maps > >>>> into which LSP. > >>>> > >>>> > >>> > >>> > >>> I'm a little confused. I thought we were only doing IP > >>> flows. Are we now including MPLS flows (LSPs)? > >>> > >>> > >>> > >>>>> Assuming you are talking about the latter, what can be done > >>>>> with the label information? If the flow F1 had label 57 > >>>>> and F2 had label 57 you don't even know if it is the > >>>>> same LSP. > >>>>> > >>>>> > >>>> You are right. I would also need interface information. > >>>> > >>>> > >>> > >>> OK. So now I have F1, I1 and L57 and then F2, I1 and L57. > >>> I still don't know if it is the same LSP. > >>> > >>> > >>> > >>>>>>> If we are going to go this way, which I am > >>>>>>> against, then we should also include FEC. At least > >>>>>>> that would be more meaningful information in the > >>>>>>> case of dynamic LSPs. > >>>>>>> > >>>>>>> > >>>>>> This could be useful, but the FEC is a higher level information > >>>>>> that is not available in many cases. Also we would need a good model > >>>>>> for FEC information. > >>>>>> > >>>>>> > >>>>> If the device knows the label it knows the FEC. There are > >>>>> some concrete FEC definitions now and we can always add more > >>>>> as they materialize. > >>>>> > >>>>> > >>>> All you need for an LSP are entries in insegment table, outsegment > >>>> table > >>>> and switching table. How does the device know anything about the > >>>> FEC if the > >>>> LSP was explicitly setup by a management system that added entries > >>>> to these > >>>> tables. > >>>> > >>>> > >>> > >>> Let me make sure I understand. Some external management > >>> station received the FEC and programmed the device? If > >>> that is the case then you are correct. However, wont many > >>> deployments have the 2 functions on one device? If so, > >>> then reporting FEC is at least a MAY requirement. > >>> > >> I have to admit that I haven't been thinking too much in the draft > >> about MPLS. > >> I agree now that it makes more sense to report the FEC than the MPLS > >> label, since the label has got a local significance > >> > >> But this is not in contradiction with what is in the draft! > >> > >> 4.4. MPLS Label > >> > >> If the observation point is located at a device supporting > >> Multiprotocol Label Switching (MPLS, see [RFC3031]) then the metering > >> process MUST be able to separate flows by the MPLS label. > >> > >> And SHOU:LD report the FEC > > > > > > Here in Section 4 we are talking about separating flows. > > Do we want to separate flows by the FEC also? > > As there is a matching Label -> FEC, we can still separate by Label I thought there could be multiple FEC's per label. > > > > > Or are you suggesting to add the FEC to the list of SHOULD > > attributes in Section 6.1? > > And yes: SHOULD report the FEC in Section 6.1 > > Regards, Benoit. > > > > > > > Juergen > > > >> > >> Regards, Benoit. > >> > >>> > >>> > >>> > >>>> Juergen > >>>> > >>>> > >>> > >>> -- > >>> Help mailto:majordomo@net.doit.wisc.edu and say "help" in > >>> message body > >>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > >>> "unsubscribe ipfix" in message body > >>> Archive http://ipfix.doit.wisc.edu/archive/ > >>> > >>> > >> > >> > >> > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Aug 29 16:03:48 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09154 for ; Thu, 29 Aug 2002 16:03:48 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17kVKR-0005gP-00 for ipfix-list@mil.doit.wisc.edu; Thu, 29 Aug 2002 14:51:43 -0500 Received: from [64.95.122.60] (helo=RS-SC-EXC4.rs.riverstonenet.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17kVKO-0005f9-00 for ipfix-req@net.doit.wisc.edu; Thu, 29 Aug 2002 14:51:40 -0500 Received: from riverstonenet.com ([134.141.180.76]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 29 Aug 2002 12:51:08 -0700 Message-ID: <3D6E7AC6.2EF85E5F@riverstonenet.com> Date: Thu, 29 Aug 2002 15:49:26 -0400 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Benoit Claise CC: Sebastian Zander , Juergen Quittek , req Subject: Re: [ipfix-req] IPFIX Requirements Questions (timestamps) References: <3D6BC9AD.CAC153C8@riverstonenet.com> <42174623.1030483746@[192.168.102.164]> <3D6C18A3.764A46B9@riverstonenet.com> <3D6CA423.3020900@fokus.gmd.de> <3D6CD222.CAC66D82@riverstonenet.com> <3D6E2E64.7060902@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Aug 2002 19:51:08.0741 (UTC) FILETIME=[6B38EF50:01C24F95] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Benoit Claise wrote: > > All, > > [taking the latest email on this thread ... hopefully because there are > so many emails] > > >>>>>5.4 Timestamps > >>>>> > >>>>> Time stamps to not always mapped to the first packet and last > >>>>> packet. In many cases, the end timestamp is merely when > >>>>> the flow timed out and has nothing to do with when the > >>>>> last packet was seen. Allowing both semantics may be useful. > >>>>> A re-wording like this... > >>>>> > >>>>> > >>>>> The metering process MUST be able to generate timestamps for the > >>>>> start and end of a flow. The metering process MAY also provide > >>>>> timestamps for the first and the last observed packet > >>>>> of a flow. The timestamp resolution MUST be at least the one of > >>>>> the sysUpTime [RFC1213], which is one centisecond. > >>>>> > >>>>> Note - this does not mandate 2 timestamp fields for a flow. You > >>>>> could have one element for each meaning (e.g. Flow-start-time, > >>>>> first-packet-time, flow-start-and-first-packet-time) and use > >>>>> the one with the desired meaning. > >>>>> > >>>>> > >>>>> > >>>>You just added a MAY requirement for the timeout timestamp. We can do this, > >>>>but everything you mention was already possible without this additional > >>>>requirement. It was just required that the metering process can provide > >>>>these timestamps (if configured so). Whether or not they are exported > >>>>and whether or not other timestamps are exported was already left open > >>>>by the requirements. > >>>> > >>>> > >>>> > >>> I disagree. I'm not talking about what is exported, I talking > >>> about semantics. The req doc currently ties the timestamp event > >>> to packet observation. All metering processes will know > >>> when they created and deleted a flow. They may or may not > >>> know when the first or last packet was observed. > >>> > >>> The typical example of this is last packet. In many platforms > >>> the first packet is processed by the CPU and creates a hardware entry. > >>> The rest of the packets are processed and counted in hardware > >>> and thus there is no timestamp available, just a count. All > >>> that is known is when the flow was artifically timed out. > >>> > The timestamp of the last packet observed is what we need for accounting > and not when the flow expires from the cache. > In our implementation, we create the timestamp of the last packet > observed in the flow. We do this in hardware and obvioulsy in software > on the smaller platforms. The hardware timestamps every packet? In any case, I'm not saying it is one or the other. I'm saying we need to provide both definitions. Not all platforms will timestamp every packet. The timeout time is still useful. If the timeout period is say 10 seconds you know the last packet time within 10 seconds. Paul > > Regards, Benoit. > > >>> > >>> A weaker argument can be made for first packet observed. There > >>> may be a known significant delay from packet observation to timestamp. > >>> In this case the metering process can report the time at which it > >>> created the flow but not first packet time. Weak I know. > >>> > >>> > >>I agree that we have to look at current practice but I have the feeling that > >>we get more and more vague just to support any existing thing. The requirements > >>are driven by applications. Lets look at accounting. I am wondering how IPFIX > >>information can be used for accounting when > >> > >>- there are no correct stop timestamps (there are no requirements on > >> the flow timeout) > >> > >> > > > > I don't think that is the case. If you report a flow end > > and the flow timeout period is 10 seconds, that will be > > close enough for most applications, even accounting. > > > > > > > >>- there are no requirements on the report time (when are reports send) > >> (e.g. it is not required to export information at/after flow end) > >> > >> > > > > Good point. Maybe we need some text on report time. > > > > The exporting process MUST be able to report on flow > > start and end within a configurable time limit. > > > > > > > > > >>- there is no timestamp required in interim flow records > >> > >> > > > > I'm not sure I follow here. There is a SHOULD requirement > > for regular reporting. > > > > > > > >>- byte counters may not be correct (in case of port filtering and fragmentation) > >> > >>Well forget about the last one but with the first three we basically do not > >>comply to the req of the AAA WG for accounting. > >> > >>If the MUST requirement of the current draft is a problem for a lot of current > >>hardware then at least the requirement should be reduced to a SHOULD and not > >>a MAY. > >> > >> > > > > In this particular case I believe the definition is the > > problem, not the current hardware. I can't imagine any > > hardware ever timestamping every packet. > > > > > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" 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 Aug 29 16:07:39 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09283 for ; Thu, 29 Aug 2002 16:07:39 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17kVOJ-0005nz-00 for ipfix-list@mil.doit.wisc.edu; Thu, 29 Aug 2002 14:55:43 -0500 Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17kVOG-0005mq-00 for ipfix-req@net.doit.wisc.edu; Thu, 29 Aug 2002 14:55:40 -0500 Received: from mira-sjcd-1.cisco.com (IDENT:mirapoint@mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g7TJt3KD014705; Thu, 29 Aug 2002 12:55:03 -0700 (PDT) Received: from cisco.com (dhcp-171-71-137-31.cisco.com [171.71.137.31]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ADK38360; Thu, 29 Aug 2002 12:55:31 -0700 (PDT) Message-ID: <3D6E7C16.FCB32F97@cisco.com> Date: Thu, 29 Aug 2002 12:55:03 -0700 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: Juergen Quittek CC: calato@riverstonenet.com, req Subject: Re: [ipfix-req] IPFIX Requirements Questions References: <3D6BC9AD.CAC153C8@riverstonenet.com> <42174623.1030483746@[192.168.102.164]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Juergen Quittek wrote: > --On 27 August 2002 14:49 -0400 calato@riverstonenet.com wrote: > > > > > As I work on the advocates document some questions > > have come to mind on the requirements document. > > > > 4.3 Distinguishing flows using Transport Header Fields > > > > In the case of fragmented packets there are > > no port numbers. Are we saying flow state information > > MUST be maintained? In general, it is not clear from > > No, the requirements document does not say so. > > > the document what the requirements are for fragmented > > packets. > > I think the requirements should not include a requirement for > keeping state of fragmented packets. Would you like to see > an explicit statement on that? This would be a NO NEED FOR > statement :-) > > > 4.4 MPLS Label > > > > In the case of dynamic LSP's the label is not useful. > > Why require distinguishing flows based on label. > > What can be done with that information? > > Well, for each attribute there are situations where it does not make > sense to use it for distinguishing flows. But being able to distinguish > flows by label seems to be useful to me in general. I agree especially if label to prefix mapping can be provided by some out-of-scope means -:) > > > > 5.3 Overload Behavior > > > > This section needs to be re-worked a little. Some > > of the MUST's impose undue burden on the device. > > > > 1. Must distinguish flow records before and after the > > behavior change. > > > > In the case where the behavior is to drop > > overflow flows, why do we need to distinguish > > flows. Perhaps I misunderstood something. > > > > > > 2. All flows from previous behavior MUST be terminated. > > > > > > Again, if I simply dropped excess flows why terminate > > all existing ones. This will likely cause more overflow > > as the get reestablished. This also seems to go to > > far towards implementation. > > I agree. It may be a good idea : * as a basic operation indicate this condition to the collector. * if there is a per flow/per observation point action taken like change of sampling rate, then it make sens to terminate & recreate the flows. But I am not comfortable with a MUST here. > > > > 3. Meeting process MUST NOT merge previous records. > > > > > > > > I think what we are trying to say is flows with a different > > definition MUST be distinguishable. How that is done is not > > part of the requirements doc. > > Also agreed. However, it is not just different definition, but also > different measurement technique, different sampling rate, etc. > > We need to express this intended requirement it in a better way. > > > 5.4 Timestamps > > > > Time stamps to not always mapped to the first packet and last > > packet. In many cases, the end timestamp is merely when > > the flow timed out and has nothing to do with when the > > last packet was seen. Allowing both semantics may be useful. > > A re-wording like this... > > > > > > The metering process MUST be able to generate timestamps for the > > start and end of a flow. The metering process MAY also provide > > timestamps for the first and the last observed packet > > of a flow. The timestamp resolution MUST be at least the one of > > the sysUpTime [RFC1213], which is one centisecond. > > > > Note - this does not mandate 2 timestamp fields for a flow. You > > could have one element for each meaning (e.g. Flow-start-time, > > first-packet-time, flow-start-and-first-packet-time) and use > > the one with the desired meaning. > > You just added a MAY requirement for the timeout timestamp. We can do this, > but everything you mention was already possible without this additional > requirement. It was just required that the metering process can provide > these timestamps (if configured so). Whether or not they are exported > and whether or not other timestamps are exported was already left open > by the requirements. > > > 6.1 information Model > > > > 9 Packet Counter > > 10 Byte counter > > > > As mentioned earlier, for fragments this > > requires state information? If there is no > > state info, then what flow are the counted > > towards? > > Do you suggest to include a requirement for keeping fragment state info? I guess this is a a requirement quite difficult to meet ubiquitously. Thanks Ganesh > > > > 13 BGP AS number > > > > Is this the AS number for the observation point, the > > source/destination address in the packet or some > > combination? > > This is already revised in the upcoming version. This MUST requirement > is removed and replaced by a MAY requirement on source address AS#, > destination address AS#, and next hop AS#. > > > 14. MPLS Label > > > > As stated earlier, in the case of dynamic LSP's the > > label has no meaning. > > Yes, but here the general ability of reporting it is required. > > > 21 multicast replication number > > > > The document stated this can change over the life > > of the flow. But no mention of what happens when > > it changes. Is that a new flow? If not, what meaning > > does it have when reported? What can I do with it? > > Whether or not it is a new flow when the factor changes depends on the > used flow definition. In the revision we added a phrase that computation > of the factor must be clearly define (factor of last observed packet, > mean value, ...). However, from the applications we could not derive a > clear preference for one or the other definition. Therefore, the precise > definiton is left to the concrete protocol. > > > 6.2 Data Model > > > > What about allowing Vendors to add information independently? > > Some data to be transported may be vendor specific and never > > make it into the IPFIX spec. > > I don't see how the requirements forbid this. > > > 8.3 Several Collecting Processes > > > > No mention is made when reporting to several devices > > of ensuring the duplicate data does not cause a double > > counting problem. > > We discussed this issue, but did not find a clear requirement for > avoiding this or for providing means for avoiding this. One problem > is that the collecting process is completely out of scope. > Do you have an idea? > > > 9. Special Device Considerations > > > > I'm not sure of the meaning for the following... > > > > ... > > > > Please note that here, the observation > > point of a single flow cannot exceed the set of most fine-granular > > observation points linked to a single metering process, because only > > the metering process can merge packets observed at different fine- > > granular observation points to a joint flow. > > When merging flow records already exported from the first level metering > systems, you might create new aggregated flows for which also the "observation > point" gets aggregated. The resulting one might include all first level > observation points. > > > > > ... > > > > Also the > > locations of metering processes are not of any relevance for this > > document (in contrast to the locations of observation points and the > > exporting processes). > > Well what's the question here. We care about where packets are observed, > not about where they are processed and converted into fow records. > > Juergen > > > > Paul > > > > -- > > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > "unsubscribe ipfix" in message body > > Archive http://ipfix.doit.wisc.edu/archive/ > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Aug 29 16:12:53 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09491 for ; Thu, 29 Aug 2002 16:12:52 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17kVWh-00068h-00 for ipfix-list@mil.doit.wisc.edu; Thu, 29 Aug 2002 15:04:24 -0500 Received: from sj-msg-core-2.cisco.com ([171.69.24.11]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17kVWd-00066W-00 for ipfix-req@net.doit.wisc.edu; Thu, 29 Aug 2002 15:04:19 -0500 Received: from mira-sjcd-1.cisco.com (IDENT:mirapoint@mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g7TK3Bds010436; Thu, 29 Aug 2002 13:03:11 -0700 (PDT) Received: from cisco.com (dhcp-171-71-137-31.cisco.com [171.71.137.31]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ADK38647; Thu, 29 Aug 2002 13:03:32 -0700 (PDT) Message-ID: <3D6E7DF8.67E4152E@cisco.com> Date: Thu, 29 Aug 2002 13:03:04 -0700 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: Juergen Quittek CC: calato@riverstonenet.com, req Subject: Re: fragmented packets (was: Re: [ipfix-req] IPFIX Requirements Questions) References: <3D6C18A3.764A46B9@riverstonenet.com> <1785807.1030527914@[192.168.102.164]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Juergen Quittek wrote: > Hi Paul, > > --On 27 August 2002 20:26 -0400 calato@riverstonenet.com wrote: > > > Juergen Quittek wrote: > >> > >> --On 27 August 2002 14:49 -0400 calato@riverstonenet.com wrote: > >> > >> > > >> > As I work on the advocates document some questions > >> > have come to mind on the requirements document. > >> > > >> > 4.3 Distinguishing flows using Transport Header Fields > >> > > >> > In the case of fragmented packets there are > >> > no port numbers. Are we saying flow state information > >> > MUST be maintained? In general, it is not clear from > >> > >> No, the requirements document does not say so. > >> > >> > the document what the requirements are for fragmented > >> > packets. > >> > >> I think the requirements should not include a requirement for > >> keeping state of fragmented packets. Would you like to see > >> an explicit statement on that? This would be a NO NEED FOR > >> statement :-) > > > > I think we need to be explicit. Most people will think > > of fragements as being counted in the same flow as the > > first packet not as 2 differernt flows. > > I see. Waht about adding a new subsection to Section "5. Metering > Process": > > 5.8. Packet Fragmentation > > In case of IP packet fragmentation, only one fragment of a single > packet might contain sufficient information for classifying the > packet correctly. The metering process MAY keep state of > IP packet fragmentation in order to map fragments that do not > contain sufficient header information correctly to flows. > > [...] > > >> > 6.1 information Model > >> > > >> > 9 Packet Counter > >> > 10 Byte counter > >> > > >> > As mentioned earlier, for fragments this > >> > requires state information? If there is no > >> > state info, then what flow are the counted > >> > towards? > >> > >> Do you suggest to include a requirement for keeping fragment state info? > > > > > > A MAY is as far as I would go. There may certainly be probes > > that have this capability. We should have a requirement that > > says fragment counting MUST be clearly defined. > > OK. Currently, we have > > 9. packet counter > If a packet is fragmented, each fragment is counted as an > individual packet. But it may be counted into a wrong or a coarser flow. So it depends on the device capability & traffic pattern. > > 10. byte counter > Which bytes of a packet are counted MUST be defined exactly. > > What about appending > > The behavior of the byte counter in case of IP packet > fragmentation MUST be clearly defined. > ? Had a basic question here. Whe we say byte counter, does it exclude upto L4 header? Ganesh > > > Please note that we also have in the MAY attributes section > > 26. fragmented packet counter > counter of all packets for which the fragmented bit is set in > the IP header > > Juergen > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Aug 29 16:28:06 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09967 for ; Thu, 29 Aug 2002 16:28:06 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17kVlo-0006Ua-00 for ipfix-list@mil.doit.wisc.edu; Thu, 29 Aug 2002 15:20:00 -0500 Received: from sj-msg-core-3.cisco.com ([171.70.157.152]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17kVlm-0006UG-00 for ipfix-req@net.doit.wisc.edu; Thu, 29 Aug 2002 15:19:58 -0500 Received: from mira-sjcd-1.cisco.com (IDENT:mirapoint@mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g7TKJE3x002089; Thu, 29 Aug 2002 13:19:14 -0700 (PDT) Received: from cisco.com (dhcp-171-71-137-31.cisco.com [171.71.137.31]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ADK39232; Thu, 29 Aug 2002 13:19:42 -0700 (PDT) Message-ID: <3D6E81C3.2A3E2D8A@cisco.com> Date: Thu, 29 Aug 2002 13:19:15 -0700 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: Juergen Quittek CC: calato@riverstonenet.com, req Subject: Re: MPLS label (was:Re: [ipfix-req] IPFIX Requirements Questions) References: <3D6C18A3.764A46B9@riverstonenet.com> <4553948.1030530472@[192.168.102.164]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Juergen Quittek wrote: > Hi Paul, > > --On 27 August 2002 20:26 -0400 calato@riverstonenet.com wrote: > > [...] > > >> > 4.4 MPLS Label > >> > > >> > In the case of dynamic LSP's the label is not useful. > >> > Why require distinguishing flows based on label. > >> > What can be done with that information? > >> > >> Well, for each attribute there are situations where it does not make > >> sense to use it for distinguishing flows. But being able to distinguish > >> flows by label seems to be useful to me in general. > > > > > > Then why not include things like VPI/VCI for ATM > > or other L2.5 tunnels? Why does MPLS get special > > consideration? > > In general I see your point, although MPLS appears to be closer > related to IP than plain ATM. I'll have to agree with both of you:) I think there has been more voices for MPLS compared to ATM though I do not see a reson for it not to be included. > > > > Also, I may be wrong here but I beleive the primary > > use of MPLS will be with dynamic LSP's so the label > > has little meaning the majority of time. At best > > it would be a MAY requirement, not a MUST. > > For me, metering on a per-LSP basis is highly benefitial for the > operation of MPLS networks, even in the case of dynamic label > assignment. The LSR MIB already offers this kind of performance > information, but I think it also fits well into IPFIX. Though dynamic in nature, the label meaning can be obtained from the edge device at different levels. So I think this information is very useful. -ganesh > > > > If we are going to go this way, which I am > > against, then we should also include FEC. At least > > that would be more meaningful information in the > > case of dynamic LSPs. > > This could be useful, but the FEC is a higher level information > that is not available in many cases. Also we would need a good model > for FEC information. > > Juergen > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Aug 29 16:38:25 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10306 for ; Thu, 29 Aug 2002 16:38:25 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17kVsQ-0006cQ-00 for ipfix-list@mil.doit.wisc.edu; Thu, 29 Aug 2002 15:26:50 -0500 Received: from sj-msg-core-3.cisco.com ([171.70.157.152]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17kVsN-0006c1-00 for ipfix-req@net.doit.wisc.edu; Thu, 29 Aug 2002 15:26:47 -0500 Received: from mira-sjcd-1.cisco.com (IDENT:mirapoint@mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g7TKQ23x005737; Thu, 29 Aug 2002 13:26:02 -0700 (PDT) Received: from cisco.com (dhcp-171-71-137-31.cisco.com [171.71.137.31]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ADK39480; Thu, 29 Aug 2002 13:26:31 -0700 (PDT) Message-ID: <3D6E835C.3D912808@cisco.com> Date: Thu, 29 Aug 2002 13:26:04 -0700 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: David Moore CC: calato@riverstonenet.com, Juergen Quittek , req Subject: Re: [ipfix-req] IPFIX Requirements Questions References: <3D6BC9AD.CAC153C8@riverstonenet.com> <42174623.1030483746@[192.168.102.164]> <3D6C18A3.764A46B9@riverstonenet.com> <20020828092046.W66212@login.caida.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit David Moore wrote: > On Tue, Aug 27, 2002 at 08:26:11PM -0400, calato@riverstonenet.com wrote: > > I disagree. I'm not talking about what is exported, I talking > > about semantics. The req doc currently ties the timestamp event > > to packet observation. All metering processes will know > > when they created and deleted a flow. They may or may not > > know when the first or last packet was observed. > > > > The typical example of this is last packet. In many platforms > > the first packet is processed by the CPU and creates a hardware entry. This may not be the first packet in the flow but it is the first packet seen by this observation point. > > > The rest of the packets are processed and counted in hardware > > and thus there is no timestamp available, just a count. All > > that is known is when the flow was artifically timed out. Same holds good here. It may not be last packet in the flow But we are forced to flush the cache because of being full or whatever. In either case if we can register the time at which the first & last packet for this packet came in at this observation point (with tolerances based on implementation) is that not sufficiently broad? Some of the h/w implemetation do a periodic cache flushing. But the time is still closest to the last packet.. -ganesh > > > Is this because there is no clock available to the hardware? > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" 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 Aug 29 16:54:36 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08778 for ; Thu, 29 Aug 2002 15:55:29 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17kVEg-0005WO-00 for ipfix-list@mil.doit.wisc.edu; Thu, 29 Aug 2002 14:45:46 -0500 Received: from sj-msg-core-4.cisco.com ([171.71.163.54]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17kVEe-0005VL-00 for ipfix-req@net.doit.wisc.edu; Thu, 29 Aug 2002 14:45:44 -0500 Received: from mira-sjcd-1.cisco.com (IDENT:mirapoint@mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g7TJjDW4005503; Thu, 29 Aug 2002 12:45:13 -0700 (PDT) Received: from cisco.com (dhcp-171-71-137-31.cisco.com [171.71.137.31]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ADK37980; Thu, 29 Aug 2002 12:45:40 -0700 (PDT) Message-ID: <3D6E79C9.AB8020FE@cisco.com> Date: Thu, 29 Aug 2002 12:45:13 -0700 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: calato@riverstonenet.com CC: req Subject: Re: [ipfix-req] IPFIX Requirements Questions References: <3D6BC9AD.CAC153C8@riverstonenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit calato@riverstonenet.com wrote: > As I work on the advocates document some questions > have come to mind on the requirements document. > > 4.3 Distinguishing flows using Transport Header Fields > > In the case of fragmented packets there are > no port numbers. Are we saying flow state information > MUST be maintained? In general, it is not clear from > the document what the requirements are for fragmented > packets. I do not see a way to distinguishing flows for fragmented packets and not all fragments pass through the same router. > > > 4.4 MPLS Label > > In the case of dynamic LSP's the label is not useful. > Why require distinguishing flows based on label. > What can be done with that information? If we can get a label to prefix mapping (from the control plane) then it would be be very useful information. So I think this defn. still holds good. > > > 5.3 Overload Behavior > > This section needs to be re-worked a little. Some > of the MUST's impose undue burden on the device. > > 1. Must distinguish flow records before and after the > behavior change. Probably the intention is that it is one of the flow expiration reasons. But I am not sure whether it needs to be tied with a flow is it is the device's behavior. So keeping a MUST here does not seem to be required. > > > In the case where the behavior is to drop > overflow flows, why do we need to distinguish > flows. Perhaps I misunderstood something. > > 2. All flows from previous behavior MUST be terminated. > > > > Again, if I simply dropped excess flows why terminate > all existing ones. This will likely cause more overflow > as the get reestablished. This also seems to go to > far towards implementation. > I do not understand why. The reason you stated above is good enough for this not to be done. > > 3. Meeting process MUST NOT merge previous records. > > I think what we are trying to say is flows with a different > definition MUST be distinguishable. How that is done is not > part of the requirements doc. What I understand here is that 3 different flow records be cretaed * prior to overload * overload * post overload While I can udnderstand this from an export process perspective, I am not sure how much sense it makes to go per flow on overload. > > > 5.4 Timestamps > > Time stamps to not always mapped to the first packet and last > packet. In many cases, the end timestamp is merely when > the flow timed out and has nothing to do with when the > last packet was seen. Allowing both semantics may be useful. > A re-wording like this... While there may be a minor delay in setting the timestamp after the last packet is seen, I am not sure by the above statement that "has nothing to do with when the last packet was seen." Is it not the case that the flow was alive at this observation point only till it saw the last packet? > > > The metering process MUST be able to generate timestamps for the > start and end of a flow. The metering process MAY also provide > timestamps for the first and the last observed packet > of a flow. The timestamp resolution MUST be at least the one of > the sysUpTime [RFC1213], which is one centisecond. > > Note - this does not mandate 2 timestamp fields for a flow. You > could have one element for each meaning (e.g. Flow-start-time, > first-packet-time, flow-start-and-first-packet-time) and use > the one with the desired meaning. > > 6.1 information Model > > 9 Packet Counter > 10 Byte counter > > As mentioned earlier, for fragments this > requires state information? If there is no > state info, then what flow are the counted > towards? > > 13 BGP AS number > > Is this the AS number for the observation point, the > source/destination address in the packet or some > combination? Correct me if I'm wrong - usually a set of prefixes are associated with an AS. An observation point is too vague a definition to associate to an AS. Say it is a router LC, there could be multiple ASs within it. > > > 14. MPLS Label > > As stated earlier, in the case of dynamic LSP's the > label has no meaning. > > 21 multicast replication number > > The document stated this can change over the life > of the flow. But no mention of what happens when > it changes. Is that a new flow? If not, what meaning > does it have when reported? What can I do with it? It would be useful if the collector is going to calculate the replication factor over a period of time. > > > > 6.2 Data Model > > What about allowing Vendors to add information independently? > Some data to be transported may be vendor specific and never > make it into the IPFIX spec. > > 8.3 Several Collecting Processes > > No mention is made when reporting to several devices > of ensuring the duplicate data does not cause a double > counting problem. > I must have forgotten. Can you elaborate a little more? Thanks Ganesh > > 9. Special Device Considerations > > I'm not sure of the meaning for the following... > > ... > > Please note that here, the observation > point of a single flow cannot exceed the set of most fine-granular > observation points linked to a single metering process, because only > the metering process can merge packets observed at different fine- > granular observation points to a joint flow. > > ... > > Also the > locations of metering processes are not of any relevance for this > document (in contrast to the locations of observation points and the > exporting processes). > > Paul > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Aug 29 17:01:48 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11076 for ; Thu, 29 Aug 2002 17:01:48 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17kW8j-00074c-00 for ipfix-list@mil.doit.wisc.edu; Thu, 29 Aug 2002 15:43:41 -0500 Received: from [64.95.122.60] (helo=RS-SC-EXC4.rs.riverstonenet.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17kW8h-00074B-00 for ipfix-req@net.doit.wisc.edu; Thu, 29 Aug 2002 15:43:39 -0500 Received: from riverstonenet.com ([134.141.180.76]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 29 Aug 2002 13:43:06 -0700 Message-ID: <3D6E86F1.1CF943F0@riverstonenet.com> Date: Thu, 29 Aug 2002 16:41:21 -0400 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Ganesh Sadasivan CC: req Subject: Re: [ipfix-req] IPFIX Requirements Questions References: <3D6BC9AD.CAC153C8@riverstonenet.com> <3D6E79C9.AB8020FE@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Aug 2002 20:43:07.0567 (UTC) FILETIME=[AE3003F0:01C24F9C] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Ganesh Sadasivan wrote: > > calato@riverstonenet.com wrote: > > > As I work on the advocates document some questions > > have come to mind on the requirements document. > > > > 4.3 Distinguishing flows using Transport Header Fields > > > > In the case of fragmented packets there are > > no port numbers. Are we saying flow state information > > MUST be maintained? In general, it is not clear from > > the document what the requirements are for fragmented > > packets. > > I do not see a way to distinguishing flows for fragmented packets > and not all fragments pass through the same router. Right. Keeping state is no guarentee. > > > > > > > 4.4 MPLS Label > > > > In the case of dynamic LSP's the label is not useful. > > Why require distinguishing flows based on label. > > What can be done with that information? > > If we can get a label to prefix mapping (from the control plane) > then it would be be very useful information. So I think this defn. > still holds good. Who is "we"? If you mean the Collecting Process, then querying the device after the fact has problems since LSPs are dynamic. > > > > > > > 5.3 Overload Behavior > > > > This section needs to be re-worked a little. Some > > of the MUST's impose undue burden on the device. > > > > 1. Must distinguish flow records before and after the > > behavior change. > > Probably the intention is that it is one of the flow expiration > reasons. But I am not sure whether it needs to be tied with > a flow is it is the device's behavior. So keeping a MUST here > does not seem to be required. > > > > > > > In the case where the behavior is to drop > > overflow flows, why do we need to distinguish > > flows. Perhaps I misunderstood something. > > > > 2. All flows from previous behavior MUST be terminated. > > > > > > > > > Again, if I simply dropped excess flows why terminate > > all existing ones. This will likely cause more overflow > > as the get reestablished. This also seems to go to > > far towards implementation. > > > > I do not understand why. The reason you stated above is > good enough for this not to be done. I'm not sure I follow. The cost of terminating and re-establishing millions of flow is not reason enough? > > > > > 3. Meeting process MUST NOT merge previous records. > > > > I think what we are trying to say is flows with a different > > definition MUST be distinguishable. How that is done is not > > part of the requirements doc. > > What I understand here is that 3 different flow records be cretaed > * prior to overload > * overload > * post overload > While I can udnderstand this from an export process perspective, > I am not sure how much sense it makes to go per flow on overload. > > > > > > > 5.4 Timestamps > > > > Time stamps to not always mapped to the first packet and last > > packet. In many cases, the end timestamp is merely when > > the flow timed out and has nothing to do with when the > > last packet was seen. Allowing both semantics may be useful. > > A re-wording like this... > > While there may be a minor delay in setting the timestamp after the > last packet is seen, If the hardware stamps all packets, no problem. If the software has to do it, how do you know what the last packet is? > I am not sure by the above statement that > "has nothing to do with when the last packet was seen." > Is it not the > case that the flow was alive at this observation point only till it saw the > last packet? In the case of timeout, it is the time at which the device noticed that there were no more packets since the last time it checked. It does not know the time of the last packet observed. > > > > > > > The metering process MUST be able to generate timestamps for the > > start and end of a flow. The metering process MAY also provide > > timestamps for the first and the last observed packet > > of a flow. The timestamp resolution MUST be at least the one of > > the sysUpTime [RFC1213], which is one centisecond. > > > > Note - this does not mandate 2 timestamp fields for a flow. You > > could have one element for each meaning (e.g. Flow-start-time, > > first-packet-time, flow-start-and-first-packet-time) and use > > the one with the desired meaning. > > > > 6.1 information Model > > > > 9 Packet Counter > > 10 Byte counter > > > > As mentioned earlier, for fragments this > > requires state information? If there is no > > state info, then what flow are the counted > > towards? > > > > 13 BGP AS number > > > > Is this the AS number for the observation point, the > > source/destination address in the packet or some > > combination? > > Correct me if I'm wrong - usually a set of prefixes are associated with an AS. > An observation point is too vague a definition to associate to an AS. Say > it is a router LC, there could be multiple ASs within it. But suppose the entire router is in a single AS. Should we report it? In your example, maybe we report a list. > > > > > > > 14. MPLS Label > > > > As stated earlier, in the case of dynamic LSP's the > > label has no meaning. > > > > 21 multicast replication number > > > > The document stated this can change over the life > > of the flow. But no mention of what happens when > > it changes. Is that a new flow? If not, what meaning > > does it have when reported? What can I do with it? > > It would be useful if the collector is going to calculate the > replication factor over a period of time. > > > > > > > > > 6.2 Data Model > > > > What about allowing Vendors to add information independently? > > Some data to be transported may be vendor specific and never > > make it into the IPFIX spec. > > > > 8.3 Several Collecting Processes > > > > No mention is made when reporting to several devices > > of ensuring the duplicate data does not cause a double > > counting problem. > > > > I must have forgotten. Can you elaborate a little more? Depends on why you are reporting to 2 devices. If it is for completely different applications, no problem. But if there is a sharing of data for back up purposes or any other reason then ensuring you don't double count comes into play. > > Thanks > Ganesh > > > > > 9. Special Device Considerations > > > > I'm not sure of the meaning for the following... > > > > ... > > > > Please note that here, the observation > > point of a single flow cannot exceed the set of most fine-granular > > observation points linked to a single metering process, because only > > the metering process can merge packets observed at different fine- > > granular observation points to a joint flow. > > > > ... > > > > Also the > > locations of metering processes are not of any relevance for this > > document (in contrast to the locations of observation points and the > > exporting processes). > > > > Paul > > > > -- > > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > "unsubscribe ipfix" in message body > > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Aug 29 17:10:21 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11325 for ; Thu, 29 Aug 2002 17:10:21 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17kWMR-0007QW-00 for ipfix-list@mil.doit.wisc.edu; Thu, 29 Aug 2002 15:57:51 -0500 Received: from [64.95.122.60] (helo=RS-SC-EXC4.rs.riverstonenet.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17kWMO-0007QA-00 for ipfix-req@net.doit.wisc.edu; Thu, 29 Aug 2002 15:57:49 -0500 Received: from riverstonenet.com ([134.141.180.76]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 29 Aug 2002 13:57:07 -0700 Message-ID: <3D6E8A3E.2410188B@riverstonenet.com> Date: Thu, 29 Aug 2002 16:55:26 -0400 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Ganesh Sadasivan CC: Juergen Quittek , req Subject: Re: MPLS label (was:Re: [ipfix-req] IPFIX Requirements Questions) References: <3D6C18A3.764A46B9@riverstonenet.com> <4553948.1030530472@[192.168.102.164]> <3D6E81C3.2A3E2D8A@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Aug 2002 20:57:08.0411 (UTC) FILETIME=[A35EA0B0:01C24F9E] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Ganesh Sadasivan wrote: > > Juergen Quittek wrote: > > > Hi Paul, > > > > --On 27 August 2002 20:26 -0400 calato@riverstonenet.com wrote: > > > > [...] > > > > >> > 4.4 MPLS Label > > >> > > > >> > In the case of dynamic LSP's the label is not useful. > > >> > Why require distinguishing flows based on label. > > >> > What can be done with that information? > > >> > > >> Well, for each attribute there are situations where it does not make > > >> sense to use it for distinguishing flows. But being able to distinguish > > >> flows by label seems to be useful to me in general. > > > > > > > > > Then why not include things like VPI/VCI for ATM > > > or other L2.5 tunnels? Why does MPLS get special > > > consideration? > > > > In general I see your point, although MPLS appears to be closer > > related to IP than plain ATM. > > I'll have to agree with both of you:) I think there has been more > voices for MPLS compared to ATM though I do not see a reson > for it not to be included. > > > > > > > > Also, I may be wrong here but I beleive the primary > > > use of MPLS will be with dynamic LSP's so the label > > > has little meaning the majority of time. At best > > > it would be a MAY requirement, not a MUST. > > > > For me, metering on a per-LSP basis is highly benefitial for the > > operation of MPLS networks, even in the case of dynamic label > > assignment. The LSR MIB already offers this kind of performance > > information, but I think it also fits well into IPFIX. > > Though dynamic in nature, the label meaning can be obtained from > the edge device at different levels. So I think this information > is very useful. Are you saying the Collecting process needs to get additional info from the device in order for field reported by IPFIX to be useful? Not to mention that since the labels are dynamic in nature, asking about label 57 in 2 consecutive requests may come back with different answers. Help me out here, I'm struggling to see the usefulness of this piece of data. > -ganesh > > > > > > > > If we are going to go this way, which I am > > > against, then we should also include FEC. At least > > > that would be more meaningful information in the > > > case of dynamic LSPs. > > > > This could be useful, but the FEC is a higher level information > > that is not available in many cases. Also we would need a good model > > for FEC information. > > > > Juergen > > > > -- > > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > "unsubscribe ipfix" in message body > > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Aug 29 17:13:00 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11433 for ; Thu, 29 Aug 2002 17:13:00 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17kWSx-0007dG-00 for ipfix-list@mil.doit.wisc.edu; Thu, 29 Aug 2002 16:04:35 -0500 Received: from [64.95.122.60] (helo=RS-SC-EXC4.rs.riverstonenet.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17kWSv-0007ch-00 for ipfix-req@net.doit.wisc.edu; Thu, 29 Aug 2002 16:04:33 -0500 Received: from riverstonenet.com ([134.141.180.76]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 29 Aug 2002 14:04:01 -0700 Message-ID: <3D6E8BDC.C3904A07@riverstonenet.com> Date: Thu, 29 Aug 2002 17:02:20 -0400 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Ganesh Sadasivan CC: David Moore , Juergen Quittek , req Subject: Re: [ipfix-req] IPFIX Requirements Questions References: <3D6BC9AD.CAC153C8@riverstonenet.com> <42174623.1030483746@[192.168.102.164]> <3D6C18A3.764A46B9@riverstonenet.com> <20020828092046.W66212@login.caida.org> <3D6E835C.3D912808@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Aug 2002 21:04:02.0044 (UTC) FILETIME=[99EA03C0:01C24F9F] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Ganesh Sadasivan wrote: > > David Moore wrote: > > > On Tue, Aug 27, 2002 at 08:26:11PM -0400, calato@riverstonenet.com wrote: > > > I disagree. I'm not talking about what is exported, I talking > > > about semantics. The req doc currently ties the timestamp event > > > to packet observation. All metering processes will know > > > when they created and deleted a flow. They may or may not > > > know when the first or last packet was observed. > > > > > > The typical example of this is last packet. In many platforms > > > the first packet is processed by the CPU and creates a hardware entry. > > This may not be the first packet in the flow but it is the first packet seen by > this > observation point. Not according to the IPFIX definition of a flow. Flow and observation point are tied together. You are using the term flow at a higher level. > > > > > > The rest of the packets are processed and counted in hardware > > > and thus there is no timestamp available, just a count. All > > > that is known is when the flow was artifically timed out. > > Same holds good here. It may not be last packet in the flow But we are > forced to flush the cache because of being full or whatever. In either case > if we can register the time at which the first & last packet for this packet came > in at this observation point (with tolerances based on implementation) is that > not sufficiently broad? Some of the h/w implemetation do a periodic cache > flushing. But the time is still closest to the last packet.. If the timestamping is hardware based I'm OK with ignoring minor skews in time due to hw implementation. But when it is software that uses a configurable interval for inactivity period, I think it is better to have that represented in the data. > -ganesh > > > > > > > Is this because there is no clock available to the hardware? > > > > -- > > Help mailto:majordomo@net.doit.wisc.edu and say "help" 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 Aug 29 17:37:03 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12002 for ; Thu, 29 Aug 2002 17:37:02 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17kWm1-0000Gs-00 for ipfix-list@mil.doit.wisc.edu; Thu, 29 Aug 2002 16:24:17 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17kWlu-0000GW-00 for ipfix-req@net.doit.wisc.edu; Thu, 29 Aug 2002 16:24:10 -0500 Received: from cisco.com (bclaise-isdn-home2.cisco.com [10.49.4.219]) by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id g7TLNS721703; Thu, 29 Aug 2002 23:23:28 +0200 (CEST) Message-ID: <3D6E90D0.8000507@cisco.com> Date: Thu, 29 Aug 2002 23:23:28 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020815 X-Accept-Language: en-us, en MIME-Version: 1.0 To: calato@riverstonenet.com CC: Juergen Quittek , req Subject: Re: overload behavior (was: Re: [ipfix-req] IPFIX Requirements Questions) References: <3D6CD65A.C52F4654@riverstonenet.com> <26869946.1030552789@[192.168.102.164]> <3D6DEF45.80700@cisco.com> <3D6E7738.F8E9E429@riverstonenet.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit calato@riverstonenet.com wrote: >Benoit Claise wrote: > > >>Paul, >> >>[let me take the latest email on this thread] >> >> >> >>>Hi Paul, >>> >>>--On 28 August 2002 09:55 -0400 calato@riverstonenet.com wrote: >>> >>> >>> >>>>Juergen Quittek wrote: >>>> >>>> >>>> >>>>>Hi Paul, >>>>> >>>>>--On 27 August 2002 20:26 -0400 calato@riverstonenet.com wrote: >>>>> >>>>> [...] >>>>> >>>>> >>>>> >>>>>>>>5.3 Overload Behavior >>>>>>>> >>>>>>>> This section needs to be re-worked a little. Some >>>>>>>> of the MUST's impose undue burden on the device. >>>>>>>> >>>>>>>> 1. Must distinguish flow records before and after the >>>>>>>> behavior change. >>>>>>>> >>>>>>>> In the case where the behavior is to drop >>>>>>>> overflow flows, why do we need to distinguish >>>>>>>> flows. Perhaps I misunderstood something. >>>>>>>> >>>>>>>> >>An example (somehow already discussed below) is: >>1. you do sampling 1/100. >>2. for whatever reason, you drop overflow flows (or you decide to change >>the sampling rate) >>3. the new sampling rate is now 1/200 >>4. the collector must know that. >> >> > > I agree with your example. However, I have a different example > where it is not necessary. But, according to the document > I MUST distinguish the flow records. The requirements go > to far in mandating behavior for all overload solutions. > Let me take then a different example. Let's consider you use IPFIX for billing. So you're not doing sampling. For whatever reason, you drop the overflow flows. I think that the collector MUST know about it. For example: From 8.00 to 10.30 -> correct billing From 10.30 to 10.45 -> I lost some flow records -> I must take an action (for example a correction on the bill or whatever) From 10.45 -> back to normal > > I think Juergen agreed on this particular point. How to > rectify it is still unclear. I chose one way and Juergen > another. We still need further discussion. > > > >>>>>>>> 2. All flows from previous behavior MUST be terminated. >>>>>>>> >>>>>>>> >>>>>>>> Again, if I simply dropped excess flows why >>>>>>>> >>>>>>>> >>>>>terminate >>>>> >>>>> >>>>>>>> all existing ones. This will likely cause more >>>>>>>> >>>>>>>> >>>>>overflow >>>>> >>>>> >>>>>>>> as the get reestablished. This also seems to go to >>>>>>>> far towards implementation. >>>>>>>> >>>>>>>> >>>>>>>I agree. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> 3. Meeting process MUST NOT merge previous records. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I think what we are trying to say is flows with a >>>>>>>> >>>>>>>> >>>>>different >>>>> >>>>> >>>>>>>> definition MUST be distinguishable. How that is done is not >>>>>>>> part of the requirements doc. >>>>>>>> >>>>>>>> >>Agreed. It was actually the goal of the sentence "the overload behavior >>MUST be >> clearly defined and the collecting process MUST be able to >> distinguish the flow records exported before and after the metering >> process behavior change" >>Because, in my view, dropping the overflows flows is changing the >>"definition" of the flow, as you wrote Paul wrote it in "flows with a >>different definition MUST be distinguishable" >> >> > > Dropping is not a change for all flow definitions. > See my previous remark. >In fact > sampling is the only definition I can think of which is > affected by dropping. > > > >>>>>>>Also agreed. However, it is not just different definition, but also >>>>>>>different measurement technique, different sampling rate, etc. >>>>>>> >>>>>>>We need to express this intended requirement it in a better way. >>>>>>> >>>>>>> >>>>>> Agreed. >>>>>> >>>>>> What this points out to me is that we do not have a term >>>>>> that refers to the set of information that is the flow >>>>>> definition. We touch on it in section 2.1 when discussing >>>>>> the flow definition itself, in section 2.3 when discussing >>>>>> classifying and then again in section 4 when discussing >>>>>> distinguishing flows. >>>>>> >>>>>> What about a new term "Distinguishing Properties" or >>>>>> "Flow Properties"? Its definition would be >>>>>> >>>>>> The set of fields, functions and parameters (e.g. >>>>>> >>>>>> >>>>>sampling >>>>> >>>>> >>>>>> rate) used to map packets to flows. >>>>>> >>>>>> Then we can say each flow MUST be able to be mapped to its >>>>>> "Distinguishing properties". >>>>>> >>>>>> This would cover changing behavior due to overload, >>>>>> >>>>>> >>>>>configuration >>>>> >>>>> >>>>>> changes, etc... >>>>>> >>>>>> Thoughts? >>>>>> >>>>>> >>>>>I think the mistake in the current version of the text is that it >>>>>asks on separating flows before and after the metering process was >>>>>modified. It is indepenedent of whether the individual flows are >>>>>affected or not. I think it is sufficient to fix this. >>>>> >>>>> >>>> >>>> You side stepped my main 2 issues here. >>>> >>>> 1. We need a definition for the set of functions, >>>> fields and parameters use to map packets to flows. >>>> If it is there and I missed it, let me know. >>>> >>>> 2. We need a requirement that allows the Collecting >>>> device to map flows to the set of functions, >>>> fields and parameters used to create the flow. >>>> >>>> >>>My intention was not to side step them, but to answer on the portion >>>of your comment on which I already made up my mind already. On this issue >>>I still have to think some more. >>> >>> >>> >>>>>The current text is >>>>> >>>>> Overload behavior is not restricted to the four options listed >>>>>above. >>>>> But in case the overload behavior has an impact on the metering >>>>> process or the exporting process, the overload behavior MUST be >>>>> clearly defined and the collecting process MUST be able to >>>>> distinguish the flow records exported before and after the metering >>>>> process behavior change: in case of any change of the meter's >>>>> behavior, all flow records metered by the previous behavior MUST be >>>>> terminated and exported according to the configuration of the >>>>> exporting process. The metering process MUST not merge the flow >>>>> records generated with the new behavior with the flow records >>>>> generated with the previous behavior. >>>>> >>>>>I suggest to replace it by >>>>> >>>>> Overload behavior is not restricted to the four options listed >>>>>above. >>>>> But in case the overload behavior induces a change of the >>>>>behavior of >>>>> metering process and/or the exporting process, the following >>>>>requirements >>>>> must be met for all flows affected by the change of behavior: >>>>> - The overload behavior MUST be clearly defined. >>>>> >>>>> >>>> Agreed. >>>> >>>> >>>> >>>>> - For each flows affected by the change, its record MUST be >>>>>terminated >>>>> at the time of change. >>>>> >>>>> >>>> This seems like implementation detail. Maybe I want to leave >>>> them in tact and when the overload situation is resolved I can >>>> start adding to the counter again. >>>> >>>> >>>I don't think this would be a good idea, because it might not be clear >>>to the collector that you ignored all packets for some time. This seems >>>to be a very unreliable behavior. >>> >>> >>Agreed with Juergen on that one. >>In my example: >>1. you do sampling 1/100. >>2. for whatever reason, you drop overflow flows (or you decide to change >>the sampling rate) >>3. the new sampling rate is now 1/200 >>4. the collector must know that. >> >>How would the collector be able to distinguish the 2 series of flow >>records. If for example you want to multiply the first serie usage by >>100 and the second serie by 200? >> >> > > I agree sampling is a special case where the sampled pool is > a piece of key information and thus can be considered part > of the definition. > > In the example I gave suppose I switch to a coarse grained > flow definition but there are still a few thousand of them. Then > the overload situation is over and I go back to my fine grained > definition. Overload happens again and now I have to set up > all those flows again at the worst possible time. > I agree there is a risk of overload flapping in your specific example. But anyway you can not do anything with flow records on the collector if you don't know the "distinguishing properties" (term that you introduced). As a consequence, you have to stop/expire/export all flow records with the coarse grained flow definition. Otherwise, you mismatch both flow record types on the collector -> you can not use the data Regards, Benoit. > > > > Paul > > >>Regards, Benoit. >> >> >> >>>However, you still might be right. Very often it is hard to distinguish >>>between the real requirement and a particular implementation meeting >>>that requirement. In this case I am not sure. >>> >>> >>> >>>>> - For each flow affected by the change, the collecting process >>>>>MUST be >>>>> able to determine whether the corresponding exported flow >>>>>record was >>>>> created before or after the change of behavior. >>>>> >>>>> >>>> I believe that if we address the 2 issues discussed earlier >>>> these would no longer be needed. >>>> >>>> >>>Would be fine. >>> >>> Juergen >>> >>> >>>-- >>>Help mailto:majordomo@net.doit.wisc.edu and say "help" in >>>message body >>>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>>"unsubscribe ipfix" in message body >>>Archive http://ipfix.doit.wisc.edu/archive/ >>> >>> -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Aug 29 18:12:47 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13169 for ; Thu, 29 Aug 2002 18:12:47 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17kXJq-00012S-00 for ipfix-list@mil.doit.wisc.edu; Thu, 29 Aug 2002 16:59:14 -0500 Received: from [64.95.122.60] (helo=RS-SC-EXC4.rs.riverstonenet.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17kXJo-00011h-00 for ipfix-req@net.doit.wisc.edu; Thu, 29 Aug 2002 16:59:12 -0500 Received: from riverstonenet.com ([134.141.180.76]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 29 Aug 2002 14:57:08 -0700 Message-ID: <3D6E984F.9BDC7185@riverstonenet.com> Date: Thu, 29 Aug 2002 17:55:27 -0400 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Benoit Claise CC: Juergen Quittek , req Subject: Re: overload behavior (was: Re: [ipfix-req] IPFIX Requirements Questions) References: <3D6CD65A.C52F4654@riverstonenet.com> <26869946.1030552789@[192.168.102.164]> <3D6DEF45.80700@cisco.com> <3D6E7738.F8E9E429@riverstonenet.com> <3D6E90D0.8000507@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Aug 2002 21:57:09.0214 (UTC) FILETIME=[059D8FE0:01C24FA7] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Benoit Claise wrote: > > calato@riverstonenet.com wrote: > > >Benoit Claise wrote: > > > > > >>Paul, > >> > >>[let me take the latest email on this thread] > >> > >> > >> > >>>Hi Paul, > >>> > >>>--On 28 August 2002 09:55 -0400 calato@riverstonenet.com wrote: > >>> > >>> > >>> > >>>>Juergen Quittek wrote: > >>>> > >>>> > >>>> > >>>>>Hi Paul, > >>>>> > >>>>>--On 27 August 2002 20:26 -0400 calato@riverstonenet.com wrote: > >>>>> > >>>>> [...] > >>>>> > >>>>> > >>>>> > >>>>>>>>5.3 Overload Behavior > >>>>>>>> > >>>>>>>> This section needs to be re-worked a little. Some > >>>>>>>> of the MUST's impose undue burden on the device. > >>>>>>>> > >>>>>>>> 1. Must distinguish flow records before and after the > >>>>>>>> behavior change. > >>>>>>>> > >>>>>>>> In the case where the behavior is to drop > >>>>>>>> overflow flows, why do we need to distinguish > >>>>>>>> flows. Perhaps I misunderstood something. > >>>>>>>> > >>>>>>>> > >>An example (somehow already discussed below) is: > >>1. you do sampling 1/100. > >>2. for whatever reason, you drop overflow flows (or you decide to change > >>the sampling rate) > >>3. the new sampling rate is now 1/200 > >>4. the collector must know that. > >> > >> > > > > I agree with your example. However, I have a different example > > where it is not necessary. But, according to the document > > I MUST distinguish the flow records. The requirements go > > to far in mandating behavior for all overload solutions. > > > Let me take then a different example. Let's consider you use IPFIX for > billing. So you're not doing sampling. > For whatever reason, you drop the overflow flows. I think that the > collector MUST know about it. > For example: > From 8.00 to 10.30 -> correct billing > From 10.30 to 10.45 -> I lost some flow records -> I must take an > action (for example a correction on the bill or whatever) > From 10.45 -> back to normal We must be getting close because we're getting to nitty gritty details :-) First, I have no problem reporting the overload situation along with any parameters (time, number of packets dropped, etc...) My issue is with terminating all existing flows. Suppose I have room for 100 flows. I'm using SRC/DST IP as my "Distinguishing Properties". 100 flows have now been established and I'm continuing to increment the counter as the packets for those flows arrive. Now at 10:30 101th flow comes in and so I drop it. Why do I need to terminate the 100 existing flows that are happily incrementing their counters? The fact that I dropped the flow has not altered the "Distinguishing Properties" which are in affect. > > > > > I think Juergen agreed on this particular point. How to > > rectify it is still unclear. I chose one way and Juergen > > another. We still need further discussion. > > > > > > > >>>>>>>> 2. All flows from previous behavior MUST be terminated. > >>>>>>>> > >>>>>>>> > >>>>>>>> Again, if I simply dropped excess flows why > >>>>>>>> > >>>>>>>> > >>>>>terminate > >>>>> > >>>>> > >>>>>>>> all existing ones. This will likely cause more > >>>>>>>> > >>>>>>>> > >>>>>overflow > >>>>> > >>>>> > >>>>>>>> as the get reestablished. This also seems to go to > >>>>>>>> far towards implementation. > >>>>>>>> > >>>>>>>> > >>>>>>>I agree. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> 3. Meeting process MUST NOT merge previous records. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> I think what we are trying to say is flows with a > >>>>>>>> > >>>>>>>> > >>>>>different > >>>>> > >>>>> > >>>>>>>> definition MUST be distinguishable. How that is done is not > >>>>>>>> part of the requirements doc. > >>>>>>>> > >>>>>>>> > >>Agreed. It was actually the goal of the sentence "the overload behavior > >>MUST be > >> clearly defined and the collecting process MUST be able to > >> distinguish the flow records exported before and after the metering > >> process behavior change" > >>Because, in my view, dropping the overflows flows is changing the > >>"definition" of the flow, as you wrote Paul wrote it in "flows with a > >>different definition MUST be distinguishable" > >> > >> > > > > Dropping is not a change for all flow definitions. > > > See my previous remark. > > >In fact > > sampling is the only definition I can think of which is > > affected by dropping. > > > > > > > >>>>>>>Also agreed. However, it is not just different definition, but also > >>>>>>>different measurement technique, different sampling rate, etc. > >>>>>>> > >>>>>>>We need to express this intended requirement it in a better way. > >>>>>>> > >>>>>>> > >>>>>> Agreed. > >>>>>> > >>>>>> What this points out to me is that we do not have a term > >>>>>> that refers to the set of information that is the flow > >>>>>> definition. We touch on it in section 2.1 when discussing > >>>>>> the flow definition itself, in section 2.3 when discussing > >>>>>> classifying and then again in section 4 when discussing > >>>>>> distinguishing flows. > >>>>>> > >>>>>> What about a new term "Distinguishing Properties" or > >>>>>> "Flow Properties"? Its definition would be > >>>>>> > >>>>>> The set of fields, functions and parameters (e.g. > >>>>>> > >>>>>> > >>>>>sampling > >>>>> > >>>>> > >>>>>> rate) used to map packets to flows. > >>>>>> > >>>>>> Then we can say each flow MUST be able to be mapped to its > >>>>>> "Distinguishing properties". > >>>>>> > >>>>>> This would cover changing behavior due to overload, > >>>>>> > >>>>>> > >>>>>configuration > >>>>> > >>>>> > >>>>>> changes, etc... > >>>>>> > >>>>>> Thoughts? > >>>>>> > >>>>>> > >>>>>I think the mistake in the current version of the text is that it > >>>>>asks on separating flows before and after the metering process was > >>>>>modified. It is indepenedent of whether the individual flows are > >>>>>affected or not. I think it is sufficient to fix this. > >>>>> > >>>>> > >>>> > >>>> You side stepped my main 2 issues here. > >>>> > >>>> 1. We need a definition for the set of functions, > >>>> fields and parameters use to map packets to flows. > >>>> If it is there and I missed it, let me know. > >>>> > >>>> 2. We need a requirement that allows the Collecting > >>>> device to map flows to the set of functions, > >>>> fields and parameters used to create the flow. > >>>> > >>>> > >>>My intention was not to side step them, but to answer on the portion > >>>of your comment on which I already made up my mind already. On this issue > >>>I still have to think some more. > >>> > >>> > >>> > >>>>>The current text is > >>>>> > >>>>> Overload behavior is not restricted to the four options listed > >>>>>above. > >>>>> But in case the overload behavior has an impact on the metering > >>>>> process or the exporting process, the overload behavior MUST be > >>>>> clearly defined and the collecting process MUST be able to > >>>>> distinguish the flow records exported before and after the metering > >>>>> process behavior change: in case of any change of the meter's > >>>>> behavior, all flow records metered by the previous behavior MUST be > >>>>> terminated and exported according to the configuration of the > >>>>> exporting process. The metering process MUST not merge the flow > >>>>> records generated with the new behavior with the flow records > >>>>> generated with the previous behavior. > >>>>> > >>>>>I suggest to replace it by > >>>>> > >>>>> Overload behavior is not restricted to the four options listed > >>>>>above. > >>>>> But in case the overload behavior induces a change of the > >>>>>behavior of > >>>>> metering process and/or the exporting process, the following > >>>>>requirements > >>>>> must be met for all flows affected by the change of behavior: > >>>>> - The overload behavior MUST be clearly defined. > >>>>> > >>>>> > >>>> Agreed. > >>>> > >>>> > >>>> > >>>>> - For each flows affected by the change, its record MUST be > >>>>>terminated > >>>>> at the time of change. > >>>>> > >>>>> > >>>> This seems like implementation detail. Maybe I want to leave > >>>> them in tact and when the overload situation is resolved I can > >>>> start adding to the counter again. > >>>> > >>>> > >>>I don't think this would be a good idea, because it might not be clear > >>>to the collector that you ignored all packets for some time. This seems > >>>to be a very unreliable behavior. > >>> > >>> > >>Agreed with Juergen on that one. > >>In my example: > >>1. you do sampling 1/100. > >>2. for whatever reason, you drop overflow flows (or you decide to change > >>the sampling rate) > >>3. the new sampling rate is now 1/200 > >>4. the collector must know that. > >> > >>How would the collector be able to distinguish the 2 series of flow > >>records. If for example you want to multiply the first serie usage by > >>100 and the second serie by 200? > >> > >> > > > > I agree sampling is a special case where the sampled pool is > > a piece of key information and thus can be considered part > > of the definition. > > > > In the example I gave suppose I switch to a coarse grained > > flow definition but there are still a few thousand of them. Then > > the overload situation is over and I go back to my fine grained > > definition. Overload happens again and now I have to set up > > all those flows again at the worst possible time. > > > I agree there is a risk of overload flapping in your specific example. > But anyway you can not do anything with flow records on the collector if > you don't know the "distinguishing properties" (term that you introduced). > As a consequence, you have to stop/expire/export all flow records with > the coarse grained flow definition. > Otherwise, you mismatch both flow record types on the collector -> you > can not use the data Yes I can :-) Lets assume under normal conditions a device wants to use multiple "distinguishing property" sets. Nothing unusual here. But it does mean there is a need to map a flow to a "distinguishing property" set, right? If we still agree, then my overload flows have one set of "distinguishing property" while the other flows have a different "distinguishing property" set, no problem. Please keep in mind I am not advocating this as an overload behavior. But I am against the requirements ruling it or other similar ones out. Paul > > Regards, Benoit. > > > > > > > > > Paul > > > > > >>Regards, Benoit. > >> > >> > >> > >>>However, you still might be right. Very often it is hard to distinguish > >>>between the real requirement and a particular implementation meeting > >>>that requirement. In this case I am not sure. > >>> > >>> > >>> > >>>>> - For each flow affected by the change, the collecting process > >>>>>MUST be > >>>>> able to determine whether the corresponding exported flow > >>>>>record was > >>>>> created before or after the change of behavior. > >>>>> > >>>>> > >>>> I believe that if we address the 2 issues discussed earlier > >>>> these would no longer be needed. > >>>> > >>>> > >>>Would be fine. > >>> > >>> Juergen > >>> > >>> > >>>-- > >>>Help mailto:majordomo@net.doit.wisc.edu and say "help" in > >>>message body > >>>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > >>>"unsubscribe ipfix" in message body > >>>Archive http://ipfix.doit.wisc.edu/archive/ > >>> > >>> -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Aug 29 18:51:34 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14254 for ; Thu, 29 Aug 2002 18:51:34 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17kY0C-00025d-00 for ipfix-list@mil.doit.wisc.edu; Thu, 29 Aug 2002 17:43:00 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17kY09-00025Q-00 for ipfix-req@net.doit.wisc.edu; Thu, 29 Aug 2002 17:42:58 -0500 Received: from cisco.com (bclaise-isdn-home2.cisco.com [10.49.4.219]) by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id g7TMgH721602; Fri, 30 Aug 2002 00:42:17 +0200 (CEST) Message-ID: <3D6EA348.5040908@cisco.com> Date: Fri, 30 Aug 2002 00:42:16 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020815 X-Accept-Language: en-us, en MIME-Version: 1.0 To: calato@riverstonenet.com CC: Juergen Quittek , req Subject: Re: MPLS label (was:Re: [ipfix-req] IPFIX Requirements Questions) References: <3D6E012A.6010804@cisco.com> <34028240.1030638935@[192.168.102.164]> <3D6E3B5C.90404@cisco.com> <3D6E7B3F.6EF78048@riverstonenet.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Paul, >Benoit Claise wrote: > > >>Juergen Quittek wrote: >> >> >> >>>Hi Benoit, >>> >>>-- Benoit Claise wrote on 29 August 2002 13:10 +0200: >>> >>> >>> >>>>Hi, >>>> >>>> >>>> >>>>>Juergen Quittek wrote: >>>>> >>>>> >>>>> >>>>> >>>>>>Hi Paul, >>>>>> >>>>>>--On 28 August 2002 09:18 -0400 calato@riverstonenet.com wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>Juergen Quittek wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>Hi Paul, >>>>>>>> >>>>>>>>--On 27 August 2002 20:26 -0400 calato@riverstonenet.com wrote: >>>>>>>> >>>>>>>>[...] >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>4.4 MPLS Label >>>>>>>>>>> >>>>>>>>>>> In the case of dynamic LSP's the label is not useful. >>>>>>>>>>> Why require distinguishing flows based on label. >>>>>>>>>>> What can be done with that information? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>Well, for each attribute there are situations where it does not >>>>>>>>>>make >>>>>>>>>>sense to use it for distinguishing flows. But being able to >>>>>>>>>>distinguish >>>>>>>>>>flows by label seems to be useful to me in general. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Then why not include things like VPI/VCI for ATM >>>>>>>>> or other L2.5 tunnels? Why does MPLS get special >>>>>>>>> consideration? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>In general I see your point, although MPLS appears to be closer >>>>>>>>related to IP than plain ATM. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Why? I can take and ATM PVC and use it as a tunnel for >>>>>>> IP traffic just like MPLS. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>Yes, but MPLS integrates with IP forwarcing when using CR-LDP >>>>>>or RSVP-TE. Also you can use MPLS as "glue" between IP and ATM. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> I don't understand your argument here. Both technologies >>>>> are viable solutions and exist in the market today. >>>>> If one is included, so should the other. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>>>> Also, I may be wrong here but I beleive the primary >>>>>>>>> use of MPLS will be with dynamic LSP's so the label >>>>>>>>> has little meaning the majority of time. At best >>>>>>>>> it would be a MAY requirement, not a MUST. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>For me, metering on a per-LSP basis is highly benefitial for the >>>>>>>>operation of MPLS networks, even in the case of dynamic label >>>>>>>>assignment. The LSR MIB already offers this kind of performance >>>>>>>>information, but I think it also fits well into IPFIX. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Are you talking about metering LSP's themselves or >>>>>>> metering IP flows traveling through an LSP? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>I'm talking about metering LSPs and about observing which flow maps >>>>>>into which LSP. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> I'm a little confused. I thought we were only doing IP >>>>> flows. Are we now including MPLS flows (LSPs)? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>> Assuming you are talking about the latter, what can be done >>>>>>> with the label information? If the flow F1 had label 57 >>>>>>> and F2 had label 57 you don't even know if it is the >>>>>>> same LSP. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>You are right. I would also need interface information. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> OK. So now I have F1, I1 and L57 and then F2, I1 and L57. >>>>> I still don't know if it is the same LSP. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>>>> If we are going to go this way, which I am >>>>>>>>> against, then we should also include FEC. At least >>>>>>>>> that would be more meaningful information in the >>>>>>>>> case of dynamic LSPs. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>This could be useful, but the FEC is a higher level information >>>>>>>>that is not available in many cases. Also we would need a good model >>>>>>>>for FEC information. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> If the device knows the label it knows the FEC. There are >>>>>>> some concrete FEC definitions now and we can always add more >>>>>>> as they materialize. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>All you need for an LSP are entries in insegment table, outsegment >>>>>>table >>>>>>and switching table. How does the device know anything about the >>>>>>FEC if the >>>>>>LSP was explicitly setup by a management system that added entries >>>>>>to these >>>>>>tables. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Let me make sure I understand. Some external management >>>>> station received the FEC and programmed the device? If >>>>> that is the case then you are correct. However, wont many >>>>> deployments have the 2 functions on one device? If so, >>>>> then reporting FEC is at least a MAY requirement. >>>>> >>>>> >>>>> >>>>I have to admit that I haven't been thinking too much in the draft >>>>about MPLS. >>>>I agree now that it makes more sense to report the FEC than the MPLS >>>>label, since the label has got a local significance >>>> >>>>But this is not in contradiction with what is in the draft! >>>> >>>>4.4. MPLS Label >>>> >>>> If the observation point is located at a device supporting >>>> Multiprotocol Label Switching (MPLS, see [RFC3031]) then the metering >>>> process MUST be able to separate flows by the MPLS label. >>>> >>>>And SHOU:LD report the FEC >>>> >>>> >>>Here in Section 4 we are talking about separating flows. >>>Do we want to separate flows by the FEC also? >>> >>> >>As there is a matching Label -> FEC, we can still separate by Label >> >> > > I thought there could be multiple FEC's per label. > I doublechecked with some of our experts. label: FEC is a 1:1 relationship FEC: label is a 1:n relationship In conclusion, what we need in the req. draft is: 4.4. MPLS Label If the observation point is located at a device supporting Multiprotocol Label Switching (MPLS, see [RFC3031]) then the metering process MUST be able to separate flows by the MPLS label. 6.1. Information Model The exporting process SHOULD be able to report the following attributes for each metered flow: if MPLS is supported at the observation point: the Forwarding Equivalent Class (relative to the top label) Why a SHOULD and not a MUST? Because in case of static label whose setup is done by a NMS, we don't need to export the labels. And if we want to be complete... 6.1. Information Model The exporting process MAY be able to report the following attributes for each metered flow: if MPLS is supported at the observation point: the underlying labels (second bottom label and below) Why? the report of the MPLS/VPN label for example Regards, Benoit. > > > >>>Or are you suggesting to add the FEC to the list of SHOULD >>>attributes in Section 6.1? >>> >>> >>And yes: SHOULD report the FEC in Section 6.1 >> >>Regards, Benoit. >> >> >> >>> Juergen >>> >>> >>> >>>>Regards, Benoit. >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>>> Juergen >>>>>> >>>>>> >>>>>> >>>>>> >>>>>-- >>>>>Help mailto:majordomo@net.doit.wisc.edu and say "help" in >>>>>message body >>>>>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>>>>"unsubscribe ipfix" in message body >>>>>Archive http://ipfix.doit.wisc.edu/archive/ >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Aug 29 19:11:08 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14802 for ; Thu, 29 Aug 2002 19:11:08 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17kYJB-0002d1-00 for ipfix-list@mil.doit.wisc.edu; Thu, 29 Aug 2002 18:02:37 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17kYJ7-0002cF-00 for ipfix-req@net.doit.wisc.edu; Thu, 29 Aug 2002 18:02:33 -0500 Received: from cisco.com (bclaise-isdn-home2.cisco.com [10.49.4.219]) by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id g7TN1r704843; Fri, 30 Aug 2002 01:01:53 +0200 (CEST) Message-ID: <3D6EA7E0.8050301@cisco.com> Date: Fri, 30 Aug 2002 01:01:52 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020815 X-Accept-Language: en-us, en MIME-Version: 1.0 To: calato@riverstonenet.com CC: Juergen Quittek , req Subject: Re: fragmented packets (was: Re: [ipfix-req] IPFIX Requirements Questions) References: <3D6CCAE5.1BF2C42D@riverstonenet.com> <25723999.1030551643@[192.168.102.164]> <3D6DF431.60800@cisco.com> <3D6E77F9.FB5E16F9@riverstonenet.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Paul, Juergen and all, >Benoit Claise wrote: > > >>Paul and Juergen, >> >> >> >>>Hi Paul, >>> >>>--On 28 August 2002 09:06 -0400 calato@riverstonenet.com wrote: >>> >>> >>> >>>>Juergen Quittek wrote: >>>> >>>> >>>> >>>>>Hi Paul, >>>>> >>>>>--On 27 August 2002 20:26 -0400 calato@riverstonenet.com wrote: >>>>> >>>>> >>>>> >>>>>>Juergen Quittek wrote: >>>>>> >>>>>> >>>>>>>--On 27 August 2002 14:49 -0400 calato@riverstonenet.com wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>>As I work on the advocates document some questions >>>>>>>>have come to mind on the requirements document. >>>>>>>> >>>>>>>>4.3 Distinguishing flows using Transport Header Fields >>>>>>>> >>>>>>>> In the case of fragmented packets there are >>>>>>>> no port numbers. Are we saying flow state information >>>>>>>> MUST be maintained? In general, it is not clear from >>>>>>>> >>>>>>>> >>>>>>>No, the requirements document does not say so. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> the document what the requirements are for fragmented >>>>>>>> packets. >>>>>>>> >>>>>>>> >>>>>>>I think the requirements should not include a requirement for >>>>>>>keeping state of fragmented packets. Would you like to see >>>>>>>an explicit statement on that? This would be a NO NEED FOR >>>>>>>statement :-) >>>>>>> >>>>>>> >>>>>> I think we need to be explicit. Most people will think >>>>>> of fragements as being counted in the same flow as the >>>>>> first packet not as 2 differernt flows. >>>>>> >>>>>> >>>>>I see. Waht about adding a new subsection to Section "5. Metering >>>>>Process": >>>>> >>>>>5.8. Packet Fragmentation >>>>> >>>>> In case of IP packet fragmentation, only one fragment of a single >>>>> packet might contain sufficient information for classifying the >>>>> packet correctly. The metering process MAY keep state of >>>>> IP packet fragmentation in order to map fragments that do not >>>>> contain sufficient header information correctly to flows. >>>>> >>>>> >>>> How about a slight re-wording... >>>> >>>> In case of IP datagram fragmentation, only the first fragment might >>>> contain sufficient information for classifying the packet correctly. >>>> The metering process MAY keep state of IP fragmentation in order to >>>> map fragments without sufficient header information to the same >>>> flow as the first fragmented packet. >>>> >>>> >>>Initially I also wanted to phrase like this. But it's IP. And fragments >>>might get re-ordered. The first fragment of a packet that is observed, >>>is not necessarily the fragment containing the TCP/UDP header. >>> >>>Now, if you say "first", it is not clear whether you mean the fragment >>>with the first bytes of the IP payload or the first fragment observed >>>at the observation point. Your last sentence seems to assume that the >>>first observed packet is the one with the first bytes of the payload. >>> >>> >>Why not merge your 2 texts: >> >> In case of IP packet fragmentation, only one fragment of the initial >> packet might contain sufficient information for classifying the >> packet correctly. Note that this fragment is the first one generated >> by the router imposing the fragmentation, but might not be the first >> one observed by the IPFIX device, due reordering reasons. >> The metering process MAY keep state of IP packet fragmentation >> in order to map fragments that do not contain sufficient header >> information correctly to flows. >> >> >> > > Juergen suggested a merged text. Are you suggesting > an alternative? > To summarize: Juergen proposed: In case of IP datagram fragmentation, for many typical classification schemes, only one fragment contains sufficient information to classify the packet. I proposed above: In case of IP packet fragmentation, only one fragment of the initial packet might contain sufficient information for classifying the packet correctly. Note that this fragment is the first one generated by the router imposing the fragmentation, but might not be the first one observed by the IPFIX device, due reordering reasons. The metering process MAY keep state of IP packet fragmentation in order to map fragments that do not contain sufficient header information correctly to flows. I think both of them express the same idea. The second one maybe contains some more clarifications. So I'm not really in favor of one or the other. Choose the one that you want to. I'm not sure what were your conclusions for fragmentation and section "6.1 Information Model" 1. Have something like (implicitely talking about fragmentation): 9. packet counter Which packets are counted MUST be defined exactly. 10. byte counter Which bytes of a packet are counted MUST be defined exactly. OR 2. 9. packet counter Which packets are counted MUST be defined exactly. 10. byte counter Which bytes of a packet are counted MUST be defined exactly. And an extra sentence about fragmentation. "The behavior of the byte and packet counters in case of IP packet fragmentation MUST be clearly defined." Regards, Benoit. > > > >>> >>> >>>>> [...] >>>>> >>>>> >>>>> >>>>>>>>6.1 information Model >>>>>>>> >>>>>>>> 9 Packet Counter >>>>>>>> 10 Byte counter >>>>>>>> >>>>>>>> As mentioned earlier, for fragments this >>>>>>>> requires state information? If there is no >>>>>>>> state info, then what flow are the counted >>>>>>>> towards? >>>>>>>> >>>>>>>> >>>>>>>Do you suggest to include a requirement for keeping fragment >>>>>>> >>>>>>> >>>>>state info? >>>>> >>>>> >>>>>> A MAY is as far as I would go. There may certainly be probes >>>>>> that have this capability. We should have a requirement that >>>>>> says fragment counting MUST be clearly defined. >>>>>> >>>>>> >>>>>OK. Currently, we have >>>>> >>>>> 9. packet counter >>>>> If a packet is fragmented, each fragment is counted as an >>>>> individual packet. >>>>> 10. byte counter >>>>> Which bytes of a packet are counted MUST be defined exactly. >>>>> >>>>>What about appending >>>>> >>>>> The behavior of the byte counter in case of IP packet >>>>> fragmentation MUST be clearly defined. >>>>> >>>>> >>>> With the new section on fragmentation I think we can >>>> eliminate any mention of it on the counters. >>>> >>>> >>>The new section of the fragmentation is a MAY requirement. But for >>>understamding the behavior of the byte counter you MUST know whether >>>or not the option is implemented. >>> >>> >>So, haven't we enough with "The behavior of the byte and packet counters >>in case of IP packet >> fragmentation MUST be clearly defined."? >> We need the packet counter in the sentence above: to know if the flow >>state information is maintained for fragemented packets >> >> >> >>> >>> >>>>>? >>>>> >>>>>Please note that we also have in the MAY attributes section >>>>> >>>>> 26. fragmented packet counter >>>>> counter of all packets for which the fragmented bit is set in >>>>> the IP header >>>>> >>>>> >>>> I'm not sure why this was added. If you want that info, >>>> make the IP fragment bit part of the flow definition. >>>> >>>> >>It makes sense. >> >>Regards, Benoit >> >> >> >>>Do you suggest to remove it? Anyone else? >>> >>> >>> Juergen >>> >>> >>> >>>-- >>>Help mailto:majordomo@net.doit.wisc.edu and say "help" in >>>message body >>>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>>"unsubscribe ipfix" in message body >>>Archive http://ipfix.doit.wisc.edu/archive/ >>> >>> -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Aug 29 20:03:42 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15959 for ; Thu, 29 Aug 2002 20:03:42 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17kZ5s-0003gC-00 for ipfix-list@mil.doit.wisc.edu; Thu, 29 Aug 2002 18:52:56 -0500 Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17kZ5q-0003fM-00 for ipfix-req@net.doit.wisc.edu; Thu, 29 Aug 2002 18:52:54 -0500 Received: from mira-sjcd-1.cisco.com (IDENT:mirapoint@mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g7TNqNKB016212; Thu, 29 Aug 2002 16:52:23 -0700 (PDT) Received: from cisco.com (dhcp-171-71-137-31.cisco.com [171.71.137.31]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ADK47770; Thu, 29 Aug 2002 16:52:49 -0700 (PDT) Message-ID: <3D6EB3B4.E582EDE5@cisco.com> Date: Thu, 29 Aug 2002 16:52:21 -0700 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: calato@riverstonenet.com CC: req Subject: Re: [ipfix-req] IPFIX Requirements Questions References: <3D6BC9AD.CAC153C8@riverstonenet.com> <3D6E79C9.AB8020FE@cisco.com> <3D6E86F1.1CF943F0@riverstonenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit calato@riverstonenet.com wrote: > Ganesh Sadasivan wrote: > > > > calato@riverstonenet.com wrote: > > > > > As I work on the advocates document some questions > > > have come to mind on the requirements document. > > > > > > 4.3 Distinguishing flows using Transport Header Fields > > > > > > In the case of fragmented packets there are > > > no port numbers. Are we saying flow state information > > > MUST be maintained? In general, it is not clear from > > > the document what the requirements are for fragmented > > > packets. > > > > I do not see a way to distinguishing flows for fragmented packets > > and not all fragments pass through the same router. > > Right. Keeping state is no guarentee. > > > > > > > > > > > > 4.4 MPLS Label > > > > > > In the case of dynamic LSP's the label is not useful. > > > Why require distinguishing flows based on label. > > > What can be done with that information? > > > > If we can get a label to prefix mapping (from the control plane) > > then it would be be very useful information. So I think this defn. > > still holds good. > > Who is "we"? If you mean the Collecting Process, then > querying the device after the fact has problems since > LSPs are dynamic. The association of {incoming label, FEC} is available at the exporter (referred to as "we") and application that it points to. I am not sure how dynamic this information is -I guess it depends on the label type (TE-tunnel, BGP label, IGP label, VPN label etc). These associations when made available to the collector with timestamping, it can do the mapping from "label in flow record" -> FEC/application/etc. Infact there are vendors interested in getting this kind of information. > > > > > > > > > > > > > 5.3 Overload Behavior > > > > > > This section needs to be re-worked a little. Some > > > of the MUST's impose undue burden on the device. > > > > > > 1. Must distinguish flow records before and after the > > > behavior change. > > > > Probably the intention is that it is one of the flow expiration > > reasons. But I am not sure whether it needs to be tied with > > a flow is it is the device's behavior. So keeping a MUST here > > does not seem to be required. > > > > > > > > > > > In the case where the behavior is to drop > > > overflow flows, why do we need to distinguish > > > flows. Perhaps I misunderstood something. > > > > > > 2. All flows from previous behavior MUST be terminated. > > > > > > > > > > > > > > Again, if I simply dropped excess flows why terminate > > > all existing ones. This will likely cause more overflow > > > as the get reestablished. This also seems to go to > > > far towards implementation. > > > > > > > I do not understand why. The reason you stated above is > > good enough for this not to be done. > > I'm not sure I follow. The cost of terminating and > re-establishing millions of flow is not reason enough? I am in sync with you. > > > > > > > > > > 3. Meeting process MUST NOT merge previous records. > > > > > > I think what we are trying to say is flows with a different > > > definition MUST be distinguishable. How that is done is not > > > part of the requirements doc. > > > > What I understand here is that 3 different flow records be cretaed > > * prior to overload > > * overload > > * post overload > > While I can udnderstand this from an export process perspective, > > I am not sure how much sense it makes to go per flow on overload. > > > > > > > > > > > 5.4 Timestamps > > > > > > Time stamps to not always mapped to the first packet and last > > > packet. In many cases, the end timestamp is merely when > > > the flow timed out and has nothing to do with when the > > > last packet was seen. Allowing both semantics may be useful. > > > A re-wording like this... > > > > While there may be a minor delay in setting the timestamp after the > > last packet is seen, > > If the hardware stamps all packets, no problem. If the > software has to do it, how do you know what the last packet > is? I'm confused. If there is a mechanism to detect the flow end by means of packet or otherwise, then it is possible to get a fine grained granularity. If otherwise, there could be some periodic mechanisms (operating in msec periodicity) that poll of counter deltas for each flow & update the timestamp. > > > > I am not sure by the above statement that > > "has nothing to do with when the last packet was seen." > > Is it not the > > case that the flow was alive at this observation point only till it saw the > > last packet? > > In the case of timeout, it is the time at which the device > noticed that there were no more packets since the last time > it checked. It does not know the time of the last packet > observed. > > > > > > > > > > > > The metering process MUST be able to generate timestamps for the > > > start and end of a flow. The metering process MAY also provide > > > timestamps for the first and the last observed packet > > > of a flow. The timestamp resolution MUST be at least the one of > > > the sysUpTime [RFC1213], which is one centisecond. > > > > > > Note - this does not mandate 2 timestamp fields for a flow. You > > > could have one element for each meaning (e.g. Flow-start-time, > > > first-packet-time, flow-start-and-first-packet-time) and use > > > the one with the desired meaning. > > > > > > 6.1 information Model > > > > > > 9 Packet Counter > > > 10 Byte counter > > > > > > As mentioned earlier, for fragments this > > > requires state information? If there is no > > > state info, then what flow are the counted > > > towards? > > > > > > 13 BGP AS number > > > > > > Is this the AS number for the observation point, the > > > source/destination address in the packet or some > > > combination? > > > > Correct me if I'm wrong - usually a set of prefixes are associated with an AS. > > An observation point is too vague a definition to associate to an AS. Say > > it is a router LC, there could be multiple ASs within it. > > But suppose the entire router is in a single AS. Should > we report it? > Why not? > > In your example, maybe we report a list. > > > > > > > > > > > > 14. MPLS Label > > > > > > As stated earlier, in the case of dynamic LSP's the > > > label has no meaning. > > > > > > 21 multicast replication number > > > > > > The document stated this can change over the life > > > of the flow. But no mention of what happens when > > > it changes. Is that a new flow? If not, what meaning > > > does it have when reported? What can I do with it? > > > > It would be useful if the collector is going to calculate the > > replication factor over a period of time. > > > > > > > > > > > > > > 6.2 Data Model > > > > > > What about allowing Vendors to add information independently? > > > Some data to be transported may be vendor specific and never > > > make it into the IPFIX spec. > > > > > > 8.3 Several Collecting Processes > > > > > > No mention is made when reporting to several devices > > > of ensuring the duplicate data does not cause a double > > > counting problem. > > > > > > > I must have forgotten. Can you elaborate a little more? > > Depends on why you are reporting to 2 devices. If > it is for completely different applications, no problem. > But if there is a sharing of data for back up purposes > or any other reason then ensuring you don't double > count comes into play. Ok, I understand the application. Probably then it is a good idea to associate the flows with the latest timestamp which is put on the export packet when it is sent out. Just a thought. -ganesh > > > > > > Thanks > > Ganesh > > > > > > > > 9. Special Device Considerations > > > > > > I'm not sure of the meaning for the following... > > > > > > ... > > > > > > Please note that here, the observation > > > point of a single flow cannot exceed the set of most fine-granular > > > observation points linked to a single metering process, because only > > > the metering process can merge packets observed at different fine- > > > granular observation points to a joint flow. > > > > > > ... > > > > > > Also the > > > locations of metering processes are not of any relevance for this > > > document (in contrast to the locations of observation points and the > > > exporting processes). > > > > > > Paul > > > > > > -- > > > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > > "unsubscribe ipfix" in message body > > > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Aug 30 03:54:00 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06524 for ; Fri, 30 Aug 2002 03:53:59 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17kgQg-0006jh-00 for ipfix-list@mil.doit.wisc.edu; Fri, 30 Aug 2002 02:42:54 -0500 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17kgQd-0006iy-00 for ipfix-eval@net.doit.wisc.edu; Fri, 30 Aug 2002 02:42:51 -0500 Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g7U7gHU08208; Fri, 30 Aug 2002 09:42:18 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 952D556EEF; Fri, 30 Aug 2002 09:42:16 +0200 (CEST) Date: Fri, 30 Aug 2002 09:42:17 +0200 From: Juergen Quittek To: ram.gopal@nokia.com Cc: n.brownlee@auckland.ac.nz, ipfix-eval@net.doit.wisc.edu Subject: RE: reminder (was Re: [ipfix-eval] IPFIX Evaluation: update) Message-ID: <1431588.1030700537@[192.168.102.164]> In-Reply-To: References: X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Ram, You may be right, but how do you interpret the phrase "Advocacy drafts published" in this sniplet from Nevil's message? > > 2 September Cutoff for Protocol Submissions to Evaluation Team > > Advocacy drafts published Juergen -- ram.gopal@nokia.com wrote on 29 August 2002 14:13 -0400: > Hello Juergen, > > The 2 September is cut-off date for "protocol submission" and not > "protocol evaluation" document. > > > Regards > Ramg > >> -----Original Message----- >> From: ext Juergen Quittek [mailto:quittek@ccrle.nec.de] >> Sent: Thursday, August 29, 2002 12:50 PM >> To: Nevil Brownlee; ipfix-eval@net.doit.wisc.edu >> Subject: reminder (was Re: [ipfix-eval] IPFIX Evaluation: update) >> >> >> Dear protocol advocates: >> >> -- Nevil Brownlee wrote on 07 August 2002 15:13 +1200: >> >> > Hello all: >> > >> > At the IPFIX meeting in Yokohama we reached consensus on >> the evaluation >> > process, with the following timetable: >> > >> > 5 July Publish Protocol Advocacy draft and Call >> for Submissions >> > >> > 15 July Work on consensus in Yokohama, agree on timetable >> > >> > 2 September Cutoff for Protocol Submissions to Evaluation Team >> > Advocacy drafts published >> >> Please do not miss the cutoff date for the protocol >> evaluation drafts on next Monday. >> >> 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 >> >> -- >> Help mailto:majordomo@net.doit.wisc.edu and say "help" >> 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 Aug 30 08:27:50 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13807 for ; Fri, 30 Aug 2002 08:27:49 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17kkcu-0006tb-00 for ipfix-list@mil.doit.wisc.edu; Fri, 30 Aug 2002 07:11:48 -0500 Received: from mgw-dax1.ext.nokia.com ([63.78.179.216]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17kkcs-0006tS-00 for ipfix-eval@net.doit.wisc.edu; Fri, 30 Aug 2002 07:11:46 -0500 Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g7UCCKx20699 for ; Fri, 30 Aug 2002 07:12:20 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 30 Aug 2002 07:11:43 -0500 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 30 Aug 2002 07:11:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: reminder (was Re: [ipfix-eval] IPFIX Evaluation: update) Date: Fri, 30 Aug 2002 08:11:21 -0400 Message-ID: Thread-Topic: reminder (was Re: [ipfix-eval] IPFIX Evaluation: update) Thread-Index: AcJP+eebiF2h3zh5Q4yoVSpdveOPrQAJDMLg From: To: Cc: , X-OriginalArrivalTime: 30 Aug 2002 12:11:22.0491 (UTC) FILETIME=[5AF2FCB0:01C2501E] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA13807 Hello Juergen, I interpreted as Sep 2 is deadline for submission to evaluation team. Then at earliest we should produce the evaluation document for discussion not exactly on Sep 2. Regards Ramg > -----Original Message----- > From: ext Juergen Quittek [mailto:quittek@ccrle.nec.de] > Sent: Friday, August 30, 2002 3:42 AM > To: Gopal Ram (NRC/Boston) > Cc: n.brownlee@auckland.ac.nz; ipfix-eval@net.doit.wisc.edu > Subject: RE: reminder (was Re: [ipfix-eval] IPFIX Evaluation: update) > > > Hi Ram, > > You may be right, but how do you interpret the phrase > "Advocacy drafts published" in this sniplet from Nevil's > message? > > > > 2 September Cutoff for Protocol Submissions to > Evaluation Team > > > Advocacy drafts published > > Juergen > > > -- ram.gopal@nokia.com wrote on 29 August 2002 14:13 -0400: > > > Hello Juergen, > > > > The 2 September is cut-off date for "protocol submission" and not > > "protocol evaluation" document. > > > > > > Regards > > Ramg > > > >> -----Original Message----- > >> From: ext Juergen Quittek [mailto:quittek@ccrle.nec.de] > >> Sent: Thursday, August 29, 2002 12:50 PM > >> To: Nevil Brownlee; ipfix-eval@net.doit.wisc.edu > >> Subject: reminder (was Re: [ipfix-eval] IPFIX Evaluation: update) > >> > >> > >> Dear protocol advocates: > >> > >> -- Nevil Brownlee wrote on 07 August 2002 15:13 +1200: > >> > >> > Hello all: > >> > > >> > At the IPFIX meeting in Yokohama we reached consensus on > >> the evaluation > >> > process, with the following timetable: > >> > > >> > 5 July Publish Protocol Advocacy draft and Call > >> for Submissions > >> > > >> > 15 July Work on consensus in Yokohama, agree on > timetable > >> > > >> > 2 September Cutoff for Protocol Submissions to > Evaluation Team > >> > Advocacy drafts published > >> > >> Please do not miss the cutoff date for the protocol > >> evaluation drafts on next Monday. > >> > >> 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 >> >> -- >> Help mailto:majordomo@net.doit.wisc.edu and say "help" >> in message body >> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >> "unsubscribe ipfix" in message body >> Archive http://ipfix.doit.wisc.edu/archive/ >> -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Aug 30 08:29:01 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13888 for ; Fri, 30 Aug 2002 08:29:01 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17kkjc-00076U-00 for ipfix-list@mil.doit.wisc.edu; Fri, 30 Aug 2002 07:18:44 -0500 Received: from mgw-dax2.ext.nokia.com ([63.78.179.217]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17kkjZ-00076O-00 for ipfix-eval@net.doit.wisc.edu; Fri, 30 Aug 2002 07:18:42 -0500 Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g7UCIrM00934 for ; Fri, 30 Aug 2002 07:18:53 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 30 Aug 2002 07:18:40 -0500 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 30 Aug 2002 05:18:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: reminder (was Re: [ipfix-eval] IPFIX Evaluation: update) Date: Fri, 30 Aug 2002 08:18:26 -0400 Message-ID: Thread-Topic: reminder (was Re: [ipfix-eval] IPFIX Evaluation: update) Thread-Index: AcJP+eebiF2h3zh5Q4yoVSpdveOPrQAJJBfA From: To: Cc: , X-OriginalArrivalTime: 30 Aug 2002 12:18:27.0384 (UTC) FILETIME=[58348380:01C2501F] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA13888 Hello Juergen, Sorry, the earlier email slips out of my hands. I interpreted as Sep 2 deadline for submission to evaluation team. Then at the earliest we should produce the evaluation document to the mailing list for enough debate/discussion and it need not be on Sep 2nd itself. FYI, I have completed reading all the IPFIX candidates and in half way mark in documenting as per template. On the other side, I am also waiting till Sep 2nd to see any other IPFIX candidate protocol submission. Regards Ramg > Hi Ram, > > You may be right, but how do you interpret the phrase > "Advocacy drafts published" in this sniplet from Nevil's > message? > > > > 2 September Cutoff for Protocol Submissions to > Evaluation Team > > > Advocacy drafts published > > Juergen > > > -- ram.gopal@nokia.com wrote on 29 August 2002 14:13 -0400: > > > Hello Juergen, > > > > The 2 September is cut-off date for "protocol submission" and not > > "protocol evaluation" document. > > > > > > Regards > > Ramg > > > >> -----Original Message----- > >> From: ext Juergen Quittek [mailto:quittek@ccrle.nec.de] > >> Sent: Thursday, August 29, 2002 12:50 PM > >> To: Nevil Brownlee; ipfix-eval@net.doit.wisc.edu > >> Subject: reminder (was Re: [ipfix-eval] IPFIX Evaluation: update) > >> > >> > >> Dear protocol advocates: > >> > >> -- Nevil Brownlee wrote on 07 August 2002 15:13 +1200: > >> > >> > Hello all: > >> > > >> > At the IPFIX meeting in Yokohama we reached consensus on > >> the evaluation > >> > process, with the following timetable: > >> > > >> > 5 July Publish Protocol Advocacy draft and Call > >> for Submissions > >> > > >> > 15 July Work on consensus in Yokohama, agree on > timetable > >> > > >> > 2 September Cutoff for Protocol Submissions to > Evaluation Team > >> > Advocacy drafts published > >> > >> Please do not miss the cutoff date for the protocol > >> evaluation drafts on next Monday. > >> > >> 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 > >> > >> -- > >> Help mailto:majordomo@net.doit.wisc.edu and say "help" > >> in message body > >> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > >> "unsubscribe ipfix" in message body > >> Archive http://ipfix.doit.wisc.edu/archive/ > >> > > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" > in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Aug 30 09:47:28 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17017 for ; Fri, 30 Aug 2002 09:47:27 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17klyE-00018l-00 for ipfix-list@mil.doit.wisc.edu; Fri, 30 Aug 2002 08:37:55 -0500 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17klyC-00018O-00 for ipfix-eval@net.doit.wisc.edu; Fri, 30 Aug 2002 08:37:52 -0500 Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g7UDbDU23658; Fri, 30 Aug 2002 15:37:13 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 2569A5DE05; Fri, 30 Aug 2002 15:37:11 +0200 (CEST) Date: Fri, 30 Aug 2002 15:37:11 +0200 From: Juergen Quittek To: ram.gopal@nokia.com Cc: n.brownlee@auckland.ac.nz, ipfix-eval@net.doit.wisc.edu Subject: RE: reminder (was Re: [ipfix-eval] IPFIX Evaluation: update) Message-ID: <22725026.1030721831@[192.168.102.164]> In-Reply-To: References: X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Ram, -- ram.gopal@nokia.com wrote on 30 August 2002 08:18 -0400: > Hello Juergen, > > Sorry, the earlier email slips out of my hands. I interpreted as Sep 2 deadline for submission to evaluation team. Yes. Now I see what you mean. I just wanted to remind the declared (and all other potential) advocates of the deadline for the advocacy drafts that contain individual protocol evaluations. Of course the deadline of the joint evaluation draft is later. > Then at the earliest we should produce the evaluation document to the mailing list for enough debate/discussion and it need not be on Sep 2nd itself. You are right. The joint draft is scheduled for Oct. 16. > > FYI, I have completed reading all the IPFIX candidates and in half way mark in documenting as per template. On the other side, I am also waiting till Sep 2nd to see any other IPFIX candidate protocol submission. > Great! Juergen > > Regards > Ramg > >> Hi Ram, >> >> You may be right, but how do you interpret the phrase >> "Advocacy drafts published" in this sniplet from Nevil's >> message? >> >> > > 2 September Cutoff for Protocol Submissions to >> Evaluation Team >> > > Advocacy drafts published >> >> Juergen >> >> >> -- ram.gopal@nokia.com wrote on 29 August 2002 14:13 -0400: >> >> > Hello Juergen, >> > >> > The 2 September is cut-off date for "protocol submission" and not >> > "protocol evaluation" document. >> > >> > >> > Regards >> > Ramg >> > >> >> -----Original Message----- >> >> From: ext Juergen Quittek [mailto:quittek@ccrle.nec.de] >> >> Sent: Thursday, August 29, 2002 12:50 PM >> >> To: Nevil Brownlee; ipfix-eval@net.doit.wisc.edu >> >> Subject: reminder (was Re: [ipfix-eval] IPFIX Evaluation: update) >> >> >> >> >> >> Dear protocol advocates: >> >> >> >> -- Nevil Brownlee wrote on 07 August 2002 15:13 +1200: >> >> >> >> > Hello all: >> >> > >> >> > At the IPFIX meeting in Yokohama we reached consensus on >> >> the evaluation >> >> > process, with the following timetable: >> >> > >> >> > 5 July Publish Protocol Advocacy draft and Call >> >> for Submissions >> >> > >> >> > 15 July Work on consensus in Yokohama, agree on >> timetable >> >> > >> >> > 2 September Cutoff for Protocol Submissions to >> Evaluation Team >> >> > Advocacy drafts published >> >> >> >> Please do not miss the cutoff date for the protocol >> >> evaluation drafts on next Monday. >> >> >> >> 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 >> >> >> >> -- >> >> Help mailto:majordomo@net.doit.wisc.edu and say "help" >> >> in message body >> >> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >> >> "unsubscribe ipfix" in message body >> >> Archive http://ipfix.doit.wisc.edu/archive/ >> >> >> >> >> >> -- >> Help mailto:majordomo@net.doit.wisc.edu and say "help" >> in message body >> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >> "unsubscribe ipfix" in message body >> Archive http://ipfix.doit.wisc.edu/archive/ >> -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Aug 30 10:32:35 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19039 for ; Fri, 30 Aug 2002 10:32:34 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17kmYu-0002CI-00 for ipfix-list@mil.doit.wisc.edu; Fri, 30 Aug 2002 09:15:48 -0500 Received: from [64.95.122.60] (helo=RS-SC-EXC4.rs.riverstonenet.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17kmYs-0002Bf-00 for ipfix-req@net.doit.wisc.edu; Fri, 30 Aug 2002 09:15:46 -0500 Received: from riverstonenet.com ([134.141.180.105]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 30 Aug 2002 07:15:12 -0700 Message-ID: <3D6F7D8A.337CA9D5@riverstonenet.com> Date: Fri, 30 Aug 2002 10:13:30 -0400 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Benoit Claise CC: Juergen Quittek , req Subject: Re: fragmented packets (was: Re: [ipfix-req] IPFIX Requirements Questions) References: <3D6CCAE5.1BF2C42D@riverstonenet.com> <25723999.1030551643@[192.168.102.164]> <3D6DF431.60800@cisco.com> <3D6E77F9.FB5E16F9@riverstonenet.com> <3D6EA7E0.8050301@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Aug 2002 14:15:13.0435 (UTC) FILETIME=[A8230EB0:01C2502F] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Benoit Claise wrote: > > Paul, Juergen and all, > > >Benoit Claise wrote: > > > > > >>Paul and Juergen, > >> > >> > >> > >>>Hi Paul, > >>> > >>>--On 28 August 2002 09:06 -0400 calato@riverstonenet.com wrote: > >>> > >>> > >>> > >>>>Juergen Quittek wrote: > >>>> > >>>> > >>>> > >>>>>Hi Paul, > >>>>> > >>>>>--On 27 August 2002 20:26 -0400 calato@riverstonenet.com wrote: > >>>>> > >>>>> > >>>>> > >>>>>>Juergen Quittek wrote: > >>>>>> > >>>>>> > >>>>>>>--On 27 August 2002 14:49 -0400 calato@riverstonenet.com wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>As I work on the advocates document some questions > >>>>>>>>have come to mind on the requirements document. > >>>>>>>> > >>>>>>>>4.3 Distinguishing flows using Transport Header Fields > >>>>>>>> > >>>>>>>> In the case of fragmented packets there are > >>>>>>>> no port numbers. Are we saying flow state information > >>>>>>>> MUST be maintained? In general, it is not clear from > >>>>>>>> > >>>>>>>> > >>>>>>>No, the requirements document does not say so. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> the document what the requirements are for fragmented > >>>>>>>> packets. > >>>>>>>> > >>>>>>>> > >>>>>>>I think the requirements should not include a requirement for > >>>>>>>keeping state of fragmented packets. Would you like to see > >>>>>>>an explicit statement on that? This would be a NO NEED FOR > >>>>>>>statement :-) > >>>>>>> > >>>>>>> > >>>>>> I think we need to be explicit. Most people will think > >>>>>> of fragements as being counted in the same flow as the > >>>>>> first packet not as 2 differernt flows. > >>>>>> > >>>>>> > >>>>>I see. Waht about adding a new subsection to Section "5. Metering > >>>>>Process": > >>>>> > >>>>>5.8. Packet Fragmentation > >>>>> > >>>>> In case of IP packet fragmentation, only one fragment of a single > >>>>> packet might contain sufficient information for classifying the > >>>>> packet correctly. The metering process MAY keep state of > >>>>> IP packet fragmentation in order to map fragments that do not > >>>>> contain sufficient header information correctly to flows. > >>>>> > >>>>> > >>>> How about a slight re-wording... > >>>> > >>>> In case of IP datagram fragmentation, only the first fragment might > >>>> contain sufficient information for classifying the packet correctly. > >>>> The metering process MAY keep state of IP fragmentation in order to > >>>> map fragments without sufficient header information to the same > >>>> flow as the first fragmented packet. > >>>> > >>>> > >>>Initially I also wanted to phrase like this. But it's IP. And fragments > >>>might get re-ordered. The first fragment of a packet that is observed, > >>>is not necessarily the fragment containing the TCP/UDP header. > >>> > >>>Now, if you say "first", it is not clear whether you mean the fragment > >>>with the first bytes of the IP payload or the first fragment observed > >>>at the observation point. Your last sentence seems to assume that the > >>>first observed packet is the one with the first bytes of the payload. > >>> > >>> > >>Why not merge your 2 texts: > >> > >> In case of IP packet fragmentation, only one fragment of the initial > >> packet might contain sufficient information for classifying the > >> packet correctly. Note that this fragment is the first one generated > >> by the router imposing the fragmentation, but might not be the first > >> one observed by the IPFIX device, due reordering reasons. > >> The metering process MAY keep state of IP packet fragmentation > >> in order to map fragments that do not contain sufficient header > >> information correctly to flows. > >> > >> > >> > > > > Juergen suggested a merged text. Are you suggesting > > an alternative? > > > To summarize: > > Juergen proposed: > In case of IP datagram fragmentation, for many typical > classification schemes, only one fragment contains > sufficient information to classify the packet. ^^^^^^ fragment With the above change I think this is clear and easy to read. > > I proposed above: > > In case of IP packet fragmentation, only one fragment of the initial > packet might contain sufficient information for classifying the > packet correctly. Note that this fragment is the first one generated > by the router imposing the fragmentation, but might not be the first > one observed by the IPFIX device, due reordering reasons. > The metering process MAY keep state of IP packet fragmentation > in order to map fragments that do not contain sufficient header > information correctly to flows. This one is OK but goes into explanation I'm not sure is necessary if you assume familiarity with IP. Also, there are 3 terms "initial packet", "packet" and "fragment". So I get a bit lost. But either way will suffice as far as I'm concerned. > > I think both of them express the same idea. > The second one maybe contains some more clarifications. > > So I'm not really in favor of one or the other. Choose the one that you want to. > > I'm not sure what were your conclusions for fragmentation and section "6.1 Information Model" > > 1. Have something like (implicitely talking about fragmentation): > 9. packet counter > Which packets are counted MUST be defined exactly. > 10. byte counter > Which bytes of a packet are counted MUST be defined exactly. Which bytes are counted is a legitimate issue. Do we include ethernet headers, IP headers, CRC, etc...In other words some bytes are never counted under ANY circumstances. I don't see similar issues for the packet counter. As soon as you start talking about which flow a packet gets counted against, it is a "Distinguishing Properties" issue. If you talk about what flows get counted it is a configuration issue. The question on fragment is are they distinguished by the full header information or just a subset. > > OR > > 2. > 9. packet counter > Which packets are counted MUST be defined exactly. > 10. byte counter > Which bytes of a packet are counted MUST be defined exactly. > And an extra sentence about fragmentation. > "The behavior of the byte and packet counters in case of IP packet fragmentation MUST be clearly defined." > > Regards, Benoit. > > > > > > > > >>> > >>> > >>>>> [...] > >>>>> > >>>>> > >>>>> > >>>>>>>>6.1 information Model > >>>>>>>> > >>>>>>>> 9 Packet Counter > >>>>>>>> 10 Byte counter > >>>>>>>> > >>>>>>>> As mentioned earlier, for fragments this > >>>>>>>> requires state information? If there is no > >>>>>>>> state info, then what flow are the counted > >>>>>>>> towards? > >>>>>>>> > >>>>>>>> > >>>>>>>Do you suggest to include a requirement for keeping fragment > >>>>>>> > >>>>>>> > >>>>>state info? > >>>>> > >>>>> > >>>>>> A MAY is as far as I would go. There may certainly be probes > >>>>>> that have this capability. We should have a requirement that > >>>>>> says fragment counting MUST be clearly defined. > >>>>>> > >>>>>> > >>>>>OK. Currently, we have > >>>>> > >>>>> 9. packet counter > >>>>> If a packet is fragmented, each fragment is counted as an > >>>>> individual packet. > >>>>> 10. byte counter > >>>>> Which bytes of a packet are counted MUST be defined exactly. > >>>>> > >>>>>What about appending > >>>>> > >>>>> The behavior of the byte counter in case of IP packet > >>>>> fragmentation MUST be clearly defined. > >>>>> > >>>>> > >>>> With the new section on fragmentation I think we can > >>>> eliminate any mention of it on the counters. > >>>> > >>>> > >>>The new section of the fragmentation is a MAY requirement. But for > >>>understamding the behavior of the byte counter you MUST know whether > >>>or not the option is implemented. > >>> > >>> > >>So, haven't we enough with "The behavior of the byte and packet counters > >>in case of IP packet > >> fragmentation MUST be clearly defined."? > >> We need the packet counter in the sentence above: to know if the flow > >>state information is maintained for fragemented packets > >> > >> > >> > >>> > >>> > >>>>>? > >>>>> > >>>>>Please note that we also have in the MAY attributes section > >>>>> > >>>>> 26. fragmented packet counter > >>>>> counter of all packets for which the fragmented bit is set in > >>>>> the IP header > >>>>> > >>>>> > >>>> I'm not sure why this was added. If you want that info, > >>>> make the IP fragment bit part of the flow definition. > >>>> > >>>> > >>It makes sense. > >> > >>Regards, Benoit > >> > >> > >> > >>>Do you suggest to remove it? Anyone else? > >>> > >>> > >>> Juergen > >>> > >>> > >>> > >>>-- > >>>Help mailto:majordomo@net.doit.wisc.edu and say "help" in > >>>message body > >>>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > >>>"unsubscribe ipfix" in message body > >>>Archive http://ipfix.doit.wisc.edu/archive/ > >>> > >>> -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Aug 30 10:38:43 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19275 for ; Fri, 30 Aug 2002 10:38:42 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17kmip-0002PO-00 for ipfix-list@mil.doit.wisc.edu; Fri, 30 Aug 2002 09:26:03 -0500 Received: from [64.95.122.60] (helo=RS-SC-EXC4.rs.riverstonenet.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17kmil-0002OU-00 for ipfix-req@net.doit.wisc.edu; Fri, 30 Aug 2002 09:25:59 -0500 Received: from riverstonenet.com ([134.141.180.105]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 30 Aug 2002 07:25:26 -0700 Message-ID: <3D6F7FF1.AAE20A81@riverstonenet.com> Date: Fri, 30 Aug 2002 10:23:45 -0400 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Benoit Claise CC: Juergen Quittek , req Subject: Re: MPLS label (was:Re: [ipfix-req] IPFIX Requirements Questions) References: <3D6E012A.6010804@cisco.com> <34028240.1030638935@[192.168.102.164]> <3D6E3B5C.90404@cisco.com> <3D6E7B3F.6EF78048@riverstonenet.com> <3D6EA348.5040908@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Aug 2002 14:25:27.0447 (UTC) FILETIME=[161DDA70:01C25031] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Benoit Claise wrote: > > Paul, > > >Benoit Claise wrote: > > > > > >>Juergen Quittek wrote: > >> > >> > >> > >>>Hi Benoit, > >>> > >>>-- Benoit Claise wrote on 29 August 2002 13:10 +0200: > >>> > >>> > >>> > >>>>Hi, > >>>> > >>>> > >>>> > >>>>>Juergen Quittek wrote: > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>Hi Paul, > >>>>>> > >>>>>>--On 28 August 2002 09:18 -0400 calato@riverstonenet.com wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>>Juergen Quittek wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>Hi Paul, > >>>>>>>> > >>>>>>>>--On 27 August 2002 20:26 -0400 calato@riverstonenet.com wrote: > >>>>>>>> > >>>>>>>>[...] > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>>>4.4 MPLS Label > >>>>>>>>>>> > >>>>>>>>>>> In the case of dynamic LSP's the label is not useful. > >>>>>>>>>>> Why require distinguishing flows based on label. > >>>>>>>>>>> What can be done with that information? > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>Well, for each attribute there are situations where it does not > >>>>>>>>>>make > >>>>>>>>>>sense to use it for distinguishing flows. But being able to > >>>>>>>>>>distinguish > >>>>>>>>>>flows by label seems to be useful to me in general. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> Then why not include things like VPI/VCI for ATM > >>>>>>>>> or other L2.5 tunnels? Why does MPLS get special > >>>>>>>>> consideration? > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>In general I see your point, although MPLS appears to be closer > >>>>>>>>related to IP than plain ATM. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> Why? I can take and ATM PVC and use it as a tunnel for > >>>>>>> IP traffic just like MPLS. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>Yes, but MPLS integrates with IP forwarcing when using CR-LDP > >>>>>>or RSVP-TE. Also you can use MPLS as "glue" between IP and ATM. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> I don't understand your argument here. Both technologies > >>>>> are viable solutions and exist in the market today. > >>>>> If one is included, so should the other. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>>>> Also, I may be wrong here but I beleive the primary > >>>>>>>>> use of MPLS will be with dynamic LSP's so the label > >>>>>>>>> has little meaning the majority of time. At best > >>>>>>>>> it would be a MAY requirement, not a MUST. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>For me, metering on a per-LSP basis is highly benefitial for the > >>>>>>>>operation of MPLS networks, even in the case of dynamic label > >>>>>>>>assignment. The LSR MIB already offers this kind of performance > >>>>>>>>information, but I think it also fits well into IPFIX. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> Are you talking about metering LSP's themselves or > >>>>>>> metering IP flows traveling through an LSP? > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>I'm talking about metering LSPs and about observing which flow maps > >>>>>>into which LSP. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> I'm a little confused. I thought we were only doing IP > >>>>> flows. Are we now including MPLS flows (LSPs)? > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>> Assuming you are talking about the latter, what can be done > >>>>>>> with the label information? If the flow F1 had label 57 > >>>>>>> and F2 had label 57 you don't even know if it is the > >>>>>>> same LSP. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>You are right. I would also need interface information. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> OK. So now I have F1, I1 and L57 and then F2, I1 and L57. > >>>>> I still don't know if it is the same LSP. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>>>> If we are going to go this way, which I am > >>>>>>>>> against, then we should also include FEC. At least > >>>>>>>>> that would be more meaningful information in the > >>>>>>>>> case of dynamic LSPs. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>This could be useful, but the FEC is a higher level information > >>>>>>>>that is not available in many cases. Also we would need a good model > >>>>>>>>for FEC information. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> If the device knows the label it knows the FEC. There are > >>>>>>> some concrete FEC definitions now and we can always add more > >>>>>>> as they materialize. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>All you need for an LSP are entries in insegment table, outsegment > >>>>>>table > >>>>>>and switching table. How does the device know anything about the > >>>>>>FEC if the > >>>>>>LSP was explicitly setup by a management system that added entries > >>>>>>to these > >>>>>>tables. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> Let me make sure I understand. Some external management > >>>>> station received the FEC and programmed the device? If > >>>>> that is the case then you are correct. However, wont many > >>>>> deployments have the 2 functions on one device? If so, > >>>>> then reporting FEC is at least a MAY requirement. > >>>>> > >>>>> > >>>>> > >>>>I have to admit that I haven't been thinking too much in the draft > >>>>about MPLS. > >>>>I agree now that it makes more sense to report the FEC than the MPLS > >>>>label, since the label has got a local significance > >>>> > >>>>But this is not in contradiction with what is in the draft! > >>>> > >>>>4.4. MPLS Label > >>>> > >>>> If the observation point is located at a device supporting > >>>> Multiprotocol Label Switching (MPLS, see [RFC3031]) then the metering > >>>> process MUST be able to separate flows by the MPLS label. > >>>> > >>>>And SHOU:LD report the FEC > >>>> > >>>> > >>>Here in Section 4 we are talking about separating flows. > >>>Do we want to separate flows by the FEC also? > >>> > >>> > >>As there is a matching Label -> FEC, we can still separate by Label > >> > >> > > > > I thought there could be multiple FEC's per label. > > > I doublechecked with some of our experts. > > label: FEC is a 1:1 relationship > FEC: label is a 1:n relationship I got a different answer from our guys. They said our current implementation is 1:1 for label->FEC but specifications indicate 1:n is possible. Maybe we can get hold of someone in the MPLS WG to help clear this up. > > In conclusion, what we need in the req. draft is: > > 4.4. MPLS Label > > If the observation point is located at a device supporting > Multiprotocol Label Switching (MPLS, see [RFC3031]) then the metering > process MUST be able to separate flows by the MPLS label. My comment is LSP's are too dynamic for labels to be useful. Are you saying you believe labels are stable enough to be useful? Again, I'm no MPLS expert so I'm just posing the questions based on my limited understanding. > > 6.1. Information Model > The exporting process SHOULD be able to report the following > attributes for each metered flow: > if MPLS is supported at the observation point: the Forwarding Equivalent Class (relative to the top label) > > Why a SHOULD and not a MUST? > Because in case of static label whose setup is done by a NMS, we don't need to export the labels. It is worded like this, it can remain a MUST. if dynamic MPLS LSPs are supported at the observation point: the Forwarding Equivalent Class (relative to the top label) > > And if we want to be complete... > > 6.1. Information Model > The exporting process MAY be able to report the following > attributes for each metered flow: > if MPLS is supported at the observation point: the underlying labels (second bottom label and below) > > Why? the report of the MPLS/VPN label for example > > Regards, Benoit. > > > > > > > > >>>Or are you suggesting to add the FEC to the list of SHOULD > >>>attributes in Section 6.1? > >>> > >>> > >>And yes: SHOULD report the FEC in Section 6.1 > >> > >>Regards, Benoit. > >> > >> > >> > >>> Juergen > >>> > >>> > >>> > >>>>Regards, Benoit. > >>>> > >>>> > >>>> > >>>>> > >>>>> > >>>>> > >>>>>> Juergen > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>-- > >>>>>Help mailto:majordomo@net.doit.wisc.edu and say "help" in > >>>>>message body > >>>>>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > >>>>>"unsubscribe ipfix" in message body > >>>>>Archive http://ipfix.doit.wisc.edu/archive/ > >>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Aug 30 11:00:26 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20324 for ; Fri, 30 Aug 2002 11:00:25 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17kn7B-00030E-00 for ipfix-list@mil.doit.wisc.edu; Fri, 30 Aug 2002 09:51:14 -0500 Received: from [64.95.122.60] (helo=RS-SC-EXC4.rs.riverstonenet.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17kn79-0002zc-00 for ipfix-req@net.doit.wisc.edu; Fri, 30 Aug 2002 09:51:11 -0500 Received: from riverstonenet.com ([134.141.180.105]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 30 Aug 2002 07:50:39 -0700 Message-ID: <3D6F85D9.4A194E21@riverstonenet.com> Date: Fri, 30 Aug 2002 10:48:57 -0400 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Quittek CC: Sebastian Zander , req Subject: Re: duplicated flow records (was: Re: [ipfix-req] IPFIX Requirements Questions) References: <3D6CA423.3020900@fokus.gmd.de> <17917774.1030543836@[192.168.102.164]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Aug 2002 14:50:40.0288 (UTC) FILETIME=[9BD71200:01C25034] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Juergen Quittek wrote: > > Sebastian, > > --On 28 August 2002 12:21 +0200 Sebastian Zander wrote: > > > > >>>8.3 Several Collecting Processes > >>>> > >>>> No mention is made when reporting to several devices > >>>> of ensuring the duplicate data does not cause a double > >>>> counting problem. > >>>> > >>> We discussed this issue, but did not find a clear requirement for > >>> avoiding this or for providing means for avoiding this. > >>> > >> > >> I don't understand. Double counting would surely cause > >> problems for many if not all of the applications. > >> > >> > >> > >>> One problem > >>> is that the collecting process is completely out of scope. > >>> > >> > >> We are opening the door by allowing data to be sent to > >> multiple Collectors. I think it would be difficult and > >> perhaps even impossible, without protocol support. But > >> I'm open to ideas on how it could be accomplished without > >> protocol support. > >> > >> > >>> Do you have an idea? > >>> > >> > >> For example, in LFAP a Flow ID, timestamp and message ID > >> uniquely identifies flow information. So the Collector could > >> use that to weed out duplicate data. How and when would be > >> out of scope. But the means is defined by the protocol. > > I support to include duplicate detection as a requirement in the draft > > but without suggestion a specific solution. That should be left for > > > > the spec. > > > > Could you (or anyone else) suggest where to extend the requirements > document and what text to insert? Since no one else took a stab... In draft-ietf-ipfix-reqs-05.txt section 6.3.2. Reliability In the event Flow Records are sent more than once (to the same or separate Collectors), the records MUST be uniquely identifiable. > > It looks like this would be a requirement for the exporting process. > > Juergen -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Aug 30 11:23:06 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21224 for ; Fri, 30 Aug 2002 11:23:05 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17knT4-0003bf-00 for ipfix-list@mil.doit.wisc.edu; Fri, 30 Aug 2002 10:13:50 -0500 Received: from [64.95.122.60] (helo=RS-SC-EXC4.rs.riverstonenet.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17knT2-0003b3-00 for ipfix-req@net.doit.wisc.edu; Fri, 30 Aug 2002 10:13:48 -0500 Received: from riverstonenet.com ([134.141.180.105]) by RS-SC-EXC4.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 30 Aug 2002 08:13:15 -0700 Message-ID: <3D6F8B26.65F87881@riverstonenet.com> Date: Fri, 30 Aug 2002 11:11:34 -0400 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Ganesh Sadasivan CC: req Subject: Re: [ipfix-req] IPFIX Requirements Questions References: <3D6BC9AD.CAC153C8@riverstonenet.com> <3D6E79C9.AB8020FE@cisco.com> <3D6E86F1.1CF943F0@riverstonenet.com> <3D6EB3B4.E582EDE5@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Aug 2002 15:13:16.0330 (UTC) FILETIME=[C41AA8A0:01C25037] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Ganesh Sadasivan wrote: > > calato@riverstonenet.com wrote: > > > Ganesh Sadasivan wrote: > > > > > > calato@riverstonenet.com wrote: > > > > > > > As I work on the advocates document some questions > > > > have come to mind on the requirements document. > > > > > > > > 4.3 Distinguishing flows using Transport Header Fields > > > > > > > > In the case of fragmented packets there are > > > > no port numbers. Are we saying flow state information > > > > MUST be maintained? In general, it is not clear from > > > > the document what the requirements are for fragmented > > > > packets. > > > > > > I do not see a way to distinguishing flows for fragmented packets > > > and not all fragments pass through the same router. > > > > Right. Keeping state is no guarentee. > > > > > > > > > > > > > > > > > 4.4 MPLS Label > > > > > > > > In the case of dynamic LSP's the label is not useful. > > > > Why require distinguishing flows based on label. > > > > What can be done with that information? > > > > > > If we can get a label to prefix mapping (from the control plane) > > > then it would be be very useful information. So I think this defn. > > > still holds good. > > > > Who is "we"? If you mean the Collecting Process, then > > querying the device after the fact has problems since > > LSPs are dynamic. > > The association of {incoming label, FEC} is available at the > exporter (referred to as "we") and application that it points to. Agreed. if the exporter does the FEC look up at the time it records the flow, that should be good enough. > I am not sure how dynamic this information is -I guess it depends > on the label type (TE-tunnel, BGP label, IGP label, VPN label etc). How dynamic the label is, is probably the critical piece of knowledge I'm not totally sure of. Hopefully we can get some clarity on this. > These associations when made available to the collector with > timestamping, it can do the mapping from "label in flow record" -> > FEC/application/etc. Infact there are vendors interested in getting > this kind of information. Are you saying that some other process is collecting and time stamping label->FEC/application/etc. information? > > > > > > > > > > > > > > > > > > > > 5.3 Overload Behavior > > > > > > > > This section needs to be re-worked a little. Some > > > > of the MUST's impose undue burden on the device. > > > > > > > > 1. Must distinguish flow records before and after the > > > > behavior change. > > > > > > Probably the intention is that it is one of the flow expiration > > > reasons. But I am not sure whether it needs to be tied with > > > a flow is it is the device's behavior. So keeping a MUST here > > > does not seem to be required. > > > > > > > > > > > > > > > In the case where the behavior is to drop > > > > overflow flows, why do we need to distinguish > > > > flows. Perhaps I misunderstood something. > > > > > > > > 2. All flows from previous behavior MUST be terminated. > > > > > > > > > > > > > > > > > > > Again, if I simply dropped excess flows why terminate > > > > all existing ones. This will likely cause more overflow > > > > as the get reestablished. This also seems to go to > > > > far towards implementation. > > > > > > > > > > I do not understand why. The reason you stated above is > > > good enough for this not to be done. > > > > I'm not sure I follow. The cost of terminating and > > re-establishing millions of flow is not reason enough? > > I am in sync with you. Sorry, I miss read your response. I guess I'm just used to getting beaten up lately :-) > > > > > > > > > > > > > > > > 3. Meeting process MUST NOT merge previous records. > > > > > > > > I think what we are trying to say is flows with a different > > > > definition MUST be distinguishable. How that is done is not > > > > part of the requirements doc. > > > > > > What I understand here is that 3 different flow records be cretaed > > > * prior to overload > > > * overload > > > * post overload > > > While I can udnderstand this from an export process perspective, > > > I am not sure how much sense it makes to go per flow on overload. > > > > > > > > > > > > > > > 5.4 Timestamps > > > > > > > > Time stamps to not always mapped to the first packet and last > > > > packet. In many cases, the end timestamp is merely when > > > > the flow timed out and has nothing to do with when the > > > > last packet was seen. Allowing both semantics may be useful. > > > > A re-wording like this... > > > > > > While there may be a minor delay in setting the timestamp after the > > > last packet is seen, > > > > If the hardware stamps all packets, no problem. If the > > software has to do it, how do you know what the last packet > > is? > > I'm confused. If there is a mechanism to detect the flow end by > means of packet or otherwise, then it is possible to get > a fine grained granularity. If otherwise, there could be some > periodic mechanisms (operating in msec periodicity) > that poll of counter deltas for each flow & update the timestamp. How do you poll millions of flows in msec? > > > > > > > > I am not sure by the above statement that > > > "has nothing to do with when the last packet was seen." > > > Is it not the > > > case that the flow was alive at this observation point only till it saw the > > > last packet? > > > > In the case of timeout, it is the time at which the device > > noticed that there were no more packets since the last time > > it checked. It does not know the time of the last packet > > observed. > > > > > > > > > > > > > > > > > The metering process MUST be able to generate timestamps for the > > > > start and end of a flow. The metering process MAY also provide > > > > timestamps for the first and the last observed packet > > > > of a flow. The timestamp resolution MUST be at least the one of > > > > the sysUpTime [RFC1213], which is one centisecond. > > > > > > > > Note - this does not mandate 2 timestamp fields for a flow. You > > > > could have one element for each meaning (e.g. Flow-start-time, > > > > first-packet-time, flow-start-and-first-packet-time) and use > > > > the one with the desired meaning. > > > > > > > > 6.1 information Model > > > > > > > > 9 Packet Counter > > > > 10 Byte counter > > > > > > > > As mentioned earlier, for fragments this > > > > requires state information? If there is no > > > > state info, then what flow are the counted > > > > towards? > > > > > > > > 13 BGP AS number > > > > > > > > Is this the AS number for the observation point, the > > > > source/destination address in the packet or some > > > > combination? > > > > > > Correct me if I'm wrong - usually a set of prefixes are associated with an AS. > > > An observation point is too vague a definition to associate to an AS. Say > > > it is a router LC, there could be multiple ASs within it. > > > > But suppose the entire router is in a single AS. Should > > we report it? > > > > Why not? Agreed. But that was not clear from the req doc. > > > > > In your example, maybe we report a list. > > > > > > > > > > > > > > > > > 14. MPLS Label > > > > > > > > As stated earlier, in the case of dynamic LSP's the > > > > label has no meaning. > > > > > > > > 21 multicast replication number > > > > > > > > The document stated this can change over the life > > > > of the flow. But no mention of what happens when > > > > it changes. Is that a new flow? If not, what meaning > > > > does it have when reported? What can I do with it? > > > > > > It would be useful if the collector is going to calculate the > > > replication factor over a period of time. > > > > > > > > > > > > > > > > > > > 6.2 Data Model > > > > > > > > What about allowing Vendors to add information independently? > > > > Some data to be transported may be vendor specific and never > > > > make it into the IPFIX spec. > > > > > > > > 8.3 Several Collecting Processes > > > > > > > > No mention is made when reporting to several devices > > > > of ensuring the duplicate data does not cause a double > > > > counting problem. > > > > > > > > > > I must have forgotten. Can you elaborate a little more? > > > > Depends on why you are reporting to 2 devices. If > > it is for completely different applications, no problem. > > But if there is a sharing of data for back up purposes > > or any other reason then ensuring you don't double > > count comes into play. > > Ok, I understand the application. Probably then it is a good idea > to associate the flows with the latest timestamp which is put > on the export packet when it is sent out. Just a thought. Might work depending on the stamp stamp granularity. Paul > -ganesh > > > > > > > > > > > Thanks > > > Ganesh > > > > > > > > > > > 9. Special Device Considerations > > > > > > > > I'm not sure of the meaning for the following... > > > > > > > > ... > > > > > > > > Please note that here, the observation > > > > point of a single flow cannot exceed the set of most fine-granular > > > > observation points linked to a single metering process, because only > > > > the metering process can merge packets observed at different fine- > > > > granular observation points to a joint flow. > > > > > > > > ... > > > > > > > > Also the > > > > locations of metering processes are not of any relevance for this > > > > document (in contrast to the locations of observation points and the > > > > exporting processes). > > > > > > > > Paul > > > > > > > > -- > > > > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > > > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > > > "unsubscribe ipfix" in message body > > > > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Aug 30 13:31:34 2002 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26820 for ; Fri, 30 Aug 2002 13:31:34 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 17kpP4-0006RT-00 for ipfix-list@mil.doit.wisc.edu; Fri, 30 Aug 2002 12:17:50 -0500 Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 17kpP1-0006RK-00 for ipfix-req@net.doit.wisc.edu; Fri, 30 Aug 2002 12:17:47 -0500 Received: from mira-sjcd-1.cisco.com (IDENT:mirapoint@mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g7UHHGKB000067; Fri, 30 Aug 2002 10:17:16 -0700 (PDT) Received: from cisco.com (dhcp-171-71-137-31.cisco.com [171.71.137.31]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ADK68465; Fri, 30 Aug 2002 10:17:44 -0700 (PDT) Message-ID: <3D6FA89C.CD9B13D0@cisco.com> Date: Fri, 30 Aug 2002 10:17:17 -0700 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: calato@riverstonenet.com CC: req Subject: Re: [ipfix-req] IPFIX Requirements Questions References: <3D6BC9AD.CAC153C8@riverstonenet.com> <3D6E79C9.AB8020FE@cisco.com> <3D6E86F1.1CF943F0@riverstonenet.com> <3D6EB3B4.E582EDE5@cisco.com> <3D6F8B26.65F87881@riverstonenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit calato@riverstonenet.com wrote: > Ganesh Sadasivan wrote: > > > > calato@riverstonenet.com wrote: > > > > > Ganesh Sadasivan wrote: > > > > > > > > calato@riverstonenet.com wrote: > > > > > > > > > As I work on the advocates document some questions > > > > > have come to mind on the requirements document. > > > > > > > > > > 4.3 Distinguishing flows using Transport Header Fields > > > > > > > > > > In the case of fragmented packets there are > > > > > no port numbers. Are we saying flow state information > > > > > MUST be maintained? In general, it is not clear from > > > > > the document what the requirements are for fragmented > > > > > packets. > > > > > > > > I do not see a way to distinguishing flows for fragmented packets > > > > and not all fragments pass through the same router. > > > > > > Right. Keeping state is no guarentee. > > > > > > > > > > > > > > > > > > > > > > 4.4 MPLS Label > > > > > > > > > > In the case of dynamic LSP's the label is not useful. > > > > > Why require distinguishing flows based on label. > > > > > What can be done with that information? > > > > > > > > If we can get a label to prefix mapping (from the control plane) > > > > then it would be be very useful information. So I think this defn. > > > > still holds good. > > > > > > Who is "we"? If you mean the Collecting Process, then > > > querying the device after the fact has problems since > > > LSPs are dynamic. > > > > The association of {incoming label, FEC} is available at the > > exporter (referred to as "we") and application that it points to. > > Agreed. if the exporter does the FEC look up at the time it > records the flow, that should be good enough. > > > I am not sure how dynamic this information is -I guess it depends > > on the label type (TE-tunnel, BGP label, IGP label, VPN label etc). > > How dynamic the label is, is probably the critical > piece of knowledge I'm not totally sure of. Hopefully > we can get some clarity on this. > I'll try to poll some experts in this area and get a better idea. > > > These associations when made available to the collector with > > timestamping, it can do the mapping from "label in flow record" -> > > FEC/application/etc. Infact there are vendors interested in getting > > this kind of information. > > Are you saying that some other process is collecting > and time stamping label->FEC/application/etc. information? Right now I'll have to assume the above unless we are exploring means to describe FEC through the export protocol. The short answer is that label is an interesting field for collectors and they can use it as an ID to do whatever post-processing they want to. Thanks Ganesh > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 5.3 Overload Behavior > > > > > > > > > > This section needs to be re-worked a little. Some > > > > > of the MUST's impose undue burden on the device. > > > > > > > > > > 1. Must distinguish flow records before and after the > > > > > behavior change. > > > > > > > > Probably the intention is that it is one of the flow expiration > > > > reasons. But I am not sure whether it needs to be tied with > > > > a flow is it is the device's behavior. So keeping a MUST here > > > > does not seem to be required. > > > > > > > > > > > > > > > > > > > In the case where the behavior is to drop > > > > > overflow flows, why do we need to distinguish > > > > > flows. Perhaps I misunderstood something. > > > > > > > > > > 2. All flows from previous behavior MUST be terminated. > > > > > > > > > > > > > > > > > > > > > > > > Again, if I simply dropped excess flows why terminate > > > > > all existing ones. This will likely cause more overflow > > > > > as the get reestablished. This also seems to go to > > > > > far towards implementation. > > > > > > > > > > > > > I do not understand why. The reason you stated above is > > > > good enough for this not to be done. > > > > > > I'm not sure I follow. The cost of terminating and > > > re-establishing millions of flow is not reason enough? > > > > I am in sync with you. > > Sorry, I miss read your response. I guess I'm just > used to getting beaten up lately :-) > > > > > > > > > > > > > > > > > > > > > > > 3. Meeting process MUST NOT merge previous records. > > > > > > > > > > I think what we are trying to say is flows with a different > > > > > definition MUST be distinguishable. How that is done is not > > > > > part of the requirements doc. > > > > > > > > What I understand here is that 3 different flow records be cretaed > > > > * prior to overload > > > > * overload > > > > * post overload > > > > While I can udnderstand this from an export process perspective, > > > > I am not sure how much sense it makes to go per flow on overload. > > > > > > > > > > > > > > > > > > > 5.4 Timestamps > > > > > > > > > > Time stamps to not always mapped to the first packet and last > > > > > packet. In many cases, the end timestamp is merely when > > > > > the flow timed out and has nothing to do with when the > > > > > last packet was seen. Allowing both semantics may be useful. > > > > > A re-wording like this... > > > > > > > > While there may be a minor delay in setting the timestamp after the > > > > last packet is seen, > > > > > > If the hardware stamps all packets, no problem. If the > > > software has to do it, how do you know what the last packet > > > is? > > > > I'm confused. If there is a mechanism to detect the flow end by > > means of packet or otherwise, then it is possible to get > > a fine grained granularity. If otherwise, there could be some > > periodic mechanisms (operating in msec periodicity) > > that poll of counter deltas for each flow & update the timestamp. > > How do you poll millions of flows in msec? This is an implementation detail. I was suggesting the above as an idea - that's all. Probably handling millions of flows would have some kind of h/w assist or is that not the case? Well there may be other means to implement the same. But in an extreme case if there are no resources to handle such a situation, the implementation may have to adopt flushing the cache every 'n' seconds or so with updating the timestamp while doing the flush. I am not sure if this is a common practice or not... > > > > > > > > > > > > > > I am not sure by the above statement that > > > > "has nothing to do with when the last packet was seen." > > > > Is it not the > > > > case that the flow was alive at this observation point only till it saw the > > > > last packet? > > > > > > In the case of timeout, it is the time at which the device > > > noticed that there were no more packets since the last time > > > it checked. It does not know the time of the last packet > > > observed. > > > > > > > > > > > > > > > > > > > > > > The metering process MUST be able to generate timestamps for the > > > > > start and end of a flow. The metering process MAY also provide > > > > > timestamps for the first and the last observed packet > > > > > of a flow. The timestamp resolution MUST be at least the one of > > > > > the sysUpTime [RFC1213], which is one centisecond. > > > > > > > > > > Note - this does not mandate 2 timestamp fields for a flow. You > > > > > could have one element for each meaning (e.g. Flow-start-time, > > > > > first-packet-time, flow-start-and-first-packet-time) and use > > > > > the one with the desired meaning. > > > > > > > > > > 6.1 information Model > > > > > > > > > > 9 Packet Counter > > > > > 10 Byte counter > > > > > > > > > > As mentioned earlier, for fragments this > > > > > requires state information? If there is no > > > > > state info, then what flow are the counted > > > > > towards? > > > > > > > > > > 13 BGP AS number > > > > > > > > > > Is this the AS number for the observation point, the > > > > > source/destination address in the packet or some > > > > > combination? > > > > > > > > Correct me if I'm wrong - usually a set of prefixes are associated with an AS. > > > > An observation point is too vague a definition to associate to an AS. Say > > > > it is a router LC, there could be multiple ASs within it. > > > > > > But suppose the entire router is in a single AS. Should > > > we report it? > > > > > > > Why not? > > Agreed. But that was not clear from the req doc. > > > > > > > > > In your example, maybe we report a list. > > > > > > > > > > > > > > > > > > > > > > 14. MPLS Label > > > > > > > > > > As stated earlier, in the case of dynamic LSP's the > > > > > label has no meaning. > > > > > > > > > > 21 multicast replication number > > > > > > > > > > The document stated this can change over the life > > > > > of the flow. But no mention of what happens when > > > > > it changes. Is that a new flow? If not, what meaning > > > > > does it have when reported? What can I do with it? > > > > > > > > It would be useful if the collector is going to calculate the > > > > replication factor over a period of time. > > > > > > > > > > > > > > > > > > > > > > > > 6.2 Data Model > > > > > > > > > > What about allowing Vendors to add information independently? > > > > > Some data to be transported may be vendor specific and never > > > > > make it into the IPFIX spec. > > > > > > > > > > 8.3 Several Collecting Processes > > > > > > > > > > No mention is made when reporting to several devices > > > > > of ensuring the duplicate data does not cause a double > > > > > counting problem. > > > > > > > > > > > > > I must have forgotten. Can you elaborate a little more? > > > > > > Depends on why you are reporting to 2 devices. If > > > it is for completely different applications, no problem. > > > But if there is a sharing of data for back up purposes > > > or any other reason then ensuring you don't double > > > count comes into play. > > > > Ok, I understand the application. Probably then it is a good idea > > to associate the flows with the latest timestamp which is put > > on the export packet when it is sent out. Just a thought. > > Might work depending on the stamp stamp granularity. > > Paul > > > -ganesh > > > > > > > > > > > > > > > > Thanks > > > > Ganesh > > > > > > > > > > > > > > 9. Special Device Considerations > > > > > > > > > > I'm not sure of the meaning for the following... > > > > > > > > > > ... > > > > > > > > > > Please note that here, the observation > > > > > point of a single flow cannot exceed the set of most fine-granular > > > > > observation points linked to a single metering process, because only > > > > > the metering process can merge packets observed at different fine- > > > > > granular observation points to a joint flow. > > > > > > > > > > ... > > > > > > > > > > Also the > > > > > locations of metering processes are not of any relevance for this > > > > > document (in contrast to the locations of observation points and the > > > > > exporting processes). > > > > > > > > > > Paul > > > > > > > > > > -- > > > > > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > > > > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > > > > "unsubscribe ipfix" in message body > > > > > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/