From rahulp@cisco.com Tue Mar 5 09:56:11 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04AB321F8615 for ; Tue, 5 Mar 2013 09:56:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3bGsTBHEhpXj for ; Tue, 5 Mar 2013 09:56:10 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1F721F8613 for ; Tue, 5 Mar 2013 09:56:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5360; q=dns/txt; s=iport; t=1362506170; x=1363715770; h=from:to:subject:date:message-id:mime-version; bh=Zo6Wh8cmPY5lhQVVul11aXJN7BL43XOx8zMTxocAlic=; b=ZiFSe2FI/aP/af9gbMHjwTG9C3HtxzRboVIyj2ZD/Ace7agN9EirJyUE Ih1IrAWM6qTMrSO/nvOSNQBQFpPIdZhCeH7Ua3Dv2+d8wf0/+903iCC2h dnV7hLoAMepLPnCboJnbiviflu2a07G4DTdkhLuiroSWD65yirVoboZyl 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEwxNlGtJXHB/2dsb2JhbABFhGLAEIFsFnOCLQEEgQsBKlYnBAEaiAusUZANjlyDF2EDpziDCIIn X-IronPort-AV: E=Sophos;i="4.84,788,1355097600"; d="scan'208,217";a="183997147" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 05 Mar 2013 17:56:09 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r25Hu9Hs022320 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 5 Mar 2013 17:56:09 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.93]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Tue, 5 Mar 2013 11:56:09 -0600 From: "Rahul Patel (rahulp)" To: "ipfix@ietf.org" , "Benoit Claise (bclaise)" Thread-Topic: Feedback: regarding draft-ietf-ipfix-mediation-protocol Thread-Index: AQHOGcq3m3VkIH+yRkGa/Azkao+B1g== Date: Tue, 5 Mar 2013 17:56:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.154.209.157] Content-Type: multipart/alternative; boundary="_000_A1EE24E3D6D8B14A92CCA1AFB88718B218449C39xmbrcdx05ciscoc_" MIME-Version: 1.0 Subject: [IPFIX] Feedback: regarding draft-ietf-ipfix-mediation-protocol X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 17:56:11 -0000 --_000_A1EE24E3D6D8B14A92CCA1AFB88718B218449C39xmbrcdx05ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Few comments. 1. Page 8: * The difference between "Intermediate Selection Process" and "Inter= mediate Flow Selection Process" is not clear. Is the first one selecting re= cord purely on matching content (value of the fields) in the record and the= second one selecting on matching attributes of the fields that are not par= t of the record in *addition* to matching content in the record? An example= would help here. * Also in the example " e.g., Filtering only records from a given ne= twork to a given Collector" - Does "given network" means "source-ip/source-= prefix of the exporter"?. 2. Page 13: * "Figure B" A typo? Should it be "Figure 3"? General * On correlation process =96 how to correlate, what cannot be correlate= d, etc =96 is this out of scope of this draft? For example, Mediator A rece= ives metric N1 and N2 per 5-tuple from exporter X and metric N3 and N4 per = 5-tuple from exporter Y. Mediator A can easily correlate and exporter N1, N= 2, N3 and N4 to another collector C. If the key fields are not matching or = one is subset of other then data can either not be correlated or can be rep= resented in a different way. Most likely all of this out of scope of this d= ocument but just wanted to check. Thanks, -Rahul --_000_A1EE24E3D6D8B14A92CCA1AFB88718B218449C39xmbrcdx05ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7E9AC69FD77CE54F926BCCE6786F2BEF@cisco.com> Content-Transfer-Encoding: quoted-printable


Few comments.

  1. Page 8: 
    1. The difference between "Intermediate Selection Process" and &= quot;Intermediate Flow Selection Process" is not clear. Is the first o= ne selecting record purely on matching content (value of the fields) in the= record and the second one selecting on matching attributes of the fields that are not part of the record in *addition* to matching co= ntent in the record? An example would help here.
    1. Also in the example " e.g., Filtering= only records from a given network to a given Collector" - Does "given network" means "so= urce-ip/source-prefix of the exporter"?.
  2. &qu= ot;Figure B" A typo? Should it be "Figure 3"?
General
  • On correlation process =96 how t= o correlate, what cannot be correlated, etc =96 is this out of scope of this draft? For example, Mediator A receiv= es metric N1 and N2 per 5-tuple from exporter X and metric N3 and N4 per 5-= tuple from exporter Y. Mediator A can easily correlate and exporter N1, N2,= N3 and N4 to another collector C. If the key fields are not matching or one is subset of other then data can= either not be correlated or can be represented in a different way. Most li= kely all of this out of scope of this document but just wanted to check.
Th= anks,
-R= ahul
--_000_A1EE24E3D6D8B14A92CCA1AFB88718B218449C39xmbrcdx05ciscoc_-- From trammell@tik.ee.ethz.ch Wed Mar 6 03:54:01 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 264EE21F8481 for ; Wed, 6 Mar 2013 03:54:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-ST5s-1zBCT for ; Wed, 6 Mar 2013 03:54:00 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 18E0C21F846C for ; Wed, 6 Mar 2013 03:54:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id B72A4D94EB for ; Wed, 6 Mar 2013 12:53:58 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Wstvj7rAiyOl for ; Wed, 6 Mar 2013 12:53:57 +0100 (MET) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 98088D95FD for ; Wed, 6 Mar 2013 12:53:42 +0100 (MET) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Mar 2013 12:53:40 +0100 Message-Id: <611B0651-A855-458F-A6D3-9402CC723A9B@tik.ee.ethz.ch> To: IETF IPFIX Working Group Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [IPFIX] New Version Notification for draft-ietf-ipfix-mediation-protocol-04.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 11:54:01 -0000 Greetings, all, It's been brought to my attention that this message somehow failed to = make it to the list... Cheers, Brian > From: Brian Trammell > Subject: Re: New Version Notification for = draft-ietf-ipfix-mediation-protocol-04.txt > Date: February 25, 2013 6:45:02 PM GMT+01:00 > To: IETF IPFIX Working Group >=20 > Greetings, all, >=20 > We've submitted a new revision of the mediator protocol draft. This = revision is content-complete; that is, there exists some suggested text = for all known open issues, although the authors believe there remain = some points for discussion, which we would like to address at the = meeting in Orlando. >=20 > Cheers, >=20 > Brian >=20 From paitken@cisco.com Fri Mar 8 04:11:04 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A661821F8675 for ; Fri, 8 Mar 2013 04:11:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yVR-ELeSQ+eM for ; Fri, 8 Mar 2013 04:11:01 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id AA79621F8609 for ; Fri, 8 Mar 2013 04:11:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=959; q=dns/txt; s=iport; t=1362744660; x=1363954260; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=lfPnp+IZa8rZGh6AvAFt59W0ADMA6ozCuQOQ8h+iOo0=; b=lTHQkb++3zDGC2Sso6U7O9OTAFKKZZDbtaROy7Tp++/bXGBaThlq44WT aHfzBvNuVTc8iHMsmLFaNOIL8RG1c577UjNwZ782ohyOyGbXjKGT5Ks6p Hi+A737IOwpNIQw4s4WQNJvtsi52f/Vl7gjfhPbq+aLBosqe6xHvnTNtZ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAPPUOVGQ/khR/2dsb2JhbAA5CoUHwR4WdIJaETMNPRYYAwIBAgFLDQgBAYgPmh2gf41RhQIDllOFeYp5gwo X-IronPort-AV: E=Sophos;i="4.84,807,1355097600"; d="scan'208";a="81059436" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 08 Mar 2013 12:10:58 +0000 Received: from [10.55.89.8] (dhcp-10-55-89-8.cisco.com [10.55.89.8]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r28CAu1j024111 for ; Fri, 8 Mar 2013 12:10:56 GMT Message-ID: <5139D551.1000905@cisco.com> Date: Fri, 08 Mar 2013 12:10:57 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: IETF IPFIX Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] new IPFIX information elements for names X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 12:11:04 -0000 Dear IPFIX experts, I'd like to propose some new IPFIX Information Elements to export name strings corresponding to existing IE IDs: meteringProcessId -> meteringProcessName templateId -> templateName exportingProcessId -> exportingProcessName observationPointId -> observationPointName Our immediate need is only for meteringProcessName, and we've been asked for the templateName to help identify the template's purpose. Quickly checking other export IDs, "exportingProcessName" and "observationPointName" seem obvious inclusions which could be included in the infomodel if you think they would be useful - though we've no immediate plans / need for these. I'll send the request to IANA subject to your feedback. Thanks, P. PS of course the ideal way to implement this would be a "name" field attribute, using the EFSF described in the mib-variable-export draft. However, that's a ways away... From andrewf@plixer.com Fri Mar 8 05:02:50 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21C5E21F863B for ; Fri, 8 Mar 2013 05:02:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40vs8iJh55LR for ; Fri, 8 Mar 2013 05:02:35 -0800 (PST) Received: from smtp.plixer.com (smtp.plixer.com [64.140.243.151]) by ietfa.amsl.com (Postfix) with ESMTP id 8009D21F85CE for ; Fri, 8 Mar 2013 05:02:35 -0800 (PST) Received: from [10.11.1.15] ([10.11.1.15]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Mar 2013 08:02:33 -0500 Message-ID: <5139E16B.9050007@plixer.com> Date: Fri, 08 Mar 2013 08:02:35 -0500 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: ipfix@ietf.org References: <5139D551.1000905@cisco.com> In-Reply-To: <5139D551.1000905@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Mar 2013 13:02:33.0752 (UTC) FILETIME=[330D7980:01CE1BFD] Subject: Re: [IPFIX] new IPFIX information elements for names X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 13:02:50 -0000 Yes, please. Two thumbs up for templateName. As for the others, having a name to associate with any ID is a request I hear often. -Andrew On 03/08/2013 07:10 AM, Paul Aitken wrote: > Dear IPFIX experts, > > I'd like to propose some new IPFIX Information Elements to export name > strings corresponding to existing IE IDs: > > meteringProcessId -> meteringProcessName > templateId -> templateName > exportingProcessId -> exportingProcessName > observationPointId -> observationPointName > > > Our immediate need is only for meteringProcessName, and we've been > asked for the templateName to help identify the template's purpose. > > Quickly checking other export IDs, "exportingProcessName" and > "observationPointName" seem obvious inclusions which could be included > in the infomodel if you think they would be useful - though we've no > immediate plans / need for these. > > I'll send the request to IANA subject to your feedback. > > Thanks, > P. > > > PS of course the ideal way to implement this would be a "name" field > attribute, using the EFSF described in the mib-variable-export draft. > However, that's a ways away... > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From internet-drafts@ietf.org Sun Mar 10 18:15:23 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08AF421F858E; Sun, 10 Mar 2013 18:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.389 X-Spam-Level: X-Spam-Status: No, score=-102.389 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nqn4tRFB3054; Sun, 10 Mar 2013 18:15:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A315D21F874E; Sun, 10 Mar 2013 18:15:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.42 Message-ID: <20130311011518.7665.33603.idtracker@ietfa.amsl.com> Date: Sun, 10 Mar 2013 18:15:18 -0700 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-flow-selection-tech-14.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 01:15:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Flow Information Export Working Group = of the IETF. Title : Flow Selection Techniques Author(s) : Salvatore D'Antonio Tanja Zseby Christian Henke Lorenzo Peluso Filename : draft-ietf-ipfix-flow-selection-tech-14.txt Pages : 31 Date : 2013-03-10 Abstract: Intermediate Flow Selection Process is the process of selecting a subset of Flows from all observed Flows. The Intermediate Flow Selection Process may be located at an IPFIX Exporter, Collector, or within an IPFIX Mediator. It reduces the effort of post-processing Flow data and transferring Flow Records. This document describes motivations for using the Intermediate Flow Selection process and presents Intermediate Flow Selection techniques. It provides an information model for configuring Intermediate Flow Selection Process techniques and discusses what information about an Intermediate Flow Selection Process should be exported. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipfix-flow-selection-tech-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-flow-selection-tech-14 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From salvatore.dantonio@uniparthenope.it Sun Mar 10 23:45:33 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1ED621F8818 for ; Sun, 10 Mar 2013 23:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.731 X-Spam-Level: X-Spam-Status: No, score=0.731 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uVoXNzmALP2h for ; Sun, 10 Mar 2013 23:45:31 -0700 (PDT) Received: from mail.uniparthenope.it (mail.uniparthenope.it [192.167.9.244]) by ietfa.amsl.com (Postfix) with ESMTP id 2E7A921F882D for ; Sun, 10 Mar 2013 23:45:31 -0700 (PDT) Received: from mail2.uniparthenope.it (unknown [10.1.2.108]) by mail.uniparthenope.it (Postfix) with SMTP id BCA7F19A2B; Mon, 11 Mar 2013 06:45:28 +0000 (UTC) Received: from (unknown [192.168.241.108]) by mail2.uniparthenope.it with smtp id 0b59_42c3a65a_8a17_11e2_9101_001372515a5c; Mon, 11 Mar 2013 07:45:27 +0100 Received: from spamk.uniparthenope.it (localhost [127.0.0.1]) by spamk.uniparthenope.it (Postfix) with ESMTP id 4674DC4301; Mon, 11 Mar 2013 07:45:28 +0100 (CET) Received: by spamk.uniparthenope.it (Postfix, from userid 500) id 43896C4305; Mon, 11 Mar 2013 07:45:28 +0100 (CET) Received: from mail.uniparthenope.it (unknown [192.168.241.109]) by spamk.uniparthenope.it (Postfix) with ESMTP id 5A206C4301; Mon, 11 Mar 2013 07:45:27 +0100 (CET) Received: from saldantoPC (host7-81-static.104-82-b.business.telecomitalia.it [82.104.81.7]) (Authenticated sender: salvatore.dantonio@uniparthenope.it) by mail.uniparthenope.it (Postfix) with ESMTPA id 915DE19A2B; Mon, 11 Mar 2013 07:45:26 +0100 (CET) From: "Salvatore D'Antonio" To: "'Benoit Claise'" , References: <20130223105900.31873.39377.idtracker@ietfa.amsl.com> <512A2CA3.8060809@cisco.com> <512DE8DC.1070902@cisco.com> In-Reply-To: <512DE8DC.1070902@cisco.com> Date: Mon, 11 Mar 2013 07:45:26 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4U2sAuTdX25R18QP6ph0GQ1uj9GQJSDCFA Content-Language: it Message-ID: <000601ce1e24$03f496a0$0bddc3e0$@dantonio@uniparthenope.it> Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CE1E2C.65B8FEA0" X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.42/RELEASE, bases: 20130311 #9683996, check: 20130311 clean Cc: draft-ietf-ipfix-flow-selection-tech@tools.ietf.org Subject: [IPFIX] R: One more feedback on XML: New Version Notification - draft-ietf-ipfix-flow-selection-tech-13.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 06:45:33 -0000 Messaggio multipart in formato MIME. ------=_NextPart_000_0007_01CE1E2C.65B8FEA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Benoit, all =20 I submitted a new version of the ID on Flow Selection Techniques. With respect to the previous version the Appendix A has been removed, section 7.1 to section 7.11 have been moved to IANA Considerations = section, in section 7.x the status Proposed has been changed with Current, and = TBDx has been replaced by 9 in the registry. =20 Kind regards, =20 Salvatore=20 =20 Da: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] Per conto di Benoit Claise Inviato: mercoled=EC 27 febbraio 2013 12:07 A: ipfix@ietf.org Cc: draft-ietf-ipfix-flow-selection-tech@tools.ietf.org Oggetto: [IPFIX] One more feedback on XML: New Version Notification - draft-ietf-ipfix-flow-selection-tech-13.txt =20 Dear authors, One more feedback, and a question for the WG Based on feedback received from the OPS DIRECTORATE on RFC5102bis, the following was inserted http://tools.ietf.org/html/draft-ietf-ipfix-information-model-rfc5102bis-= 10# section-7.3 The reference to the current schema is embedded in the registry [IPFIX-IANA ]; this schema may change from time to time as = necessary to support the maintenance of the registry. As such, the schema urn:ietf:params:xml:schema:ipfix-info [IPFIX-XML-SCHEMA ] specified in [RFC5102 ] has been deprecated. Should the IPFIX draft remove the reference to the RFC5102 xsd? Typically for this draft, it means removing the appendix A (http://tools.ietf.org/html/draft-ietf-ipfix-flow-selection-tech-13#appen= dix -A) Personally, I believe it makes sense to remove it. Regards, Benoit (as a contributor) Dear authors, Looking at the diff, I have the following feedback. flowSelectorAlgorithm is a new IE, to be registered by IANA I see this in section 7.1: New assignments for the registry will be administered by IANA and are subject to Expert Review [RFC5226 ]. This new registry should be in the IANA considerations section. For an example of the IANA considerations, see http://tools.ietf.org/html/rfc6313#section-11.3 So the section 7.1 to 7.11 should be in the IANA considerations section. Also, in that registry, I see: +----+------------------------+--------------------------+ |TBDx| Flow-state Dependent | No agreed Parameters | | | Intermediate Flow | | | | Selection Process | | +----+------------------------+--------------------------+ This should be +----+------------------------+--------------------------+ | 9 | Flow-state Dependent | No agreed Parameters | | | Intermediate Flow | | | | Selection Process | | +----+------------------------+--------------------------+ On this last point, I realized that I mislead you. Mea culpa. I see in section 7.x Status: Proposed The status should be "current" Really, http://tools.ietf.org/html/rfc6313#section-11.3 is a good = example. And finally, there are new fields in http://www.iana.org/assignments/ipfix/ipfix.xml since you posted you version. For example "revision". Instruct IANA that they need to put the value 0. These comments can be taken into account part of the WGLC to come. Up to chairs to decide. Regards, Benoit A new version (-13) has been submitted for draft-ietf-ipfix-flow-selection-tech: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-flow-selection-tech-= 13. txt =20 Sub state has been changed to AD Followup from Revised ID Needed =20 =20 The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/ =20 Diff from previous version: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-flow-selection-tech-1= 3 =20 IETF Secretariat. =20 =20 =20 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix =20 _____ =20 Nessun virus nel messaggio. Controllato da AVG - www.avg.com Versione: 2013.0.2899 / Database dei virus: 2641/6133 - Data di = rilascio: 25/02/2013 ------=_NextPart_000_0007_01CE1E2C.65B8FEA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear Benoit, all

 

I submitted a new version of the ID on Flow Selection Techniques.

With respect to the previous version the Appendix A has = been removed, section 7.1 to section 7.11 have been moved to IANA = Considerations section, in section 7.x the status Proposed has been changed with = Current, and TBDx has been replaced by 9 in the registry.

 

Kind regards,

 

Salvatore

 

Da: = ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] Per conto di Benoit Claise
Inviato: mercoled=EC 27 febbraio 2013 12:07
A: ipfix@ietf.org
Cc: draft-ietf-ipfix-flow-selection-tech@tools.ietf.org
Oggetto: [IPFIX] One more feedback on XML: New Version = Notification - draft-ietf-ipfix-flow-selection-tech-13.txt

 

Dear authors,

One more feedback, and a question for the WG
Based on feedback received from the OPS DIRECTORATE on RFC5102bis, the following was inserted
http://tools.ietf.org/html/draft-ietf-ipfix-infor= mation-model-rfc5102bis-10#section-7.3

=A0=A0 The reference to the current schema is embedded in the =
registry
=A0=A0 [IPFIX-IANA]; this schema may change from =
time to time as necessary
=A0=A0 to support the =
maintenance of the registry. As such, the =
schema
=A0=A0 urn:ietf:params:xml:schema:ipfix-info =
[IPFIX-XML-SCHEMA] specified =
in
=A0=A0 [RFC5102] has been deprecated.

Should the IPFIX draft remove the reference to the = RFC5102 xsd?
Typically for this draft, it means removing the appendix A (http://tools.ietf.org/html/draft-ietf-ipfix-flow-selection-= tech-13#appendix-A)
Personally, I believe it makes sense to remove it.

Regards, Benoit (as a contributor)

Dear authors,

Looking at the diff, I have the following feedback.

flowSelectorAlgorithm is a new IE, to be registered by IANA
I see this in section 7.1:

New assignments for the registry will be administered =
by
IANA and are subject to Expert Review [RFC5226].

This new registry should be in the IANA = considerations section.
For an example of the IANA considerations, see http://tools.iet= f.org/html/rfc6313#section-11.3
So the section 7.1 to 7.11 should be in the IANA considerations = section.

Also, in that registry, I see:

=A0=A0 =
+----+------------------------+--------------------------+
=A0=A0 |TBDx| Flow-state Dependent=A0=A0 | No agreed =
Parameters=A0=A0=A0=A0 |
=A0=A0 |=A0=A0=A0 | =
Intermediate Flow=A0=A0=A0=A0=A0 =
|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0 |
=A0=A0 |=A0=A0=A0 | Selection =
Process=A0=A0=A0=A0=A0 =
|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0 |
=A0=A0 =
+----+------------------------+--------------------------+


This should be



=A0=A0 =
+----+------------------------+--------------------------+
=A0=A0 |=A0 9 | Flow-state Dependent=A0=A0 | No agreed =
Parameters=A0=A0=A0=A0 |
=A0=A0 |=A0=A0=A0 | =
Intermediate Flow=A0=A0=A0=A0=A0 =
|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0 |
=A0=A0 |=A0=A0=A0 | Selection =
Process=A0=A0=A0=A0=A0 =
|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0 |
=A0=A0 =
+----+------------------------+--------------------------+


On this last point, I realized that I mislead you. =
Mea
culpa.



I see  in section 7.x



=A0=A0 Status: Proposed



The status should be "current"



Really, http://tools.iet=
f.org/html/rfc6313#section-11.3
is a good example.



And finally, there are new fields in http://www.iana.=
org/assignments/ipfix/ipfix.xml
since you posted you version. For example "revision". Instruct =
IANA
that they need to put the value 0.



These comments can be taken into account part of the WGLC to come. Up to =
chairs
to decide.



Regards, Benoit



A new =
version (-13) has been submitted for =
draft-ietf-ipfix-flow-selection-tech:
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-flow=
-selection-tech-13.txt
 
Sub state has been changed to AD Followup from Revised ID = Needed
 
 =

The IETF datatracker page for this Internet-Draft =
is:
https://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-t=
ech/
 
Diff from =
previous version:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-flow-selec=
tion-tech-13
 
IETF =
Secretariat.
 
 =

 





_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org=
/mailman/listinfo/ipfix

 

Nessun virus nel messaggio.
Controllato da AVG - www.avg.com
Versione: 2013.0.2899 / Database dei virus: 2641/6133 - Data di = rilascio: 25/02/2013

------=_NextPart_000_0007_01CE1E2C.65B8FEA0-- From paitken@cisco.com Wed Mar 13 03:27:00 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 513D521F8D85 for ; Wed, 13 Mar 2013 03:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X+NQx2U3i-XE for ; Wed, 13 Mar 2013 03:26:59 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 8924A21F8D8C for ; Wed, 13 Mar 2013 03:26:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7015; q=dns/txt; s=iport; t=1363170418; x=1364380018; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=4idmeGnUOOfHR1oRGk3EJoGbfgOT1SUmLsHhDgwRmaY=; b=nDjHOtPFx9VWQ22VzDf9kul6MRPX3W1Tr05qW/UM2+SjyZAr9noE80vh ekonYIc+dN5GLsa7D3UZJ7n4EFNqG9W1kqeV46LD6b8DDPx5l2K+zIKA8 ZrqOVazDeH9j3ua6JAu1w3r9OgJdLJpvRSBsHNPkUqBXWWtnYeOfl2efQ Q=; X-IronPort-AV: E=Sophos;i="4.84,834,1355097600"; d="scan'208";a="81223144" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 13 Mar 2013 10:26:57 +0000 Received: from [10.61.65.93] (ams3-vpn-dhcp349.cisco.com [10.61.65.93]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2DAQuJC021200; Wed, 13 Mar 2013 10:26:57 GMT Message-ID: <51405471.6050406@cisco.com> Date: Wed, 13 Mar 2013 10:26:57 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: Gerhard Muenz References: <510B8EA3.3050205@cisco.com> <511D8010.6030209@cisco.com> <511DFF13.6050001@net.in.tum.de> In-Reply-To: <511DFF13.6050001@net.in.tum.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] IPFIX observationPointId uniqueness X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 10:27:00 -0000 Gerhard, We are monitoring traffic in multiple places - at the ingress and egress interfaces, at processes, in ACLs, in policies. Each of these has a unique 32-bit ID (ie, there may be up to N x 32-bit IDs). However, these IDs are in unique number spaces. eg, the interface ID could happen to be the same as the process ID or the same as the policy ID. So it's not possible to say what the ID represents without knowing the type. You would meet this issue if you monitor interfaces and also want to report PSAMP stats for each selection process. Somehow you need to report distinct IDs for the interfaces versus the processes. Several possibilities come to mind: 1. use multiple different IEs, one per observation point type, with multiple templates. This is not ideal, because we have to request new IEs for each new observation point type, and store / export multiple templates. ie, it adds a layer of unnecessary complexity rather than rather than simplifying the export. 2. implement a conversion function, mapping the N x 32-bit IDs into the 1 x 32-bit observationDomainID space. Obviously only a limited number of conversions (1/N) are possible, and there'll be a trade-off between the table size and lookup time. 3. associate an observationPointType with each observationPointID, and not require any conversion at all. Each internal ID is mapped 1:1 with an observationPointId, with uniqueness being determined by the associated observationPointType. This is the simplest and cleanest solution. So to answer your questions directly: - Do you really need OPID for your purpose? Have you thought about using IEs like ingressPhysicalInterface or ingressInterface? Or, if these IEs are not appropriate, about defining new IEs? - per (1) above, this makes for an unnecessarily complex solution. - If you need to use OPIDs and if you want to avoid any mapping, have you thought about assigning the different sources (interface cards, VLANs) to different ODs? - they are all within a single OD. - Example use case: report packet counts as traffic progresses through selection and filtering within the router. The report will be exported in a single message with a single OD in the header. It's not possible to export a single cohesive report using multiple ODs. P. On 15/02/13 09:25, Gerhard Muenz wrote: > > Benoit, Paul, > > Like Benoit, I do not have a good feeling about this proposal. On the > other hand, I have not found any RFC that really requires the use of > OPIDs. Even RFC5476 leaves it open whether the OP is identified by > OPID or any other IE. Therefore, I have been silent until now. > > IPFIX-CONFIG assumes that the OPID is assigned by the IPFIX device, > i.e. it is not a configuration parameter. I think that we agree here. > > Up to now, the IPFIX RFCs do not impose any restriction on the OPID > except for the uniqueness per OD. This means that various > implementations are possible right now: > 1) OPID is equal to an internal identifier (e.g. internal interface > number) or a non-IPFIX MIB index (e.g. ifIndex, entPhysicalIndex). > 2) OPID is equal to the IPFIX-MIB index ipfixObservationPointIndex > 3) OPID is unrelated to any other index, the IPFIX device provides the > internal mapping > > If IPFIX-MIB is supported by the device, the natural choice for me > would be 2). This would allow easy mapping of MIB entries and IPFIX > export. > > As Paul points out, 1) only works as long as the internal identifiers > are unique per OD. > > My questions to Paul are: > - Do you really need OPID for your purpose? Have you thought about > using IEs like ingressPhysicalInterface or ingressInterface? Or, if > these IEs are not appropriate, about defining new IEs? > - If you need to use OPIDs and if you want to avoid any mapping, have > you thought about assigning the different sources (interface cards, > VLANs) to different ODs? > > Regards, > Gerhard > > > On 15.02.2013 01:23, Benoit Claise wrote: >> Paul, >> >> At first glance, it looks reasonable. >> But what would be the consequence on the Selection Sequence Report >> Interpretation(see http://tools.ietf.org/html/rfc5476#section-6.5.1). If >> we use the observationPointId and it's not unique, then we need to >> include the observationPointType? >> Note that the sentence "It is RECOMMENDED that this identifier is also >> unique per IPFIX Device." was inserted specifically for this. >> >> Regards, Benot >>> Dear IPFIX experts, >>> >>> IPFIX observationPointId (#138) is defined as: >>> >>> An identifier of an Observation Point that is unique per >>> Observation Domain. It is RECOMMENDED that this identifier is >>> also unique per IPFIX Device. Typically, this Information >>> Element is used for limiting the scope of other Information >>> Elements. >>> >>> We now also have observationPointType (#277), defined as: >>> >>> Type of observation point. Values assigned to date are: >>> >>> 1. Physical port >>> 2. Port channel >>> 3. Vlan. >>> >>> >>> Could we relax the uniqueness requirements of observationPointId when >>> an observationPointType is also exported, such that the { >>> observationPointType, observationPointId } pair must be unique, though >>> not the observationPointId itself. >>> >>> The reason being that observation points of different types already >>> have IDs, though these are not unique. eg, we have interface 1, 2, 3, >>> ...; vlan 1, 2, 3, ...; port 1, 2, 3, ... >>> >>> So an extra mediation layer is required to convert values from each of >>> these number spaces into unique IDs in the observationPointId number >>> space - which becomes harder as we add more places that observations >>> can be made, ie more observationPointTypes. >>> >>> Whereas prefixing with the observationPointType achieves the required >>> uniqueness in a faster, simpler, and more reliable way. >>> >>> To achieve this, I'd propose the following definition change: >>> >>> An identifier of an Observation Point that is unique per >>> Observation Domain and per observationPointType, if specified. >>> It is RECOMMENDED that this identifier is >>> also unique per IPFIX Device. Typically, this Information >>> Element is used for limiting the scope of other Information >>> Elements. >>> >>> For backwards compatibility, we could define observationPointType = 0 >>> to be "unspecified". >>> >>> Thanks, >>> P. >>> >>> >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix >> >> >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix >> From paitken@cisco.com Wed Mar 13 04:26:44 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8817D21F8D2F for ; Wed, 13 Mar 2013 04:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ic1K47ToQ-m6 for ; Wed, 13 Mar 2013 04:26:44 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id B0E2121F8D2B for ; Wed, 13 Mar 2013 04:26:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=437; q=dns/txt; s=iport; t=1363174003; x=1364383603; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=tyZZpLMbs9X7nixvTa7Q1CCcNCcdu8wBE9mEICuejuQ=; b=f1gJQty5Ar/pgucZk+tt6lhxhG9EM7Ez1Yj9H/MRRhtMaivqskjctrn1 /OIWKPKqdI1Mmy90NI6PaidSF3pw8/1FXzRnNXhw7JfXlS2Tx6Wj5Jq8Q yXBytcj5QSJxysF4b/B/nEa1rjI4Yvty2bN+QhFGtKpvRuRkmg6DuyCh5 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAKRhQFGQ/khN/2dsb2JhbABDhQjBTRZ0gmgzDT0WGAMCAQIBSw0IAQGIEKAtoS2SVAOWVoV7inuDCjw X-IronPort-AV: E=Sophos;i="4.84,836,1355097600"; d="scan'208";a="12572902" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 13 Mar 2013 11:26:37 +0000 Received: from [10.61.65.93] (ams3-vpn-dhcp349.cisco.com [10.61.65.93]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r2DBQb2R025069 for ; Wed, 13 Mar 2013 11:26:37 GMT Message-ID: <5140626E.6030608@cisco.com> Date: Wed, 13 Mar 2013 11:26:38 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: IETF IPFIX Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] IPFIX processId uniqueness X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 11:26:44 -0000 Dear IPFIX experts, RFC5102 defines two processId IEs: meteringProcessId and exportingProcessId. And we could expect more *ProcessId IEs in future. Are these expected or required to be unique? Do we allow that a single process can both meter and export, therefore they are not unique? What about the case of multiple CPUs, where although the processes are unique, the processIDs happen to be identical? Thanks, P. From trammell@tik.ee.ethz.ch Wed Mar 13 06:42:50 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 633BB21F87F9 for ; Wed, 13 Mar 2013 06:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYCB8jTJQ7tx for ; Wed, 13 Mar 2013 06:42:49 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id B54C021F87AC for ; Wed, 13 Mar 2013 06:42:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 68310D9305; Wed, 13 Mar 2013 14:42:48 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id CHERos2HKdHf; Wed, 13 Mar 2013 14:42:48 +0100 (MET) Received: from dhcp-5213.meeting.ietf.org (dhcp-5213.meeting.ietf.org [130.129.82.19]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id C71C1D9304; Wed, 13 Mar 2013 14:42:47 +0100 (MET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Brian Trammell In-Reply-To: <5140626E.6030608@cisco.com> Date: Wed, 13 Mar 2013 09:42:45 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5140626E.6030608@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1499) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] IPFIX processId uniqueness X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 13:42:50 -0000 Hi, Paul, These appear to me to be completely implementation-dependent, and are = used to scope metadata reporting within an observation domain. I can't = think of a useful application of comparison among epId and mpId, so I'm = not sure why you'd need to enforce process ID uniqueness across multiple = process ID IEs. Because of the implementation-specificness, the CP, for = example, shouldn't presume that an MP an EP are the same (host OS) = process just because their epId and mpId match, but that's okay because = I can't see why the CP would ever have to deduce that anyway. Regards, Brian On 13 Mar 2013, at 7:26, Paul Aitken wrote: > Dear IPFIX experts, >=20 > RFC5102 defines two processId IEs: meteringProcessId and = exportingProcessId. And we could expect more *ProcessId IEs in future. >=20 > Are these expected or required to be unique? >=20 > Do we allow that a single process can both meter and export, therefore = they are not unique? >=20 > What about the case of multiple CPUs, where although the processes are = unique, the processIDs happen to be identical? >=20 > Thanks, > P. > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From tasaxena@cisco.com Wed Mar 13 07:32:22 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CEAE21F8E49 for ; Wed, 13 Mar 2013 07:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5donxuvTU+iN for ; Wed, 13 Mar 2013 07:32:21 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 5403421F8E53 for ; Wed, 13 Mar 2013 07:32:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1430; q=dns/txt; s=iport; t=1363185141; x=1364394741; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=N8cU4fGeAa92IzZ5ulJZDjKudgZ1d8rLrLzz7DQTXMM=; b=kXkhapixg9ye+tdWg+EZP9ZvY94aoDwn17n0BXtDvP3WxKO2USB8PAwi 0Rizb0GbgsZsnMpOcXB3FZXGHlCC0pGzUhYSLbPvUN2iIv+2IPh84OT6u KKsJAMM2r581cPY3graTEAUwW3ZDUZLiMPtOdlwh8ioQfZ2zh93byIbBo s=; X-IronPort-AV: E=Sophos;i="4.84,837,1355097600"; d="scan'208";a="186984851" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 13 Mar 2013 14:32:21 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r2DEWKpQ005953 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Mar 2013 14:32:20 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.248]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Wed, 13 Mar 2013 09:32:20 -0500 From: "Tarun Saxena (tasaxena)" To: "Paul Aitken (paitken)" , IETF IPFIX Working Group Thread-Topic: [IPFIX] IPFIX processId uniqueness Thread-Index: AQHOH92nakKIUh/AJU26IXie6AtY8ZijqjYA Date: Wed, 13 Mar 2013 14:32:19 +0000 Message-ID: References: <5140626E.6030608@cisco.com> In-Reply-To: <5140626E.6030608@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.103.230.191] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPFIX] IPFIX processId uniqueness X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 14:32:22 -0000 There are implementations where exporting and metering processes are same, = as well those where they are different. It would be nice to have the two independent of each other. They can be sam= e or different based on the dynamic assignment. There could be a problem in case if exporting and metering processes are ru= nning on different hardware and end up with the same pId. In that case it c= an be left to the implementation to decide if it wants to distinguish betwe= en the two by reserving some bits, as the RFC does not mandate the way in w= hich processId is framed. Thanks Tarun -----Original Message-----=20 From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf Of P= aul Aitken (paitken) Sent: Wednesday, March 13, 2013 4:57 PM To: IETF IPFIX Working Group Subject: [IPFIX] IPFIX processId uniqueness Dear IPFIX experts, RFC5102 defines two processId IEs: meteringProcessId and=20 exportingProcessId. And we could expect more *ProcessId IEs in future. Are these expected or required to be unique? Do we allow that a single process can both meter and export, therefore=20 they are not unique? What about the case of multiple CPUs, where although the processes are=20 unique, the processIDs happen to be identical? Thanks, P. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From muenz@net.in.tum.de Wed Mar 13 14:43:13 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC16821F8C4F for ; Wed, 13 Mar 2013 14:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fth4+xquk3Y7 for ; Wed, 13 Mar 2013 14:43:13 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mailsender1.informatik.tu-muenchen.de [131.159.0.97]) by ietfa.amsl.com (Postfix) with ESMTP id 5146121F8B9F for ; Wed, 13 Mar 2013 14:43:03 -0700 (PDT) Received: from [192.168.2.32] (g230151168.adsl.alicedsl.de [92.230.151.168]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 61014188DE61; Wed, 13 Mar 2013 22:43:00 +0100 (CET) Message-ID: <5140F2E1.10008@net.in.tum.de> Date: Wed, 13 Mar 2013 22:42:57 +0100 From: Gerhard Muenz User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Paul Aitken References: <510B8EA3.3050205@cisco.com> <511D8010.6030209@cisco.com> <511DFF13.6050001@net.in.tum.de> <51405471.6050406@cisco.com> In-Reply-To: <51405471.6050406@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] IPFIX observationPointId uniqueness X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 21:43:14 -0000 Paul, I always thought of OPID, ODID, MPID, EPID etc. as being abstract identifiers. If an implementation can map them directly to implementation-specific internal parameters, that's fine. If not, a mapping needs to be provided by the device. That's the same for other data models. For example, you would also need to assign ipfixObservationPointIndex for each OP if you implement IPFIX-MIB. You could use the same value for the OPID IE. If there is no other solution than map 32 bit directly into OPID, I would prefer changing OPID to unsigned64. Regards, Gerhard On 13.03.2013 11:26, Paul Aitken wrote: > Gerhard, > > We are monitoring traffic in multiple places - at the ingress and egress > interfaces, at processes, in ACLs, in policies. > > Each of these has a unique 32-bit ID (ie, there may be up to N x 32-bit > IDs). > > However, these IDs are in unique number spaces. eg, the interface ID > could happen to be the same as the process ID or the same as the policy > ID. So it's not possible to say what the ID represents without knowing > the type. > > You would meet this issue if you monitor interfaces and also want to > report PSAMP stats for each selection process. Somehow you need to > report distinct IDs for the interfaces versus the processes. > > Several possibilities come to mind: > > 1. use multiple different IEs, one per observation point type, with > multiple templates. This is not ideal, because we have to request new > IEs for each new observation point type, and store / export multiple > templates. ie, it adds a layer of unnecessary complexity rather than > rather than simplifying the export. > > 2. implement a conversion function, mapping the N x 32-bit IDs into the > 1 x 32-bit observationDomainID space. Obviously only a limited number of > conversions (1/N) are possible, and there'll be a trade-off between the > table size and lookup time. > > 3. associate an observationPointType with each observationPointID, and > not require any conversion at all. Each internal ID is mapped 1:1 with > an observationPointId, with uniqueness being determined by the > associated observationPointType. This is the simplest and cleanest solution. > > > So to answer your questions directly: > > - Do you really need OPID for your purpose? Have you thought about using > IEs like ingressPhysicalInterface or ingressInterface? Or, if these IEs > are not appropriate, about defining new IEs? > > - per (1) above, this makes for an unnecessarily complex solution. > > > - If you need to use OPIDs and if you want to avoid any mapping, have > you thought about assigning the different sources (interface cards, > VLANs) to different ODs? > > - they are all within a single OD. > - Example use case: report packet counts as traffic progresses > through selection and filtering within the router. The report will be > exported in a single message with a single OD in the header. > It's not possible to export a single cohesive report using > multiple ODs. > > P. > > > > On 15/02/13 09:25, Gerhard Muenz wrote: >> >> Benoit, Paul, >> >> Like Benoit, I do not have a good feeling about this proposal. On the >> other hand, I have not found any RFC that really requires the use of >> OPIDs. Even RFC5476 leaves it open whether the OP is identified by >> OPID or any other IE. Therefore, I have been silent until now. >> >> IPFIX-CONFIG assumes that the OPID is assigned by the IPFIX device, >> i.e. it is not a configuration parameter. I think that we agree here. >> >> Up to now, the IPFIX RFCs do not impose any restriction on the OPID >> except for the uniqueness per OD. This means that various >> implementations are possible right now: >> 1) OPID is equal to an internal identifier (e.g. internal interface >> number) or a non-IPFIX MIB index (e.g. ifIndex, entPhysicalIndex). >> 2) OPID is equal to the IPFIX-MIB index ipfixObservationPointIndex >> 3) OPID is unrelated to any other index, the IPFIX device provides the >> internal mapping >> >> If IPFIX-MIB is supported by the device, the natural choice for me >> would be 2). This would allow easy mapping of MIB entries and IPFIX >> export. >> >> As Paul points out, 1) only works as long as the internal identifiers >> are unique per OD. >> >> My questions to Paul are: >> - Do you really need OPID for your purpose? Have you thought about >> using IEs like ingressPhysicalInterface or ingressInterface? Or, if >> these IEs are not appropriate, about defining new IEs? >> - If you need to use OPIDs and if you want to avoid any mapping, have >> you thought about assigning the different sources (interface cards, >> VLANs) to different ODs? >> >> Regards, >> Gerhard >> >> >> On 15.02.2013 01:23, Benoit Claise wrote: >>> Paul, >>> >>> At first glance, it looks reasonable. >>> But what would be the consequence on the Selection Sequence Report >>> Interpretation(see http://tools.ietf.org/html/rfc5476#section-6.5.1). If >>> we use the observationPointId and it's not unique, then we need to >>> include the observationPointType? >>> Note that the sentence "It is RECOMMENDED that this identifier is also >>> unique per IPFIX Device." was inserted specifically for this. >>> >>> Regards, Benot >>>> Dear IPFIX experts, >>>> >>>> IPFIX observationPointId (#138) is defined as: >>>> >>>> An identifier of an Observation Point that is unique per >>>> Observation Domain. It is RECOMMENDED that this identifier is >>>> also unique per IPFIX Device. Typically, this Information >>>> Element is used for limiting the scope of other Information >>>> Elements. >>>> >>>> We now also have observationPointType (#277), defined as: >>>> >>>> Type of observation point. Values assigned to date are: >>>> >>>> 1. Physical port >>>> 2. Port channel >>>> 3. Vlan. >>>> >>>> >>>> Could we relax the uniqueness requirements of observationPointId when >>>> an observationPointType is also exported, such that the { >>>> observationPointType, observationPointId } pair must be unique, though >>>> not the observationPointId itself. >>>> >>>> The reason being that observation points of different types already >>>> have IDs, though these are not unique. eg, we have interface 1, 2, 3, >>>> ...; vlan 1, 2, 3, ...; port 1, 2, 3, ... >>>> >>>> So an extra mediation layer is required to convert values from each of >>>> these number spaces into unique IDs in the observationPointId number >>>> space - which becomes harder as we add more places that observations >>>> can be made, ie more observationPointTypes. >>>> >>>> Whereas prefixing with the observationPointType achieves the required >>>> uniqueness in a faster, simpler, and more reliable way. >>>> >>>> To achieve this, I'd propose the following definition change: >>>> >>>> An identifier of an Observation Point that is unique per >>>> Observation Domain and per observationPointType, if specified. >>>> It is RECOMMENDED that this identifier is >>>> also unique per IPFIX Device. Typically, this Information >>>> Element is used for limiting the scope of other Information >>>> Elements. >>>> >>>> For backwards compatibility, we could define observationPointType = 0 >>>> to be "unspecified". >>>> >>>> Thanks, >>>> P. >>>> >>>> >>>> _______________________________________________ >>>> IPFIX mailing list >>>> IPFIX@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipfix >>> >>> >>> >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix >>> > From ietf@meetecho.com Wed Mar 13 16:31:46 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F34411E8135 for ; Wed, 13 Mar 2013 16:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.66 X-Spam-Level: X-Spam-Status: No, score=-0.66 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXaTVKVhoYL2 for ; Wed, 13 Mar 2013 16:31:45 -0700 (PDT) Received: from smtpdg9.aruba.it (smtpdg8.aruba.it [62.149.158.238]) by ietfa.amsl.com (Postfix) with ESMTP id 3240411E810D for ; Wed, 13 Mar 2013 16:31:44 -0700 (PDT) Received: from dell-tcastaldi ([130.129.16.136]) by smtpcmd03.ad.aruba.it with bizsmtp id BBXg1l00U2w8SR601BXirw; Thu, 14 Mar 2013 00:31:43 +0100 Date: Wed, 13 Mar 2013 19:31:38 -0400 (EDT) From: Meetecho Team To: ipfix@ietf.org Message-ID: <11775580.15.1363217498489.JavaMail.tcastaldi@dell-tcastaldi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_14_13965908.1363217498487" Subject: [IPFIX] Meetecho support for IPFIX session X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 23:31:46 -0000 ------=_Part_14_13965908.1363217498487 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, a virtual room has been reserved on the Meetecho system for the IPFIX WG meeting session. Access to the on-line session (including audio and video streams) will be made available (just a couple of minutes before session start time) at: http://www.meetecho.com/ietf86/ipfix The Meetecho session automatically logs you into the standard IETF jabber room. So, from there, you can have an integrated experience involving all media and allowing you to interact with the room. A tutorial of interactivity features of the tool can be found at: http://www.meetecho.com/ietf86 Cheers, the Meetecho Team This email has been automatically generated by The Meetecho Conferencing System ------=_Part_14_13965908.1363217498487-- From paitken@cisco.com Thu Mar 14 03:59:41 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF74A21F8DCF for ; Thu, 14 Mar 2013 03:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JwnNIgSAtBE3 for ; Thu, 14 Mar 2013 03:59:36 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id CFB0521F8DDF for ; Thu, 14 Mar 2013 03:59:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25146; q=dns/txt; s=iport; t=1363258775; x=1364468375; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=gF5f/lvy/McoXcxgNrytpMKUGEmIldqNJs5jzMhAsf4=; b=JHI97fu+ZOvgEl+eD2buqmZK4wBKP87zZSChd2MsMG6WHT5Wszg1QXLC WGTc3TZr9BybixAWyGt5I2imzJK1kwFnoYZZDYtcA/QWEC4J+0m5l/ALJ GcPG0LNdYCblRCuePSGSpQt4C1e6ZlMJdRgBbbLwskn/8Qih4VtKtdVqq A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAKisQVGQ/khN/2dsb2JhbAA5BwPEfIFjFnSCKQEBAQMbHjQKCAkuNAIKQgEMBgIBAQUSh3MGDMEkBI1AAgkGgSsogy8Di3eHHINFgR+EXnKEfIUXgwo8gTc X-IronPort-AV: E=Sophos;i="4.84,844,1355097600"; d="scan'208";a="81266630" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 14 Mar 2013 10:59:32 +0000 Received: from [10.61.89.71] (ams3-vpn-dhcp6472.cisco.com [10.61.89.71]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r2EAxVXM022100; Thu, 14 Mar 2013 10:59:31 GMT Message-ID: <5141AD94.60703@cisco.com> Date: Thu, 14 Mar 2013 10:59:32 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: IETF IPFIX Working Group , draft-krishnan-ipfix-flow-aware-packet-sampling@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] review of draft-krishnan-ipfix-flow-aware-packet-sampling-03 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 10:59:41 -0000 Dear authors, Please find some review comments inline: > IPFIX R. Krishnan > Internet Draft D. Meyer > Intended status: Informational Brocade Communications > Expires: August 2013 Ning So > February 24, 2013 Tata Communications > > > > Flow Aware Packet Sampling Techniques > > draft-krishnan-ipfix-flow-aware-packet-sampling-03.txt > > Status of this Memo > > This Internet-Draft is submitted in full conformance with the > provisions of BCP 78 and BCP 79. This document may not be modified, > and derivative works of it may not be created, except to publish it > as an RFC and to translate it into languages other than English. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html > > This Internet-Draft will expire on August 24, 2013. > > Copyright Notice > > Copyright (c) 2013 IETF Trust and the persons identified as the > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with respect > to this document. > > > > Krishnan Expires August 24, 2013 [Page 1] > > Internet-Draft Flow Aware Packet Sampling Techniques February 2013 > > > Abstract > > The demands on the networking infrastructure and thus the > switch/router bandwidths are growing exponentially; the drivers are > bandwidth hungry rich media applications, inter data center > communications etc. Using sampling techniques, for a given sampling > rate, the amount of samples that need to be processed is increasing > exponentially. This draft suggests flow aware sampling techniques for > handling various scenarios with minimal sampling overhead. > > Table of Contents > > > 1. Introduction...................................................2 > 1.1. Acronyms..................................................3 > 1.2. Terminology...............................................3 > 2. Flow Aware Packet Sampling.....................................3 > 2.1. Large Flow Recognition....................................4 > 2.1.1. Flow Identification..................................4 > 2.1.2. Criteria for Identifying a Large Flow................5 > 2.1.3. Automatic Recognition................................5 > 2.1.3.1. Applicability of suggested technique............6 > 2.1.3.2. Enhancements to suggested technique.............7 > 2.1.3.3. Handling Inactive Large Flows...................7 > 2.1.4. Simulation...........................................7 > 3. Acknowledgements...............................................7 > 4. IANA Considerations............................................7 > 5. Security Considerations........................................7 > 6. Data Model Considerations......................................8 > 7. References.....................................................8 > 7.1. Normative References......................................8 > 7.2. Informative References....................................8 > > 1. Introduction > > Packet sampling techniques in switches and routers provide an > effective mechanism for approximate detection of various types of > flows -- long-lived large flows and other flows (which include long- > lived small flows, short-lived small/large flows) with minimal packet > replication bandwidth overhead. A large percentage of the packet > samples comprise of long-lived large flows and a small percentage of > the packet samples comprise of other flows. The long-lived large > flows aka top-talkers consume a large percentage of the bandwidth and > small percentage of the flow space. The other flows, which are the > typical cause of security threats like Denial of Service (DOS) > attacks, Scanning attacks etc., consume a small percentage of the > bandwidth and a large percentage of the flow space. This draft > > > Krishnan Expires August 24, 2013 [Page 2] > > Internet-Draft Flow Aware Packet Sampling Techniques February 2013 > > > explores light-weight techniques for automatically detecting the top- > talkers in real-time with a high degree of accuracy and sampling only > the other flows -- this makes security threat detection more > effective with minimal sampling overhead. > > 1.1. Acronyms > > DOS: Denial of Service > > GRE: Generic Routing Encapsulation > > MPLS: Multi Protocol Label Switching > > NVGRE: Network Virtualization using Generic Routing Encapsulation > > TCAM: Ternary Content Addressable Memory > > STT: Stateless Transport Tunneling > > VXLAN: Virtual Extensible LAN > > 1.2. Terminology > > Large flow(s): long-lived large flow(s) > > Small flow(s): long-lived small flow(s) and short-lived small/large > flow(s) These definitions are circular, and inconsistent with the text below. Rather, use the same definitions as below: "Large flow: a long-lived flow which exceeds a certain minimum bandwidth threshold over an observation interval." > > 2. Flow Aware Packet Sampling > > The steps in flow aware packet sampling are described below > > 1) Large Flow Recognition in switches and routers: > > From a bandwidth and time duration perspective, in order to > identify large flows in switches and routers, we define an > observation interval and observe the bandwidth of the flow over > that interval. A flow that exceeds a certain minimum bandwidth > threshold over that observation interval would be considered a > large flow. For identifying large flows, use the techniques > described in Section 2.1. This helps in identifying the large > flows aka top-talkers in real-time with a high degree of accuracy > in switches and routers. > > 2) Large Flow Classification: > > > > > Krishnan Expires August 24, 2013 [Page 3] > > Internet-Draft Flow Aware Packet Sampling Techniques February 2013 > > > The identified large flows can be broadly classified into 2 > categories as detailed below. > > a. Well behaved (steady rate) large flows, e.g. video streams > > b. Bursty (fluctuating rate) large flows e.g. Peer-to-Peer > traffic > > The large flows can be sampled at a low rate for further analysis > or need not be sampled. If desired, the large flows could be > exported to a central entity, for e.g. Netflow Collector, for > further analysis. If large flows are not sampled, then how do we know they're large flows? ie, there seems to be a pre-requisite flow classification step ahead of the sampling. > > 3) Small Flow Processing: > > The small flows (excluding the large flows) can be sampled at a > normal rate. The small flows can be examined for determining > security threats like DOS attacks (for e.g. SYN floods), Scanning > attacks etc. [FDDOS, PDSN, ALDS] > > Thus, we can see that, security threat detection is possible with > minimal sampling overhead. Paraphrasing what I read so far: traffic may be divided into two groups, using techniques to be discussed in s2.1. Since this task is out of scope of the current discussion, our task is trivial: one group can be ignored, while the other group contains all the security threats. So forget about "large" and "small" flows for a moment. I went back a and re-read the above text substituting s/large/safe/ and s/small/dangerous/, which was much more entertaining. > > For packet sampling, it is recommended to use PSAMP -- [RFC 5474], > [RFC 5475], [RFC 5476], [RFC 5477]. > > 2.1. Large Flow Recognition > > 2.1.1. Flow Identification > > A flow (large flow or small flow) can be defined as a sequence of > packets for which ordered delivery should be maintained. Flows are This isn't the IPFIX definition of "Flow". > typically identified using one or more fields from the packet header > from the following list: > > . Layer 2: source MAC address, destination MAC address, VLAN ID. > > . IP header: IP Protocol, IP source address, IP destination > address, flow label (IPv6 only), TCP/UDP source port, TCP/UDP > destination port. > > . MPLS Labels. In one implementation, perhaps. Per RFC5101, flows are defined by packet header fields, and also by packet characteristics and by fields derived from the packet treatment. In fact, IPFIX defines over 300 fields which can be used. So the above list isn't a typical list; it's just one example. > > For tunneling protocols like GRE, VXLAN, NVGRE, STT, etc., flow > identification is possible based on inner and/or outer headers. The > above list is not exhaustive. The mechanisms described in this > > > > Krishnan Expires August 24, 2013 [Page 4] > > Internet-Draft Flow Aware Packet Sampling Techniques February 2013 > > > document are agnostic to the fields that are used for flow > identification. > > 2.1.2. Criteria for Identifying a Large Flow > > From a bandwidth and time duration perspective, in order to identify > large flows we define an observation interval and observe the > bandwidth of the flow over that interval. A flow that exceeds a > certain minimum bandwidth threshold over that observation interval > would be considered a large flow. You'll have to look at every packet to determine the bandwidth, which rather defeats the point of sampling - which is that you only need to look at a small number of packets to gain an impression of the traffic. > > The two parameters -- the observation interval, and the minimum > bandwidth threshold over that observation interval -- should be > programmable in a switch or a router to facilitate handling of > different use cases and traffic characteristics. For example, a flow > which is at or above 10 Mbps for a time period of at least 30 minutes > could be declared a large flow. > > An optional parameter is a policy specification (for e.g. identify > flows only from a given IP source and/or destination address) Again, this requires looking at every packet in order to filter those of interest - which rather defeats the point of sampling. Also, by the time the flow has been identified as either "large" or "small", it'll be too late to begin sampling it since the packets will be gone. So, sampling must be done on all traffic (ie, in real time) until the large / small determination is made, at which time the large flows can be disregarded. Also, there's a trivial attack vector: the attacker simply sends a long-lived ("large") flow, which will be determined as "safe" and therefore disregarded. > > 2.1.3. Automatic Recognition > > Implementations can perform automatic recognition of large flows in a > switch or a router -- it is an inline solution and would be expected > to operate at line rate. > > The advantages and disadvantages of automatic recognition are: > > Advantages: > > . Accurate and performed in real-time. > > Disadvantages: > > . Not supported in many switches and routers. > > As mentioned earlier, the observation interval for determining a > large flow and the bandwidth threshold for classifying a flow as a > large flow should be programmable parameters in a switch or a router. > > The implementation of automatic recognition of large flows is vendor > dependent. Below is a suggested technique. > > This technique uses a counting Bloom filter using thresholding and > periodic reset. This technique requires a few tables -- a flow table, > and multiple hash tables. > > > Krishnan Expires August 24, 2013 [Page 5] > > Internet-Draft Flow Aware Packet Sampling Techniques February 2013 > > > The flow table comprises entries which are programmed with packet > fields for flows that are already known to be large flows and each > entry has a corresponding byte counter. It is initialized as an > empty table (i.e. none of the incoming packets would match a flow > table entry). > > The hash tables each have a different hash function and comprise > entries which are byte counters. The counters are initialized to > zero and would be modified as described by the algorithm below. > > Step 1) If the large flow exists in the flow table (for e.g. TCAM), > increment the counter associated with the flow by the packet size. > Else, proceed to Step 2. > > Step 2) The hash function for each table is applied to the fields of > the packet header and the result is looked up in parallel in > corresponding hash table and the associated counter corresponding to > the entry that is hit in that table is incremented by the packet > size. If the counter exceeds a programmed byte threshold in the > observation interval (this counter threshold would be set to match > the bandwidth threshold) in the entries that were hit in all of the > hash tables, a candidate large flow is learnt and programmed in the > flow table and the counters are reset. > > Additionally, the counters in all of the hash tables must be reset > every observation interval. Since these aren't rolling counters, a "large" flow which crosses the interval boundary could be mis-classified as two "small" flows. > > There may be some false positives due to multiple small flows > masquerading as a large flow. The number of such false positives is > reduced by increasing the number of parallel hash tables using > different hash functions. There will be a design tradeoff between > size of the hash tables, the number of hash tables, and the > probability of a false positive. > > This technique for automatic recognition is also suggested in [draft- > krishnan-opsawg-large-flow-load-balancing] -- please refer to the > draft for more details on the algorithm. > > 2.1.3.1. Applicability of suggested technique > > The suggested technique for automatic recognition works well for > standard applications generating large flows, for e.g. video content > like movies and catch-up episodes, backup transactions etc. with a > detection time of approximately 30-60 seconds. These detection times > ensure that short-lived large flows, for e.g. HD video clips, are not > unnecessarily recognized. You've implemented this? > > > > Krishnan Expires August 24, 2013 [Page 6] > > Internet-Draft Flow Aware Packet Sampling Techniques February 2013 > > > 2.1.3.2. Enhancements to suggested technique > > If faster flow recognition times are desired (much shorter than 30s), > the suggested technique may pose the following problem that the > effective filtered flow size is phase-dependent: that is, relatively > smaller constant-rate flows, for e.g. HD video clips, beginning early > within a counting Bloom filter reset interval would be unnecessarily > detected with the same probability as relatively larger flows > beginning toward the interval. > > [VRM] suggests techniques for addressing the above problem using > rotating conservative counting Bloom filters with periodic decay. > > 2.1.3.3. Handling Inactive Large Flows > > Once a flow has been recognized as a large flow, it should continue > to be recognized as a large flow as long as the traffic received > during an observation interval exceeds some fraction of the bandwidth > threshold, for example 80% of the bandwidth threshold. If the traffic > received during an observation interval falls below a fraction of the > bandwidth threshold, the large flow should be removed from the flow- > table. Unfortunately it's not possible to know for certain whether the flow's traffic exceeds the bandwidth threshold until the end of the observation interval (eg, if the flow is bursty, and only exceeds the threshold in the closing moments of the interval). Therefore many large flows from previous intervals will inhabit the table while waiting to be determined as small flows and removed. This may prevent new large flows from the current interval from being added. In the worst case, if an average of N "large" flows are determined in an interval, then the table would need to store 2N flows: N from the previous interval, and N from the current interval (although there may be some overlap, so < 2N). If a flow's bandwidth is low during one observation interval, it would be removed then have to be re-learnt in the next interval. > > 2.1.4. Simulation > > Simulation results for flow aware packet sampling are presented in > Appendix A. The goal of the simulation is to demonstrate the > effectiveness of flow aware packet sampling in a multi-tenant video > streaming data center. > > 3. Acknowledgements > > The authors would like to thank Juergen Quittek, Brian Carpenter, > Michael Fargano, Michael Bugenhagen, Jianrong Wong and Brian > Trammell for all the support and valuable input. > > 4. IANA Considerations > > This memo includes no request to IANA. > > 5. Security Considerations > > This document does not directly impact the security of the Internet > infrastructure or its applications. In fact, it proposes techniques > which could help in identifying a DOS attack pattern. > > > > Krishnan Expires August 24, 2013 [Page 7] > > Internet-Draft Flow Aware Packet Sampling Techniques February 2013 > > > > 6. Data Model Considerations > > In Section 2, for exporting the identified large flows to an external > entity, it is recommended to use IPFIX protocol [RFC 5101]. > > Section 2.1.2 defines programmable parameters in switches and routers > for automatic identification. IETF could potentially consider a > standards-based activity around defining a data model for moving this > information from a central management entity to the switch/router. What's your goal? > > 7. References > > 7.1. Normative References > > 7.2. Informative References > > [RFC 5474] N. Duffield et al., "A Framework for Packet Selection and > Reporting", March 2009. > > [RFC 5475] T. Zseby et al., "Sampling and Filtering Techniques for IP > Packet Selection", March 2009. > > [RFC 5476] B. Claise, Ed. et al., "Packet Sampling (PSAMP) Protocol > Specifications", March 2009. > > [RFC 5477] T. Dietz et al., "Information Model for Packet Sampling > Exports", March 2009. > > [RFC 5101] B. Claise, "Specification of the IP Flow Information > Export (IPFIX) Protocol for the Exchange of IP Traffic Flow > Information", January 2008 > > [draft-krishnan-opsawg-large-flow-load-balancing] R. Krishnan et > al., "Best Practices for Optimal LAG/ECMP Component Link Utilization > in Provider Backbone Networks", February 2013 > > [VRM] G. Bianchi et al., "Measurement Data Reduction through > Variation Rate Metering", INFOCOM 2010 > > [PDSN] Ignasi Paredes-Oliva et al., "Portscan Detection with Sampled > NetFlow", TMA 2009 > > [ALDS] Z. Morley Mao et al., "Analyzing Large DDoS Attacks Using > Multiple Data Sources", SIGCOMM 2006 > > > > > Krishnan Expires August 24, 2013 [Page 8] > > Internet-Draft Flow Aware Packet Sampling Techniques February 2013 > > > [FDDOS] David Holmes, "The DDoS Threat Spectrum", F5 White paper 2012 > > Appendix A: Simulation of Flow aware packet sampling > > Goal: > > Demonstrate the effectiveness of flow aware packet sampling in a > practical use case, for e.g. multi-tenant video streaming in a data > center. > > Test Topology: > > Multiple virtual servers (server hosted on a virtual machine) > connected to a virtual switch (vSwitch) which in turn connects to the > data center network using a 10Gbps ethernet interface. > > 2 virtual servers are active. > > First virtual server > > . Traffic types > > o HD MPEG-4 video streams (bit rate 10Mbps) - 100 - 1Gbps > > o SD MPEG-2 video streams (bit rate 4Mbps) - 300 - 1.2Gbps > > o Other traffic - 500Mbps (Video clips, DOS attacks (for e.g. > SYN floods), Scanning attacks etc.) > > . Aggregate traffic - 2.7Gbps > > Second virtual server > > . Traffic types > > o HD MPEG-4 video streams (bit rate 10Mbps) - 50 - .5Gbps > > o SD MPEG-2 video streams (bit rate 4Mbps) - 500 - 2.0Gbps > > o Backup transaction - 100Mbps > > o Other traffic - 500Mbps (Video clips, DOS attacks (for e.g. > SYN floods), Scanning attacks etc.) > > . Aggregate traffic - 3.1Gbps > > Total traffic on 2 servers - 5.8Gbps > > > Krishnan Expires August 24, 2013 [Page 9] > > Internet-Draft Flow Aware Packet Sampling Techniques February 2013 > > > Existing techniques: > > Normal sampling rate - 1:1000 > > Total sampled traffic = 5.8Gbps/1000 = 5.8Mbps > > Flow aware sampling technique: > > Large flow recognition parameters > > . Observation interval for large flow - 60 seconds > > . Minimum bandwidth threshold over the observation interval - > 2Mbps > > Aggregate bit rate of large flows = 4.8Gbps > > Aggregate bit rate of small flows = 1Gbps > > Low sampling rate of large flows - 1:10000 > > Normal sampling rate of small flows - 1:1000 > > Total sampled traffic = 4.8Gbps/10000 + 1Gbps/1000 = 1.48Mbps > > Percentage improvement in sampling (most of the samples are only > small flows) = (5.8 - 1.48)/5.8 ~= 78% > > The small flows can be examined in a central entity like Netflow > Collector for determining security threats like DOS attacks, Scanning > attacks etc. Thus, we can see that, security threat detection is > possible with minimal sampling overhead. Agreed, when classification is moved to a separate step and disregarded. Analogy: consider anti-virus on a PC. If all the viruses are put into one folder by some means, then quarantining them will become trivially easy. P. > > Authors' Addresses > > Ram Krishnan > Brocade Communications > San Jose, 95134, USA > > Phone: +001-408-406-7890 > Email: ramk@brocade.com > > > David Meyer > Brocade Communications > > > > Krishnan Expires August 24, 2013 [Page 10] > > Internet-Draft Flow Aware Packet Sampling Techniques February 2013 > > > San Jose, 95134, USA > > Phone: +001-408-333-4193 > Email: dmm@1-4-5.net > > Ning So > Tata Communications > Plano, TX 75082, USA > > Phone: +001-972-955-0914 > Email: ning.so@tatacommunications.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Krishnan Expires August 24, 2013 [Page 11] > From paitken@cisco.com Thu Mar 14 05:18:04 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90A7021F8AD8 for ; Thu, 14 Mar 2013 05:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.233 X-Spam-Level: X-Spam-Status: No, score=-5.233 tagged_above=-999 required=5 tests=[FF_IHOPE_YOU_SINK=2.166, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGZ9Goi21GH5 for ; Thu, 14 Mar 2013 05:18:00 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 177FC21F8E0F for ; Thu, 14 Mar 2013 05:17:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=65427; q=dns/txt; s=iport; t=1363263478; x=1364473078; h=message-id:date:from:mime-version:to:subject; bh=6qLybVfipvGNcW4O5R9JyXt8N8U6kHVsnIOSQc4DwT4=; b=ILJMXLtnGP9Qvp6Pc4ZmpnC/6hlXe8IRbsVMjvHWmoAbt7duIeYATy3L vN9IRvXQGBgRtvf+TP82w7dVKnPG/YQQ8CT8IXW1CkHClkHPT9r5CpKOf dQFlwtwkll3FykvzmPAgk7wV/H52q7gtDbBEn9nIGfVljqb44vclNnxXs k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAG6+QVGQ/khR/2dsb2JhbAA5CsR5gWEWdIIpAQEBAxsBXQYJHw8WAQEWAwIBAgEJLhQBDAYCAQEFiAUGDMEoBI1ACwaBD4NzA5ZYgR+EXosFgwo8gTc X-IronPort-AV: E=Sophos;i="4.84,844,1355097600"; d="scan'208,217";a="81269006" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 14 Mar 2013 12:17:56 +0000 Received: from [10.61.89.71] (ams3-vpn-dhcp6472.cisco.com [10.61.89.71]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r2ECHsQT020121; Thu, 14 Mar 2013 12:17:54 GMT Message-ID: <5141BFF2.8010501@cisco.com> Date: Thu, 14 Mar 2013 12:17:54 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: draft-trammell-ipfix-text-adt@tools.ietf.org, IETF IPFIX Working Group Content-Type: multipart/alternative; boundary="------------070009070908000601030807" Subject: [IPFIX] review of draft-trammell-ipfix-text-adt-00 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 12:18:04 -0000 This is a multi-part message in MIME format. --------------070009070908000601030807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Brian, Here's a review of draft-trammell-ipfix-text-adt-00. Please find comments inline. > > > > IPFIX Working Group B. Trammell > Internet-Draft ETH Zurich > Intended status: Informational November 5, 2012 > Expires: May 9, 2013 > > > Textual Representation of IPFIX Abstract Data Types > draft-trammell-ipfix-text-adt-00.txt > > Abstract > > This document defines UTF-8 representations for IPFIX abstract data > types, to support interoperable usage of the IPFIX Information > Elements with protocols based on textual encodings. > > Status of this Memo > > This Internet-Draft is submitted in full conformance with the > provisions of BCP 78 and BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF). Note that other groups may also distribute > working documents as Internet-Drafts. The list of current Internet- > Drafts is at http://datatracker.ietf.org/drafts/current/. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > This Internet-Draft will expire on May 9, 2013. > > Copyright Notice > > Copyright (c) 2012 IETF Trust and the persons identified as the > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the Simplified BSD License. > > > > > > Trammell Expires May 9, 2013 [Page 1] > > Internet-Draft IPFIX Text Types November 2012 > > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 3. Identifying Information Elements . . . . . . . . . . . . . . . 3 > 4. Data Type Encodings . . . . . . . . . . . . . . . . . . . . . 4 > 4.1. octetArray . . . . . . . . . . . . . . . . . . . . . . . . 4 > 4.2. unsigned* . . . . . . . . . . . . . . . . . . . . . . . . 4 > 4.3. signed* . . . . . . . . . . . . . . . . . . . . . . . . . 5 > 4.4. float* . . . . . . . . . . . . . . . . . . . . . . . . . . 6 > 4.5. boolean . . . . . . . . . . . . . . . . . . . . . . . . . 6 > 4.6. macAddress . . . . . . . . . . . . . . . . . . . . . . . . 6 > 4.7. string . . . . . . . . . . . . . . . . . . . . . . . . . . 6 > 4.8. dateTime* . . . . . . . . . . . . . . . . . . . . . . . . 6 > 4.9. ipv4Address . . . . . . . . . . . . . . . . . . . . . . . 7 > 4.10. ipv6Address . . . . . . . . . . . . . . . . . . . . . . . 7 > 4.11. basicList, subTemplateList, and subTemplateMultiList . . . 7 > 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 > 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 > 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 > 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 > 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 > Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . . 8 > Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 > > > > > > > > > > > > > > > > > > > > > > > > > > > > Trammell Expires May 9, 2013 [Page 2] > > Internet-Draft IPFIX Text Types November 2012 > > > 1. Introduction > > The IPFIX Information Model, as defined by the IANA IPFIX Information > Element Registry, provides a rich set of Information Elements for > description of information about network entities and network traffic > data, and abstract data types for these Information Elements. The > IPFIX Protocol Specification [I-D.ietf-ipfix-protocol-rfc5101bis], in > turn, defines a big-endian binary encoding for these abstract data > types suitable for use with the IPFIX Protocol. > > However, present and future operations and management protocols and > applications may use textual encodings, and generic framing and > structure as in JSON or XML. A definition of canonical textual > encodings for the IPFIX abstract data types would allow this set of > Information Elements to be used for such applications, and for these > applications to interoperate with IPFIX applications at the > Information Element definition level. > > Note that templating or other mechanisms for data description for > such applications and protocols are application specific, and > therefore out of scope for this document: only Information Element > identification and data value representation are defined here. > > > 2. Terminology > > Capitalized terms defined in the IPFIX Protocol Specification > [I-D.ietf-ipfix-protocol-rfc5101bis] and the IPFIX Information Model > [I-D.ietf-ipfix-information-model-rfc5102bis] are used in this > document as defined in those documents. In addition, this document > defines the following terminology for its own use: > > Enclosing Context > Textual representation of IPFIX data values is applied to use the > IPFIX Information Model within some existing textual format (e.g. > XML, JSON). This outer format is referred to as the Enclosing > Context within this document. Enclosing Contexts define escaping > and quoting rules for represented data values. > > > 3. Identifying Information Elements > > The IPFIX Information Element Registry [iana-ipfix-assignments] > defines a set of Information Elements and numbered by Information Doesn't parse. Remove "and". > Element Identifiers, and named for human-readability. These > Information Element Identifiers are meant for use with the IPFIX > protocol, and have little meaning when applying the IPFIX Information > Element Registry to textual representations. > > > > Trammell Expires May 9, 2013 [Page 3] > > Internet-Draft IPFIX Text Types November 2012 > > > Instead, applications using textual representations of Information > Elements SHOULD use Information Element names to identify them; see > Appendix A for examples illustrating this principle. If the names are to be the (joint?) primary reference for IEs, then IE doctors should review all the IE names to ensure consistency, and define rules for new IE names to ensure that consistency is maintained. > > > 4. Data Type Encodings > > [FIXME frontmatter] > > This section uses ABNF [RFC5234], including the Core Rules in Where is "Core Rules" defined? > Appendix B, to describe the format of textual representations of > IPFIX abstract data types. > > 4.1. octetArray > > [FIXME: native hex strings for comparative human readabilty.] > > 4.2. unsigned* * it's a pointer? > > First, in the special case that the unsigned Information Element has > identifier semantics, and refers to a set of codepoints, either in an > external registry, a sub-registry, or directly in the description of > the Information Element, then the name or short description for that > codepoint MAY be used to improve readability. > > If the Enclosing Context defines a representation for unsigned > integers, that representation SHOULD be used. > > Otherwise, the values of Information Elements of an unsigned integer > type may be represented either as unprefixed base-10 (decimal) > strings, or as base-16 (hexadecimal) strings prefixed by '0x'; in > ABNF: > > unsigned = 1*DIGIT / '0x' 1*HEXDIG RFC5234, sigh: / looks like division, although it's intended as "OR". Consider allowing binary or any arbitrary number base to be used. > > Leading zeroes are allowed in either encoding, and do not signify > base-8 (octal) encoding. > > The encoded value must be in range for the corresponding abstract > data type or Information Element. Out of range values should be > interpreted as clipped to the implicit range for the Information > Element as defined by the abstract data type, or to the explicit > range of the Information Element if defined. Minimum and maximum > values for abstract data types are shown in Table 1 below. > > > > > > > > Trammell Expires May 9, 2013 [Page 4] > > Internet-Draft IPFIX Text Types November 2012 > > > +------------+---------+----------------------+ > | type | minimum | maximum | > +------------+---------+----------------------+ > | unsigned8 | 0 | 255 | > | unsigned16 | 0 | 65536 | > | unsigned32 | 0 | 4294967295 | > | unsigned64 | 0 | 18446744073709551615 | > +------------+---------+----------------------+ > > Table 1: Ranges for unsigned abstract data types > Can we ever get away from the idea that u8, u16, u32, and u64 are different types? Rather, they're just different size encodings of the same type. > 4.3. signed* (Same comments for this section as for "unsigned" above.) > > If the Enclosing Context defines a representation for signed > integers, that representation should be used. > > Otherwise, the values of Information Elements of signed integer types > should be represented as optionally-prefixed base-10 (decimal) > strings; if the sign is omitted, it is assumed to be positive. In > ABNF: > > sign = "+" / "-" > > signed = [sign] 1*DIGIT > > Leading zeroes are allowed, and do not signify base-8 (octal) > encoding. > > The encoded value must be in range for the corresponding abstract > data type or Information Element. Out of range values should be > interpreted as clipped to the implicit range for the Information > Element as defined by the abstract data type, or to the explicit > range of the Information Element if defined. Minimum and maximum > values for abstract data types are shown in Table 2 below. > > +----------+----------------------+----------------------+ > | type | minimum | maximum | > +----------+----------------------+----------------------+ > | signed8 | -128 | +127 | > | signed16 | -32768 | +32767 | > | signed32 | -2147483648 | +2147483647 | > | signed64 | -9223372036854775808 | +9223372036854775807 | > +----------+----------------------+----------------------+ > > Table 2: Ranges for signed abstract data types > > > > > > > Trammell Expires May 9, 2013 [Page 5] > > Internet-Draft IPFIX Text Types November 2012 > > > 4.4. float* > > If the Enclosing Context defines a representation for floating point > numbers, that representation should be used. > > [FIXME: there appears to be no defined (non-interchange) format for > floating point numbers, but we probably want to define something > reasonably human-readable without getting too into locale issues.] > > exponent = 'e' 1*3DIGIT > > right-decimal = '.' 0*DIGIT ie, a decimal point with at least zero digits following? Why? The decimal point is only required when there are following digits. > > float = [sign] 1*DIGIT [right-decimal] [exponent] > > 4.5. boolean > > [FIXME: frontmatter. note that booleans may also be natually Typo, "naturally". > represented by the presence or absence of a value in the structure of > the document in the Enclosing Context.] > > boolean-yes = "1" / "y" / "Y" / "t" / "T" > > boolean-no = "0" / "n" / "N" / "f" / "F" > > boolean = boolean-yes / boolean-no RFC5235 ABNF inconsistently uses - as a range indicator while also allowing it in rule names. > > 4.6. macAddress > > [FIXME: frontmatter] > > macaddress = 2*HEXDIG 5*( ":" 2*HEXDIG ) Should be "5*5" to constrain the maximum size too, since exactly 6 pairs of digits are required. > > 4.7. string > > As Information Elements of the string type are simply UTF-8 encoded > strings, they are represented directly, subject to the escaping and > encoding rules of the Enclosing Context. If the Enclosing Context > cannot natively represent UTF-8 characters, the escaping facility > provided by the Enclosing Context must be used for non-representable > characters. Additionally, strings containing characters reserved in > the Enclosing Context (e.g. markup characters, quotes) must be > escaped or quoted according to the rules of the Enclosing Context. > > 4.8. dateTime* > > [FIXME: [RFC3339]] > > > > > Trammell Expires May 9, 2013 [Page 6] > > Internet-Draft IPFIX Text Types November 2012 > > > [FIXME: explain precision rules] > > 4.9. ipv4Address > > [FIXME: frontmatter. dotted-quad.] > > ipv4address = 1*3DIGIT 3*( "." 1*3DIGIT ) Again, use 3*3 to constrain the maximum length, since exactly 4 digits are required. > > 4.10. ipv6Address > > [FIXME: section 2.2 of [RFC4291], recommend section 4 of [RFC5952]] > > 4.11. basicList, subTemplateList, and subTemplateMultiList > > These abstract data types, defined for IPFIX Structured Data > [RFC6313], do not represent actual data types; they are instead > designed to provide a mechanism by which complex structure below the > template level. It is assumed that protocols using textual > Information Element representation will provide their own structure. > Therefore, Information Elements of these Data Types should not be > used in textual representations. Doesn't make sense. > > > 5. Security Considerations > > [FIXME: content would be nice] > > > 6. IANA Considerations > > This document has no considerations for IANA. > > > 7. References > > 7.1. Normative References > > [I-D.ietf-ipfix-protocol-rfc5101bis] > Claise, B. and B. Trammell, "Specification of the IP Flow > Information eXport (IPFIX) Protocol for the Exchange of > Flow Information", draft-ietf-ipfix-protocol-rfc5101bis-02 > (work in progress), June 2012. > > [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the > Internet: Timestamps", RFC 3339, July 2002. > > [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing > Architecture", RFC 4291, February 2006. > > > > Trammell Expires May 9, 2013 [Page 7] > > Internet-Draft IPFIX Text Types November 2012 > > > [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax > Specifications: ABNF", STD 68, RFC 5234, January 2008. > > [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 > Address Text Representation", RFC 5952, August 2010. > > [iana-ipfix-assignments] > Internet Assigned Numbers Authority, "IP Flow Information > Export Information Elements > (http://www.iana.org/assignments/ipfix/ipfix.xml)", > November 2012. > > 7.2. Informative References > > [I-D.ietf-ipfix-information-model-rfc5102bis] > Claise, B. and B. Trammell, "Information Model for IP Flow > Information eXport (IPFIX)", > draft-ietf-ipfix-information-model-rfc5102bis-06 (work in > progress), October 2012. > > [I-D.ietf-ipfix-ie-doctors] > Trammell, B. and B. Claise, "Guidelines for Authors and > Reviewers of IPFIX Information Elements", > draft-ietf-ipfix-ie-doctors-07 (work in progress), > October 2012. > > [RFC6313] Claise, B., Dhandapani, G., Aitken, P., and S. Yates, > "Export of Structured Data in IP Flow Information Export > (IPFIX)", RFC 6313, July 2011. > > > Appendix A. Example > > In this section, we examine an IPFIX Template and a Data Record > defined by that Template, and show how that Data Record would be > represented in JSON according to the specification in this document. > Note that this is specifically NOT a recommendation for a particular > representation, merely an illustration of the encodings in this > document. > > [FIXME improve frontmatter] Figure 1 shows a Template in IEspec > format as defined in section 9.1 of [I-D.ietf-ipfix-ie-doctors]. A > Message containing this Template and a Data Record is shown in > Figure 2, and a corresponding JSON Object using the text format > defined in this document is shown in Figure 3. Personally I'd rather that each description immediately precedes the corresponding figure. P. > > > > > > > Trammell Expires May 9, 2013 [Page 8] > > Internet-Draft IPFIX Text Types November 2012 > > > flowStartMilliseconds(152)[8] > flowEndMilliseconds(153)[8] > octetDeltaCount(1)[4] > packetDeltaCount(2)[4] > sourceIPv6Address(27)[4]{key} > destinationIPv6Address(28)[4]{key} > sourceTransportPort(7)[2]{key} > destinationTransportPort(11)[2]{key} > protocolIdentifier(4)[1]{key} > tcpControlBits(6)[1] > flowEndReason(136)[1] > > Figure 1: Sample flow template (IPFIX) > > > 1 2 3 4 5 6 > 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 0x000a | length 135 | export time 1352140263 | msg > | sequence 0 | domain 1 | hdr > | SetID 2 | length 52 | tid 256 | fields 11 | tmpl > | IE 152 | length 8 | IE 153 | length 8 | set > | IE 1 | length 4 | IE 2 | length 4 | > | IE 27 | length 16 | IE 28 | length 16 | > | IE 7 | length 2 | IE 11 | length 2 | > | IE 4 | length 1 | IE 6 | length 1 | > | IE 136 | length 1 | SetID 256 | length 83 | data > | start time 1352140261135 | set > | end time 1352140262880 | > | octets 195383 | packets 88 | > | sip6 | > | 2001:0db8:000c:1337:0000:0000:0000:0002 | > | dip6 | > | 2001:0db8:000c:1337:0000:0000:0000:0003 | > | sp 80 | dp 32991 | prt 6 | tcp 19| fe 3 | > +-------------------------------------------------------+ > > Figure 2: IPFIX message containing sample flow > > > > > > > > > > > > > > Trammell Expires May 9, 2013 [Page 9] > > Internet-Draft IPFIX Text Types November 2012 > > > { > "flowStartMilliseconds": "2012-11-05 18:31:01.135", > "flowEndMilliseconds": "2012-11-05 18:31:02.880", > "octetDeltaCount": 195383, > "packetDeltaCount": 88, > "sourceIPv6Address": "2001:db8:c:1337::2", > "destinationIPv6Address": "2001:db8:c:1337::3", > "sourceTransportPort": 80, > "destinationTransportPort": 32991, > "protocolIdentifier": "tcp", > "tcpControlBits": 19, > "flowEndReason": 3 > } > > Figure 3: JSON object containing sample flow > > > Author's Address > > Brian Trammell > Swiss Federal Institute of Technology Zurich > Gloriastrasse 35 > 8092 Zurich > Switzerland > > Phone: +41 44 632 70 13 > Email: trammell@tik.ee.ethz.ch > > > > > > > > > > > > > > > > > > > > > > > > > Trammell Expires May 9, 2013 [Page 10] > --------------070009070908000601030807 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Brian,

Here's a review of draft-trammell-ipfix-text-adt-00.

Please find comments inline.





IPFIX Working Group                                          B. Trammell
Internet-Draft                                                ETH Zurich
Intended status: Informational                          November 5, 2012
Expires: May 9, 2013


          Textual Representation of IPFIX Abstract Data Types
                  draft-trammell-ipfix-text-adt-00.txt

Abstract

   This document defines UTF-8 representations for IPFIX abstract data
   types, to support interoperable usage of the IPFIX Information
   Elements with protocols based on textual encodings.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on May 9, 2013.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.





Trammell                   Expires May 9, 2013                  [Page 1]

Internet-Draft              IPFIX Text Types               November 2012


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Identifying Information Elements . . . . . . . . . . . . . . .  3
   4.  Data Type Encodings  . . . . . . . . . . . . . . . . . . . . .  4
     4.1.  octetArray . . . . . . . . . . . . . . . . . . . . . . . .  4
     4.2.  unsigned*  . . . . . . . . . . . . . . . . . . . . . . . .  4
     4.3.  signed*  . . . . . . . . . . . . . . . . . . . . . . . . .  5
     4.4.  float* . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.5.  boolean  . . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.6.  macAddress . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.7.  string . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.8.  dateTime*  . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.9.  ipv4Address  . . . . . . . . . . . . . . . . . . . . . . .  7
     4.10. ipv6Address  . . . . . . . . . . . . . . . . . . . . . . .  7
     4.11. basicList, subTemplateList, and subTemplateMultiList . . .  7
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     7.1.  Normative References . . . . . . . . . . . . . . . . . . .  7
     7.2.  Informative References . . . . . . . . . . . . . . . . . .  8
   Appendix A.  Example . . . . . . . . . . . . . . . . . . . . . . .  8
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10



























Trammell                   Expires May 9, 2013                  [Page 2]

Internet-Draft              IPFIX Text Types               November 2012


1.  Introduction

   The IPFIX Information Model, as defined by the IANA IPFIX Information
   Element Registry, provides a rich set of Information Elements for
   description of information about network entities and network traffic
   data, and abstract data types for these Information Elements.  The
   IPFIX Protocol Specification [I-D.ietf-ipfix-protocol-rfc5101bis], in
   turn, defines a big-endian binary encoding for these abstract data
   types suitable for use with the IPFIX Protocol.

   However, present and future operations and management protocols and
   applications may use textual encodings, and generic framing and
   structure as in JSON or XML.  A definition of canonical textual
   encodings for the IPFIX abstract data types would allow this set of
   Information Elements to be used for such applications, and for these
   applications to interoperate with IPFIX applications at the
   Information Element definition level.

   Note that templating or other mechanisms for data description for
   such applications and protocols are application specific, and
   therefore out of scope for this document: only Information Element
   identification and data value representation are defined here.


2.  Terminology

   Capitalized terms defined in the IPFIX Protocol Specification
   [I-D.ietf-ipfix-protocol-rfc5101bis] and the IPFIX Information Model
   [I-D.ietf-ipfix-information-model-rfc5102bis] are used in this
   document as defined in those documents.  In addition, this document
   defines the following terminology for its own use:

   Enclosing Context
      Textual representation of IPFIX data values is applied to use the
      IPFIX Information Model within some existing textual format (e.g.
      XML, JSON).  This outer format is referred to as the Enclosing
      Context within this document.  Enclosing Contexts define escaping
      and quoting rules for represented data values.


3.  Identifying Information Elements

   The IPFIX Information Element Registry [iana-ipfix-assignments]
   defines a set of Information Elements and numbered by Information

Doesn't parse. Remove "and".


   Element Identifiers, and named for human-readability.  These
   Information Element Identifiers are meant for use with the IPFIX
   protocol, and have little meaning when applying the IPFIX Information
   Element Registry to textual representations.



Trammell                   Expires May 9, 2013                  [Page 3]

Internet-Draft              IPFIX Text Types               November 2012


   Instead, applications using textual representations of Information
   Elements SHOULD use Information Element names to identify them; see
   Appendix A for examples illustrating this principle.

If the names are to be the (joint?) primary reference for IEs, then IE doctors should review all the IE names to ensure consistency, and define rules for new IE names to ensure that consistency is maintained.




4.  Data Type Encodings

   [FIXME frontmatter]

   This section uses ABNF [RFC5234], including the Core Rules in

Where is "Core Rules" defined?


   Appendix B, to describe the format of textual representations of
   IPFIX abstract data types.

4.1.  octetArray

   [FIXME: native hex strings for comparative human readabilty.]

4.2.  unsigned*

* it's a pointer?



   First, in the special case that the unsigned Information Element has
   identifier semantics, and refers to a set of codepoints, either in an
   external registry, a sub-registry, or directly in the description of
   the Information Element, then the name or short description for that
   codepoint MAY be used to improve readability.

   If the Enclosing Context defines a representation for unsigned
   integers, that representation SHOULD be used.

   Otherwise, the values of Information Elements of an unsigned integer
   type may be represented either as unprefixed base-10 (decimal)
   strings, or as base-16 (hexadecimal) strings prefixed by '0x'; in
   ABNF:

   unsigned = 1*DIGIT / '0x' 1*HEXDIG

RFC5234, sigh: / looks like division, although it's intended as "OR".

Consider allowing binary or any arbitrary number base to be used.



   Leading zeroes are allowed in either encoding, and do not signify
   base-8 (octal) encoding.

   The encoded value must be in range for the corresponding abstract
   data type or Information Element.  Out of range values should be
   interpreted as clipped to the implicit range for the Information
   Element as defined by the abstract data type, or to the explicit
   range of the Information Element if defined.  Minimum and maximum
   values for abstract data types are shown in Table 1 below.







Trammell                   Expires May 9, 2013                  [Page 4]

Internet-Draft              IPFIX Text Types               November 2012


              +------------+---------+----------------------+
              |       type | minimum |              maximum |
              +------------+---------+----------------------+
              |  unsigned8 |       0 |                  255 |
              | unsigned16 |       0 |                65536 |
              | unsigned32 |       0 |           4294967295 |
              | unsigned64 |       0 | 18446744073709551615 |
              +------------+---------+----------------------+

             Table 1: Ranges for unsigned abstract data types


Can we ever get away from the idea that u8, u16, u32, and u64 are different types?
Rather, they're just different size encodings of the same type.


4.3.  signed*

(Same comments for this section as for "unsigned" above.)



   If the Enclosing Context defines a representation for signed
   integers, that representation should be used.

   Otherwise, the values of Information Elements of signed integer types
   should be represented as optionally-prefixed base-10 (decimal)
   strings; if the sign is omitted, it is assumed to be positive.  In
   ABNF:

   sign = "+" / "-"

   signed = [sign] 1*DIGIT

   Leading zeroes are allowed, and do not signify base-8 (octal)
   encoding.

   The encoded value must be in range for the corresponding abstract
   data type or Information Element.  Out of range values should be
   interpreted as clipped to the implicit range for the Information
   Element as defined by the abstract data type, or to the explicit
   range of the Information Element if defined.  Minimum and maximum
   values for abstract data types are shown in Table 2 below.

        +----------+----------------------+----------------------+
        |     type |              minimum |              maximum |
        +----------+----------------------+----------------------+
        |  signed8 |                 -128 |                 +127 |
        | signed16 |               -32768 |               +32767 |
        | signed32 |          -2147483648 |          +2147483647 |
        | signed64 | -9223372036854775808 | +9223372036854775807 |
        +----------+----------------------+----------------------+

              Table 2: Ranges for signed abstract data types






Trammell                   Expires May 9, 2013                  [Page 5]

Internet-Draft              IPFIX Text Types               November 2012


4.4.  float*

   If the Enclosing Context defines a representation for floating point
   numbers, that representation should be used.

   [FIXME: there appears to be no defined (non-interchange) format for
   floating point numbers, but we probably want to define something
   reasonably human-readable without getting too into locale issues.]

   exponent = 'e' 1*3DIGIT

   right-decimal = '.' 0*DIGIT

ie, a decimal point with at least zero digits following? Why? The decimal point is only required when there are following digits.



   float = [sign] 1*DIGIT [right-decimal] [exponent]

4.5.  boolean

   [FIXME: frontmatter. note that booleans may also be natually

Typo, "naturally".


   represented by the presence or absence of a value in the structure of
   the document in the Enclosing Context.]

   boolean-yes = "1" / "y" / "Y" / "t" / "T"

   boolean-no = "0" / "n" / "N" / "f" / "F"

   boolean = boolean-yes / boolean-no

RFC5235 ABNF inconsistently uses - as a range indicator while also allowing it in rule names.



4.6.  macAddress

   [FIXME: frontmatter]

   macaddress = 2*HEXDIG 5*( ":" 2*HEXDIG )

Should be "5*5" to constrain the maximum size too, since exactly 6 pairs of digits are required.



4.7.  string

   As Information Elements of the string type are simply UTF-8 encoded
   strings, they are represented directly, subject to the escaping and
   encoding rules of the Enclosing Context.  If the Enclosing Context
   cannot natively represent UTF-8 characters, the escaping facility
   provided by the Enclosing Context must be used for non-representable
   characters.  Additionally, strings containing characters reserved in
   the Enclosing Context (e.g. markup characters, quotes) must be
   escaped or quoted according to the rules of the Enclosing Context.

4.8.  dateTime*

   [FIXME: [RFC3339]]




Trammell                   Expires May 9, 2013                  [Page 6]

Internet-Draft              IPFIX Text Types               November 2012


   [FIXME: explain precision rules]

4.9.  ipv4Address

   [FIXME: frontmatter. dotted-quad.]

   ipv4address = 1*3DIGIT 3*( "." 1*3DIGIT )

Again, use 3*3 to constrain the maximum length, since exactly 4 digits are required.



4.10.  ipv6Address

   [FIXME: section 2.2 of [RFC4291], recommend section 4 of [RFC5952]]

4.11.  basicList, subTemplateList, and subTemplateMultiList

   These abstract data types, defined for IPFIX Structured Data
   [RFC6313], do not represent actual data types; they are instead
   designed to provide a mechanism by which complex structure below the
   template level.  It is assumed that protocols using textual
   Information Element representation will provide their own structure.
   Therefore, Information Elements of these Data Types should not be
   used in textual representations.

Doesn't make sense.




5.  Security Considerations

   [FIXME: content would be nice]


6.  IANA Considerations

   This document has no considerations for IANA.


7.  References

7.1.  Normative References

   [I-D.ietf-ipfix-protocol-rfc5101bis]
              Claise, B. and B. Trammell, "Specification of the IP Flow
              Information eXport (IPFIX) Protocol for the Exchange of
              Flow Information", draft-ietf-ipfix-protocol-rfc5101bis-02
              (work in progress), June 2012.

   [RFC3339]  Klyne, G., Ed. and C. Newman, "Date and Time on the
              Internet: Timestamps", RFC 3339, July 2002.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.



Trammell                   Expires May 9, 2013                  [Page 7]

Internet-Draft              IPFIX Text Types               November 2012


   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [RFC5952]  Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
              Address Text Representation", RFC 5952, August 2010.

   [iana-ipfix-assignments]
              Internet Assigned Numbers Authority, "IP Flow Information
              Export Information Elements
              (http://www.iana.org/assignments/ipfix/ipfix.xml)",
              November 2012.

7.2.  Informative References

   [I-D.ietf-ipfix-information-model-rfc5102bis]
              Claise, B. and B. Trammell, "Information Model for IP Flow
              Information eXport (IPFIX)",
              draft-ietf-ipfix-information-model-rfc5102bis-06 (work in
              progress), October 2012.

   [I-D.ietf-ipfix-ie-doctors]
              Trammell, B. and B. Claise, "Guidelines for Authors and
              Reviewers of IPFIX Information Elements",
              draft-ietf-ipfix-ie-doctors-07 (work in progress),
              October 2012.

   [RFC6313]  Claise, B., Dhandapani, G., Aitken, P., and S. Yates,
              "Export of Structured Data in IP Flow Information Export
              (IPFIX)", RFC 6313, July 2011.


Appendix A.  Example

   In this section, we examine an IPFIX Template and a Data Record
   defined by that Template, and show how that Data Record would be
   represented in JSON according to the specification in this document.
   Note that this is specifically NOT a recommendation for a particular
   representation, merely an illustration of the encodings in this
   document.

   [FIXME improve frontmatter] Figure 1 shows a Template in IEspec
   format as defined in section 9.1 of [I-D.ietf-ipfix-ie-doctors].  A
   Message containing this Template and a Data Record is shown in
   Figure 2, and a corresponding JSON Object using the text format
   defined in this document is shown in Figure 3.

Personally I'd rather that each description immediately precedes the corresponding figure.

P.








Trammell                   Expires May 9, 2013                  [Page 8]

Internet-Draft              IPFIX Text Types               November 2012


         flowStartMilliseconds(152)<dateTimeMilliseconds>[8]
         flowEndMilliseconds(153)<dateTimeMilliseconds>[8]
         octetDeltaCount(1)<unsigned64>[4]
         packetDeltaCount(2)<unsigned64>[4]
         sourceIPv6Address(27)<ipv4Address>[4]{key}
         destinationIPv6Address(28)<ipv4Address>[4]{key}
         sourceTransportPort(7)<unsigned16>[2]{key}
         destinationTransportPort(11)<unsigned16>[2]{key}
         protocolIdentifier(4)<unsigned8>[1]{key}
         tcpControlBits(6)<unsigned8>[1]
         flowEndReason(136)<unsigned8>[1]

                  Figure 1: Sample flow template (IPFIX)


             1         2         3         4         5         6
   0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | 0x000a        | length 135    | export time 1352140263        | msg
  | sequence 0                    | domain 1                      | hdr
  | SetID 2       | length 52     | tid 256       | fields 11     | tmpl
  | IE 152        | length 8      | IE 153        | length 8      | set
  | IE 1          | length 4      | IE 2          | length 4      |
  | IE 27         | length 16     | IE 28         | length 16     |
  | IE 7          | length 2      | IE 11         | length 2      |
  | IE 4          | length 1      | IE 6          | length 1      |
  | IE 136        | length 1      | SetID 256     | length 83     | data
  | start time                                     1352140261135  | set
  | end time                                       1352140262880  |
  | octets                195383  | packets                   88  |
  | sip6                                                          |
  |                       2001:0db8:000c:1337:0000:0000:0000:0002 |
  | dip6                                                          |
  |                       2001:0db8:000c:1337:0000:0000:0000:0003 |
  | sp        80  | dp     32991  | prt 6 | tcp 19| fe 3  |
  +-------------------------------------------------------+

              Figure 2: IPFIX message containing sample flow













Trammell                   Expires May 9, 2013                  [Page 9]

Internet-Draft              IPFIX Text Types               November 2012


           {
               "flowStartMilliseconds": "2012-11-05 18:31:01.135",
               "flowEndMilliseconds": "2012-11-05 18:31:02.880",
               "octetDeltaCount": 195383,
               "packetDeltaCount": 88,
               "sourceIPv6Address": "2001:db8:c:1337::2",
               "destinationIPv6Address": "2001:db8:c:1337::3",
               "sourceTransportPort": 80,
               "destinationTransportPort": 32991,
               "protocolIdentifier": "tcp",
               "tcpControlBits": 19,
               "flowEndReason": 3
           }

               Figure 3: JSON object containing sample flow


Author's Address

   Brian Trammell
   Swiss Federal Institute of Technology Zurich
   Gloriastrasse 35
   8092 Zurich
   Switzerland

   Phone: +41 44 632 70 13
   Email: trammell@tik.ee.ethz.ch
























Trammell                   Expires May 9, 2013                 [Page 10]


--------------070009070908000601030807-- From paitken@cisco.com Thu Mar 14 16:38:16 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99E2911E8143 for ; Thu, 14 Mar 2013 16:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.316 X-Spam-Level: X-Spam-Status: No, score=-8.316 tagged_above=-999 required=5 tests=[AWL=3.083, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7OlpxEy7Bc9 for ; Thu, 14 Mar 2013 16:38:08 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id A822011E80E7 for ; Thu, 14 Mar 2013 16:38:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=171998; q=dns/txt; s=iport; t=1363304283; x=1364513883; h=message-id:date:from:mime-version:to:subject; bh=t3KXmzBzeEmuUWONVbOTlJA32vmysOLlC3kl9ppxkmk=; b=mIixwznD/mhZqI/tkZaFjaW+xNsIVH50QYJNWfKH90Jj/ATgUxzeJnTQ /89iYaaSFBixDmNQW/F6sV9BUAfC0+q2zQsg+OGivdRXmqFhltQNLm9YN 8njgyr0BhvdBZbWNcw0mvd5HVLlHKThAdD0Q91QJfxSspGyEgKdOWzYKI o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFANxeQlGQ/khM/2dsb2JhbAA5CoUUiHW2fIFnFnSCKwEBAQMbAQxABAcMCR8PDAsBHAIKLhQBDAYCAQEFiAUGDMF5BI1GCwYEAQt1CioDEIM2A4t3hmI6g0WBH4RecooTgwo8gS4BCBc X-IronPort-AV: E=Sophos;i="4.84,848,1355097600"; d="scan'208,217";a="151769484" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 14 Mar 2013 23:37:59 +0000 Received: from [10.55.82.144] (dhcp-10-55-82-144.cisco.com [10.55.82.144]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2ENbsKq015512; Thu, 14 Mar 2013 23:37:55 GMT Message-ID: <51425F53.10203@cisco.com> Date: Thu, 14 Mar 2013 23:37:55 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: draft-ietf-ipfix-mediation-protocol@tools.ietf.org, IETF IPFIX Working Group Content-Type: multipart/alternative; boundary="------------030608080101070204090503" Subject: [IPFIX] review of draft-ietf-ipfix-mediation-protocol-04 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 23:38:16 -0000 This is a multi-part message in MIME format. --------------030608080101070204090503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear Authors, Here's another review of draft-ietf-ipfix-mediation-protocol-04. Overall I'm happy with the shape of this draft; I have no major technical issues. Just some minor ones, and loads of editorial issues. Please find comments inline: > > IPFIX Working Group B. Claise > Internet-Draft Cisco Systems, Inc. > Intended status: Standards Track A. Kobayashi > Expires: August 29, 2013 NTT > B. Trammell > ETH Zurich > February 25, 2013 > > > Operation of the IP Flow Information Export (IPFIX) Protocol on IPFIX > Mediators > draft-ietf-ipfix-mediation-protocol-04.txt > > Abstract > > This document specifies the operation of the IP Flow Information > Export (IPFIX) protocol specific to IPFIX Mediators, including > Template and Observation Point management, timing considerations, and > other Mediator-specific concerns. > > Status of this Memo > > This Internet-Draft is submitted in full conformance with the > provisions of BCP 78 and BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF). Note that other groups may also distribute > working documents as Internet-Drafts. The list of current Internet- > Drafts is at http://datatracker.ietf.org/drafts/current/. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > This Internet-Draft will expire on August 29, 2013. > > Copyright Notice > > Copyright (c) 2013 IETF Trust and the persons identified as the > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with respect > to this document. Code Components extracted from this document must > > > > Claise, et al. Expires August 29, 2013 [Page 1] > > Internet-Draft IPFIX MED-PROTO February 2013 > > > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the Simplified BSD License. > > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 1.1. IPFIX Documents Overview . . . . . . . . . . . . . . . . . 3 > 1.2. IPFIX Mediator Documents Overview . . . . . . . . . . . . 4 > 1.3. Relationship with the IPFIX and PSAMP Protocols . . . . . 5 > 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 > 3. Handling IPFIX Message Headers . . . . . . . . . . . . . . . . 8 > 4. Template Management . . . . . . . . . . . . . . . . . . . . . 10 > 4.1. Passing Unmodified Templates through an IPFIX Mediator . . 11 > 4.1.1. Template Mapping and Information Element Ordering . . 14 > 4.2. Creating New Templates at an IPFIX Mediator . . . . . . . 15 > 4.3. Handling Unknown Information Elements . . . . . . . . . . 16 > 5. Preserving Original Observation Point Information . . . . . . 16 > 5.1. originalExporterIPv4Address Information Element . . . . . 18 > 5.2. originalExporterIPv6Address Information Element . . . . . 18 > 6. Managing Observation Domain IDs . . . . . . . . . . . . . . . 19 > 6.1. originalObservationDomainId Information Element . . . . . 19 > 7. Timing Considerations . . . . . . . . . . . . . . . . . . . . 20 > 8. Transport Considerations . . . . . . . . . . . . . . . . . . . 21 > 9. Collecting Process Considerations . . . . . . . . . . . . . . 21 > 10. Specific Reporting Requirements . . . . . . . . . . . . . . . 22 > 10.1. Intermediate Process Reliability Statistics Template . . . 22 > 10.2. Flow Key Options Template . . . . . . . . . . . . . . . . 23 > 10.3. intermediateProcessId Information Element . . . . . . . . 24 > 10.4. ignoredRecordTotalCount Information Element . . . . . . . 24 > 11. Configuration Management . . . . . . . . . . . . . . . . . . . 24 > 12. Security Considerations . . . . . . . . . . . . . . . . . . . 25 > 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 > 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 > 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 > 15.1. Normative References . . . . . . . . . . . . . . . . . . . 26 > 15.2. Informative References . . . . . . . . . . . . . . . . . . 27 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 > > > > > > > > > > > > > Claise, et al. Expires August 29, 2013 [Page 2] > > Internet-Draft IPFIX MED-PROTO February 2013 > > > 1. Introduction > > The IPFIX architectural components in [RFC5470] consist of IPFIX > Devices and IPFIX Collectors communicating using the IPFIX protocol > [I-D.ietf-ipfix-protocol-rfc5101bis], which specifies how to export > IP Flow information. This protocol is designed to export information > about IP traffic Flows and related measurement data, where a Flow is > defined by a set of key attributes (e.g. source and destination IP > address, source and destination port, etc.). > > However, thanks to its Template mechanism, the IPFIX protocol can > export any type of information, as long as the relevant Information > Element is specified in the IPFIX Information Model > [I-D.ietf-ipfix-information-model-rfc5102bis], registered with IANA, > or specified as an enterprise-specific Information Element. The > specifications in the IPFIX protocol > [I-D.ietf-ipfix-protocol-rfc5101bis] have not been defined in the > context of an IPFIX Mediator receiving, aggregating, correlating, > anonymizing, etc... Flow Records from the one or multiple Exporters. > Indeed, the IPFIX protocol must be adapted for Intermediate > Processes, as defined in the IPFIX Mediation Reference Model as > specified in Figure A of [RFC6183], which is based on the IPFIX > Mediation Problem Statement [RFC5982]. > > This document specifies the IP Flow Information Export (IPFIX) > protocol in the context of the implementation and deployment of IPFIX > Mediators. The use of the IPFIX protocol within an IPFIX Mediator -- > a device which contains both a Collecting Process and an Exporting > Process -- has an impact on the technical details of the usage of the > protocol. An overview of the technical problem is covered in section > 6 of [RFC5982]: loss of original Exporter information, loss of base > time information, transport sessions management, loss of Options > Template Information, Template Id management, considerations for > network considerations for aggregation. > > The specifications in this document are based on the IPFIX protocol > specifications [I-D.ietf-ipfix-protocol-rfc5101bis] but adapted > according to the IPFIX Mediation Framework [RFC6183]. > > 1.1. IPFIX Documents Overview > > The IPFIX Protocol [I-D.ietf-ipfix-protocol-rfc5101bis] provides > network administrators with access to IP Flow information. > > The architecture for the export of measured IP Flow information out > of an IPFIX Exporting Process to a Collecting Process is defined in > the IPFIX Architecture [RFC5470], per the requirements defined in the > IPFIX Requirement doc, [RFC3917]. > > > > Claise, et al. Expires August 29, 2013 [Page 3] > > Internet-Draft IPFIX MED-PROTO February 2013 > > > The IPFIX Architecture [RFC5470] specifies how IPFIX Data Records and > Templates are carried via a congestion-aware transport protocol from > IPFIX Exporting Processes to IPFIX Collecting Processes. > > IPFIX has a formal description of IPFIX Information Elements, their > name, type and additional semantic information, as specified in the > IPFIX Information Model > [I-D.ietf-ipfix-information-model-rfc5102bis]. The registry is > maintained by IANA [IPFIX-IANA]. New Information Element definitions > can be added to this registry subject to an Expert Review [RFC5226], > with additional process considerationsdecribed in [IPFIX-IE- Typo, "described". > DOCTORS]; that document also provides guidelines for authors and > reviewers of new Information Element definitions. The inline export > of the Information Element type information is specified in > [RFC5610]. > > The IPFIX Applicability Statement [RFC5472] describes what type of > applications can use the IPFIX protocol and how they can use the > information provided. It furthermore shows how the IPFIX framework > relates to other architectures and frameworks. > > 1.2. IPFIX Mediator Documents Overview > > The "IPFIX Mediation: Problem Statement" [RFC5982] provides an > overview of the applicability of IPFIX Mediators, and defines > requirements for IPFIX Mediators in general terms. This document is > of use largely to define the problems to be solved through the > deployment of IPFIX Mediators, and to provide scope to the role of > IPFIX Mediators within an IPFIX collection infrastructure. > > The "IPFIX Mediation: Framework" [RFC6183], which details the IPFIX > Mediation reference model and the components of an IPFIX Mediator, > provides more architectural details of the arrangement of > Intermediate Processes within an IPFIX Mediator. > > Documents specifying the operations of specific Intermediate > Processes cover the operation of these Processes within the IPFIX > Mediator framework, and comply with the specifications given in this > document; they may additionally specify the operation of the process > independently, outside the context of an IPFIX Mediator, when this is > appropriate. The details of specific Intermediate Processes, when > these have additional export specifications (e.g., metadata about the > intermediate processing conveyed through IPFIX Options Templates), > are each treated in their own document. As of today, these documents > are: > > 1. "IP Flow Anonymization Support", [RFC6235], which describes > Anonymization techniques for IP flow data and the export of > > > > Claise, et al. Expires August 29, 2013 [Page 4] > > Internet-Draft IPFIX MED-PROTO February 2013 > > > Anonymized data using the IPFIX protocol. > > 2. "Flow Selection Techniques" [I-D.ietf-ipfix-flow-selection-tech], > which describes the process of selecting a subset of Flows from > all Flows observed at an Observation Point, the flow selection > motivations, and some specific flow selection techniques. > > 3. "Exporting Aggregated Flow Data using IP Flow Information Export" > [I-D.ietf-ipfix-a9n] which describes Aggregated Flow export > within the framework of IPFIX Mediators and defines an > interoperable, implementation-independent method for Aggregated > Flow export. > > This document specifies the IP Flow Information Export (IPFIX) > protocol specific to Mediation, i.e. the specifications that all > Intermediate Processes type must comply to. Some extra > specifications might be required per Intermediate Process type (In > which case, the Intermediate Process specific document would cover > those). > > 1.3. Relationship with the IPFIX and PSAMP Protocols > > The specification in this document applies to the IPFIX protocol > specifications [I-D.ietf-ipfix-protocol-rfc5101bis]. All > specifications from [I-D.ietf-ipfix-protocol-rfc5101bis] apply unless > specified otherwise in this document. > > As the Packet Sampling (PSAMP) protocol specifications [RFC5476] are > based on the IPFIX protocol specifications, the specifications in > this document are also valid for the PSAMP protocol. Therefore, the > method specified by this document also applies to PSAMP. > > > 2. Terminology > > IPFIX-specific terms, such as Observation Domain, Flow, Flow Key, > Metering Process, Exporting Process, Exporter, IPFIX Device, > Collecting Process, Collector, Template, IPFIX Message, Message > Header, Template Record, Data Record, Options Template Record, Set, > Data Set, Information Element, Scope and Transport Session, used in > this document are defined in [I-D.ietf-ipfix-protocol-rfc5101bis]. > The PSAMP-specific terms used in this document, such as Filtering and > Sampling, are defined in [RFC5476]. > > IPFIX Mediation terms related to aggregation, such as the Interval, > Aggregated Flow, and Aggregated Function are defined in > [I-D.ietf-ipfix-a9n]. > > > > > Claise, et al. Expires August 29, 2013 [Page 5] > > Internet-Draft IPFIX MED-PROTO February 2013 > > > The IPFIX Mediation-specific terminology used in this document is > defined in "IPFIX Mediation: Problem Statement" [RFC5982], and reused > in "IPFIX Mediation: Framework" [RFC6183]. However, since both of > those documents are an informational RFCs, the definitions have been > reproduced here along with additional definitions. > > Similarly, since [RFC6235] is an experimental RFC, the Anonymization > Record, Anonymized Data Record, and Intermediate Anonymization > Process terms, specified in [RFC6235], are also reproduced here. > > In this document, as in [I-D.ietf-ipfix-protocol-rfc5101bis], > [RFC5476], [I-D.ietf-ipfix-a9n], and [RFC6235], the first letter of > each IPFIX-specific and PSAMP-specific term is capitalized along with > the IPFIX Mediation-specific term defined here. > > In this document, we call a stream of records carrying flow- or > packet-based information a "record stream". The records may be > encoded as IPFIX Data Recordsof any other format. Typo, "or". > > Transport Session Information: The Transport Session is specified > in [I-D.ietf-ipfix-protocol-rfc5101bis]. In SCTP, the Transport > Session Information is the SCTP association. In TCP and UDP, the > Transport Session Information corresponds to a 5-tuple {Exporter > IP address, Collector IP address, Exporter transport port, > Collector transport port, transport protocol}. > > Original Exporter: An Original Exporter is an IPFIX Device that > hosts the Observation Points where the metered IP packets are > observed. > > Original Observation Point: An Observation Point of the Original > Exporter. In the case of the Intermediate Aggregation Process on These definitions imply that OPs belong to the exporter, which is not the case; they belong to the MP or to the IPFIX device. > an IPFIX Mediator, the Original Observation Point can be composed > of, but not limited to, a (set of) specific Exporter(s), a (set > of) specific interface(s) on an Exporter, a (set of) line card(s) > on an Exporter, or any combinations of these. > > IPFIX Mediation: IPFIX Mediation is the manipulation and conversion > of a record stream for subsequent export using the IPFIX protocol. > > Template Mapping: A mapping from Template Records and/or Options > Template Records received by an IPFIX Mediator to Template Records > and/or Options Template Records sent by that IPFIX Mediator. Each > entry in a Template Mapping is scoped by incoming or outgoing > Transport Session and Observation Domain, as with Templates and > Options Templates in the IPFIX Protocol. > > > > > > Claise, et al. Expires August 29, 2013 [Page 6] > > Internet-Draft IPFIX MED-PROTO February 2013 > > > Anonymization Record: A record that defines the properties of the > anonymization applied to a single Information Element within a > single Template or Options Template, as in [RFC6235]. > > Anonymized Data Record: A Data Record within a Data Set containing > at least one Information Element with Anonymized values. The > Information Element(s) within the Template or Options Template > describing this Data Record SHOULD have a corresponding > Anonymization Record, as in [RFC6235]. > > The following terms are used in this document to describe the > architectural entities used by IPFIX Mediation. > > Intermediate Process: An Intermediate Process takes a record stream > as its input from Collecting Processes, Metering Processes, IPFIX > File Readers, other Intermediate Processes, or other record > sources; performs some transformations on this stream, based upon > the content of each record, states maintained across multiple > records, or other data sources; and passes the transformed record > stream as its output to Exporting Processes, IPFIX File Writers, > or other Intermediate Processes, in order to perform IPFIX > Mediation. Typically, an Intermediate Process is hosted by an > IPFIX Mediator. Alternatively, an Intermediate Process may be > hosted by an Original Exporter. > > IPFIX Mediator: An IPFIX Mediator is an IPFIX Device that provides > IPFIX Mediation by receiving a record stream from some data > sources, hosting one or more Intermediate Processes to transform > that stream, and exporting the transformed record stream into > IPFIX Messages via an Exporting Process. In the common case, an > IPFIX Mediator receives a record stream from a Collecting Process, > but it could also receive a record stream from data sources not > encoded using IPFIX, e.g., in the case of conversion from the > NetFlow V9 protocol [RFC3954] to IPFIX protocol. > > Specific Intermediate Processes are described below. > > Intermediate Conversion Process (as in [RFC6183]): An Intermediate > Conversion Process is an Intermediate Process that transforms non- > IPFIX into IPFIX or manages the relation among Templates and > states of incoming/outgoing transport sessions in the case of > transport protocol conversion (e.g., from UDP to SCTP). > > Intermediate Aggregation Process (as in [I-D.ietf-ipfix-a9n]): an > Intermediate Process (IAP) as in [RFC6183] that aggregates > records, based upon a set of Flow Keys or functions applied to > fields from the record. > > > > > Claise, et al. Expires August 29, 2013 [Page 7] > > Internet-Draft IPFIX MED-PROTO February 2013 > > > Intermediate Correlation Process (as in [RFC6183]): An Intermediate > Correlation Process is an Intermediate Process that adds > information to records, noting correlations among them, or > generates new records with correlated data from multiple records > (e.g., the production of bidirectional flow records from > unidirectional flow records). > > Intermediate Anonymization Process (as in [RFC6235]): An > intermediate process that takes Data Records and transforms them > into Anonymized Data Records. > > Intermediate Selection Process (as in [RFC6183]): An Intermediate > Selection Process is an Intermediate Process that selects records > from a sequence based upon criteria-evaluated record values and > passes only those records that match the criteria (e.g., Filtering > only records from a given network to a given Collector). > > Intermediate Flow Selection Process (as in > [I-D.ietf-ipfix-flow-selection-tech]: An Intermediate Flow > Selection Process is an Intermediate Process as in [RFC6183] that > takes Flow Records as its input and selects a subset of this set > as its output. Intermediate Flow Selection Process is a more > general concept than Intermediate Selection Process as defined in > [RFC6183]. While an Intermediate Selection Process selects Flow > Records from a sequence based upon criteria-evaluated Flow record > values and passes only those Flow Records that match the criteria, > an Intermediate Flow Selection Process selects Flow Records using > selection criteria applicable to a larger set of Flow > characteristics and information. For all the words, I only understood that IFSP is a superset of ISP - and I feel that I missed the point? > > > 3. Handling IPFIX Message Headers > > The format of the IPFIX Message Header as exported by an IPFIX > Mediator is shown in Figure 1. Note that the format is compatible > with the IPFIX Message Header defined in > [I-D.ietf-ipfix-protocol-rfc5101bis], with some field definitions > (for the example, the Export Time) updated in the context of the > IPFIX Mediator. > > > > > > > > > > > > > Claise, et al. Expires August 29, 2013 [Page 8] > > Internet-Draft IPFIX MED-PROTO February 2013 > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Version | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Export Time | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Observation Domain ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 1: IP Message Header format > > The header fields as exported by an IPFIX Mediator are describe > below. > > Version: Version of IPFIX to which this Message conforms. The > value of this field is 0x000a for the current version, > incrementing by one the version used in the NetFlow services > export version 9 [RFC3954]. > > Length: Total length of the IPFIX Message, measured in octets, > including Message Header and Set(s). > > Export Time: Time at which the IPFIX Message Header leaves the > IPFIX Mediator, expressed in seconds since the UNIX epoch of 1 > January 1970 at 00:00 UTC, encoded as an unsigned 32-bit integer. > However, in the specific case of an IPFIX Mediator containing an > Intermediate Conversion Process, the IPFIX Mediator MAYkeep the > export time received from the incoming Transport Session. I know exactly what you're saying here, but others might not. I suggest s/keep/use/. > > Sequence Number: Incremental sequence counter modulo 2^32 of all > IPFIX Data Records sent in a the current stream from the current > Observation Domain by the Exporting Process. Each SCTP Stream > counts sequence numbers separately, while all messages in a TCP > connection or UDP transport session are considered to be part of > the same stream. This value SHOULD be used by the Collecting > Process to identify whether any IPFIX Data Records have been > missed. Template and Options Template Records do not increase the > Sequence Number. > > Observation Domain ID: A 32-bit identifier of the Observation > Domain that is locally unique to the Exporting Process. The > Exporting Process uses the Observation Domain ID to uniquely > identify to the Collecting Process the Observation Domain that > metered the Flows. It is RECOMMENDED that this identifier also be > unique per IPFIX Device. Collecting Processes SHOULD use the > > > > Claise, et al. Expires August 29, 2013 [Page 9] > > Internet-Draft IPFIX MED-PROTO February 2013 > > > Transport Session and the Observation Domain ID field to separate > different export streams originating from the same Exporter. The > Observation Domain ID SHOULD be 0 when no specific Observation > Domain ID is relevant for the entire IPFIX Message, for example, > when exporting the Exporting Process Statistics, or in case of a > hierarchy of Collectors when aggregated Data Records are exported. > See Section 4.1 for special considerations for Observation Domain > management while passing unmodified templates through an IPFIX > Mediator, and Section 5 for guidelines for preservation of > original Observation Domain information at an IPFIX Mediator. > > The following specifications, copied over from > [I-D.ietf-ipfix-protocol-rfc5101bis] have some implications in this > document: "Template Withdrawals MAY appear interleaved with Template > Sets, Options Template Sets, and Data Sets within an IPFIX Message. > In this case, the Templates and Template Withdrawals shall be taken > to take effect in the order in which they appear in the IPFIX > Message." > > If an IPFIX Mediator receives an IPFIX Message composed of Template > Withdrawals and Template Sets, and if the IPFIX Mediator forwards > this IPFIX Message, it MUST not modify the Set order. Note that the TWM + Template definitions in separate messages must also not be re-ordered. > Template Mapping (see section 4.1) is theauthorative source of Typo, "authoritative". > information on the IPFIX Mediator to decide whether the entire IPFIX > Messages can be forwarded as such. > > > 4. Template Management > > How an IPFIX Mediator handles the Templates it receives from the > Original Exporter depends entirely on the nature of the Intermediate > Process running on that IPFIX Mediator. > > IPFIX Mediators that passsubstantially the same Data Records from > the Original Exporter downstream, (e.g., an Intermediate Selection > Process), pass unmodified Template as described in Section 4.1; this I can't parse this properly - partly because the comma section is completely parenthesised. What does "substantially the same Data Records" mean? It could be: * the same data records, +/- a field or two. * the same fields, +/- some records. Should "Template" be plural? > section describes a Template Mapping required to make this work in > the general case, and the correlation between thereceivd and > generated IPFIX Message Withdrawals. Typo, "received". > > IPFIX Mediators that export Data Records which aresubstantially > changed from the Data Records received from the Original Exporter What does "substantially changed" mean? * fields reordered, added, or removed * fields unmodified, but records added / removed > follow the guidelines in Section 4.2 instead: in this case, the IPFIX > Mediator generates new (Options) Template Records as a result of the > Intermediate Process, and no Template Mapping is required. > > Subsequent subsections deal with specific issues in Template > management that may occur at IPFIX Mediators. > > > > Claise, et al. Expires August 29, 2013 [Page 10] > > Internet-Draft IPFIX MED-PROTO February 2013 > > > 4.1. Passing Unmodified Templates through an IPFIX Mediator > > The first case is a situation where the IPFIX Mediator doesn't modify The "second case" is 5 pages away at the bottom of page 15. Perhaps just say, "In this case, the IPFIX Mediator...". > the (Options) Template Record(s) content. A typical example is an Hurrah, a definition of "substantially the same"! > Intermediate Flow Selection Process acting as distributor, which > collects Flow Records from one or more Exporters, and based on the > Information Elements content, redirects the Flow Records to the > appropriate Collector. This example is a typical case of a single > network operation center managing multiple universities: an unique > IPFIX Collector collects all Flow Records for the common > infrastructure, but might be re-exporting specific university Flow > Records to the responsible system administrator. Does this case include the situation where incoming templates contain the same fields, but in a different order? So the mediator could re-order the fields and export the contents with a single outgoing Template. [Later: subject to key fields, per below.] > > As specified in [I-D.ietf-ipfix-protocol-rfc5101bis], the Template > IDs are unique per Exporter, per Transport Session, and per > Observation Domain. As there is no guarantee that, for similar > Template Records, the Template IDs received on the incoming Transport > Session and exported to the outgoing Transport Session would be same, > the IPFIX Mediator MUST maintain a Template Mapping composed of > related received and exported (Options) Template Records: > > o for each received (Options) Template Record: Template Record > Information Elements, Template ID, Observation Domain Id, and > Transport Session Information,metada scoped to the Template (*) Typo, "metadata". > > o for each exported (Options) Template Record: Template Record > Information Elements, Template ID, Collector, Observation Domain > Id, and Transport Session Information metadata scoped to the > Template (*) > > (*)The "metadata scoped to the Template" encompasses the metadata, > that are scoped to the Template, I'm glad you explained; I'd never have guessed. > and that help to determine the > semantics of the Template Record. Note that these metadata are > typically sent in Data Records described by an Options Template. A > example is the flowKeyIndicator: An IPFIX Mediator could potentially > received two different Template IDs, from the same Exporter, with the > same Information Elements, but with a different set of Flow Keys > (indicated by the flowKeyIndicator in an Options Template Record). This complicates my question about field-ordering above. > Another example is the combination of anonymizationFlags and > anonymizationTechnique [RFC6235]). This metadata information must be > present in the Template Mapping, to stress that the two Template > Record semantics are different. So templates can potentially be merged provided that the semantics are the same. > > If an IPFIX Mediator receives an IPFIX Withdrawal Message for a > (Options) Template Record that is not used anymore in any other > Template Mappings, the IPFIX Mediator SHOULD export the appropriate > IPFIX Withdrawal Message(s) on the outgoing Transport Session, and > remove the corresponding entry in the Template Mapping. > > > > Claise, et al. Expires August 29, 2013 [Page 11] > > Internet-Draft IPFIX MED-PROTO February 2013 > > > If a (Options) Template Record is not used anymore in an outgoing > Transport Session, it MUST be withdrawn with an IPFIX Template > Withdrawal Message on that specific outgoing Transport Session, and > its entry MUST be removed from the Template Mapping. > > If an incoming or outgoing Transport Session is gracefully shutdown > or reset, the (Options) Template Records corresponding to that > Transport Session MUST be removed from the Template Mapping. > > For example, Figure 2 displays an example of an Intermediate Flow > Selection Process, re-distributing Data Records to Collectors on the > basis of customer networks, i.e. the Route Distinguisher (RD). In > this example, the Template Record received from the Exporter #1 is > reused towards Collector #1, Collector #2, and Collector #3. If the incoming template is reused, then why does customer A receive Template 256, while customers B and C receive Template 257? What's the difference between Template 256 and Template 257? > > Tmpl. .---------. > ID 256 | | > .---->|Collector|<==>Customer > | |#1 | A > | | | > RD=100:1 '---------' > .---------.Templ. .---------. | > | |Id | |----' .---------. > | |258 | | RD=100:2 | | > |IPFIX |------->|IPFIX |--------->|Collector|<==>Customer > |Exporter | |Mediator | Tmpl. |#2 | B > |#1 | | | ID 257 | | > | | | |----. '---------' > '---------' '---------' | > RD=100:3 > Tmpl. | .---------. > ID | | | > 257 '---->|Collector|<==>Customer > |#3 | C > | | > '---------' > > Figure 2: Intermediate Flow Selection Process example The middle of the figure is hideously cramped, in the area under RD=100:2. Some vertical spacing would really help. Also there's enough room to write "Customer A" without wrapping. Additionally 2 columns can be recovered by narrowing the Exporter and Mediator boxes. The figure can also be pulled up to 3 spaces leftwards if needs be. "Templ. Id 258" is inconsistent with "Tmpl. ID nnn" everywhere else. So, putting that all together, let me redraw the figure for you: .---------. Tmpl. | | ID .---->|Collector|<==>Customer A 256 | | #1 | | | | RD=100:1 '---------' .--------. .--------. | | | Tmpl. | |----' | | Id | | .---------. | | 258 | | RD=100:2 | | | IPFIX |------->| IPFIX |--------->|Collector|<==>Customer B |Exporter| |Mediator| Tmpl. | #2 | | #1 | | | ID 257 | | | | | | '---------' | | | |----. '--------' '--------' | RD=100:3 | .---------. Tmpl. | | | ID '---->|Collector|<==>Customer C 257 | #3 | | | '---------' > > Figure 3 shows the Template Mapping for the system shown in Figure 2. > > > > > > > > > > > > Claise, et al. Expires August 29, 2013 [Page 12] > > Internet-Draft IPFIX MED-PROTO February 2013 > > > Template Entry A: > Incoming Transport Session Information (from Exporter#1): > Source IP: > Destination IP: > Protocol: SCTP > Source Port: > Destination Port: 4739 (IPFIX) > Observation Domain Id: > Template Id: 258 > Metada scoped to the Template : Typo. > > Template Entry B: > Outgoing Transport Session Information (to Collector#1): > Source IP: > Destination IP: > Protocol: SCTP > Source Port: > Destination Port: 4739 (IPFIX) > Observation Domain Id: > Template Id: 256 > Metada scoped to the Template : Typo. > > Template Entry C: > Outgoing Transport Session Information (to Collector#2): > Source IP: > Destination IP: > Protocol: SCTP > Source Port: > Destination Port: 4739 (IPFIX) > Observation Domain Id: > Template Id: 257 > Metada scoped to the Template : Typo. > > Template Entry D: > Outgoing Transport Session Information (to Collector#3): > Source IP: > Destination IP: > Protocol: SCTP > Source Port: > Destination Port: 4739 (IPFIX) > Observation Domain Id: > Template Id: 257 > Metada scoped to the Template : Indentation of "Template ID: 257" is inconsistent with usage above. Typo, "metadata". BTW, note the potential for confusion where: Template Entry B corresponds to customer A Template Entry C corresponds to customer B Template Entry D corresponds to customer C > > Figure 3: Template Mapping example: templates > > The Template Mapping corresponding tofigure B can be displayed as: Where is "figure B" ? > > > > > Claise, et al. Expires August 29, 2013 [Page 13] > > Internet-Draft IPFIX MED-PROTO February 2013 > > > Template Entry A <----> Template Entry B > Template Entry A <----> Template Entry C > Template Entry A <----> Template Entry D > > Template Mapping example: mappings > > Alternatively, the Template Mapping may be optimized as: > > +--> Template Entry B > | > Template Entry A <--+--> Template Entry C > | > +--> Template Entry D > > Template Mapping example: mappings Please label this Figure in case someone wants to refer to it in future work. Also please add one line saying "Figure 3a shows stuff" so that the figure isn't orphaned. The text immediately above Figure 2 says, "In this example, the Template Record received from the Exporter #1 is reused towards Collector #1, Collector #2, and Collector #3." So why is the template mapping not simply: Template Entry A <----> Template Entry A' > > Note that all examples use Transport Sessions based on the SCTP > protocol, as simplified use cases. However, theprotocol would be > important in situations such as an Intermediate Conversion Process > doing transport protocol conversion. Clarify "protocol" = transport protocol, rather than IPFIX protocol. > > 4.1.1. Template Mapping and Information Element Ordering > > In the situation where Original Exporters each export an (Options) > Template to a single IPFIX Mediator, and the (Options) Template > Record contains the same Information Elements but in different order, > should the IPFIX Mediator maintain a Template Mapping with a single > Export Template Record (see figure "Template Mapping and Ordering: a > single Export Template Record") or should the IPFIX Mediator maintain > multiple independent Template Records (see figure "Template Mapping > and Ordering: multiple Export Template Record") before re-exporting > to the Collector? NO. Give them a simple name, eg "Figure 4" and "Figure 5". > > Template Entry A <--+ > | > Template Entry B <--+--> Template Entry D > | > Template Entry C <--+ > > Template Mapping and Ordering: a single Export Template Record > > > Template Entry A <--+--> Template Entry D > > Template Entry B <--+--> Template Entry E > > Template Entry C <--+--> Template Entry F > > > > > Claise, et al. Expires August 29, 2013 [Page 14] > > Internet-Draft IPFIX MED-PROTO February 2013 > > > Template Mapping and Ordering: multiple Export Template Records Label these figures, because they're referenced within this document. > > The answer depends whether the order of the Information Elements > implies some specific semantic. One of the guiding principles in > IPFIX protocol specificationsis that the semantic meaning of one > Information Element doesn't depend on the value ofthe different > Information Element. However, there is one noticeable exception, as > mentioned in [I-D.ietf-ipfix-protocol-rfc5101bis]: Missing word, "is". BTW, where is this (often cited) principle actually stated? s/the different/another/, or /any other/ > > "Multiple Scope Fields MAY be present in the Options Template Record, > in which case, the composite scope is the combination of the scopes. > For example, if the two scopes are meteringProcessId and templateId, > the combined scope is this Template for this Metering Process. If a > different order of Scope Fields would result in a Record having a > different semantic meaning, then the order of Scope Fields MUST be > preserved by the Exporting Process. For example, in the context of > PSAMP [RFC5476], if the first scope defines the filtering function, > while the second scope defines the sampling function, the order of > the scope is important. Applying the sampling function first, > followed by the filtering function, would lead to potentially > different Data Records than applying the filtering function first, > followed by the sampling function." > > If an IPFIX Mediator receives, from multiple Exporters, Template > Records with identical Information Elements, but ordered differently, > it SHOULD consider those Template Records as identical. Almost: subject to metadata in options, eg flowKeyIndicator. > > If an IPFIX Mediator receives, from multiple Exporters, Options > Template Records with identical and ordered Information Elements in > the Scope fields, and with identical Information Elements, but > ordered differently, in the non Scope fields, it SHOULD consider > those Template Records as identical. > > If an IPFIX Mediator receives, from multiple Exporters, Options > Template Records with identical Information Elements in the scope, > but ordered differently, it MUST consider those Template Records as > semantically different. Basically scope == key fields, so this agrees with my assertion above. (BTW, if we do IPFIX-2, then we should *only* have options templates, with zero or more scope fields. Think how much simpler that'd make all the drafts!) > > 4.2. Creating New Templates at an IPFIX Mediator > > The second case is a situation where the IPFIX Mediator generates new > (Options) Template Records as a result of the Intermediate Process. As predicted, I already forgot that there was a first case. > > In this situation, the IPFIX Mediator doesn't need to maintain a > Template Mapping, as it generates its own series of (Options) > Template Records. However, the following special case might still > require a Template Mapping, i.e. a situation where the IPFIX > Mediator, typically containing an Intermediate Conversion Process, > > > > Claise, et al. Expires August 29, 2013 [Page 15] > > Internet-Draft IPFIX MED-PROTO February 2013 > > > Intermediate Aggregation Process, or Intermediate Anonymization > Process in case of black-marker Anonymization [RFC6235], generates > new (Options) Template Records based on what it receives from the > Exporter(s), and based on the Intermediate Process function. In such > a case,it's important to keep the correlation between the received > (Options) Template Records and exported Derived (Options) Template > Records in the Template Mapping. These Template Mappings would be > kept as in Section 4.1, except that the exported Template would not > be identical to the received Template. It took me a while to parse this correctly. s/exported/the/ would help considerably. "Derived (Options) Template" isn't defined. > > 4.3. Handling Unknown Information Elements > > Depending on application requirements, Mediators which do not > generate new Records SHOULD re-export values for unknown Information > Elements, whether enterprise-specific Information Elements or > Information Elements in theIANA IPFIX Information Element registry > added since the Mediator was implemented or updated. However, as > there may be presence or ordering dependencies among the unknown > Information Elements, the Mediator MUST NOT omit fields from such re- > exported Records, or re-order any fields within the Records. Add a reference for IANA's registry. BTW, it'd be nice to use a consistent phrase for that throughout all the WG drafts. May a Mediator append fields? That too could lead to ambiguity, eg if any of the unknown fields is a bitmap describing the other fields, it wouldn't correctly describe any appended fields. > > Mediators which generate new Records, as in Section 4.2, SHOULD NOT > use values of Information Elements they do not understand. If they > do pass such values, they MUST NOT pass values of unknownInformaiton > Elements unless all such values are passed on in the original order > in which they were received. Typo. > > In any case, Mediators handling unknown Information Elements SHOULD > log this fact, as it is likely that mediation of records containing > unknown values will have unintended consequences. > > > 5. Preserving Original Observation Point Information > > Depending on the use case, the Collector in an Exporter - IPFIX > Mediator - Collector structure may need to receive information about > the Original Observation Point(s), otherwise it may wrongly conclude > that the IPFIX Device exporting the Flow Records, i.e. the IPFIX > Mediator, directly observed the packets that generated the Flow > Records. Two new Information Elements are introducedin the > subsections belowto address this use case: Remove "in the subsections below". In the IANA section, I'll argue that it'd be better for all the new IEs to be in the IANA section. > originalExporterIPv4Address and originalExporterIPv6Address. > Practically, the Original Exporterswill not exporting these "will not be exporting" What about the case of tiered Mediators? Perhaps the originalExporter*Address should be passed-through. > Information Elements. Therefore, the Intermediate Process SHOULD > report the Original Observation Point(s) to the best of its > knowledge.Note that the Configuration Data Model for IPFIX and > PSAMP [RFC6728] may help. Help in what way? > > > > > Claise, et al. Expires August 29, 2013 [Page 16] > > Internet-Draft IPFIX MED-PROTO February 2013 > > > In the IPFIX Mediator, the Observation Point(s) may be represented > by: > > o A single Original Exporter (represented by the > originalExporterIPv4Address or originalExporterIPv6Address > Information Elements) > > o A list of Original Exporters (represented bythe > originalExporterIPv4Address or originalExporterIPv6Address > Information Elements). s/the/a list of/ > > o Any combination or list of Information Elements representing > Observation Points. For example: > > * A list of Original Exporter interface(s) (represented by the > originalExporterIPv4Address or originalExporterIPv6Address, the > ingressInterface and/or egressInterface Information Elements, > respectively) > > * A list of Original Exporter line card (represented by the > originalExporterIPv4Address or originalExporterIPv6Address, the > lineCardId Information Elements, respectively) > > Some Information Elements characterizing the Observation Point may be > added. For example, the flowDirection Information Element specifies > the direction of the observation, and, as such, characterizes the > Observation Point. > > Any combination of the above representations is possible. For > example, in case of an Intermediate Aggregation Process, an Original > Observation Point could be composed of: > > exporterIPv4Address 192.0.2.1 > exporterIPv4Address 192.0.2.2, > interface ethernet 0, direction ingress > interface ethernet 1, direction ingress > interface serial 1, direction egress > interface serial 2, direction egress > exporterIPv4Address 192.0.2.3, > lineCardId 1, direction ingress > > Figure 4: Complex Observation Point Definition Example This figure is orphaned. Add a line saying "Figure 4 shows some interesting stuff". > > If the Original Observation Point is composed of a list, thenthe > IPFIX Structured Data [RFC6313] MUST be used to export it from the > IPFIX Mediator. Remove "the". > > The most generic way to export the Original Observation Point is to > > > > Claise, et al. Expires August 29, 2013 [Page 17] > > Internet-Draft IPFIX MED-PROTO February 2013 > > > use a subTemplateMultiList, with the semantic "exactlyOneOf". Taking > the previous example, the following encoding can be used: > > Template Record 257: exporterIPv4Address > Template Record 258: exporterIPv4Address, > basicList of ingressInterface, flowDirection > Template Record 259: exporterIPv4Address, lineCardId, flowDirection > > Figure 5: Complex Observation Point Definition Example: Templates This figure is orphaned. Above say, "the encoding in Figure 5 can be used:". > > The Original Observation Point is modeled with the Data Records > corresponding to either Template Record 1, Template Record 2, or > Template Record 3 but not more than one of these ("exactlyOneOf" > semantic). This implies that the Flow was observed at exactly one of > the Observation Points reported. > > When an IPFIX Mediator receives Flow Records containing the Original > Observation Point Information Element, i.e. > originalExporterIPv6Address or originalExporterIPv4Address, the IPFIX Why put IPv6 first, before IPv4? This is inconsistent with earlier usage. > Mediator SHOULD NOT modify its value(s) when composing new Flow > Records in the general case. Known exceptions include anonymization > per [RFC6235] section 7.2.4 and an Intermediate Correlation Process > rewriting addresses across NAT. In other words, the Original > Observation Point should not be replaced with the IPFIX Mediator > Observation Point. The daisy chain of (Exporter, Observation Point) > representing the path the Flow Records took from the Exporter to the > top Collector in the Exporter - IPFIX Mediator(s) - Collector > structure model is out of the scope of this specification. > > 5.1. originalExporterIPv4Address Information Element > > Description: The IPv4 address used by the Exporting Process on an > Original Exporter, as seen by the Collecting Process on an IPFIX > Mediator. Used to provide information about the Original > Observation Points to a downstream Collector. > > Data Type: ipv4Address > > ElementId: TBD1 > > 5.2. originalExporterIPv6Address Information Element > > Description: The IPv6 address used by the Exporting Process on an > Original Exporter, as seen by the Collecting Process on an IPFIX > Mediator. Used to provide information about the Original > Observation Points to a downstream Collector. > > > > > > Claise, et al. Expires August 29, 2013 [Page 18] > > Internet-Draft IPFIX MED-PROTO February 2013 > > > Data Type: ipv6Address > > ElementId: TBD2 In the IANA section, I'll argue that it'd be better for all the new IEs to be in the IANA section. > > > 6. Managing Observation Domain IDs > > In any case, the Observation Domain ID of any IPFIX Message "In any case" probably worked when this text followed directly from some previous argument. However, it seems out of place here. It could be dropped with no loss of meaning. > containing Flow Records relevant to no particular Observation Domain, > or to multiple Observation Domains, MUST have an Observation Domain > ID of 0, as in Section 3 above, and section 3.1 of > [I-D.ietf-ipfix-protocol-rfc5101bis]. So are we saying that OD zero has a special meaning? Should existing exporters avoid using OD zero in order to avoid confusing Collectors? > > IPFIX Mediators that do not change (Options) Template Records MUST > maintain a Template Mapping, as detailed in Section 4.1, to ensure > that the combination of Observation Domain IDs and Template IDs do > not collide on export. > > For IPFIX Mediators that export New (Options) Template Records, as in > Section 4.2, there are two options for Observation Domain ID > management. The first and simplest of these is to completely > decouple exported Observation Domain IDs from received Observation > Domain IDs; the IPFIX Mediator, in this case, comprises its own set > of Observation Domain(s) independent of the Observation Domain(s) of > the Original Exporters. > > The second option is to provide or maintain a Template Mapping for > received (Options) Template Records and exported inferred (Options) > Template Records, along with the appropriate Observation Domain IDs > per Transport Session, which ensures that the combination of > Observation Domain IDs and Template IDs do not collide on export. > > In some cases where the IPFIX Message Header can't contain a > consistent Observation Domain for the entire IPFIX Message, but the > Flow Records exported from the IPFIX Mediator should anyway contain > the Observation Domain of the Original Exporter, the (Options) > Template Record must contain theoriginalObservationDomainId Specified in s6.1 below. > Information Element. When an IPFIX Mediator receives Flow Records > containing the originalObservationDomainId Information Element, the > IPFIX Mediator MUST NOT modify its value(s) when composing new Flow > Records with the originalObservationDomainId Information Element. > > 6.1. originalObservationDomainId Information Element > > > > > > > > > Claise, et al. Expires August 29, 2013 [Page 19] > > Internet-Draft IPFIX MED-PROTO February 2013 > > > Description: The Observation Domain ID reported by the Exporting > Process on an Original Exporter, as seen by the Collecting Process > on an IPFIX Mediator. Used to provide information about the > Original Observation Domain to a downstream Collector. > > Data Type: unsigned32 > > Data Type Semantics: identifier > > ElementId: TBD3 Is this definition sufficient for the revised IANA registry format? > > > 7. Timing Considerations > > The IPFIX Message Header "Export Time" field is the time in seconds > since 0000 UTC Jan 1, 1970, at which the IPFIX Message leaves the > IPFIX Mediator. However, in the specific case of an IPFIX Mediator > containing an Intermediate Conversion Process, the IPFIX Mediator MAY > keep the export time received from the incoming Transport Session. Again, although I know exactly what you're saying here, others might not. I suggest s/keep/use/. > > It is RECOMMENDED that IPFIX Mediators handle time using absolute > timestamps (e.g. flowStartSeconds, flowStartMilliseconds, > flowStartNanoseconds), which are specified relative to the UNIX epoch > (00:00 UTC 1 Jan 1970), where possible, rather than relative > timestamps (e.g. flowStartSysUpTime, flowStartDeltaMicroseconds), > which are specified relative to protocol structures such as system > initialization or message export time. > > The latter are difficult to manage for two reasons. First, they > require constant translation, as the system initialization time of an > intermediate system and the export time of an intermediate message > will change across mediation operations. Further, relative > timestamps introduce range problems. For example, when using the > flowStartDeltaMicroseconds and flowEndDeltaMicroseconds Information > Elements [iana-ipfix-assignments], the Data Record must be exported > within a maximum of 71 minutes after its creation. Otherwise, the > 32-bit counter would not be sufficient to contain the flow start time > offset. Those time constraints might be incompatible with some of > the application requirements of some Intermediate Processes. > > Intermediate Processes MUST NOT assume that received records appear > in flowStartTime, flowEndTime, or observationTime order. An > Intermediate Process processing timing information (e.g., an > Intermediate Aggregation Process) MAY ignore records that are > significantly out of order, in order to meet application-specific > state and latency requirements, but SHOULD report that records were > dropped. > > > > > Claise, et al. Expires August 29, 2013 [Page 20] > > Internet-Draft IPFIX MED-PROTO February 2013 > > > When an Intermediate Process aggregates information from different > Flow Records, the timestamps on exported records SHOULD be the > minimum of the start times and the maximum of the end times in the > general case. However, if the Flow Records do not overlap, i.e. if > there is a time gap between the times in the Flow Records, then the > report may be inaccurate. The IPFIX Mediator is only reporting what > it knows, on the basis of the information made available to it - and > there may not have been any data to observe during the gap. Then > again, if there is an overlap in timestamps, there's the potential of > double-accounting: different Observation Points may have observed the > same traffic simultaneously.Therefore, as there is not a single > rule that fits all different situations, a complete specification of > the precise rules of applying Flow Record timestamps at IPFIX > Mediators is out of the scope of this document. Too hard and can't be bothered? :-( > > Note that [I-D.ietf-ipfix-a9n] provides additional specifications for > handling of timestamps at an Intermediate Aggregation Process. > > > 8. Transport Considerations > > SCTP [RFC4960] using the PR-SCTP extension specified in [RFC3758] > MUST be implemented by all compliant IPFIX Mediator implementations. > TCP [RFC0793] MAY also be implemented by IPFIX Mediator compliant > implementations. UDP [RFC0768] MAY also be implemented by compliant > IPFIX Mediator implementations. Transport-specific considerations > for IPFIX Exporters as specified in sections 8.3, 8.4, 9.1, 9.2, and > 10 of [I-D.ietf-ipfix-protocol-rfc5101bis] apply to IPFIX Mediators > as well. > > SCTP SHOULD be used in deployments where IPFIX Mediators and > Collectors are communicating over links that are susceptible to > congestion. SCTP is capable of providing any required degree of > reliability. TCP MAY be used in deployments where IPFIX Mediators > and Collectors communicate over links that are susceptible to > congestion, but SCTP is preferred due to its ability to limit back > pressure on Exporters and its message versus stream orientation. UDP > MAY be used, although it is not a congestion-aware protocol. > However, in this case, the IPFIX traffic between IPFIX Mediator and > Collector MUST run in an environment where IPFIX traffic has been > provisioned for, or iscontained through some other means. Explain "contained"? > > > 9. Collecting Process Considerations > > Any Collecting Process compliant with > [I-D.ietf-ipfix-protocol-rfc5101bis] can receive IPFIX Messages from > an IPFIX Mediator. If the IPFIX Mediator uses IPFIX Structured Data > > > > Claise, et al. Expires August 29, 2013 [Page 21] > > Internet-Draft IPFIX MED-PROTO February 2013 > > > [RFC6313] to export Original Exporter Information as in Section 5, > the Collecting Process MUST support [RFC6313]. > > > 10. Specific Reporting Requirements > > IPFIX provides Options Templates forthe reporting on the reliability "for reporting the reliability" > of processes within the IPFIX Architecture. As each Mediator > includes at least one IPFIX Exporting Process, they SHOULD use the > Exporting Process Reliability Statistics Options Template, as > specified in [I-D.ietf-ipfix-protocol-rfc5101bis]. > > Analogous to the Metering Process Reliability Statistics Options > Template, also specified in [I-D.ietf-ipfix-protocol-rfc5101bis], > Mediators SHOULD implement the Intermediate Process Reliability > Statistics Options Template, specified in the subsection below. Which subsection? Add an xref. > > The Flow Keys Options Template, as specified in > [I-D.ietf-ipfix-protocol-rfc5101bis], may require special handling at > an IPFIX Mediator as described below. Described where? Add an xref. > > In addition, each Intermediate Process may have its own specific > reporting requirements (e.g. Anonymization Records as in [RFC6235], > or the Aggregation Counter Distribution Options Template as in > [I-D.ietf-ipfix-a9n]); these SHOULD be implemented as necessary as > described in the specification for each Intermediate Process. > > 10.1. Intermediate Process Reliability Statistics Template > > The Intermediate Process Statistics Options Template specifies the > structure of a Data Record for reporting Intermediate Process > statistics. It SHOULD contain the following Information Elements; > the intermediateProcessId Information Element is defined in > Section 10.3, and the ignoredRecordTotalCount Information Element is > defined in Section 10.4: > > +-------------------------+-----------------------------------------+ > | IE | Description | > +-------------------------+-----------------------------------------+ > | observationDomainId | An identifier of the Observation Domain | > | [scope] | (of messages exported by this | > | | Mediator), locally unique to the | > | | Intermediate Process, to which this | > | | statistics record applies. | > | intermediateProcessId | An identifier for the Intermediate | > | [scope] | Process to which this statistics record | > | | applies. | The intermediateProcessId is essentially meaningless outside the Mediator, so what is the value in exporting it? ie, what exactly is its purpose at the collector? > > > > > Claise, et al. Expires August 29, 2013 [Page 22] > > Internet-Draft IPFIX MED-PROTO February 2013 > > > | ignoredRecordTotalCount | The total number of Data Records | > | | received but not processed by the | > | | Intermediate Process. | > | time first record | The timestamp of the first record that | > | ignored | was ignored by the Intermediate | > | | Process. For Data Records containing | > | | timestamp ranges, this SHOULD be taken | > | | from the start timestamp of the range; | > | | for data records containing no timing | > | | information, this SHOULD be taken from | > | | the Export Time in the message header | > | | ofthe containing IPFIX Message. For | Is this the incoming IPFIX Message? So the Intermediate Process has to examine each incoming Message in some detail, even though it's ignoring them? How do you expect that to work? Also, this supposes clock synchronisation. > | | this timestamp, any of the following | > | | timestamp can be used: | > | | observationTimeSeconds, | > | | observationTimeMilliseconds, | > | | observationTimeMicroseconds, or | > | | observationTimeNanoseconds. | > | time last record | The timestamp of the last record that | > | ignored | was ignored by the Intermediate | > | | Process. For Data Records containing | > | | timestamp ranges, this SHOULD be taken | > | | from the end timestamp of the range; | > | | for data records containing no timing | > | | information, this SHOULD be taken from | > | | the Export Time in the message header | > | | of the containing IPFIX Message. For | > | | this timestamp, any of the following | > | | timestamp can be used: | > | | observationTimeSeconds, | > | | observationTimeMilliseconds, | > | | observationTimeMicroseconds, or | > | | observationTimeNanoseconds. | > +-------------------------+-----------------------------------------+ Pleaseaddsomewhitespacetomakethetablereadable. > > 10.2. Flow Key Options Template > > The Flow Keys Option Template specifies the structure of a Data > Record for reporting the Flow Keys of reported Flows. A Flow Keys > Data Record extends a particular Template Record that is referenced > by its templateId identifier. The Template Record is extended by > specifying which of the Information Elements contained in the > corresponding Data Records describe Flow properties that serve as > Flow Keys of the reported Flow. This Options Template is defined in > section 4.4 of [I-D.ietf-ipfix-protocol-rfc5101bis], and SHOULD be > used by Mediators for export as defined there. > > When an Intermediate Process exports Data Records containing > > > > Claise, et al. Expires August 29, 2013 [Page 23] > > Internet-Draft IPFIX MED-PROTO February 2013 > > > different Flow Keys from those received from the Original Exporter, > and the Original Exporter sent a Flow Keys Options record to the > IPFIX Mediator, the IPFIX Mediator MUST export a Flow Keys Options > record defining the the new set of Flow Keys. > > 10.3. intermediateProcessId Information Element > > Description: An identifier of an Intermediate Process that is > unique per IPFIX Device. Typically, this Information Element is > used for limiting the scope of other Information Elements. Note > that process identifiers may be assigned dynamically; ie.,and > Intermediate Process may be re-started with a different ID. s/and/an/ > > Data Type: unsigned32 > > Data Type Semantics: identifier > > ElementId: TBD4 > > 10.4. ignoredRecordTotalCount Information Element > > Description: The total number of received Data Records that the > Intermediate Process did not process since the (re-)initialization > of the Intermediate Process; includes only Data Records not > examined or otherwise handled by the Intermediate Process due to > resource constraints, not Data Records which were examined or > otherwise handled by the Intermediate Process but which merely do > not contribute to any exported Data Record due to the operations > performed by the Intermediate Process. If a mediator is resource constrained, how can it accurately report this figure? > > Data Type: unsigned64 > > Data Type Semantics: totalCounter > > ElementId: TBD5 Are the definitions in 10.3 and 10.4 sufficient for the revised IANA registry format? > > > 11. Configuration Management > > In general, using IPFIX Mediators to combine information from > multiple Original Exporters requires a consistent configuration of > the Metering Processes behind these Original Exporters. The details > of this consistency are specific to each Intermediate Process. > Consistency of configuration should be verified out of band, with the > MIB modules ([RFC6615] and [RFC6727]) or with the Configuration Data > Model for IPFIX and PSAMP [RFC6728] Missing final period. > > > > > > Claise, et al. Expires August 29, 2013 [Page 24] > > Internet-Draft IPFIX MED-PROTO February 2013 > > > 12. Security Considerations > > As they act as both IPFIX Collecting Processes and Exporting > Processes, the Security Considerations for IPFIX Protocol "for the IPFIX Protocol" > [I-D.ietf-ipfix-protocol-rfc5101bis] also apply to IPFIX Mediators. > The Security Considerations for IPFIX Files [RFC5655] also apply to > IPFIX Mediators that write IPFIX Files or use them for internal > storage. However, there are a few specific considerations that IPFIX > Mediator implementations must also take into account. > > By design, IPFIX Mediators are "men-in-the-middle": they intercede in > the communication between an Original Exporter (or another upstream > IPFIX Mediator) and a downstream Collecting Process. This has two > important implications for the level of confidentiality provided > across an IPFIX Mediator, and the ability to protect data integrity > and Original Exporter authenticity across anIPIIX Mediator. These > are addressed in more detail in the Security Considerations for IPFIX > Mediators in [RFC6183]. Typo. > > Note that, while IPFIX Mediators can use the exporterCertificate and > collectorCertificate Information Elements defined in [RFC5655] as > described in section 9.3 of [RFC6183] to export information about > X.509 identities in upstream TLS-protected Transport Sessions, this > mechanism cannot be used to provide true end-to-end assertions about > a chain of IPFIX Mediators: any IPFIX Mediator in the chain can > simply falsify the information about upstreamTransport Sessions In > situations where information about the chain of mediation is > important, it must be determined out of band. Missing period: s/Transport Sessions In/Transport Sessions. In/ > > > 13. IANA Considerations > > This document specifiesn new IPFIX Information Elements, s/n/some/, or delete it. > originalExporterIPv4Address in Section 5.1, > originalExporterIPv6Address in Section 5.2, and > originalObservationDomainId in Section 6.1, to be added to the IPFIX > Information Element registry [iana-ipfix-assignments]. [IANA NOTE: > please add the three Information Elements as specified in the > references subsections, and change TBD1, TBD2, and TBD3 in this > document to reflect the assigned identifiers.] Also intermediateProcessId(TBD4) in 10.4 and ignoredRecordTotalCount(TBD5) in 10.5. Rather than having the new IEs sprinkled througout the document, I'd prefer to have all the definitions consolidated here in the IANA section, with xrefs from the text. There's no advantage to defining them inline. As you see, the definitions are easily overlooked. > > > 14. Acknowledgments > > We would like to thank the IPFIX contributors, specifically Paul > Aitken for his thorough review and Rahul Patel for his feedback and s/review/reviews/ P. > comments. This work is materially supported by the European Union > Seventh Framework Programme under grant agreement 257315 (DEMONS). > > > > Claise, et al. Expires August 29, 2013 [Page 25] > > Internet-Draft IPFIX MED-PROTO February 2013 > > > 15. References > > 15.1. Normative References > > [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, > August 1980. > > [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, > RFC 793, September 1981. > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. > > [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. > Conrad, "Stream Control Transmission Protocol (SCTP) > Partial Reliability Extension", RFC 3758, May 2004. > > [RFC4960] Stewart, R., "Stream Control Transmission Protocol", > RFC 4960, September 2007. > > [RFC5655] Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. > Wagner, "Specification of the IP Flow Information Export > (IPFIX) File Format", RFC 5655, October 2009. > > [RFC6313] Claise, B., Dhandapani, G., Aitken, P., and S. Yates, > "Export of Structured Data in IP Flow Information Export > (IPFIX)", RFC 6313, July 2011. > > [RFC6615] Dietz, T., Kobayashi, A., Claise, B., and G. Muenz, > "Definitions of Managed Objects for IP Flow Information > Export", RFC 6615, June 2012. > > [RFC6727] Dietz, T., Claise, B., and J. Quittek, "Definitions of > Managed Objects for Packet Sampling", RFC 6727, > October 2012. > > [RFC6728] Muenz, G., Claise, B., and P. Aitken, "Configuration Data > Model for the IP Flow Information Export (IPFIX) and > Packet Sampling (PSAMP) Protocols", RFC 6728, > October 2012. > > [I-D.ietf-ipfix-protocol-rfc5101bis] > Claise, B. and B. Trammell, "Specification of the IP Flow > Information eXport (IPFIX) Protocol for the Exchange of > Flow Information", draft-ietf-ipfix-protocol-rfc5101bis-06 > (work in progress), February 2013. > > [I-D.ietf-ipfix-information-model-rfc5102bis] > > > > Claise, et al. Expires August 29, 2013 [Page 26] > > Internet-Draft IPFIX MED-PROTO February 2013 > > > Claise, B. and B. Trammell, "Information Model for IP Flow > Information eXport (IPFIX)", > draft-ietf-ipfix-information-model-rfc5102bis-10 (work in > progress), February 2013. > > [I-D.ietf-ipfix-flow-selection-tech] > D'Antonio, S., Zseby, T., Henke, C., and L. Peluso, "Flow > Selection Techniques", > draft-ietf-ipfix-flow-selection-tech-13 (work in > progress), February 2013. > > [I-D.ietf-ipfix-a9n] > Trammell, B., Wagner, A., and B. Claise, "Flow Aggregation > for the IP Flow Information Export (IPFIX) Protocol", > draft-ietf-ipfix-a9n-08 (work in progress), November 2012. > > 15.2. Informative References > > [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, > "Requirements for IP Flow Information Export (IPFIX)", > RFC 3917, October 2004. > > [RFC3954] Claise, B., "Cisco Systems NetFlow Services Export Version > 9", RFC 3954, October 2004. > > [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, > "Architecture for IP Flow Information Export", RFC 5470, > March 2009. > > [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP > Flow Information Export (IPFIX) Applicability", RFC 5472, > March 2009. > > [RFC5476] Claise, B., Johnson, A., and J. Quittek, "Packet Sampling > (PSAMP) Protocol Specifications", RFC 5476, March 2009. > > [RFC5610] Boschi, E., Trammell, B., Mark, L., and T. Zseby, > "Exporting Type Information for IP Flow Information Export > (IPFIX) Information Elements", RFC 5610, July 2009. > > [RFC5982] Kobayashi, A. and B. Claise, "IP Flow Information Export > (IPFIX) Mediation: Problem Statement", RFC 5982, > August 2010. > > [RFC6183] Kobayashi, A., Claise, B., Muenz, G., and K. Ishibashi, > "IP Flow Information Export (IPFIX) Mediation: Framework", > RFC 6183, April 2011. > > > > > Claise, et al. Expires August 29, 2013 [Page 27] > > Internet-Draft IPFIX MED-PROTO February 2013 > > > [RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization > Support", RFC 6235, May 2011. > > [iana-ipfix-assignments] > Internet Assigned Numbers Authority, "IP Flow Information > Export Information Elements > (http://www.iana.org/assignments/ipfix/ipfix.xml)". > > [POSIX.1] IEEE, "IEEE 1003.1-2008 - IEEE Standard for Information > Technology - Portable Operating System Interface". > > > Authors' Addresses > > Benoit Claise > Cisco Systems, Inc. > De Kleetlaan 6a b1 > 1831 Diegem > Belgium > > Phone: +32 2 704 5622 > Email: bclaise@cisco.com > > > Atsushi Kobayashi > NTT Information Sharing Platform Laboratories > 3-9-11 Midori-cho > Musashino-shi, Tokyo 180-8585 > Japan > > Phone: +81 422 59 3978 > Email: akoba@nttv6.net > > > Brian Trammell > Swiss Federal Institute of Technology Zurich > Gloriastrasse 35 > 8092 Zurich > Switzerland > > Phone: +41 44 632 70 13 > Email: trammell@tik.ee.ethz.ch > > > > > > > > > > Claise, et al. Expires August 29, 2013 [Page 28] > --------------030608080101070204090503 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear Authors,

Here's another review of draft-ietf-ipfix-mediation-protocol-04.

Overall I'm happy with the shape of this draft; I have no major technical issues. Just some minor ones, and loads of editorial issues.

Please find comments inline:



IPFIX Working Group                                            B. Claise
Internet-Draft                                       Cisco Systems, Inc.
Intended status: Standards Track                            A. Kobayashi
Expires: August 29, 2013                                             NTT
                                                             B. Trammell
                                                              ETH Zurich
                                                       February 25, 2013


 Operation of the IP Flow Information Export (IPFIX) Protocol on IPFIX
                               Mediators
               draft-ietf-ipfix-mediation-protocol-04.txt

Abstract

   This document specifies the operation of the IP Flow Information
   Export (IPFIX) protocol specific to IPFIX Mediators, including
   Template and Observation Point management, timing considerations, and
   other Mediator-specific concerns.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 29, 2013.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must



Claise, et al.           Expires August 29, 2013                [Page 1]

Internet-Draft               IPFIX MED-PROTO               February 2013


   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  IPFIX Documents Overview . . . . . . . . . . . . . . . . .  3
     1.2.  IPFIX Mediator Documents Overview  . . . . . . . . . . . .  4
     1.3.  Relationship with the IPFIX and PSAMP Protocols  . . . . .  5
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Handling IPFIX Message Headers . . . . . . . . . . . . . . . .  8
   4.  Template Management  . . . . . . . . . . . . . . . . . . . . . 10
     4.1.  Passing Unmodified Templates through an IPFIX Mediator . . 11
       4.1.1.  Template Mapping and Information Element Ordering  . . 14
     4.2.  Creating New Templates at an IPFIX Mediator  . . . . . . . 15
     4.3.  Handling Unknown Information Elements  . . . . . . . . . . 16
   5.  Preserving Original Observation Point Information  . . . . . . 16
     5.1.  originalExporterIPv4Address Information Element  . . . . . 18
     5.2.  originalExporterIPv6Address Information Element  . . . . . 18
   6.  Managing Observation Domain IDs  . . . . . . . . . . . . . . . 19
     6.1.  originalObservationDomainId Information Element  . . . . . 19
   7.  Timing Considerations  . . . . . . . . . . . . . . . . . . . . 20
   8.  Transport Considerations . . . . . . . . . . . . . . . . . . . 21
   9.  Collecting Process Considerations  . . . . . . . . . . . . . . 21
   10. Specific Reporting Requirements  . . . . . . . . . . . . . . . 22
     10.1. Intermediate Process Reliability Statistics Template . . . 22
     10.2. Flow Key Options Template  . . . . . . . . . . . . . . . . 23
     10.3. intermediateProcessId Information Element  . . . . . . . . 24
     10.4. ignoredRecordTotalCount Information Element  . . . . . . . 24
   11. Configuration Management . . . . . . . . . . . . . . . . . . . 24
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 25
   13. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 25
   14. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 25
   15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
     15.1. Normative References . . . . . . . . . . . . . . . . . . . 26
     15.2. Informative References . . . . . . . . . . . . . . . . . . 27
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28












Claise, et al.           Expires August 29, 2013                [Page 2]

Internet-Draft               IPFIX MED-PROTO               February 2013


1.  Introduction

   The IPFIX architectural components in [RFC5470] consist of IPFIX
   Devices and IPFIX Collectors communicating using the IPFIX protocol
   [I-D.ietf-ipfix-protocol-rfc5101bis], which specifies how to export
   IP Flow information.  This protocol is designed to export information
   about IP traffic Flows and related measurement data, where a Flow is
   defined by a set of key attributes (e.g. source and destination IP
   address, source and destination port, etc.).

   However, thanks to its Template mechanism, the IPFIX protocol can
   export any type of information, as long as the relevant Information
   Element is specified in the IPFIX Information Model
   [I-D.ietf-ipfix-information-model-rfc5102bis], registered with IANA,
   or specified as an enterprise-specific Information Element.  The
   specifications in the IPFIX protocol
   [I-D.ietf-ipfix-protocol-rfc5101bis] have not been defined in the
   context of an IPFIX Mediator receiving, aggregating, correlating,
   anonymizing, etc...  Flow Records from the one or multiple Exporters.
   Indeed, the IPFIX protocol must be adapted for Intermediate
   Processes, as defined in the IPFIX Mediation Reference Model as
   specified in Figure A of [RFC6183], which is based on the IPFIX
   Mediation Problem Statement [RFC5982].

   This document specifies the IP Flow Information Export (IPFIX)
   protocol in the context of the implementation and deployment of IPFIX
   Mediators.  The use of the IPFIX protocol within an IPFIX Mediator --
   a device which contains both a Collecting Process and an Exporting
   Process -- has an impact on the technical details of the usage of the
   protocol.  An overview of the technical problem is covered in section
   6 of [RFC5982]: loss of original Exporter information, loss of base
   time information, transport sessions management, loss of Options
   Template Information, Template Id management, considerations for
   network considerations for aggregation.

   The specifications in this document are based on the IPFIX protocol
   specifications [I-D.ietf-ipfix-protocol-rfc5101bis] but adapted
   according to the IPFIX Mediation Framework [RFC6183].

1.1.  IPFIX Documents Overview

   The IPFIX Protocol [I-D.ietf-ipfix-protocol-rfc5101bis] provides
   network administrators with access to IP Flow information.

   The architecture for the export of measured IP Flow information out
   of an IPFIX Exporting Process to a Collecting Process is defined in
   the IPFIX Architecture [RFC5470], per the requirements defined in the
   IPFIX Requirement doc, [RFC3917].



Claise, et al.           Expires August 29, 2013                [Page 3]

Internet-Draft               IPFIX MED-PROTO               February 2013


   The IPFIX Architecture [RFC5470] specifies how IPFIX Data Records and
   Templates are carried via a congestion-aware transport protocol from
   IPFIX Exporting Processes to IPFIX Collecting Processes.

   IPFIX has a formal description of IPFIX Information Elements, their
   name, type and additional semantic information, as specified in the
   IPFIX Information Model
   [I-D.ietf-ipfix-information-model-rfc5102bis].  The registry is
   maintained by IANA [IPFIX-IANA].  New Information Element definitions
   can be added to this registry subject to an Expert Review [RFC5226],
   with additional process considerations decribed in [IPFIX-IE-

Typo, "described".


   DOCTORS]; that document also provides guidelines for authors and
   reviewers of new Information Element definitions.  The inline export
   of the Information Element type information is specified in
   [RFC5610].

   The IPFIX Applicability Statement [RFC5472] describes what type of
   applications can use the IPFIX protocol and how they can use the
   information provided.  It furthermore shows how the IPFIX framework
   relates to other architectures and frameworks.

1.2.  IPFIX Mediator Documents Overview

   The "IPFIX Mediation: Problem Statement" [RFC5982] provides an
   overview of the applicability of IPFIX Mediators, and defines
   requirements for IPFIX Mediators in general terms.  This document is
   of use largely to define the problems to be solved through the
   deployment of IPFIX Mediators, and to provide scope to the role of
   IPFIX Mediators within an IPFIX collection infrastructure.

   The "IPFIX Mediation: Framework" [RFC6183], which details the IPFIX
   Mediation reference model and the components of an IPFIX Mediator,
   provides more architectural details of the arrangement of
   Intermediate Processes within an IPFIX Mediator.

   Documents specifying the operations of specific Intermediate
   Processes cover the operation of these Processes within the IPFIX
   Mediator framework, and comply with the specifications given in this
   document; they may additionally specify the operation of the process
   independently, outside the context of an IPFIX Mediator, when this is
   appropriate.  The details of specific Intermediate Processes, when
   these have additional export specifications (e.g., metadata about the
   intermediate processing conveyed through IPFIX Options Templates),
   are each treated in their own document.  As of today, these documents
   are:

   1.  "IP Flow Anonymization Support", [RFC6235], which describes
       Anonymization techniques for IP flow data and the export of



Claise, et al.           Expires August 29, 2013                [Page 4]

Internet-Draft               IPFIX MED-PROTO               February 2013


       Anonymized data using the IPFIX protocol.

   2.  "Flow Selection Techniques" [I-D.ietf-ipfix-flow-selection-tech],
       which describes the process of selecting a subset of Flows from
       all Flows observed at an Observation Point, the flow selection
       motivations, and some specific flow selection techniques.

   3.  "Exporting Aggregated Flow Data using IP Flow Information Export"
       [I-D.ietf-ipfix-a9n] which describes Aggregated Flow export
       within the framework of IPFIX Mediators and defines an
       interoperable, implementation-independent method for Aggregated
       Flow export.

   This document specifies the IP Flow Information Export (IPFIX)
   protocol specific to Mediation, i.e. the specifications that all
   Intermediate Processes type must comply to.  Some extra
   specifications might be required per Intermediate Process type (In
   which case, the Intermediate Process specific document would cover
   those).

1.3.  Relationship with the IPFIX and PSAMP Protocols

   The specification in this document applies to the IPFIX protocol
   specifications [I-D.ietf-ipfix-protocol-rfc5101bis].  All
   specifications from [I-D.ietf-ipfix-protocol-rfc5101bis] apply unless
   specified otherwise in this document.

   As the Packet Sampling (PSAMP) protocol specifications [RFC5476] are
   based on the IPFIX protocol specifications, the specifications in
   this document are also valid for the PSAMP protocol.  Therefore, the
   method specified by this document also applies to PSAMP.


2.  Terminology

   IPFIX-specific terms, such as Observation Domain, Flow, Flow Key,
   Metering Process, Exporting Process, Exporter, IPFIX Device,
   Collecting Process, Collector, Template, IPFIX Message, Message
   Header, Template Record, Data Record, Options Template Record, Set,
   Data Set, Information Element, Scope and Transport Session, used in
   this document are defined in [I-D.ietf-ipfix-protocol-rfc5101bis].
   The PSAMP-specific terms used in this document, such as Filtering and
   Sampling, are defined in [RFC5476].

   IPFIX Mediation terms related to aggregation, such as the Interval,
   Aggregated Flow, and Aggregated Function are defined in
   [I-D.ietf-ipfix-a9n].




Claise, et al.           Expires August 29, 2013                [Page 5]

Internet-Draft               IPFIX MED-PROTO               February 2013


   The IPFIX Mediation-specific terminology used in this document is
   defined in "IPFIX Mediation: Problem Statement" [RFC5982], and reused
   in "IPFIX Mediation: Framework" [RFC6183].  However, since both of
   those documents are an informational RFCs, the definitions have been
   reproduced here along with additional definitions.

   Similarly, since [RFC6235] is an experimental RFC, the Anonymization
   Record, Anonymized Data Record, and Intermediate Anonymization
   Process terms, specified in [RFC6235], are also reproduced here.

   In this document, as in [I-D.ietf-ipfix-protocol-rfc5101bis],
   [RFC5476], [I-D.ietf-ipfix-a9n], and [RFC6235], the first letter of
   each IPFIX-specific and PSAMP-specific term is capitalized along with
   the IPFIX Mediation-specific term defined here.

   In this document, we call a stream of records carrying flow- or
   packet-based information a "record stream".  The records may be
   encoded as IPFIX Data Records of any other format.

Typo, "or".



   Transport Session Information:   The Transport Session is specified
      in [I-D.ietf-ipfix-protocol-rfc5101bis].  In SCTP, the Transport
      Session Information is the SCTP association.  In TCP and UDP, the
      Transport Session Information corresponds to a 5-tuple {Exporter
      IP address, Collector IP address, Exporter transport port,
      Collector transport port, transport protocol}.

   Original Exporter:   An Original Exporter is an IPFIX Device that
      hosts the Observation Points where the metered IP packets are
      observed.

   Original Observation Point:   An Observation Point of the Original
      Exporter.  In the case of the Intermediate Aggregation Process on

These definitions imply that OPs belong to the exporter, which is not the case; they belong to the MP or to the IPFIX device.


      an IPFIX Mediator, the Original Observation Point can be composed
      of, but not limited to, a (set of) specific Exporter(s), a (set
      of) specific interface(s) on an Exporter, a (set of) line card(s)
      on an Exporter, or any combinations of these.

   IPFIX Mediation:   IPFIX Mediation is the manipulation and conversion
      of a record stream for subsequent export using the IPFIX protocol.

   Template Mapping:   A mapping from Template Records and/or Options
      Template Records received by an IPFIX Mediator to Template Records
      and/or Options Template Records sent by that IPFIX Mediator.  Each
      entry in a Template Mapping is scoped by incoming or outgoing
      Transport Session and Observation Domain, as with Templates and
      Options Templates in the IPFIX Protocol.





Claise, et al.           Expires August 29, 2013                [Page 6]

Internet-Draft               IPFIX MED-PROTO               February 2013


   Anonymization Record:   A record that defines the properties of the
      anonymization applied to a single Information Element within a
      single Template or Options Template, as in [RFC6235].

   Anonymized Data Record:   A Data Record within a Data Set containing
      at least one Information Element with Anonymized values.  The
      Information Element(s) within the Template or Options Template
      describing this Data Record SHOULD have a corresponding
      Anonymization Record, as in [RFC6235].

   The following terms are used in this document to describe the
   architectural entities used by IPFIX Mediation.

   Intermediate Process:   An Intermediate Process takes a record stream
      as its input from Collecting Processes, Metering Processes, IPFIX
      File Readers, other Intermediate Processes, or other record
      sources; performs some transformations on this stream, based upon
      the content of each record, states maintained across multiple
      records, or other data sources; and passes the transformed record
      stream as its output to Exporting Processes, IPFIX File Writers,
      or other Intermediate Processes, in order to perform IPFIX
      Mediation.  Typically, an Intermediate Process is hosted by an
      IPFIX Mediator.  Alternatively, an Intermediate Process may be
      hosted by an Original Exporter.

   IPFIX Mediator:   An IPFIX Mediator is an IPFIX Device that provides
      IPFIX Mediation by receiving a record stream from some data
      sources, hosting one or more Intermediate Processes to transform
      that stream, and exporting the transformed record stream into
      IPFIX Messages via an Exporting Process.  In the common case, an
      IPFIX Mediator receives a record stream from a Collecting Process,
      but it could also receive a record stream from data sources not
      encoded using IPFIX, e.g., in the case of conversion from the
      NetFlow V9 protocol [RFC3954] to IPFIX protocol.

   Specific Intermediate Processes are described below.

   Intermediate Conversion Process  (as in [RFC6183]): An Intermediate
      Conversion Process is an Intermediate Process that transforms non-
      IPFIX into IPFIX or manages the relation among Templates and
      states of incoming/outgoing transport sessions in the case of
      transport protocol conversion (e.g., from UDP to SCTP).

   Intermediate Aggregation Process  (as in [I-D.ietf-ipfix-a9n]): an
      Intermediate Process (IAP) as in [RFC6183] that aggregates
      records, based upon a set of Flow Keys or functions applied to
      fields from the record.




Claise, et al.           Expires August 29, 2013                [Page 7]

Internet-Draft               IPFIX MED-PROTO               February 2013


   Intermediate Correlation Process  (as in [RFC6183]): An Intermediate
      Correlation Process is an Intermediate Process that adds
      information to records, noting correlations among them, or
      generates new records with correlated data from multiple records
      (e.g., the production of bidirectional flow records from
      unidirectional flow records).

   Intermediate Anonymization Process  (as in [RFC6235]): An
      intermediate process that takes Data Records and transforms them
      into Anonymized Data Records.

   Intermediate Selection Process  (as in [RFC6183]): An Intermediate
      Selection Process is an Intermediate Process that selects records
      from a sequence based upon criteria-evaluated record values and
      passes only those records that match the criteria (e.g., Filtering
      only records from a given network to a given Collector).

   Intermediate Flow Selection Process  (as in
      [I-D.ietf-ipfix-flow-selection-tech]: An Intermediate Flow
      Selection Process is an Intermediate Process as in [RFC6183] that
      takes Flow Records as its input and selects a subset of this set
      as its output.  Intermediate Flow Selection Process is a more
      general concept than Intermediate Selection Process as defined in
      [RFC6183].  While an Intermediate Selection Process selects Flow
      Records from a sequence based upon criteria-evaluated Flow record
      values and passes only those Flow Records that match the criteria,
      an Intermediate Flow Selection Process selects Flow Records using
      selection criteria applicable to a larger set of Flow
      characteristics and information.

For all the words, I only understood that IFSP is a superset of ISP - and I feel that I missed the point?




3.  Handling IPFIX Message Headers

   The format of the IPFIX Message Header as exported by an IPFIX
   Mediator is shown in Figure 1.  Note that the format is compatible
   with the IPFIX Message Header defined in
   [I-D.ietf-ipfix-protocol-rfc5101bis], with some field definitions
   (for the example, the Export Time) updated in the context of the
   IPFIX Mediator.












Claise, et al.           Expires August 29, 2013                [Page 8]

Internet-Draft               IPFIX MED-PROTO               February 2013


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Version           |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Export Time                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Sequence Number                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Observation Domain ID                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 1: IP Message Header format

   The header fields as exported by an IPFIX Mediator are describe
   below.

   Version:   Version of IPFIX to which this Message conforms.  The
      value of this field is 0x000a for the current version,
      incrementing by one the version used in the NetFlow services
      export version 9 [RFC3954].

   Length:   Total length of the IPFIX Message, measured in octets,
      including Message Header and Set(s).

   Export Time:   Time at which the IPFIX Message Header leaves the
      IPFIX Mediator, expressed in seconds since the UNIX epoch of 1
      January 1970 at 00:00 UTC, encoded as an unsigned 32-bit integer.
      However, in the specific case of an IPFIX Mediator containing an
      Intermediate Conversion Process, the IPFIX Mediator MAY keep the
      export time received from the incoming Transport Session.

I know exactly what you're saying here, but others might not. I suggest s/keep/use/.



   Sequence Number:   Incremental sequence counter modulo 2^32 of all
      IPFIX Data Records sent in a the current stream from the current
      Observation Domain by the Exporting Process.  Each SCTP Stream
      counts sequence numbers separately, while all messages in a TCP
      connection or UDP transport session are considered to be part of
      the same stream.  This value SHOULD be used by the Collecting
      Process to identify whether any IPFIX Data Records have been
      missed.  Template and Options Template Records do not increase the
      Sequence Number.

   Observation Domain ID:   A 32-bit identifier of the Observation
      Domain that is locally unique to the Exporting Process.  The
      Exporting Process uses the Observation Domain ID to uniquely
      identify to the Collecting Process the Observation Domain that
      metered the Flows.  It is RECOMMENDED that this identifier also be
      unique per IPFIX Device.  Collecting Processes SHOULD use the



Claise, et al.           Expires August 29, 2013                [Page 9]

Internet-Draft               IPFIX MED-PROTO               February 2013


      Transport Session and the Observation Domain ID field to separate
      different export streams originating from the same Exporter.  The
      Observation Domain ID SHOULD be 0 when no specific Observation
      Domain ID is relevant for the entire IPFIX Message, for example,
      when exporting the Exporting Process Statistics, or in case of a
      hierarchy of Collectors when aggregated Data Records are exported.
      See Section 4.1 for special considerations for Observation Domain
      management while passing unmodified templates through an IPFIX
      Mediator, and Section 5 for guidelines for preservation of
      original Observation Domain information at an IPFIX Mediator.

   The following specifications, copied over from
   [I-D.ietf-ipfix-protocol-rfc5101bis] have some implications in this
   document: "Template Withdrawals MAY appear interleaved with Template
   Sets, Options Template Sets, and Data Sets within an IPFIX Message.
   In this case, the Templates and Template Withdrawals shall be taken
   to take effect in the order in which they appear in the IPFIX
   Message."

   If an IPFIX Mediator receives an IPFIX Message composed of Template
   Withdrawals and Template Sets, and if the IPFIX Mediator forwards
   this IPFIX Message, it MUST not modify the Set order.  Note that the

TWM + Template definitions in separate messages must also not be re-ordered.


   Template Mapping (see section 4.1) is the authorative source of

Typo, "authoritative".


   information on the IPFIX Mediator to decide whether the entire IPFIX
   Messages can be forwarded as such.


4.  Template Management

   How an IPFIX Mediator handles the Templates it receives from the
   Original Exporter depends entirely on the nature of the Intermediate
   Process running on that IPFIX Mediator.

   IPFIX Mediators that pass substantially the same Data Records from
   the Original Exporter downstream, (e.g., an Intermediate Selection
   Process), pass unmodified Template as described in Section 4.1; this

I can't parse this properly - partly because the comma section is completely parenthesised.

What does "substantially the same Data Records" mean? It could be:

    * the same data records, +/- a field or two.
    * the same fields, +/- some records.

Should "Template" be plural?


   section describes a Template Mapping required to make this work in
   the general case, and the correlation between the receivd and
   generated IPFIX Message Withdrawals.

Typo, "received".



   IPFIX Mediators that export Data Records which are substantially
   changed from the Data Records received from the Original Exporter

What does "substantially changed" mean?

    * fields reordered, added, or removed
    * fields unmodified, but records added / removed


   follow the guidelines in Section 4.2 instead: in this case, the IPFIX
   Mediator generates new (Options) Template Records as a result of the
   Intermediate Process, and no Template Mapping is required.

   Subsequent subsections deal with specific issues in Template
   management that may occur at IPFIX Mediators.



Claise, et al.           Expires August 29, 2013               [Page 10]

Internet-Draft               IPFIX MED-PROTO               February 2013


4.1.  Passing Unmodified Templates through an IPFIX Mediator

   The first case is a situation where the IPFIX Mediator doesn't modify

The "second case" is 5 pages away at the bottom of page 15. Perhaps just say, "In this case, the IPFIX Mediator...".


   the (Options) Template Record(s) content.  A typical example is an

Hurrah, a definition of "substantially the same"!


   Intermediate Flow Selection Process acting as distributor, which
   collects Flow Records from one or more Exporters, and based on the
   Information Elements content, redirects the Flow Records to the
   appropriate Collector.  This example is a typical case of a single
   network operation center managing multiple universities: an unique
   IPFIX Collector collects all Flow Records for the common
   infrastructure, but might be re-exporting specific university Flow
   Records to the responsible system administrator.

Does this case include the situation where incoming templates contain the same fields, but in a different order? So the mediator could re-order the fields and export the contents with a single outgoing Template. [Later: subject to key fields, per below.]



   As specified in [I-D.ietf-ipfix-protocol-rfc5101bis], the Template
   IDs are unique per Exporter, per Transport Session, and per
   Observation Domain.  As there is no guarantee that, for similar
   Template Records, the Template IDs received on the incoming Transport
   Session and exported to the outgoing Transport Session would be same,
   the IPFIX Mediator MUST maintain a Template Mapping composed of
   related received and exported (Options) Template Records:

   o  for each received (Options) Template Record: Template Record
      Information Elements, Template ID, Observation Domain Id, and
      Transport Session Information, metada scoped to the Template (*)

Typo, "metadata".



   o  for each exported (Options) Template Record: Template Record
      Information Elements, Template ID, Collector, Observation Domain
      Id, and Transport Session Information metadata scoped to the
      Template (*)

   (*) The "metadata scoped to the Template" encompasses the metadata,
   that are scoped to the Template,

I'm glad you explained; I'd never have guessed.


   and that help to determine the
   semantics of the Template Record.  Note that these metadata are
   typically sent in Data Records described by an Options Template.  A
   example is the flowKeyIndicator: An IPFIX Mediator could potentially
   received two different Template IDs, from the same Exporter, with the
   same Information Elements, but with a different set of Flow Keys
   (indicated by the flowKeyIndicator in an Options Template Record).

This complicates my question about field-ordering above.


   Another example is the combination of anonymizationFlags and
   anonymizationTechnique [RFC6235]).  This metadata information must be
   present in the Template Mapping, to stress that the two Template
   Record semantics are different.

So templates can potentially be merged provided that the semantics are the same.



   If an IPFIX Mediator receives an IPFIX Withdrawal Message for a
   (Options) Template Record that is not used anymore in any other
   Template Mappings, the IPFIX Mediator SHOULD export the appropriate
   IPFIX Withdrawal Message(s) on the outgoing Transport Session, and
   remove the corresponding entry in the Template Mapping.



Claise, et al.           Expires August 29, 2013               [Page 11]

Internet-Draft               IPFIX MED-PROTO               February 2013


   If a (Options) Template Record is not used anymore in an outgoing
   Transport Session, it MUST be withdrawn with an IPFIX Template
   Withdrawal Message on that specific outgoing Transport Session, and
   its entry MUST be removed from the Template Mapping.

   If an incoming or outgoing Transport Session is gracefully shutdown
   or reset, the (Options) Template Records corresponding to that
   Transport Session MUST be removed from the Template Mapping.

   For example, Figure 2 displays an example of an Intermediate Flow
   Selection Process, re-distributing Data Records to Collectors on the
   basis of customer networks, i.e. the Route Distinguisher (RD).  In
   this example, the Template Record received from the Exporter #1 is
   reused towards Collector #1, Collector #2, and Collector #3.

If the incoming template is reused, then why does customer A receive Template 256, while customers B and C receive Template 257? What's the difference between Template 256 and Template 257?



                                       Tmpl.  .---------.
                                       ID 256 |         |
                                        .---->|Collector|<==>Customer
                                        |     |#1       |    A
                                        |     |         |
                                     RD=100:1 '---------'
      .---------.Templ.  .---------.    |
      |         |Id      |         |----'     .---------.
      |         |258     |         | RD=100:2 |         |
      |IPFIX    |------->|IPFIX    |--------->|Collector|<==>Customer
      |Exporter |        |Mediator | Tmpl.    |#2       |    B
      |#1       |        |         | ID 257   |         |
      |         |        |         |----.     '---------'
      '---------'        '---------'    |
                                       RD=100:3
                                  Tmpl. |     .---------.
                                  ID    |     |         |
                                  257   '---->|Collector|<==>Customer
                                              |#3       |    C
                                              |         |
                                              '---------'

           Figure 2: Intermediate Flow Selection Process example

The middle of the figure is hideously cramped, in the area under RD=100:2. Some vertical spacing would really help.

Also there's enough room to write "Customer A" without wrapping. Additionally 2 columns can be recovered by narrowing the Exporter and Mediator boxes. The figure can also be pulled up to 3 spaces leftwards if needs be.

"Templ. Id 258" is inconsistent with "Tmpl. ID nnn" everywhere else.

So, putting that all together, let me redraw the figure for you:

                                            .---------.
                                Tmpl.       |         |
                                ID    .---->|Collector|<==>Customer A
                                256   |     |   #1    |
                                      |     |         |
                                   RD=100:1 '---------'
      .--------.        .--------.    |
      |        | Tmpl.  |        |----'
      |        | Id     |        |          .---------.
      |        | 258    |        | RD=100:2 |         |
      | IPFIX  |------->| IPFIX  |--------->|Collector|<==>Customer B
      |Exporter|        |Mediator| Tmpl.    |   #2    |
      |   #1   |        |        | ID 257   |         |
      |        |        |        |          '---------'
      |        |        |        |----.
      '--------'        '--------'    |
                                   RD=100:3
                                      |     .---------.
                                Tmpl. |     |         |
                                ID    '---->|Collector|<==>Customer C
                                257         |   #3    |
                                            |         |
                                            '---------'


   Figure 3 shows the Template Mapping for the system shown in Figure 2.











Claise, et al.           Expires August 29, 2013               [Page 12]

Internet-Draft               IPFIX MED-PROTO               February 2013


   Template Entry A:
   Incoming Transport Session Information (from Exporter#1):
     Source IP: <Exporter#1 export IP address>
     Destination IP: <IPFIX Mediator IP address>
     Protocol: SCTP
     Source Port: <source port>
     Destination Port: 4739 (IPFIX)
   Observation Domain Id: <Observation Domain ID>
   Template Id: 258
   Metada scoped to the Template : <not applicable in this case>

Typo.


   Template Entry B:
   Outgoing Transport Session Information (to Collector#1):
     Source IP: <IPFIX Mediator IP address>
     Destination IP: <IPFIX Collector#1 IP address>
     Protocol: SCTP
     Source Port: <source port>
     Destination Port: 4739 (IPFIX)
   Observation Domain Id: <Observation Domain ID>
   Template Id: 256
   Metada scoped to the Template : <not applicable in this case>

Typo.



   Template Entry C:
   Outgoing Transport Session Information (to Collector#2):
     Source IP: <IPFIX Mediator IP address>
     Destination IP: <IPFIX Collector#2 IP address>
     Protocol: SCTP
     Source Port: <source port>
     Destination Port: 4739 (IPFIX)
   Observation Domain Id: <Observation Domain ID>
   Template Id: 257
   Metada scoped to the Template : <not applicable in this case>

Typo.



   Template Entry D:
   Outgoing Transport Session Information (to Collector#3):
     Source IP: <IPFIX Mediator IP address>
     Destination IP: <IPFIX Collector#3 IP address>
     Protocol: SCTP
     Source Port: <source port>
     Destination Port: 4739 (IPFIX)
   Observation Domain Id: <Observation Domain ID>
     Template Id: 257
   Metada scoped to the Template : <not applicable in this case>

Indentation of "Template ID: 257" is inconsistent with usage above.

Typo, "metadata".

BTW, note the potential for confusion where:
    Template Entry B corresponds to customer A
    Template Entry C corresponds to customer B
    Template Entry D corresponds to customer C



               Figure 3: Template Mapping example: templates

   The Template Mapping corresponding to figure B can be displayed as:

Where is "figure B" ?






Claise, et al.           Expires August 29, 2013               [Page 13]

Internet-Draft               IPFIX MED-PROTO               February 2013


   Template Entry A   <----> Template Entry B
   Template Entry A   <----> Template Entry C
   Template Entry A   <----> Template Entry D

                    Template Mapping example: mappings

   Alternatively, the Template Mapping may be optimized as:

                         +--> Template Entry B
                         |
   Template Entry A   <--+--> Template Entry C
                         |
                         +--> Template Entry D

                    Template Mapping example: mappings

Please label this Figure in case someone wants to refer to it in future work. Also please add one line saying "Figure 3a shows stuff" so that the figure isn't orphaned.

The text immediately above Figure 2 says, "In this example, the Template Record received from the Exporter #1 is reused towards Collector #1, Collector #2, and Collector #3." So why is the template mapping not simply:

        Template Entry A <----> Template Entry A' 



   Note that all examples use Transport Sessions based on the SCTP
   protocol, as simplified use cases.  However, the protocol would be
   important in situations such as an Intermediate Conversion Process
   doing transport protocol conversion.

Clarify "protocol" = transport protocol, rather than IPFIX protocol.



4.1.1.  Template Mapping and Information Element Ordering

   In the situation where Original Exporters each export an (Options)
   Template to a single IPFIX Mediator, and the (Options) Template
   Record contains the same Information Elements but in different order,
   should the IPFIX Mediator maintain a Template Mapping with a single
   Export Template Record (see figure "Template Mapping and Ordering: a
   single Export Template Record") or should the IPFIX Mediator maintain
   multiple independent Template Records (see figure "Template Mapping
   and Ordering: multiple Export Template Record") before re-exporting
   to the Collector?

NO. Give them a simple name, eg "Figure 4" and "Figure 5".



           Template Entry A   <--+
                                 |
           Template Entry B   <--+--> Template Entry D
                                 |
           Template Entry C   <--+

      Template Mapping and Ordering: a single Export Template Record


           Template Entry A   <--+--> Template Entry D

           Template Entry B   <--+--> Template Entry E

           Template Entry C   <--+--> Template Entry F




Claise, et al.           Expires August 29, 2013               [Page 14]

Internet-Draft               IPFIX MED-PROTO               February 2013


      Template Mapping and Ordering: multiple Export Template Records

Label these figures, because they're referenced within this document.



   The answer depends whether the order of the Information Elements
   implies some specific semantic.  One of the guiding principles in
   IPFIX protocol specifications is that the semantic meaning of one
   Information Element doesn't depend on the value of the different
   Information Element.  However, there is one noticeable exception, as
   mentioned in [I-D.ietf-ipfix-protocol-rfc5101bis]:

Missing word, "is". BTW, where is this (often cited) principle actually stated?

s/the different/another/, or /any other/



   "Multiple Scope Fields MAY be present in the Options Template Record,
   in which case, the composite scope is the combination of the scopes.
   For example, if the two scopes are meteringProcessId and templateId,
   the combined scope is this Template for this Metering Process.  If a
   different order of Scope Fields would result in a Record having a
   different semantic meaning, then the order of Scope Fields MUST be
   preserved by the Exporting Process.  For example, in the context of
   PSAMP [RFC5476], if the first scope defines the filtering function,
   while the second scope defines the sampling function, the order of
   the scope is important.  Applying the sampling function first,
   followed by the filtering function, would lead to potentially
   different Data Records than applying the filtering function first,
   followed by the sampling function."

   If an IPFIX Mediator receives, from multiple Exporters, Template
   Records with identical Information Elements, but ordered differently,
   it SHOULD consider those Template Records as identical.

Almost: subject to metadata in options, eg flowKeyIndicator.



   If an IPFIX Mediator receives, from multiple Exporters, Options
   Template Records with identical and ordered Information Elements in
   the Scope fields, and with identical Information Elements, but
   ordered differently, in the non Scope fields, it SHOULD consider
   those Template Records as identical.

   If an IPFIX Mediator receives, from multiple Exporters, Options
   Template Records with identical Information Elements in the scope,
   but ordered differently, it MUST consider those Template Records as
   semantically different.

Basically scope == key fields, so this agrees with my assertion above.

(BTW, if we do IPFIX-2, then we should *only* have options templates, with zero or more scope fields. Think how much simpler that'd make all the drafts!)



4.2.  Creating New Templates at an IPFIX Mediator

   The second case is a situation where the IPFIX Mediator generates new
   (Options) Template Records as a result of the Intermediate Process.

As predicted, I already forgot that there was a first case.



   In this situation, the IPFIX Mediator doesn't need to maintain a
   Template Mapping, as it generates its own series of (Options)
   Template Records.  However, the following special case might still
   require a Template Mapping, i.e. a situation where the IPFIX
   Mediator, typically containing an Intermediate Conversion Process,



Claise, et al.           Expires August 29, 2013               [Page 15]

Internet-Draft               IPFIX MED-PROTO               February 2013


   Intermediate Aggregation Process, or Intermediate Anonymization
   Process in case of black-marker Anonymization [RFC6235], generates
   new (Options) Template Records based on what it receives from the
   Exporter(s), and based on the Intermediate Process function.  In such
   a case, it's important to keep the correlation between the received
   (Options) Template Records and exported Derived (Options) Template
   Records in the Template Mapping.  These Template Mappings would be
   kept as in Section 4.1, except that the exported Template would not
   be identical to the received Template.

It took me a while to parse this correctly. s/exported/the/ would help considerably.

"Derived (Options) Template" isn't defined.



4.3.  Handling Unknown Information Elements

   Depending on application requirements, Mediators which do not
   generate new Records SHOULD re-export values for unknown Information
   Elements, whether enterprise-specific Information Elements or
   Information Elements in the IANA IPFIX Information Element registry
   added since the Mediator was implemented or updated.  However, as
   there may be presence or ordering dependencies among the unknown
   Information Elements, the Mediator MUST NOT omit fields from such re-
   exported Records, or re-order any fields within the Records.

Add a reference for IANA's registry. BTW, it'd be nice to use a consistent phrase for that throughout all the WG drafts.

May a Mediator append fields? That too could lead to ambiguity, eg if any of the unknown fields is a bitmap describing the other fields, it wouldn't correctly describe any appended fields.



   Mediators which generate new Records, as in Section 4.2, SHOULD NOT
   use values of Information Elements they do not understand.  If they
   do pass such values, they MUST NOT pass values of unknown Informaiton
   Elements unless all such values are passed on in the original order
   in which they were received.

Typo.



   In any case, Mediators handling unknown Information Elements SHOULD
   log this fact, as it is likely that mediation of records containing
   unknown values will have unintended consequences.


5.  Preserving Original Observation Point Information

   Depending on the use case, the Collector in an Exporter - IPFIX
   Mediator - Collector structure may need to receive information about
   the Original Observation Point(s), otherwise it may wrongly conclude
   that the IPFIX Device exporting the Flow Records, i.e. the IPFIX
   Mediator, directly observed the packets that generated the Flow
   Records.  Two new Information Elements are introduced in the
   subsections below to address this use case:

Remove "in the subsections below". In the IANA section, I'll argue that it'd be better for all the new IEs to be in the IANA section.


   originalExporterIPv4Address and originalExporterIPv6Address.
   Practically, the Original Exporters will not exporting these

"will not be exporting"

What about the case of tiered Mediators? Perhaps the originalExporter*Address should be passed-through.


   Information Elements.  Therefore, the Intermediate Process SHOULD
   report the Original Observation Point(s) to the best of its
   knowledge.  Note that the Configuration Data Model for IPFIX and
   PSAMP [RFC6728] may help.

Help in what way?






Claise, et al.           Expires August 29, 2013               [Page 16]

Internet-Draft               IPFIX MED-PROTO               February 2013


   In the IPFIX Mediator, the Observation Point(s) may be represented
   by:

   o  A single Original Exporter (represented by the
      originalExporterIPv4Address or originalExporterIPv6Address
      Information Elements)

   o  A list of Original Exporters (represented by the
      originalExporterIPv4Address or originalExporterIPv6Address
      Information Elements).

s/the/a list of/



   o  Any combination or list of Information Elements representing
      Observation Points.  For example:

      *  A list of Original Exporter interface(s) (represented by the
         originalExporterIPv4Address or originalExporterIPv6Address, the
         ingressInterface and/or egressInterface Information Elements,
         respectively)

      *  A list of Original Exporter line card (represented by the
         originalExporterIPv4Address or originalExporterIPv6Address, the
         lineCardId Information Elements, respectively)

   Some Information Elements characterizing the Observation Point may be
   added.  For example, the flowDirection Information Element specifies
   the direction of the observation, and, as such, characterizes the
   Observation Point.

   Any combination of the above representations is possible.  For
   example, in case of an Intermediate Aggregation Process, an Original
   Observation Point could be composed of:

   exporterIPv4Address 192.0.2.1
   exporterIPv4Address 192.0.2.2,
     interface ethernet 0, direction ingress
     interface ethernet 1, direction ingress
     interface serial 1, direction egress
     interface serial 2, direction egress
   exporterIPv4Address 192.0.2.3,
     lineCardId 1, direction ingress

          Figure 4: Complex Observation Point Definition Example

This figure is orphaned. Add a line saying "Figure 4 shows some interesting stuff".



   If the Original Observation Point is composed of a list, then the
   IPFIX Structured Data [RFC6313] MUST be used to export it from the
   IPFIX Mediator.

Remove "the".



   The most generic way to export the Original Observation Point is to



Claise, et al.           Expires August 29, 2013               [Page 17]

Internet-Draft               IPFIX MED-PROTO               February 2013


   use a subTemplateMultiList, with the semantic "exactlyOneOf".  Taking
   the previous example, the following encoding can be used:

   Template Record 257: exporterIPv4Address
   Template Record 258: exporterIPv4Address,
                        basicList of ingressInterface, flowDirection
   Template Record 259: exporterIPv4Address, lineCardId, flowDirection

     Figure 5: Complex Observation Point Definition Example: Templates

This figure is orphaned. Above say, "the encoding in Figure 5 can be used:".



   The Original Observation Point is modeled with the Data Records
   corresponding to either Template Record 1, Template Record 2, or
   Template Record 3 but not more than one of these ("exactlyOneOf"
   semantic).  This implies that the Flow was observed at exactly one of
   the Observation Points reported.

   When an IPFIX Mediator receives Flow Records containing the Original
   Observation Point Information Element, i.e.
   originalExporterIPv6Address or originalExporterIPv4Address, the IPFIX

Why put IPv6 first, before IPv4? This is inconsistent with earlier usage.


   Mediator SHOULD NOT modify its value(s) when composing new Flow
   Records in the general case.  Known exceptions include anonymization
   per [RFC6235] section 7.2.4 and an Intermediate Correlation Process
   rewriting addresses across NAT.  In other words, the Original
   Observation Point should not be replaced with the IPFIX Mediator
   Observation Point.  The daisy chain of (Exporter, Observation Point)
   representing the path the Flow Records took from the Exporter to the
   top Collector in the Exporter - IPFIX Mediator(s) - Collector
   structure model is out of the scope of this specification.

5.1.  originalExporterIPv4Address Information Element

   Description:   The IPv4 address used by the Exporting Process on an
      Original Exporter, as seen by the Collecting Process on an IPFIX
      Mediator.  Used to provide information about the Original
      Observation Points to a downstream Collector.

   Data Type:   ipv4Address

   ElementId:   TBD1

5.2.  originalExporterIPv6Address Information Element

   Description:   The IPv6 address used by the Exporting Process on an
      Original Exporter, as seen by the Collecting Process on an IPFIX
      Mediator.  Used to provide information about the Original
      Observation Points to a downstream Collector.





Claise, et al.           Expires August 29, 2013               [Page 18]

Internet-Draft               IPFIX MED-PROTO               February 2013


   Data Type:   ipv6Address

   ElementId:   TBD2

In the IANA section, I'll argue that it'd be better for all the new IEs to be in the IANA section.




6.  Managing Observation Domain IDs

   In any case, the Observation Domain ID of any IPFIX Message

"In any case" probably worked when this text followed directly from some previous argument. However, it seems out of place here. It could be dropped with no loss of meaning.


   containing Flow Records relevant to no particular Observation Domain,
   or to multiple Observation Domains, MUST have an Observation Domain
   ID of 0, as in Section 3 above, and section 3.1 of
   [I-D.ietf-ipfix-protocol-rfc5101bis].

So are we saying that OD zero has a special meaning? Should existing exporters avoid using OD zero in order to avoid confusing Collectors?



   IPFIX Mediators that do not change (Options) Template Records MUST
   maintain a Template Mapping, as detailed in Section 4.1, to ensure
   that the combination of Observation Domain IDs and Template IDs do
   not collide on export.

   For IPFIX Mediators that export New (Options) Template Records, as in
   Section 4.2, there are two options for Observation Domain ID
   management.  The first and simplest of these is to completely
   decouple exported Observation Domain IDs from received Observation
   Domain IDs; the IPFIX Mediator, in this case, comprises its own set
   of Observation Domain(s) independent of the Observation Domain(s) of
   the Original Exporters.

   The second option is to provide or maintain a Template Mapping for
   received (Options) Template Records and exported inferred (Options)
   Template Records, along with the appropriate Observation Domain IDs
   per Transport Session, which ensures that the combination of
   Observation Domain IDs and Template IDs do not collide on export.

   In some cases where the IPFIX Message Header can't contain a
   consistent Observation Domain for the entire IPFIX Message, but the
   Flow Records exported from the IPFIX Mediator should anyway contain
   the Observation Domain of the Original Exporter, the (Options)
   Template Record must contain the originalObservationDomainId

Specified in s6.1 below.


   Information Element.  When an IPFIX Mediator receives Flow Records
   containing the originalObservationDomainId Information Element, the
   IPFIX Mediator MUST NOT modify its value(s) when composing new Flow
   Records with the originalObservationDomainId Information Element.

6.1.  originalObservationDomainId Information Element








Claise, et al.           Expires August 29, 2013               [Page 19]

Internet-Draft               IPFIX MED-PROTO               February 2013


   Description:   The Observation Domain ID reported by the Exporting
      Process on an Original Exporter, as seen by the Collecting Process
      on an IPFIX Mediator.  Used to provide information about the
      Original Observation Domain to a downstream Collector.

   Data Type:   unsigned32

   Data Type Semantics:   identifier

   ElementId:   TBD3

Is this definition sufficient for the revised IANA registry format?




7.  Timing Considerations

   The IPFIX Message Header "Export Time" field is the time in seconds
   since 0000 UTC Jan 1, 1970, at which the IPFIX Message leaves the
   IPFIX Mediator.  However, in the specific case of an IPFIX Mediator
   containing an Intermediate Conversion Process, the IPFIX Mediator MAY
   keep the export time received from the incoming Transport Session.

Again, although I know exactly what you're saying here, others might not. I suggest s/keep/use/.



   It is RECOMMENDED that IPFIX Mediators handle time using absolute
   timestamps (e.g. flowStartSeconds, flowStartMilliseconds,
   flowStartNanoseconds), which are specified relative to the UNIX epoch
   (00:00 UTC 1 Jan 1970), where possible, rather than relative
   timestamps (e.g. flowStartSysUpTime, flowStartDeltaMicroseconds),
   which are specified relative to protocol structures such as system
   initialization or message export time.

   The latter are difficult to manage for two reasons.  First, they
   require constant translation, as the system initialization time of an
   intermediate system and the export time of an intermediate message
   will change across mediation operations.  Further, relative
   timestamps introduce range problems.  For example, when using the
   flowStartDeltaMicroseconds and flowEndDeltaMicroseconds Information
   Elements [iana-ipfix-assignments], the Data Record must be exported
   within a maximum of 71 minutes after its creation.  Otherwise, the
   32-bit counter would not be sufficient to contain the flow start time
   offset.  Those time constraints might be incompatible with some of
   the application requirements of some Intermediate Processes.

   Intermediate Processes MUST NOT assume that received records appear
   in flowStartTime, flowEndTime, or observationTime order.  An
   Intermediate Process processing timing information (e.g., an
   Intermediate Aggregation Process) MAY ignore records that are
   significantly out of order, in order to meet application-specific
   state and latency requirements, but SHOULD report that records were
   dropped.




Claise, et al.           Expires August 29, 2013               [Page 20]

Internet-Draft               IPFIX MED-PROTO               February 2013


   When an Intermediate Process aggregates information from different
   Flow Records, the timestamps on exported records SHOULD be the
   minimum of the start times and the maximum of the end times in the
   general case.  However, if the Flow Records do not overlap, i.e. if
   there is a time gap between the times in the Flow Records, then the
   report may be inaccurate.  The IPFIX Mediator is only reporting what
   it knows, on the basis of the information made available to it - and
   there may not have been any data to observe during the gap.  Then
   again, if there is an overlap in timestamps, there's the potential of
   double-accounting: different Observation Points may have observed the
   same traffic simultaneously.  Therefore, as there is not a single
   rule that fits all different situations, a complete specification of
   the precise rules of applying Flow Record timestamps at IPFIX
   Mediators is out of the scope of this document.

Too hard and can't be bothered? :-(



   Note that [I-D.ietf-ipfix-a9n] provides additional specifications for
   handling of timestamps at an Intermediate Aggregation Process.


8.  Transport Considerations

   SCTP [RFC4960] using the PR-SCTP extension specified in [RFC3758]
   MUST be implemented by all compliant IPFIX Mediator implementations.
   TCP [RFC0793] MAY also be implemented by IPFIX Mediator compliant
   implementations.  UDP [RFC0768] MAY also be implemented by compliant
   IPFIX Mediator implementations.  Transport-specific considerations
   for IPFIX Exporters as specified in sections 8.3, 8.4, 9.1, 9.2, and
   10 of [I-D.ietf-ipfix-protocol-rfc5101bis] apply to IPFIX Mediators
   as well.

   SCTP SHOULD be used in deployments where IPFIX Mediators and
   Collectors are communicating over links that are susceptible to
   congestion.  SCTP is capable of providing any required degree of
   reliability.  TCP MAY be used in deployments where IPFIX Mediators
   and Collectors communicate over links that are susceptible to
   congestion, but SCTP is preferred due to its ability to limit back
   pressure on Exporters and its message versus stream orientation.  UDP
   MAY be used, although it is not a congestion-aware protocol.
   However, in this case, the IPFIX traffic between IPFIX Mediator and
   Collector MUST run in an environment where IPFIX traffic has been
   provisioned for, or is contained through some other means.

Explain "contained"?




9.  Collecting Process Considerations

   Any Collecting Process compliant with
   [I-D.ietf-ipfix-protocol-rfc5101bis] can receive IPFIX Messages from
   an IPFIX Mediator.  If the IPFIX Mediator uses IPFIX Structured Data



Claise, et al.           Expires August 29, 2013               [Page 21]

Internet-Draft               IPFIX MED-PROTO               February 2013


   [RFC6313] to export Original Exporter Information as in Section 5,
   the Collecting Process MUST support [RFC6313].


10.  Specific Reporting Requirements

   IPFIX provides Options Templates for the reporting on the reliability

"for reporting the reliability"


   of processes within the IPFIX Architecture.  As each Mediator
   includes at least one IPFIX Exporting Process, they SHOULD use the
   Exporting Process Reliability Statistics Options Template, as
   specified in [I-D.ietf-ipfix-protocol-rfc5101bis].

   Analogous to the Metering Process Reliability Statistics Options
   Template, also specified in [I-D.ietf-ipfix-protocol-rfc5101bis],
   Mediators SHOULD implement the Intermediate Process Reliability
   Statistics Options Template, specified in the subsection below.

Which subsection? Add an xref.



   The Flow Keys Options Template, as specified in
   [I-D.ietf-ipfix-protocol-rfc5101bis], may require special handling at
   an IPFIX Mediator as described below.

Described where? Add an xref.



   In addition, each Intermediate Process may have its own specific
   reporting requirements (e.g.  Anonymization Records as in [RFC6235],
   or the Aggregation Counter Distribution Options Template as in
   [I-D.ietf-ipfix-a9n]); these SHOULD be implemented as necessary as
   described in the specification for each Intermediate Process.

10.1.  Intermediate Process Reliability Statistics Template

   The Intermediate Process Statistics Options Template specifies the
   structure of a Data Record for reporting Intermediate Process
   statistics.  It SHOULD contain the following Information Elements;
   the intermediateProcessId Information Element is defined in
   Section 10.3, and the ignoredRecordTotalCount Information Element is
   defined in Section 10.4:

   +-------------------------+-----------------------------------------+
   | IE                      | Description                             |
   +-------------------------+-----------------------------------------+
   | observationDomainId     | An identifier of the Observation Domain |
   | [scope]                 | (of messages exported by this           |
   |                         | Mediator), locally unique to the        |
   |                         | Intermediate Process, to which this     |
   |                         | statistics record applies.              |
   | intermediateProcessId   | An identifier for the Intermediate      |
   | [scope]                 | Process to which this statistics record |
   |                         | applies.                                |

The intermediateProcessId is essentially meaningless outside the Mediator, so what is the value in exporting it? ie, what exactly is its purpose at the collector?






Claise, et al.           Expires August 29, 2013               [Page 22]

Internet-Draft               IPFIX MED-PROTO               February 2013


   | ignoredRecordTotalCount | The total number of Data Records        |
   |                         | received but not processed by the       |
   |                         | Intermediate Process.                   |
   | time first record       | The timestamp of the first record that  |
   | ignored                 | was ignored by the Intermediate         |
   |                         | Process.  For Data Records containing   |
   |                         | timestamp ranges, this SHOULD be taken  |
   |                         | from the start timestamp of the range;  |
   |                         | for data records containing no timing   |
   |                         | information, this SHOULD be taken from  |
   |                         | the Export Time in the message header   |
   |                         | of the containing IPFIX Message.  For   |

Is this the incoming IPFIX Message? So the Intermediate Process has to examine each incoming Message in some detail, even though it's ignoring them? How do you expect that to work?
Also, this supposes clock synchronisation.


   |                         | this timestamp, any of the following    |
   |                         | timestamp can be used:                  |
   |                         | observationTimeSeconds,                 |
   |                         | observationTimeMilliseconds,            |
   |                         | observationTimeMicroseconds, or         |
   |                         | observationTimeNanoseconds.             |
   | time last record        | The timestamp of the last record that   |
   | ignored                 | was ignored by the Intermediate         |
   |                         | Process.  For Data Records containing   |
   |                         | timestamp ranges, this SHOULD be taken  |
   |                         | from the end timestamp of the range;    |
   |                         | for data records containing no timing   |
   |                         | information, this SHOULD be taken from  |
   |                         | the Export Time in the message header   |
   |                         | of the containing IPFIX Message.  For   |
   |                         | this timestamp, any of the following    |
   |                         | timestamp can be used:                  |
   |                         | observationTimeSeconds,                 |
   |                         | observationTimeMilliseconds,            |
   |                         | observationTimeMicroseconds, or         |
   |                         | observationTimeNanoseconds.             |
   +-------------------------+-----------------------------------------+

Pleaseaddsomewhitespacetomakethetablereadable.



10.2.  Flow Key Options Template

   The Flow Keys Option Template specifies the structure of a Data
   Record for reporting the Flow Keys of reported Flows.  A Flow Keys
   Data Record extends a particular Template Record that is referenced
   by its templateId identifier.  The Template Record is extended by
   specifying which of the Information Elements contained in the
   corresponding Data Records describe Flow properties that serve as
   Flow Keys of the reported Flow.  This Options Template is defined in
   section 4.4 of [I-D.ietf-ipfix-protocol-rfc5101bis], and SHOULD be
   used by Mediators for export as defined there.

   When an Intermediate Process exports Data Records containing



Claise, et al.           Expires August 29, 2013               [Page 23]

Internet-Draft               IPFIX MED-PROTO               February 2013


   different Flow Keys from those received from the Original Exporter,
   and the Original Exporter sent a Flow Keys Options record to the
   IPFIX Mediator, the IPFIX Mediator MUST export a Flow Keys Options
   record defining the the new set of Flow Keys.

10.3.  intermediateProcessId Information Element

   Description:   An identifier of an Intermediate Process that is
      unique per IPFIX Device.  Typically, this Information Element is
      used for limiting the scope of other Information Elements.  Note
      that process identifiers may be assigned dynamically; ie., and
      Intermediate Process may be re-started with a different ID.

s/and/an/



   Data Type:   unsigned32

   Data Type Semantics:   identifier

   ElementId:   TBD4

10.4.  ignoredRecordTotalCount Information Element

   Description:   The total number of received Data Records that the
      Intermediate Process did not process since the (re-)initialization
      of the Intermediate Process; includes only Data Records not
      examined or otherwise handled by the Intermediate Process due to
      resource constraints, not Data Records which were examined or
      otherwise handled by the Intermediate Process but which merely do
      not contribute to any exported Data Record due to the operations
      performed by the Intermediate Process.

If a mediator is resource constrained, how can it accurately report this figure?



   Data Type:   unsigned64

   Data Type Semantics:   totalCounter

   ElementId:   TBD5

Are the definitions in 10.3 and 10.4 sufficient for the revised IANA registry format?




11.  Configuration Management

   In general, using IPFIX Mediators to combine information from
   multiple Original Exporters requires a consistent configuration of
   the Metering Processes behind these Original Exporters.  The details
   of this consistency are specific to each Intermediate Process.
   Consistency of configuration should be verified out of band, with the
   MIB modules ([RFC6615] and [RFC6727]) or with the Configuration Data
   Model for IPFIX and PSAMP [RFC6728]

Missing final period.







Claise, et al.           Expires August 29, 2013               [Page 24]

Internet-Draft               IPFIX MED-PROTO               February 2013


12.  Security Considerations

   As they act as both IPFIX Collecting Processes and Exporting
   Processes, the Security Considerations for IPFIX Protocol

"for the IPFIX Protocol"


   [I-D.ietf-ipfix-protocol-rfc5101bis] also apply to IPFIX Mediators.
   The Security Considerations for IPFIX Files [RFC5655] also apply to
   IPFIX Mediators that write IPFIX Files or use them for internal
   storage.  However, there are a few specific considerations that IPFIX
   Mediator implementations must also take into account.

   By design, IPFIX Mediators are "men-in-the-middle": they intercede in
   the communication between an Original Exporter (or another upstream
   IPFIX Mediator) and a downstream Collecting Process.  This has two
   important implications for the level of confidentiality provided
   across an IPFIX Mediator, and the ability to protect data integrity
   and Original Exporter authenticity across an IPIIX Mediator.  These
   are addressed in more detail in the Security Considerations for IPFIX
   Mediators in [RFC6183].

Typo.



   Note that, while IPFIX Mediators can use the exporterCertificate and
   collectorCertificate Information Elements defined in [RFC5655] as
   described in section 9.3 of [RFC6183] to export information about
   X.509 identities in upstream TLS-protected Transport Sessions, this
   mechanism cannot be used to provide true end-to-end assertions about
   a chain of IPFIX Mediators: any IPFIX Mediator in the chain can
   simply falsify the information about upstream Transport Sessions In
   situations where information about the chain of mediation is
   important, it must be determined out of band.

Missing period: s/Transport Sessions In/Transport Sessions. In/


 


13.  IANA Considerations

   This document specifies n new IPFIX Information Elements,

s/n/some/, or delete it.


   originalExporterIPv4Address in Section 5.1,
   originalExporterIPv6Address in Section 5.2, and
   originalObservationDomainId in Section 6.1, to be added to the IPFIX
   Information Element registry [iana-ipfix-assignments].  [IANA NOTE:
   please add the three Information Elements as specified in the
   references subsections, and change TBD1, TBD2, and TBD3 in this
   document to reflect the assigned identifiers.]

Also intermediateProcessId (TBD4) in 10.4 and ignoredRecordTotalCount (TBD5) in 10.5.

Rather than having the new IEs sprinkled througout the document, I'd prefer to have all the definitions consolidated here in the IANA section, with xrefs from the text.
There's no advantage to defining them inline. As you see, the definitions are easily overlooked.




14.  Acknowledgments

   We would like to thank the IPFIX contributors, specifically Paul
   Aitken for his thorough review and Rahul Patel for his feedback and

s/review/reviews/

P.


   comments.  This work is materially supported by the European Union
   Seventh Framework Programme under grant agreement 257315 (DEMONS).



Claise, et al.           Expires August 29, 2013               [Page 25]

Internet-Draft               IPFIX MED-PROTO               February 2013


15.  References

15.1.  Normative References

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              August 1980.

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, September 1981.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3758]  Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
              Conrad, "Stream Control Transmission Protocol (SCTP)
              Partial Reliability Extension", RFC 3758, May 2004.

   [RFC4960]  Stewart, R., "Stream Control Transmission Protocol",
              RFC 4960, September 2007.

   [RFC5655]  Trammell, B., Boschi, E., Mark, L., Zseby, T., and A.
              Wagner, "Specification of the IP Flow Information Export
              (IPFIX) File Format", RFC 5655, October 2009.

   [RFC6313]  Claise, B., Dhandapani, G., Aitken, P., and S. Yates,
              "Export of Structured Data in IP Flow Information Export
              (IPFIX)", RFC 6313, July 2011.

   [RFC6615]  Dietz, T., Kobayashi, A., Claise, B., and G. Muenz,
              "Definitions of Managed Objects for IP Flow Information
              Export", RFC 6615, June 2012.

   [RFC6727]  Dietz, T., Claise, B., and J. Quittek, "Definitions of
              Managed Objects for Packet Sampling", RFC 6727,
              October 2012.

   [RFC6728]  Muenz, G., Claise, B., and P. Aitken, "Configuration Data
              Model for the IP Flow Information Export (IPFIX) and
              Packet Sampling (PSAMP) Protocols", RFC 6728,
              October 2012.

   [I-D.ietf-ipfix-protocol-rfc5101bis]
              Claise, B. and B. Trammell, "Specification of the IP Flow
              Information eXport (IPFIX) Protocol for the Exchange of
              Flow Information", draft-ietf-ipfix-protocol-rfc5101bis-06
              (work in progress), February 2013.

   [I-D.ietf-ipfix-information-model-rfc5102bis]



Claise, et al.           Expires August 29, 2013               [Page 26]

Internet-Draft               IPFIX MED-PROTO               February 2013


              Claise, B. and B. Trammell, "Information Model for IP Flow
              Information eXport (IPFIX)",
              draft-ietf-ipfix-information-model-rfc5102bis-10 (work in
              progress), February 2013.

   [I-D.ietf-ipfix-flow-selection-tech]
              D'Antonio, S., Zseby, T., Henke, C., and L. Peluso, "Flow
              Selection Techniques",
              draft-ietf-ipfix-flow-selection-tech-13 (work in
              progress), February 2013.

   [I-D.ietf-ipfix-a9n]
              Trammell, B., Wagner, A., and B. Claise, "Flow Aggregation
              for the IP Flow Information Export (IPFIX) Protocol",
              draft-ietf-ipfix-a9n-08 (work in progress), November 2012.

15.2.  Informative References

   [RFC3917]  Quittek, J., Zseby, T., Claise, B., and S. Zander,
              "Requirements for IP Flow Information Export (IPFIX)",
              RFC 3917, October 2004.

   [RFC3954]  Claise, B., "Cisco Systems NetFlow Services Export Version
              9", RFC 3954, October 2004.

   [RFC5470]  Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek,
              "Architecture for IP Flow Information Export", RFC 5470,
              March 2009.

   [RFC5472]  Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP
              Flow Information Export (IPFIX) Applicability", RFC 5472,
              March 2009.

   [RFC5476]  Claise, B., Johnson, A., and J. Quittek, "Packet Sampling
              (PSAMP) Protocol Specifications", RFC 5476, March 2009.

   [RFC5610]  Boschi, E., Trammell, B., Mark, L., and T. Zseby,
              "Exporting Type Information for IP Flow Information Export
              (IPFIX) Information Elements", RFC 5610, July 2009.

   [RFC5982]  Kobayashi, A. and B. Claise, "IP Flow Information Export
              (IPFIX) Mediation: Problem Statement", RFC 5982,
              August 2010.

   [RFC6183]  Kobayashi, A., Claise, B., Muenz, G., and K. Ishibashi,
              "IP Flow Information Export (IPFIX) Mediation: Framework",
              RFC 6183, April 2011.




Claise, et al.           Expires August 29, 2013               [Page 27]

Internet-Draft               IPFIX MED-PROTO               February 2013


   [RFC6235]  Boschi, E. and B. Trammell, "IP Flow Anonymization
              Support", RFC 6235, May 2011.

   [iana-ipfix-assignments]
              Internet Assigned Numbers Authority, "IP Flow Information
              Export Information Elements
              (http://www.iana.org/assignments/ipfix/ipfix.xml)".

   [POSIX.1]  IEEE, "IEEE 1003.1-2008 - IEEE Standard for Information
              Technology - Portable Operating System Interface".


Authors' Addresses

   Benoit Claise
   Cisco Systems, Inc.
   De Kleetlaan 6a b1
   1831 Diegem
   Belgium

   Phone: +32 2 704 5622
   Email: bclaise@cisco.com


   Atsushi Kobayashi
   NTT Information Sharing Platform Laboratories
   3-9-11 Midori-cho
   Musashino-shi, Tokyo 180-8585
   Japan

   Phone: +81 422 59 3978
   Email: akoba@nttv6.net


   Brian Trammell
   Swiss Federal Institute of Technology Zurich
   Gloriastrasse 35
   8092 Zurich
   Switzerland

   Phone: +41 44 632 70 13
   Email: trammell@tik.ee.ethz.ch









Claise, et al.           Expires August 29, 2013               [Page 28]

--------------030608080101070204090503-- From n.brownlee@auckland.ac.nz Thu Mar 14 19:28:26 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA5911E80D5 for ; Thu, 14 Mar 2013 19:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nooImSkO+Fdt for ; Thu, 14 Mar 2013 19:28:25 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id 1CEB121F8F2F for ; Thu, 14 Mar 2013 19:28:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1363314505; x=1394850505; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=N5X23xeUiamZlSxRS+XxS3JgkYe8U+q1yNHZRKX3nMg=; b=jLmAXAp/99TRg3V0SY+VtXVn8zB3yL5b49hwU5ZeAhZXTYe/xAJD0wcd Lcdn2yHHka5n9mjwhwbSgvYeyVXHEJg64w88HHJdbqN8G1Za95TKFgQX5 eRTkxDLiR/4UA05FhBHNW1ZpUD7IxeYo0S/5m5ODRSZTLP4iETVqRMVsz s=; X-IronPort-AV: E=Sophos;i="4.84,849,1355050800"; d="scan'208";a="175584271" X-Ironport-HAT: None - $RELAY-AUTH X-Ironport-Source: 130.129.70.60 - Outgoing - Outgoing-SSL Received: from dhcp-463c.meeting.ietf.org (HELO [130.129.70.60]) ([130.129.70.60]) by mx2-int.auckland.ac.nz with ESMTP; 15 Mar 2013 15:28:23 +1300 Message-ID: <51428743.3060101@auckland.ac.nz> Date: Thu, 14 Mar 2013 19:28:19 -0700 From: Nevil Brownlee User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: IPFIX list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] DRAFT minutes for IPFIX meeting in Orlando X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 02:28:26 -0000 Hi all: Here are the DRAFT minutes, please send me any corrections or improvements. Cheers, Nevil One-para summary: IPFIX WG meeting in Orlando Our three current chartered drafts, Link layer IEs, MIB Variable Export and Mediation Protocol are close to completion. Several possible new work items were discussed: + Extended Field Specifier Fields (EFSF) as a way to handle 'decorators' in Information Elements, e.g. the layer of an mplsLabelSection. + A textual representation for Information Elements, making it easier to use the IPFIX Information Model for flows in text-based environments. + Mechanisms for moving Private Enterprise IEs into the IANA IPFIX IE Registry, so that Collectors can recognise them more easily. These will be discussed further on the IPFIX list. Minutes of the IPFIX meeting at IETF 86 in Orlando About 16 people present, plus 4 on jabber Scribes: Chris Inacio, Nevil Brownlee Meeting chair: Nevil Brownlee Nevil opened the meeting, and gave the IPFIX status update: - Flow Selection Techniques now in AD Follow-up, -14 version published 10 Mar 13 - IE Doctors Approved 4 Dec 12, in RFC Editor queue, MISSREF on 5101bis Initial ie-doctors team is Brian Trammell, Paul Aitken, Juergen Quittek and Nevil Brownlee - IPFIX Information Model, 5102bis Approved 13 Feb 13, MISSREF on 5101bis - IPFIX Protocol, 5101bis Submitted to IESG, 27 Feb 13 Paul Aitken presented (via Meetecho) the Link Layer IEs draft: - Revised taking account of IEEE 802 feedback, second WGLC finished 10 Mar 13 - Pat Thaler (IEEE 802 chair) reviewed the draft during WGLC. She repeated her comments for the meeting: . E-TAGs are internal to 802.1 bridges, therefore they should not be included in this draft (or in an IPFIX IE). . Similarly, the S-Channel is used for the links between bridges; this doesn't seem to be too helpful. - Authors will publish another revision, the draft should then be ready to submit. Pat agreed to review the new version. Benoit Claise asked how the IE-Doctors will work? IANA need to be asked for advice during WGLC so that they can ask the Designated Experts; that way IESG will know that any IANA problems are resolved before a draft is submitted to IESG. Paul presented the MIB Variable Export draft: - Issues raised by version -02 have been resolved, but there are still many issues to be resolved. - The draft proposes to introduce Extended Field Specifier Fields (EFSF), with 'decorators' that could, for example, be used to handle Unobserved Fields. - EFSF generated a long discussion - it could be used for many other things; this concept could provide a new, elegant and concise way of handling attributes of particular IEs. - Consensus in the meeting was that . EFSF is a new direction for IPFIX - it's really IPFIXv2. . We need to finish the MIB Variable Export draft as soon as possible. . Paul will remove it from this draft, making sure the draft will still work in IPFIXv2. . The WG should adopt this as a work item. That will require a new charter; meanwhile work on it can proceed on the IPFIX list. - Please send your comments on this to the list! Brian Trammell presented the IPFIX Mediation Protocol draft: - -03 and -04 revisions have been published since IETF 84 in Vancouver. - All open issues now have a proposed solution. - Should be ready for WGLC after one more round of reviews; Paul will review it (Brian will review MIB Export). Ram Krishnan presented his draft on Flow-Aware Packet Sampling - A vigorous discussion focused on two aspects: . There's a lot of IPR for sampling techniques, need to make sureIPFIX one-para summary that any IPR related to this draft is declared. . Although it's an interesting technique, it doesn't put forward a clear use case, so it doesn't seem to require work within the IPFIX WG. - Consensus in the room was that it needs more work to make it clear why IPFIX should work on it. Brian Trammell presented his draft on a Textual Representations for Abstract Data Types: - IPFIX is not text-based, this would provide a way to describe Information Elements by name, much like YAML or JSON. - This seems an interesting idea; please continue discussing it on the IPFIX list. Chris Inacio presented his draft on Private Enterprise Information Elements (PENIE) - This proposes a simple mechanism for setting up IE Registries - No consensus on it was reached. Paul presented his Equivalent Information Elements draft: - This draft addresses the question "how to change a PENIE into an IANA-registered IE? - It proposes that Exporters should send Equivalence Information to Collectors. - Brian and Andrew Feren commented that we now have two solutions to this problem, 'PENIE' and 'Equivalent IEs.' Perhaps we should implement both? - Benoit suggested asking Collector implementors which would work best for them. We need a brief summary of the pros and cons of each; Paul's slides do that for 'Equivalent IEs,' Chris will make a similar list for PENIE. - This could be an item in a new WG charter. There was no Other Business. The meeting finished at 1105 -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From bclaise@cisco.com Mon Mar 18 08:59:25 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8010221F8D5D for ; Mon, 18 Mar 2013 08:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.228 X-Spam-Level: X-Spam-Status: No, score=-9.228 tagged_above=-999 required=5 tests=[AWL=1.371, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDODco2xkC+2 for ; Mon, 18 Mar 2013 08:59:24 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 86DD921F8B7E for ; Mon, 18 Mar 2013 08:59:24 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r2IFxMWE016749; Mon, 18 Mar 2013 16:59:22 +0100 (CET) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r2IFx1HO013244; Mon, 18 Mar 2013 16:59:12 +0100 (CET) Message-ID: <514739B1.2090704@cisco.com> Date: Mon, 18 Mar 2013 16:58:41 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: draft-ietf-ipfix-flow-selection-tech@tools.ietf.org References: <20130311011518.7665.38589.idtracker@ietfa.amsl.com> In-Reply-To: <20130311011518.7665.38589.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] New Version Notification - draft-ietf-ipfix-flow-selection-tech-14.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 15:59:25 -0000 Dear authors, Thanks for addressing my feedback. This draft is now moving to IETF LC. Regards, Benoit > A new version (-14) has been submitted for draft-ietf-ipfix-flow-selection-tech: > http://www.ietf.org/internet-drafts/draft-ietf-ipfix-flow-selection-tech-14.txt > > Sub state has been changed to AD Followup from Revised ID Needed > > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/ > > Diff from previous version: > http://www.ietf.org/rfcdiff?url2=draft-ietf-ipfix-flow-selection-tech-14 > > IETF Secretariat. > > > From iesg-secretary@ietf.org Mon Mar 18 09:55:58 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B28F921F8FD7; Mon, 18 Mar 2013 09:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DjwpACGF2ozA; Mon, 18 Mar 2013 09:55:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AA9B521F8B64; Mon, 18 Mar 2013 09:55:31 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130318165531.28759.42024.idtracker@ietfa.amsl.com> Date: Mon, 18 Mar 2013 09:55:31 -0700 Cc: ipfix@ietf.org Subject: [IPFIX] Last Call: (Flow Selection Techniques) to Proposed Standard X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 16:55:58 -0000 The IESG has received a request from the IP Flow Information Export WG (ipfix) to consider the following document: - 'Flow Selection Techniques' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-04-01. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Intermediate Flow Selection Process is the process of selecting a subset of Flows from all observed Flows. The Intermediate Flow Selection Process may be located at an IPFIX Exporter, Collector, or within an IPFIX Mediator. It reduces the effort of post-processing Flow data and transferring Flow Records. This document describes motivations for using the Intermediate Flow Selection process and presents Intermediate Flow Selection techniques. It provides an information model for configuring Intermediate Flow Selection Process techniques and discusses what information about an Intermediate Flow Selection Process should be exported. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1540/ From iesg-secretary@ietf.org Mon Mar 18 09:55:58 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E52A021F8FD8 for ; Mon, 18 Mar 2013 09:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQ2-GBSa1q0k; Mon, 18 Mar 2013 09:55:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C02FF21F8FC0; Mon, 18 Mar 2013 09:55:31 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IANA X-Test-IDTracker: no X-IETF-IDTracker: 4.43 X-IETF-Draft-string: draft-ietf-ipfix-flow-selection-tech X-IETF-Draft-revision: 14 Message-ID: <20130318165531.28759.52346.idtracker@ietfa.amsl.com> Date: Mon, 18 Mar 2013 09:55:31 -0700 Cc: ipfix@ietf.org Subject: [IPFIX] Last Call: (Flow Selection Techniques) to Proposed Standard X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: noreply@ietf.org List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 16:55:59 -0000 The IESG has received a request from the IP Flow Information Export WG (ipfix) to consider the following document: - 'Flow Selection Techniques' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-04-01. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Intermediate Flow Selection Process is the process of selecting a subset of Flows from all observed Flows. The Intermediate Flow Selection Process may be located at an IPFIX Exporter, Collector, or within an IPFIX Mediator. It reduces the effort of post-processing Flow data and transferring Flow Records. This document describes motivations for using the Intermediate Flow Selection process and presents Intermediate Flow Selection techniques. It provides an information model for configuring Intermediate Flow Selection Process techniques and discusses what information about an Intermediate Flow Selection Process should be exported. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1540/ From bclaise@cisco.com Wed Mar 20 01:25:36 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6E921F874E for ; Wed, 20 Mar 2013 01:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.108 X-Spam-Level: X-Spam-Status: No, score=-10.108 tagged_above=-999 required=5 tests=[AWL=0.490, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RjbYCFtkMOTB for ; Wed, 20 Mar 2013 01:25:35 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 94D2821F86FA for ; Wed, 20 Mar 2013 01:25:34 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r2K8PUKM002086 for ; Wed, 20 Mar 2013 09:25:30 +0100 (CET) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r2K8OxcU004430; Wed, 20 Mar 2013 09:25:05 +0100 (CET) Message-ID: <51497242.80407@cisco.com> Date: Wed, 20 Mar 2013 09:24:34 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Rahul Patel (rahulp)" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------080308010302080702000107" Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] Feedback: regarding draft-ietf-ipfix-mediation-protocol X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 08:25:36 -0000 This is a multi-part message in MIME format. --------------080308010302080702000107 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Rahul, Thanks for your review. See in line. > > > Few comments. > > 1. Page 8: > 1. The difference between "Intermediate Selection Process" and > "Intermediate Flow Selection Process" is not clear. Is the > first one selecting record purely on matching content (value > of the fields) in the record and the second one selecting on > matching attributes of the fields that are not part of the > record in *addition* to matching content in the record? An > example would help here. > Granted, this is difficult to understand from the definitions only. There is some history behind these two separate definitions. Anyway, you get it right from your message above. I was thinking to add to a section 2.1 "Differences between Intermediate Selection Process and Intermediate Flow Selection Process" in the draft-ietf-ipfix-mediation-protocol draft. However, thinking about it some more, this section should really be done in draft-ietf-ipfix-flow-selection-tech-14, to avoid some more confusion. There is already section 3. "Difference between Intermediate Flow Selection Process and Packet Selection". Some more text should be added on the difference between Intermediate Selection Process and Intermediate Flow Selection Process When created, draft-ietf-ipfix-mediation-protocol will refer to that new section. > 1. > 1. Also in the example " e.g., Filteringonly records from a given > network to a given Collector" - Does "given network" means > "source-ip/source-prefix of the exporter"?. > It means matching the flow records to a certain prefix/AS/you-name-it, and exporting those matched flow records to an exporter. See for example, section 6.1 in RFC 6183 This could be explained better in the new section in draft-ietf-ipfix-flow-selection-tech (See previous point) > > 1. > 2. Page 13: > 1. "Figure B" A typo? Should it be "Figure 3"? > Corrected. > > 1. > > > General > > * On correlation process – how to correlate, what cannot be > correlated, etc – is this out of scope of this draft? For example, > Mediator A receives metric N1 and N2 per 5-tuple from exporter X > and metric N3 and N4 per 5-tuple from exporter Y. Mediator A can > easily correlate and exporter N1, N2, N3 and N4 to another > collector C. If the key fields are not matching or one is subset > of other then data can either not be correlated or can be > represented in a different way. Most likely all of this out of > scope of this document but just wanted to check. > Yes, it's out of scope. The specific techniques are described/specified in the respective drafts. Documents specifying the operations of specific Intermediate Processes cover the operation of these Processes within the IPFIX Mediator framework, and comply with the specifications given in this document; they may additionally specify the operation of the process independently, outside the context of an IPFIX Mediator, when this is appropriate. The details of specific Intermediate Processes, when these have additional export specifications (e.g., metadata about the intermediate processing conveyed through IPFIX Options Templates), are each treated in their own document. As of today, these documents are: 1. "IP Flow Anonymization Support", [RFC6235 ], which describes Anonymization techniques for IP flow data and the export of Anonymized data using the IPFIX protocol. 2. "Flow Selection Techniques" [I-D.ietf-ipfix-flow-selection-tech ], which describes the process of selecting a subset of Flows from all Flows observed at an Observation Point, the flow selection motivations, and some specific flow selection techniques. 3. "Exporting Aggregated Flow Data using IP Flow Information Export" [I-D.ietf-ipfix-a9n ] which describes Aggregated Flow export within the framework of IPFIX Mediators and defines an interoperable, implementation-independent method for Aggregated Flow export. This document specifies the IP Flow Information Export (IPFIX) protocol specific to Mediation, i.e. the specifications that all Intermediate Processes type must comply to. Some extra specifications might be required per Intermediate Process type (In which case, the Intermediate Process specific document would cover those). Note that http://tools.ietf.org/html/draft-ietf-ipfix-a9n-08 mentions correlation, as a special case of aggregation. However, it can be very complex, and mainly application specific, if we go beyond the simplest case. So we mentioned in section 4.2.1: The exact steps performed to correlate and normalize flows in this step are application-, implementation-, and deployment-specific, and will not be further specified in this document. Regards, Benoit (as a contributor) --------------080308010302080702000107 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi Rahul,

Thanks for your review.
See in line.


Few comments.

  1. Page 8: 
    1. The difference between "Intermediate Selection Process" and "Intermediate Flow Selection Process" is not clear. Is the first one selecting record purely on matching content (value of the fields) in the record and the second one selecting on matching attributes of the fields that are not part of the record in *addition* to matching content in the record? An example would help here.
Granted, this is difficult to understand from the definitions only. There is some history behind these two separate definitions. Anyway, you get it right from your message above.
I was thinking to add to a section 2.1 "Differences between Intermediate Selection Process and Intermediate Flow Selection Process" in the draft-ietf-ipfix-mediation-protocol draft. However, thinking about it some more, this section should really be done in draft-ietf-ipfix-flow-selection-tech-14, to avoid some more confusion.
There is already section 3. "Difference between Intermediate Flow Selection Process and Packet Selection". Some more text should be added on the difference between Intermediate Selection Process and Intermediate Flow Selection Process

When created, draft-ietf-ipfix-mediation-protocol will refer to that new section.

    1. Also in the example " e.g., Filtering only records from a given network to a given Collector" - Does "given network" means "source-ip/source-prefix of the exporter"?.
It means matching the flow records to a certain prefix/AS/you-name-it, and exporting those matched flow records to an exporter.
See for example, section 6.1 in RFC 6183
This could be explained better in the new section in draft-ietf-ipfix-flow-selection-tech (See previous point)
  2. Page 13:
    1. "Figure B" A typo? Should it be "Figure 3"?
Corrected.

General
  • On correlation process – how to correlate, what cannot be correlated, etc – is this out of scope of this draft? For example, Mediator A receives metric N1 and N2 per 5-tuple from exporter X and metric N3 and N4 per 5-tuple from exporter Y. Mediator A can easily correlate and exporter N1, N2, N3 and N4 to another collector C. If the key fields are not matching or one is subset of other then data can either not be correlated or can be represented in a different way. Most likely all of this out of scope of this document but just wanted to check.
Yes, it's out of scope.
The specific techniques are described/specified in the respective drafts.

   Documents specifying the operations of specific Intermediate
   Processes cover the operation of these Processes within the IPFIX
   Mediator framework, and comply with the specifications given in this
   document; they may additionally specify the operation of the process
   independently, outside the context of an IPFIX Mediator, when this is
   appropriate.  The details of specific Intermediate Processes, when
   these have additional export specifications (e.g., metadata about the
   intermediate processing conveyed through IPFIX Options Templates),
   are each treated in their own document.  As of today, these documents
   are:

   1.  "IP Flow Anonymization Support", [RFC6235], which describes
       Anonymization techniques for IP flow data and the export of
       Anonymized data using the IPFIX protocol.

   2.  "Flow Selection Techniques" [I-D.ietf-ipfix-flow-selection-tech],
       which describes the process of selecting a subset of Flows from
       all Flows observed at an Observation Point, the flow selection
       motivations, and some specific flow selection techniques.

   3.  "Exporting Aggregated Flow Data using IP Flow Information Export"
       [I-D.ietf-ipfix-a9n] which describes Aggregated Flow export
       within the framework of IPFIX Mediators and defines an
       interoperable, implementation-independent method for Aggregated
       Flow export.

   This document specifies the IP Flow Information Export (IPFIX)
   protocol specific to Mediation, i.e. the specifications that all
   Intermediate Processes type must comply to.  Some extra
   specifications might be required per Intermediate Process type (In
   which case, the Intermediate Process specific document would cover
   those).


Note that http://tools.ietf.org/html/draft-ietf-ipfix-a9n-08 mentions correlation, as a special case of aggregation. However, it can be very complex, and mainly application specific, if we go beyond the simplest case. So we mentioned in section 4.2.1: 
   The exact steps performed to correlate and normalize flows in this
   step are application-, implementation-, and deployment-specific, and
   will not be further specified in this document.

Regards, Benoit (as a contributor) --------------080308010302080702000107-- From bclaise@cisco.com Wed Mar 20 01:37:12 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E774121F8615; Wed, 20 Mar 2013 01:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.157 X-Spam-Level: X-Spam-Status: No, score=-10.157 tagged_above=-999 required=5 tests=[AWL=0.441, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwPKG6NK+IvR; Wed, 20 Mar 2013 01:37:12 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id BEBAF21F859B; Wed, 20 Mar 2013 01:37:11 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r2K8b9Ye003449; Wed, 20 Mar 2013 09:37:10 +0100 (CET) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r2K8aXQW014751; Wed, 20 Mar 2013 09:36:43 +0100 (CET) Message-ID: <514974F8.9030102@cisco.com> Date: Wed, 20 Mar 2013 09:36:08 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: draft-ietf-ipfix-flow-selection-tech@tools.ietf.org References: <20130318165531.28759.52346.idtracker@ietfa.amsl.com> In-Reply-To: <20130318165531.28759.52346.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------060001080902050607000007" Cc: ipfix@ietf.org, IETF-Discussion list Subject: Re: [IPFIX] Last Call: (Flow Selection Techniques) to Proposed Standard X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 08:37:13 -0000 This is a multi-part message in MIME format. --------------060001080902050607000007 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear authors, While reviewing draft-ietf-ipfix-mediation-protocol, Rahul got some feedback that actually concerns draft-ietf-ipfix-flow-selection-tech. Can you please take this into account. Regards, Benoit > > > Few comments. > > 1. Page 8: > 1. The difference between "Intermediate Selection Process" and > "Intermediate Flow Selection Process" is not clear. Is the > first one selecting record purely on matching content (value > of the fields) in the record and the second one selecting on > matching attributes of the fields that are not part of the > record in *addition* to matching content in the record? An > example would help here. > BC> Granted, this is difficult to understand from the definitions only. There is some history behind these two separate definitions. Anyway, you get it right from your message above. I was thinking to add to a section 2.1 "Differences between Intermediate Selection Process and Intermediate Flow Selection Process" in the draft-ietf-ipfix-mediation-protocol draft. However, thinking about it some more, this section should really be done in draft-ietf-ipfix-flow-selection-tech-14, to avoid some more confusion. There is already section 3. "Difference between Intermediate Flow Selection Process and Packet Selection". Some more text should be added on the difference between Intermediate Selection Process and Intermediate Flow Selection Process When created, draft-ietf-ipfix-mediation-protocol will refer to that new section. > 1. > 1. Also in the example " e.g., Filteringonly records from a given > network to a given Collector" - Does "given network" means > "source-ip/source-prefix of the exporter"?. > BC> It means matching the flow records to a certain prefix/AS/you-name-it, and exporting those matched flow records to an exporter. See for example, section 6.1 in RFC 6183 This could be explained better in the new section in draft-ietf-ipfix-flow-selection-tech (See previous point) > The IESG has received a request from the IP Flow Information Export WG > (ipfix) to consider the following document: > - 'Flow Selection Techniques' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2013-04-01. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > Intermediate Flow Selection Process is the process of selecting a > subset of Flows from all observed Flows. The Intermediate Flow > Selection Process may be located at an IPFIX Exporter, Collector, or > within an IPFIX Mediator. It reduces the effort of post-processing > Flow data and transferring Flow Records. This document describes > motivations for using the Intermediate Flow Selection process and > presents Intermediate Flow Selection techniques. It provides an > information model for configuring Intermediate Flow Selection Process > techniques and discusses what information about an Intermediate Flow > Selection Process should be exported. > > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/ballot/ > > > The following IPR Declarations may be related to this I-D: > > http://datatracker.ietf.org/ipr/1540/ > > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix > > --------------060001080902050607000007 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear authors,

While reviewing draft-ietf-ipfix-mediation-protocol, Rahul got some feedback that actually concerns draft-ietf-ipfix-flow-selection-tech.
Can you please take this into account.

Regards, Benoit



Few comments.

  1. Page 8: 
    1. The difference between "Intermediate Selection Process" and "Intermediate Flow Selection Process" is not clear. Is the first one selecting record purely on matching content (value of the fields) in the record and the second one selecting on matching attributes of the fields that are not part of the record in *addition* to matching content in the record? An example would help here.
BC> Granted, this is difficult to understand from the definitions only. There is some history behind these two separate definitions. Anyway, you get it right from your message above.
I was thinking to add to a section 2.1 "Differences between Intermediate Selection Process and Intermediate Flow Selection Process" in the draft-ietf-ipfix-mediation-protocol draft. However, thinking about it some more, this section should really be done in draft-ietf-ipfix-flow-selection-tech-14, to avoid some more confusion.
There is already section 3. "Difference between Intermediate Flow Selection Process and Packet Selection". Some more text should be added on the difference between Intermediate Selection Process and Intermediate Flow Selection Process

When created, draft-ietf-ipfix-mediation-protocol will refer to that new section.

    1. Also in the example " e.g., Filtering only records from a given network to a given Collector" - Does "given network" means "source-ip/source-prefix of the exporter"?.
BC> It means matching the flow records to a certain prefix/AS/you-name-it, and exporting those matched flow records to an exporter.
See for example, section 6.1 in RFC 6183
This could be explained better in the new section in draft-ietf-ipfix-flow-selection-tech (See previous point)


The IESG has received a request from the IP Flow Information Export WG
(ipfix) to consider the following document:
- 'Flow Selection Techniques'
  <draft-ietf-ipfix-flow-selection-tech-14.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-04-01. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   Intermediate Flow Selection Process is the process of selecting a
   subset of Flows from all observed Flows.  The Intermediate Flow
   Selection Process may be located at an IPFIX Exporter, Collector, or
   within an IPFIX Mediator.  It reduces the effort of post-processing
   Flow data and transferring Flow Records.  This document describes
   motivations for using the Intermediate Flow Selection process and
   presents Intermediate Flow Selection techniques.  It provides an
   information model for configuring Intermediate Flow Selection Process
   techniques and discusses what information about an Intermediate Flow
   Selection Process should be exported.





The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/ballot/


The following IPR Declarations may be related to this I-D:

   http://datatracker.ietf.org/ipr/1540/



_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

--------------060001080902050607000007-- From wwwrun@rfc-editor.org Wed Mar 20 04:07:52 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E88D021F8767 for ; Wed, 20 Mar 2013 04:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOmAG9SiU0Zl for ; Wed, 20 Mar 2013 04:07:51 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 77EB021F8735 for ; Wed, 20 Mar 2013 04:07:51 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id C5906B1E003; Wed, 20 Mar 2013 04:07:48 -0700 (PDT) To: brian.trammell@hitachi-eu.com, elisa.boschi@hitachi-eu.com, lutz.mark@ifam.fraunhofer.de, tanja.zseby@fokus.fraunhofer.de, arno@wagner.name, bclaise@cisco.com, joelja@bogus.com, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20130320110748.C5906B1E003@rfc-editor.org> Date: Wed, 20 Mar 2013 04:07:48 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Technical Errata Reported] RFC5655 (3559) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 11:07:52 -0000 The following errata report has been submitted for RFC5655, "Specification of the IP Flow Information Export (IPFIX) File Format". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5655&eid=3559 -------------------------------------- Type: Technical Reported by: Paul Aitken Section: 8.2.1 Original Text ------------- (none) Corrected Text -------------- Units: milliseconds Notes ----- collectionTimeMilliseconds requires units of milliseconds. Compare with sections 8.2.7 and 8.2.14 in the same document. IANA's IPFIX IE registry requires the corresponding update. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5655 (draft-ietf-ipfix-file-05) -------------------------------------- Title : Specification of the IP Flow Information Export (IPFIX) File Format Publication Date : October 2009 Author(s) : B. Trammell, E. Boschi, L. Mark, T. Zseby, A. Wagner Category : PROPOSED STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Wed Mar 20 04:12:08 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B56AF21F88A1 for ; Wed, 20 Mar 2013 04:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqUbWvK6erq4 for ; Wed, 20 Mar 2013 04:12:08 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id D69B221F88B0 for ; Wed, 20 Mar 2013 04:12:07 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 95E65B1E003; Wed, 20 Mar 2013 04:11:56 -0700 (PDT) To: brian.trammell@hitachi-eu.com, elisa.boschi@hitachi-eu.com, lutz.mark@ifam.fraunhofer.de, tanja.zseby@fokus.fraunhofer.de, arno@wagner.name, bclaise@cisco.com, joelja@bogus.com, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20130320111156.95E65B1E003@rfc-editor.org> Date: Wed, 20 Mar 2013 04:11:56 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Technical Errata Reported] RFC5655 (3560) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 11:12:08 -0000 The following errata report has been submitted for RFC5655, "Specification of the IP Flow Information Export (IPFIX) File Format". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5655&eid=3560 -------------------------------------- Type: Technical Reported by: Paul Aitken Section: 8.2.11 + .18 Original Text ------------- (none) Corrected Text -------------- Range: The valid range is 0-0. Notes ----- 8.2.11 messageScope requires a value of 0 ("The value of this Information Element MUST be written as 0") but no range is given. The range should say "0-0". (Compare with text in RFC 5102). Similarly for 8.2.18 sessionScope. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5655 (draft-ietf-ipfix-file-05) -------------------------------------- Title : Specification of the IP Flow Information Export (IPFIX) File Format Publication Date : October 2009 Author(s) : B. Trammell, E. Boschi, L. Mark, T. Zseby, A. Wagner Category : PROPOSED STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From salvatore.dantonio@uniparthenope.it Wed Mar 20 06:16:28 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A179021F8CF6; Wed, 20 Mar 2013 06:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.731 X-Spam-Level: X-Spam-Status: No, score=0.731 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPVOpLjuTnNy; Wed, 20 Mar 2013 06:16:27 -0700 (PDT) Received: from mail.uniparthenope.it (mail.uniparthenope.it [192.167.9.244]) by ietfa.amsl.com (Postfix) with ESMTP id 750FA21F8CEF; Wed, 20 Mar 2013 06:16:26 -0700 (PDT) Received: from mail2.uniparthenope.it (unknown [10.1.2.108]) by mail.uniparthenope.it (Postfix) with SMTP id CF3583F07A; Wed, 20 Mar 2013 13:16:23 +0000 (UTC) Received: from (unknown [192.168.241.108]) by mail2.uniparthenope.it with smtp id 1d7f_5cc671f4_9160_11e2_9101_001372515a5c; Wed, 20 Mar 2013 14:16:23 +0100 Received: from spamk.uniparthenope.it (localhost [127.0.0.1]) by spamk.uniparthenope.it (Postfix) with ESMTP id 52338C4301; Wed, 20 Mar 2013 14:16:23 +0100 (CET) Received: by spamk.uniparthenope.it (Postfix, from userid 500) id 4FB07C4305; Wed, 20 Mar 2013 14:16:23 +0100 (CET) Received: from mail.uniparthenope.it (unknown [192.168.241.109]) by spamk.uniparthenope.it (Postfix) with ESMTP id 94020C4301; Wed, 20 Mar 2013 14:16:22 +0100 (CET) Received: from saldantoPC (unknown [192.168.162.11]) (Authenticated sender: salvatore.dantonio@uniparthenope.it) by mail.uniparthenope.it (Postfix) with ESMTPA id 160AC3F07A; Wed, 20 Mar 2013 14:16:22 +0100 (CET) From: "Salvatore D'Antonio" To: "'Benoit Claise'" , References: <20130318165531.28759.52346.idtracker@ietfa.amsl.com> <514974F8.9030102@cisco.com> In-Reply-To: <514974F8.9030102@cisco.com> Date: Wed, 20 Mar 2013 14:16:24 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4lRigJVANLWjevScKhmQgYS8OkigAJtplw Content-Language: it Message-ID: <003b01ce256d$1f8388e0$5e8a9aa0$@dantonio@uniparthenope.it> Content-Type: multipart/alternative; boundary="----=_NextPart_000_003C_01CE2575.8147F0E0" X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.42/RELEASE, bases: 20130320 #9759762, check: 20130320 clean Cc: ipfix@ietf.org, 'IETF-Discussion list' Subject: [IPFIX] R: Last Call: (Flow Selection Techniques) to Proposed Standard X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 13:16:28 -0000 Messaggio multipart in formato MIME. ------=_NextPart_000_003C_01CE2575.8147F0E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Benoit, =20 Will do. =20 Kind regards, =20 Salvatore =20 =20 =20 Da: Benoit Claise [mailto:bclaise@cisco.com]=20 Inviato: mercoled=EC 20 marzo 2013 09:36 A: draft-ietf-ipfix-flow-selection-tech@tools.ietf.org Cc: IETF-Discussion list; Rahul Patel; ipfix@ietf.org Oggetto: Re: [IPFIX] Last Call: (Flow Selection = Techniques) to Proposed Standard =20 Dear authors, While reviewing draft-ietf-ipfix-mediation-protocol, Rahul got some = feedback that actually concerns draft-ietf-ipfix-flow-selection-tech. Can you please take this into account. =20 Regards, Benoit =20 =20 Few comments. =20 1. Page 8: =20 1. The difference between "Intermediate Selection Process" and "Intermediate Flow Selection Process" is not clear. Is the first one selecting record purely on matching content (value of the fields) in the record and the second one selecting on matching attributes of the fields that are not part of the record in *addition* to matching content in the record? An example would help here. BC> Granted, this is difficult to understand from the definitions only. There is some history behind these two separate definitions. Anyway, you = get it right from your message above. I was thinking to add to a section 2.1 "Differences between Intermediate Selection Process and Intermediate Flow Selection Process" in the draft-ietf-ipfix-mediation-protocol draft. However, thinking about it = some more, this section should really be done in draft-ietf-ipfix-flow-selection-tech-14, to avoid some more confusion. There is already section 3. "Difference between Intermediate Flow = Selection Process and Packet Selection". Some more text should be added on the difference between Intermediate Selection Process and Intermediate Flow Selection Process When created, draft-ietf-ipfix-mediation-protocol will refer to that new section. 1. =20 1. Also in the example " e.g., Filtering only records from a given network to a given Collector" - Does "given network" means "source-ip/source-prefix of the exporter"?. BC> It means matching the flow records to a certain = prefix/AS/you-name-it, and exporting those matched flow records to an exporter. See for example, section 6.1 in RFC 6183 This could be explained better in the new section in draft-ietf-ipfix-flow-selection-tech (See previous point) =20 =20 The IESG has received a request from the IP Flow Information Export WG (ipfix) to consider the following document: - 'Flow Selection Techniques' as Proposed Standard =20 The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-04-01. Exceptionally, comments may = be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. =20 Abstract =20 =20 Intermediate Flow Selection Process is the process of selecting a subset of Flows from all observed Flows. The Intermediate Flow Selection Process may be located at an IPFIX Exporter, Collector, or within an IPFIX Mediator. It reduces the effort of post-processing Flow data and transferring Flow Records. This document describes motivations for using the Intermediate Flow Selection process and presents Intermediate Flow Selection techniques. It provides an information model for configuring Intermediate Flow Selection Process techniques and discusses what information about an Intermediate Flow Selection Process should be exported. =20 =20 =20 =20 =20 The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/ =20 IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/ball= ot/ =20 =20 The following IPR Declarations may be related to this I-D: =20 http://datatracker.ietf.org/ipr/1540/ =20 =20 =20 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix =20 =20 =20 _____ =20 Nessun virus nel messaggio. Controllato da AVG - www.avg.com Versione: 2013.0.2904 / Database dei virus: 2641/6186 - Data di = rilascio: 18/03/2013 ------=_NextPart_000_003C_01CE2575.8147F0E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear Benoit,

 

Will do.

 

Kind regards,

 

Salvatore

 

 

 

Da: Benoit Claise [mailto:bclaise@cisco.com]
Inviato: mercoled=EC 20 marzo 2013 09:36
A: draft-ietf-ipfix-flow-selection-tech@tools.ietf.org
Cc: IETF-Discussion list; Rahul Patel; ipfix@ietf.org
Oggetto: Re: [IPFIX] Last Call: <draft-ietf-ipfix-flow-selection-tech-14.txt> (Flow Selection = Techniques) to Proposed Standard

 

Dear = authors,

While = reviewing draft-ietf-ipfix-mediation-protocol, Rahul got some feedback that = actually concerns draft-ietf-ipfix-flow-selection-tech.
Can you please take this into account.

 

Regards, = Benoit



 

 

Few = comments.

 

  1. Page = 8: 
    1. The difference between "Intermediate Selection Process" and "Intermediate Flow Selection Process" is not clear. Is = the first one selecting record purely on matching content (value of = the fields) in the record and the second one selecting on matching = attributes of the fields that are not part of the record in *addition* to = matching content in the record? An example would help = here.

BC> = Granted, this is difficult to understand from the definitions only. There is some history = behind these two separate definitions. Anyway, you get it right from your = message above.
I was thinking to add to a section 2.1 "Differences between = Intermediate Selection Process and Intermediate Flow Selection Process" in the draft-ietf-ipfix-mediation-protocol draft. However, thinking about it = some more, this section should really be done in draft-ietf-ipfix-flow-selection-tech-14, to avoid some more = confusion.
There is already section 3. "Difference between Intermediate Flow Selection Process and Packet Selection". Some more text should be = added on the difference between Intermediate Selection Process and Intermediate = Flow Selection Process

When created, draft-ietf-ipfix-mediation-protocol will refer to that new section.


  1.  
    1. Also in the example " e.g., Filtering only records = from a given network to a given Collector" - Does "given = network" means "source-ip/source-prefix of the = exporter"?.

BC> It means matching the flow records to a certain prefix/AS/you-name-it, = and exporting those matched flow records to an exporter.
See for example, section 6.1 in RFC 6183
This could be explained better in the new section in draft-ietf-ipfix-flow-selection-tech (See previous = point)

 

 
The IESG has received a request from the IP Flow Information =
Export WG
(ipfix) to consider the following =
document:
- 'Flow Selection =
Techniques'
=A0 =
<draft-ietf-ipfix-flow-selection-tech-14.txt> as Proposed =
Standard
 
The IESG plans =
to make a decision in the next few weeks, and =
solicits
final comments on this action. Please send =
substantive comments to the
ietf@ietf.org mailing lists by =
2013-04-01. Exceptionally, comments may be
sent to =
iesg@ietf.org instead. In either case, =
please retain the
beginning of the Subject line to =
allow automated =
sorting.
 
Abstract
 
 
=A0=
=A0 Intermediate Flow Selection Process is the process of selecting =
a
=A0=A0 subset of Flows from all observed =
Flows.=A0 The Intermediate Flow
=A0=A0 Selection =
Process may be located at an IPFIX Exporter, Collector, =
or
=A0=A0 within an IPFIX Mediator.=A0 It reduces =
the effort of post-processing
=A0=A0 Flow data and =
transferring Flow Records.=A0 This document =
describes
=A0=A0 motivations for using the =
Intermediate Flow Selection process and
=A0=A0 =
presents Intermediate Flow Selection techniques.=A0 It provides =
an
=A0=A0 information model for configuring =
Intermediate Flow Selection Process
=A0=A0 =
techniques and discusses what information about an Intermediate =
Flow
=A0=A0 Selection Process should be =
exported.
 
 
 
 
 
The file can be obtained =
via
http://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tec=
h/
 
IESG discussion =
can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-select=
ion-tech/ballot/
 
 
The following IPR Declarations may be related =
to this I-D:
 
=A0=A0 http://datatracker.ietf.or=
g/ipr/1540/
 
&nb=
sp;
 
_________________________=
______________________
IPFIX mailing =
list
IPFIX@ietf.org
https://www.ietf.org=
/mailman/listinfo/ipfix
 
<=
pre> 

 

Nessun virus nel messaggio.
Controllato da AVG - www.avg.com
Versione: 2013.0.2904 / Database dei virus: 2641/6186 - Data di = rilascio: 18/03/2013

------=_NextPart_000_003C_01CE2575.8147F0E0-- From rahulp@cisco.com Wed Mar 20 09:47:26 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 353FA11E80D1 for ; Wed, 20 Mar 2013 09:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rkem3IZlDnUx for ; Wed, 20 Mar 2013 09:47:25 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id DDA2E21F8C93 for ; Wed, 20 Mar 2013 09:47:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16027; q=dns/txt; s=iport; t=1363798044; x=1365007644; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=CGC0+LAi3Yp1YVpA/4JHRDmTnxgtymoBiFdGRQcyTog=; b=DqIyx2nImgeYOrTT2fnaQKiqQmZsK/ZJugQ/KofPEQdNOn12toMmkJGW 052z4XxCi4apGASCztr2LbNci10JMjoyKi0TgLmigvcOhtHCbvviYL37N FywWj9URO70RAvKFaPpPpLtmgTJKR1gNuE9WaIN2kKhNM6hNvxgZDe8ld M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjIFAAbnSVGtJXHB/2dsb2JhbABDhAa4TQGIR4FPFnSCJAEBAQR5EgEIEQMBAgsdORQJCAIEDgUIiAwMwlyOXiARBwaCWWEDl3+PY4MKgig X-IronPort-AV: E=Sophos;i="4.84,879,1355097600"; d="scan'208,217";a="189600509" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 20 Mar 2013 16:47:24 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r2KGlOYs011725 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 20 Mar 2013 16:47:24 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.147]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.004; Wed, 20 Mar 2013 11:47:24 -0500 From: "Rahul Patel (rahulp)" To: "Benoit Claise (bclaise)" Thread-Topic: Feedback: regarding draft-ietf-ipfix-mediation-protocol Thread-Index: AQHOGcq3m3VkIH+yRkGa/Azkao+B1piuqPAAgAAn5YA= Date: Wed, 20 Mar 2013 16:47:23 +0000 Message-ID: In-Reply-To: <51497242.80407@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.154.209.184] Content-Type: multipart/alternative; boundary="_000_A1EE24E3D6D8B14A92CCA1AFB88718B21845D2AExmbrcdx05ciscoc_" MIME-Version: 1.0 Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] Feedback: regarding draft-ietf-ipfix-mediation-protocol X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 16:47:26 -0000 --_000_A1EE24E3D6D8B14A92CCA1AFB88718B21845D2AExmbrcdx05ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Benoit, Thanks for the response. -Rahul From: "Benoit Claise (bclaise)" > Date: Wednesday, March 20, 2013 12:24 AM To: Cisco Employee > Cc: "ipfix@ietf.org" > Subject: Re: Feedback: regarding draft-ietf-ipfix-mediation-protocol Hi Rahul, Thanks for your review. See in line. Few comments. 1. Page 8: * The difference between "Intermediate Selection Process" and "Inter= mediate Flow Selection Process" is not clear. Is the first one selecting re= cord purely on matching content (value of the fields) in the record and the= second one selecting on matching attributes of the fields that are not par= t of the record in *addition* to matching content in the record? An example= would help here. Granted, this is difficult to understand from the definitions only. There i= s some history behind these two separate definitions. Anyway, you get it ri= ght from your message above. I was thinking to add to a section 2.1 "Differences between Intermediate Se= lection Process and Intermediate Flow Selection Process" in the draft-ietf-= ipfix-mediation-protocol draft. However, thinking about it some more, this = section should really be done in draft-ietf-ipfix-flow-selection-tech-14, t= o avoid some more confusion. There is already section 3. "Difference between Intermediate Flow Selection= Process and Packet Selection". Some more text should be added on the diffe= rence between Intermediate Selection Process and Intermediate Flow Selectio= n Process When created, draft-ietf-ipfix-mediation-protocol will refer to that new se= ction. 1. * Also in the example " e.g., Filtering only records from a given ne= twork to a given Collector" - Does "given network" means "source-ip/source-= prefix of the exporter"?. It means matching the flow records to a certain prefix/AS/you-name-it, and = exporting those matched flow records to an exporter. See for example, section 6.1 in RFC 6183 This could be explained better in the new section in draft-ietf-ipfix-flow-= selection-tech (See previous point) 1. 2. Page 13: * "Figure B" A typo? Should it be "Figure 3"? Corrected. 1. General * On correlation process =96 how to correlate, what cannot be correlate= d, etc =96 is this out of scope of this draft? For example, Mediator A rece= ives metric N1 and N2 per 5-tuple from exporter X and metric N3 and N4 per = 5-tuple from exporter Y. Mediator A can easily correlate and exporter N1, N= 2, N3 and N4 to another collector C. If the key fields are not matching or = one is subset of other then data can either not be correlated or can be rep= resented in a different way. Most likely all of this out of scope of this d= ocument but just wanted to check. Yes, it's out of scope. The specific techniques are described/specified in the respective drafts. Documents specifying the operations of specific Intermediate Processes cover the operation of these Processes within the IPFIX Mediator framework, and comply with the specifications given in this document; they may additionally specify the operation of the process independently, outside the context of an IPFIX Mediator, when this is appropriate. The details of specific Intermediate Processes, when these have additional export specifications (e.g., metadata about the intermediate processing conveyed through IPFIX Options Templates), are each treated in their own document. As of today, these documents are: 1. "IP Flow Anonymization Support", [RFC6235], which describes Anonymization techniques for IP flow data and the export of Anonymized data using the IPFIX protocol. 2. "Flow Selection Techniques" [I-D.ietf-ipfix-flow-selection-tech], which describes the process of selecting a subset of Flows from all Flows observed at an Observation Point, the flow selection motivations, and some specific flow selection techniques. 3. "Exporting Aggregated Flow Data using IP Flow Information Export" [I-D.ietf-ipfix-a9n] which describes Aggregated Flow = export within the framework of IPFIX Mediators and defines an interoperable, implementation-independent method for Aggregated Flow export. This document specifies the IP Flow Information Export (IPFIX) protocol specific to Mediation, i.e. the specifications that all Intermediate Processes type must comply to. Some extra specifications might be required per Intermediate Process type (In which case, the Intermediate Process specific document would cover those). Note that http://tools.ietf.org/html/draft-ietf-ipfix-a9n-08 mentions corre= lation, as a special case of aggregation. However, it can be very complex, = and mainly application specific, if we go beyond the simplest case. So we m= entioned in section 4.2.1: The exact steps performed to correlate and normalize flows in this step are application-, implementation-, and deployment-specific, and will not be further specified in this document. Regards, Benoit (as a contributor) --_000_A1EE24E3D6D8B14A92CCA1AFB88718B21845D2AExmbrcdx05ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Benoit,

Thanks for the response.

-Rahul

From: "Benoit Claise (bclaise)= " <bclaise@cisco.com> Date: Wednesday, March 20, 2013 12:= 24 AM
To: Cisco Employee <rahulp@cisco.com>
Cc: "ipfix@ietf.org" <ipf= ix@ietf.org>
Subject: Re: Feedback: regarding dr= aft-ietf-ipfix-mediation-protocol

Hi Rahul,

Thanks for your review.
See in line.


Few comments.

  1. Page 8: 
    1. The difference between "Intermediate Selection Process" and &= quot;Intermediate Flow Selection Process" is not clear. Is the first o= ne selecting record purely on matching content (value of the fields) in the= record and the second one selecting on matching attributes of the fields that are not part of the record in *addition* to matching co= ntent in the record? An example would help here.
Granted, this is difficult to understand from the definitions only. There i= s some history behind these two separate definitions. Anyway, you get it ri= ght from your message above.
I was thinking to add to a section 2.1 "Differences between Intermedia= te Selection Process and Intermediate Flow Selection Process" in the d= raft-ietf-ipfix-mediation-protocol draft. However, thinking about it some m= ore, this section should really be done in draft-ietf-ipfix-flow-selection-tech-14, to avoid some more confusion.
There is already section 3. "Difference between Intermediate Flow Sele= ction Process and Packet Selection". Some more text should be added on= the difference between Intermediate Selection Process and Intermediate Flo= w Selection Process

When created, draft-ietf-ipfix-mediation-protocol will refer to that new se= ction.

    1. Also in the example " e.g., Filtering only records from a given network to a given Collector" - Does "= given network" means "source-ip/source-prefix of the exporter&quo= t;?.
It means matching the flow records to a certain prefix/AS/you-name-it, and = exporting those matched flow records to an exporter.
See for example, section 6.1 in RFC 6183
This could be explained better in the new section in draft-ietf-ipfix-flow-= selection-tech (See previous point)
  2. Page 13:
    1. "Fig= ure B" A typo? Should it be "Figure 3"?
Corrected.

General
  • On correlation process =96= how to correlate, what cannot be correlated, etc =96 is this out of scope of this draft? For= example, Mediator A receives metric N1 and N2 per 5-tuple from exporter X = and metric N3 and N4 per 5-tuple from exporter Y. Mediator A can easily cor= relate and exporter N1, N2, N3 and N4 to another collector C. If the key fields are not matching or one is su= bset of other then data can either not be correlated or can be represented = in a different way. Most likely all of this out of scope of this document b= ut just wanted to check.
Yes, it's out of scope.
The specific techniques are described/specified in the respective drafts. 
   Documents specifying the operations of specific I=
ntermediate
   Processes cover the operation of these Processes within the IPFIX
   Mediator framework, and comply with the specifications given in this
   document; they may additionally specify the operation of the process
   independently, outside the context of an IPFIX Mediator, when this is
   appropriate.  The details of specific Intermediate Processes, when
   these have additional export specifications (e.g., metadata about the
   intermediate processing conveyed through IPFIX Options Templates),
   are each treated in their own document.  As of today, these documents
   are:

   1.  "IP Flow Anonymization Support", [=
RFC6235], which describes
       Anonymization techniques for IP flow data and the export of
       Anonymized data using the IPFIX protocol.

   2.  "Flow Selection Techniques" [I-D.ietf-ipfix-flow-selection-tech],
       which describes the process of selecting a subset of Flows from
       all Flows observed at an Observation Point, the flow selection
       motivations, and some specific flow selection techniques.

   3.  "Exporting Aggregated Flow Data using IP Flow Information Expor=
t"
       [I-D.ietf-ipfix-a9n] which describes A=
ggregated Flow export
       within the framework of IPFIX Mediators and defines an
       interoperable, implementation-independent method for Aggregated
       Flow export.

   This document specifies the IP Flow Information Export (IPFIX)
   protocol specific to Mediation, i.e. the specifications that all
   Intermediate Processes type must comply to.  Some extra
   specifications might be required per Intermediate Process type (In
   which case, the Intermediate Process specific document would cover
   those).


Note that http://tools.ietf.org/html/draft-ietf-ipfix-a9n-08 mentions correlation= , as a special case of aggregation. However, it can be very complex, and ma= inly application specific, if we go beyond the simplest case. So we mention= ed in section 4.2.1: 
   The exact steps performed to correlate and normal=
ize flows in this
   step are application-, implementation-, and deployment-specific, and
   will not be further specified in this document.

Regards, Benoit (as a contributor)
--_000_A1EE24E3D6D8B14A92CCA1AFB88718B21845D2AExmbrcdx05ciscoc_-- From steve.nash@theiet.org Thu Mar 21 04:46:08 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3696821F8F69 for ; Thu, 21 Mar 2013 04:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkMmLbh-tuY7 for ; Thu, 21 Mar 2013 04:46:07 -0700 (PDT) Received: from mtaout02-winn.ispmail.ntl.com (mtaout02-winn.ispmail.ntl.com [81.103.221.48]) by ietfa.amsl.com (Postfix) with ESMTP id 9451F21F8F0B for ; Thu, 21 Mar 2013 04:46:05 -0700 (PDT) Received: from aamtaout04-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout02-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20130321114604.TQZY23282.mtaout02-winn.ispmail.ntl.com@aamtaout04-winn.ispmail.ntl.com> for ; Thu, 21 Mar 2013 11:46:04 +0000 Received: from snashE6510 ([86.21.114.17]) by aamtaout04-winn.ispmail.ntl.com (InterMail vG.3.00.04.00 201-2196-133-20080908) with ESMTP id <20130321114604.NWZT11790.aamtaout04-winn.ispmail.ntl.com@snashE6510> for ; Thu, 21 Mar 2013 11:46:04 +0000 From: "Steve Nash" To: Date: Thu, 21 Mar 2013 11:45:55 -0000 Message-ID: <000601ce2629$a6f0da00$f4d28e00$@theiet.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CE2629.A6F323F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4mJvshVArGU+BqQmqSOio6UWzOMg== Content-Language: en-gb X-Cloudmark-Analysis: v=1.1 cv=GaEGOwq9FwezmTggA+b6yC6zDZF2HYaK6RN/tSqdnVA= c=1 sm=0 a=c6H_Kq75HOUA:10 a=H3ZbhYdykLQA:10 a=k1zQAbrYauQA:10 a=MXF7X9f8RYQA:10 a=DZEExIYWAAAA:8 a=Iyjl2YSbgbZReRFbXF0A:9 a=CjuIK1q_8ugA:10 a=KnGVzd4Q2D0A:10 a=68n-iWAU4QBtB86b:21 a=MChfjr7nZvm0pQVY:21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=xIb5Iqzr-cFftyd1GToA:9 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=FywBgKcpKQEA:10 a=ySUWau3gO-b6Dt1_:21 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 X-Mailman-Approved-At: Thu, 21 Mar 2013 08:59:50 -0700 Subject: [IPFIX] UDP Sequence Numbers rfc 5101 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: steve.nash@theiet.org List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 12:55:39 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0007_01CE2629.A6F323F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Please consider the wording of the paragraph on Sequence Numbers in Section 3.1. Incremental sequence counter modulo 2^32 of all IPFIX Data Records sent in the current stream from the current Observation Domain by the Exporting Process. Each SCTP Stream counts sequence numbers separately, while all messages in a TCP connection or UDP transport session are considered to be part of the same stream. The phrase I have put in italics is depended on Transport protocol. Section 10.3.2 Reliability says: In the case of UDP, the IPFIX Sequence Number contains the total number of IPFIX Data Records sent for the UDP Transport Session prior to the receipt of this IPFIX Message This is NOT dependent on the ObservationDomain. Nothing prohibits the Exporting Process from using the same Transport Session for multiple Observation Domains. But in UDP the Sequence number is for the Transport session, whereas in TCP and SCTP each Observation Domain has an independent sequence on the same (and on each) Transport Session. The term 'Stream' seems to take different meanings in IPFIX, depending on the transport protocol. This is not consistent with IPFIX being "Transport protocol independent " (Section 10 first para). Regards Steve Nash steve.nash@theiet.org UK _____ ------=_NextPart_000_0007_01CE2629.A6F323F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please = consider the wording of the paragraph on Sequence Numbers in Section = 3.1.

      = Incremental sequence counter modulo 2^32 of all IPFIX Data = Records

      sent = in the current stream from the current = Observation Domain by

      the Exporting Process. Each SCTP = Stream counts sequence numbers

      separately, while all messages in a = TCP connection or UDP

      = transport session are considered to be part of the same = stream.

The phrase = I have put in italics is depended on Transport = protocol.

Section = 10.3.2 Reliability says:

 =

In the case of UDP, the IPFIX Sequence Number contains = the

total number of IPFIX Data Records sent for the UDP Transport = Session

prior to the receipt of this IPFIX Message=

 =

This is = NOT dependent on the ObservationDomain.  Nothing prohibits the = Exporting Process from using the same Transport Session for multiple = Observation Domains.  But in UDP the Sequence number is for the = Transport session, whereas in TCP and SCTP each Observation Domain has = an independent sequence on the same  (and on each) Transport = Session.

 =

The term = ‘Stream’ seems to take different meanings in IPFIX, = depending on the transport protocol.

This is = not consistent with IPFIX being  “Transport protocol = independent “ = (Section 10 first para).

 =

Regards

Steve = Nash

steve.nash@theiet.org

UK

------=_NextPart_000_0007_01CE2629.A6F323F0-- From bclaise@cisco.com Sun Mar 24 16:02:44 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED54021F8498 for ; Sun, 24 Mar 2013 16:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.461 X-Spam-Level: X-Spam-Status: No, score=-10.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chAQ6NJwp7QR for ; Sun, 24 Mar 2013 16:02:43 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 1D69921F8AB2 for ; Sun, 24 Mar 2013 16:02:42 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r2ON2SQv027979; Mon, 25 Mar 2013 00:02:28 +0100 (CET) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r2ON0b62007578; Mon, 25 Mar 2013 00:00:52 +0100 (CET) Message-ID: <514F856F.9040601@cisco.com> Date: Sun, 24 Mar 2013 23:59:59 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: brian.trammell@hitachi-eu.com, elisa.boschi@hitachi-eu.com, lutz.mark@ifam.fraunhofer.de References: <20130320111156.95E65B1E003@rfc-editor.org> In-Reply-To: <20130320111156.95E65B1E003@rfc-editor.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfix@ietf.org, joelja@bogus.com, n.brownlee@auckland.ac.nz, tanja.zseby@fokus.fraunhofer.de, arno@wagner.name Subject: Re: [IPFIX] [Technical Errata Reported] RFC5655 (3560) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 23:02:44 -0000 Hi, This errata looks fine to me, but I want to hear from authors first, as this is the first time we will have a range of "0-0" in the IPFIX IANA registry. Regards, Benoit > The following errata report has been submitted for RFC5655, > "Specification of the IP Flow Information Export (IPFIX) File Format". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=5655&eid=3560 > > -------------------------------------- > Type: Technical > Reported by: Paul Aitken > > Section: 8.2.11 + .18 > > Original Text > ------------- > (none) > > Corrected Text > -------------- > Range: The valid range is 0-0. > > Notes > ----- > 8.2.11 messageScope requires a value of 0 ("The value of this Information Element MUST be written as 0") but no range is given. The range should say "0-0". (Compare with text in RFC 5102). > > > > Similarly for 8.2.18 sessionScope. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC5655 (draft-ietf-ipfix-file-05) > -------------------------------------- > Title : Specification of the IP Flow Information Export (IPFIX) File Format > Publication Date : October 2009 > Author(s) : B. Trammell, E. Boschi, L. Mark, T. Zseby, A. Wagner > Category : PROPOSED STANDARD > Source : IP Flow Information Export > Area : Operations and Management > Stream : IETF > Verifying Party : IESG > > From bclaise@cisco.com Sun Mar 24 16:09:55 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 657D021F8E15 for ; Sun, 24 Mar 2013 16:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.466 X-Spam-Level: X-Spam-Status: No, score=-10.466 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvCRa3dIX66M for ; Sun, 24 Mar 2013 16:09:54 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 3B29221F8E0E for ; Sun, 24 Mar 2013 16:09:54 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r2ON1odV027942 for ; Mon, 25 Mar 2013 00:01:50 +0100 (CET) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r2ON1YJF008006 for ; Mon, 25 Mar 2013 00:01:45 +0100 (CET) Message-ID: <514F85A9.4010401@cisco.com> Date: Mon, 25 Mar 2013 00:00:57 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "ipfix@ietf.org" References: <20130324225432.AA35BB1E002@rfc-editor.org> In-Reply-To: <20130324225432.AA35BB1E002@rfc-editor.org> X-Forwarded-Message-Id: <20130324225432.AA35BB1E002@rfc-editor.org> Content-Type: multipart/mixed; boundary="------------020807010004080801040405" Subject: [IPFIX] Fwd: [Errata Verified] RFC5655 (3559) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 23:09:55 -0000 This is a multi-part message in MIME format. --------------020807010004080801040405 Content-Type: multipart/alternative; boundary="------------010604010905000809090009" --------------010604010905000809090009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI. Regards, Benoit -------- Original Message -------- Subject: [Errata Verified] RFC5655 (3559) Date: Sun, 24 Mar 2013 15:54:32 -0700 (PDT) From: RFC Errata System To: paitken@cisco.com, brian.trammell@hitachi-eu.com, elisa.boschi@hitachi-eu.com, lutz.mark@ifam.fraunhofer.de, tanja.zseby@fokus.fraunhofer.de, arno@wagner.name CC: bclaise@cisco.com, iesg@ietf.org, rfc-editor@rfc-editor.org The following errata report has been verified for RFC5655, "Specification of the IP Flow Information Export (IPFIX) File Format". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5655&eid=3559 -------------------------------------- Status: Verified Type: Technical Reported by: Paul Aitken Date Reported: 2013-03-20 Verified by: Benoit Claise (IESG) Section: 8.2.1 Original Text ------------- (none) Corrected Text -------------- Units: milliseconds Notes ----- collectionTimeMilliseconds requires units of milliseconds. Compare with sections 8.2.7 and 8.2.14 in the same document. IANA's IPFIX IE registry requires the corresponding update. -------------------------------------- RFC5655 (draft-ietf-ipfix-file-05) -------------------------------------- Title : Specification of the IP Flow Information Export (IPFIX) File Format Publication Date : October 2009 Author(s) : B. Trammell, E. Boschi, L. Mark, T. Zseby, A. Wagner Category : PROPOSED STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG --------------010604010905000809090009 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit FYI.

Regards, Benoit


-------- Original Message --------
Subject: [Errata Verified] RFC5655 (3559)
Date: Sun, 24 Mar 2013 15:54:32 -0700 (PDT)
From: RFC Errata System <rfc-editor@rfc-editor.org>
To: paitken@cisco.com, brian.trammell@hitachi-eu.com, elisa.boschi@hitachi-eu.com, lutz.mark@ifam.fraunhofer.de, tanja.zseby@fokus.fraunhofer.de, arno@wagner.name
CC: bclaise@cisco.com, iesg@ietf.org, rfc-editor@rfc-editor.org 


The following errata report has been verified for RFC5655,
"Specification of the IP Flow Information Export (IPFIX) File Format". 

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5655&eid=3559

--------------------------------------
Status: Verified
Type: Technical

Reported by: Paul Aitken <paitken@cisco.com>
Date Reported: 2013-03-20
Verified by: Benoit Claise (IESG)

Section: 8.2.1

Original Text
-------------
(none)

Corrected Text
--------------
Units:   milliseconds

Notes
-----
collectionTimeMilliseconds requires units of milliseconds.

Compare with sections 8.2.7 and 8.2.14 in the same document.

IANA's IPFIX IE registry requires the corresponding update.

--------------------------------------
RFC5655 (draft-ietf-ipfix-file-05)
--------------------------------------
Title               : Specification of the IP Flow Information Export (IPFIX) File Format
Publication Date    : October 2009
Author(s)           : B. Trammell, E. Boschi, L. Mark, T. Zseby, A. Wagner
Category            : PROPOSED STANDARD
Source              : IP Flow Information Export
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG


--------------010604010905000809090009-- --------------020807010004080801040405 Content-Type: text/plain; charset=windows-1252; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" --------------020807010004080801040405-- From trammell@tik.ee.ethz.ch Sun Mar 24 16:18:07 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B51721F8E23 for ; Sun, 24 Mar 2013 16:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-oMBXSRKoUL for ; Sun, 24 Mar 2013 16:18:06 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 7D87421F8E14 for ; Sun, 24 Mar 2013 16:18:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 32EB9D930B; Mon, 25 Mar 2013 00:18:05 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id RM8U9jjFCYDu; Mon, 25 Mar 2013 00:18:04 +0100 (MET) Received: from [130.216.155.121] (unknown [130.216.155.121]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id F2840D9305; Mon, 25 Mar 2013 00:18:03 +0100 (MET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Brian Trammell In-Reply-To: <514F856F.9040601@cisco.com> Date: Mon, 25 Mar 2013 12:17:59 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: <3F56EE0C-0200-4903-AA8B-EF8DE3E7E278@tik.ee.ethz.ch> References: <20130320111156.95E65B1E003@rfc-editor.org> <514F856F.9040601@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1499) Cc: ipfix@ietf.org Subject: Re: [IPFIX] [Technical Errata Reported] RFC5655 (3560) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 23:18:07 -0000 Hi, Benoit, Though technically correct, this is, in my view, not what the range = attribute in the registry is for.=20 The intention of the restriction on the value of the messageScope IE is = to be clear that it is not intended to convey any data in the record, = simply to convey information in the type represented by the template. = "Range" implies to me that the values actually have semantics. Further, it is not clear that it makes sense to go through the errata = process _first_ on definitions of IEs in RFCs when we've just gone to a = fair amount of effort to be very clear (through 5102bis and ie-doctors) = that the IANA registry is the canonical reference for the information = model. Otherwise, we logically have to file errata on 5102 every time = the original IEs are updated through the ie-doctors process, which just = seems like a lot of extra bureaucracy to me. Regards, Brian On 25 Mar 2013, at 11:59, Benoit Claise wrote: > Hi, >=20 > This errata looks fine to me, but I want to hear from authors first, = as this is the first time we will have a range of "0-0" in the IPFIX = IANA registry. >=20 > Regards, Benoit >> The following errata report has been submitted for RFC5655, >> "Specification of the IP Flow Information Export (IPFIX) File = Format". >>=20 >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3D5655&eid=3D3560 >>=20 >> -------------------------------------- >> Type: Technical >> Reported by: Paul Aitken >>=20 >> Section: 8.2.11 + .18 >>=20 >> Original Text >> ------------- >> (none) >>=20 >> Corrected Text >> -------------- >> Range: The valid range is 0-0. >>=20 >> Notes >> ----- >> 8.2.11 messageScope requires a value of 0 ("The value of this = Information Element MUST be written as 0") but no range is given. The = range should say "0-0". (Compare with text in RFC 5102). >>=20 >>=20 >>=20 >> Similarly for 8.2.18 sessionScope. >>=20 >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >>=20 >> -------------------------------------- >> RFC5655 (draft-ietf-ipfix-file-05) >> -------------------------------------- >> Title : Specification of the IP Flow Information Export = (IPFIX) File Format >> Publication Date : October 2009 >> Author(s) : B. Trammell, E. Boschi, L. Mark, T. Zseby, A. = Wagner >> Category : PROPOSED STANDARD >> Source : IP Flow Information Export >> Area : Operations and Management >> Stream : IETF >> Verifying Party : IESG >>=20 >>=20 >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From trammell@tik.ee.ethz.ch Sun Mar 24 17:32:34 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC70B21F8A85 for ; Sun, 24 Mar 2013 17:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUjtdNZOaZeI for ; Sun, 24 Mar 2013 17:32:33 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id EF0B021F8A7B for ; Sun, 24 Mar 2013 17:32:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id B5D44D9308; Mon, 25 Mar 2013 01:32:31 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id oj38GZqL9Ggt; Mon, 25 Mar 2013 01:32:31 +0100 (MET) Received: from [130.216.155.121] (unknown [130.216.155.121]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 6293BD9305; Mon, 25 Mar 2013 01:32:30 +0100 (MET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Brian Trammell In-Reply-To: <000601ce2629$a6f0da00$f4d28e00$@theiet.org> Date: Mon, 25 Mar 2013 13:32:25 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: <372611A3-F9A5-462F-888A-1742DDF66209@tik.ee.ethz.ch> References: <000601ce2629$a6f0da00$f4d28e00$@theiet.org> To: steve.nash@theiet.org X-Mailer: Apple Mail (2.1499) Cc: ipfix@ietf.org Subject: Re: [IPFIX] UDP Sequence Numbers rfc 5101 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 00:32:34 -0000 Hi, Steve, This is an error in RFC 5101; the intent of the Sequence Number is that = it be Observation Domain (and in the case of SCTP, Stream) scoped (i.e., = you are correct that transport independence, to the extent possible, is = the intent). The language in the present revision of 5101bis still = contains the same error. Thanks for the catch! I would suggest we fix this by replacing the paragraph in question as = follows: OLD: The Collecting Process SHOULD deduce the loss and reordering of IPFIX Data Records by looking at the discontinuities in the IPFIX Sequence Number. In the case of UDP, the IPFIX Sequence Number contains the total number of IPFIX Data Records sent for the UDP Transport Session prior to the receipt of this IPFIX Message, modulo 2^32. A Collector SHOULD detect out-of-sequence, dropped, or duplicate IPFIX Messages by tracking the Sequence Number.=20 NEW: The Collecting Process SHOULD deduce the loss and reordering of IPFIX Data Records by looking at the discontinuities in the IPFIX Sequence Number. In the case of UDP, the IPFIX Sequence Number contains the total number of IPFIX Data Records sent for the Observation Domain in = the current UDP Transport Session prior to the receipt of this IPFIX = Message,=20 modulo 2^32. A Collector SHOULD detect out-of-sequence, dropped, or=20= duplicate IPFIX Messages by tracking the Sequence Number.=20 The document is presently in Publication Requested state, so I think = this should be placed as an RFC editor note on the document. WG: any = comments thereon? Best regards, Brian On 22 Mar 2013, at 0:45, Steve Nash wrote: > Please consider the wording of the paragraph on Sequence Numbers in = Section 3.1. > Incremental sequence counter modulo 2^32 of all IPFIX Data = Records > sent in the current stream from the current Observation Domain = by > the Exporting Process. Each SCTP Stream counts sequence numbers > separately, while all messages in a TCP connection or UDP > transport session are considered to be part of the same stream. > The phrase I have put in italics is depended on Transport protocol. > Section 10.3.2 Reliability says: > =20 > In the case of UDP, the IPFIX Sequence Number contains the > total number of IPFIX Data Records sent for the UDP Transport Session > prior to the receipt of this IPFIX Message > =20 > This is NOT dependent on the ObservationDomain. Nothing prohibits the = Exporting Process from using the same Transport Session for multiple = Observation Domains. But in UDP the Sequence number is for the = Transport session, whereas in TCP and SCTP each Observation Domain has = an independent sequence on the same (and on each) Transport Session. > =20 > The term =91Stream=92 seems to take different meanings in IPFIX, = depending on the transport protocol. > This is not consistent with IPFIX being =93Transport protocol = independent =93 (Section 10 first para). > =20 > Regards > Steve Nash > steve.nash@theiet.org > UK > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From bclaise@cisco.com Sun Mar 24 17:40:08 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE16021F8C5D for ; Sun, 24 Mar 2013 17:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.471 X-Spam-Level: X-Spam-Status: No, score=-10.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4me-36rcuc0 for ; Sun, 24 Mar 2013 17:40:07 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id A0F0A21F8CE9 for ; Sun, 24 Mar 2013 17:39:51 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r2P0DBgN003687; Mon, 25 Mar 2013 01:13:11 +0100 (CET) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r2P0COI4009335; Mon, 25 Mar 2013 01:12:46 +0100 (CET) Message-ID: <514F9642.1030904@cisco.com> Date: Mon, 25 Mar 2013 01:11:46 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Brian Trammell References: <20130320111156.95E65B1E003@rfc-editor.org> <514F856F.9040601@cisco.com> <3F56EE0C-0200-4903-AA8B-EF8DE3E7E278@tik.ee.ethz.ch> In-Reply-To: <3F56EE0C-0200-4903-AA8B-EF8DE3E7E278@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfix@ietf.org Subject: Re: [IPFIX] [Technical Errata Reported] RFC5655 (3560) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 00:40:08 -0000 Hi Brian, > Hi, Benoit, > > Though technically correct, this is, in my view, not what the range attribute in the registry is for. I accept this point of view (as well). I propose that the ie-doctors discuss this issue, and come back with a consensus on this corner case. > > The intention of the restriction on the value of the messageScope IE is to be clear that it is not intended to convey any data in the record, simply to convey information in the type represented by the template. "Range" implies to me that the values actually have semantics. > > Further, it is not clear that it makes sense to go through the errata process _first_ on definitions of IEs in RFCs when we've just gone to a fair amount of effort to be very clear (through 5102bis and ie-doctors) that the IANA registry is the canonical reference for the information model. Otherwise, we logically have to file errata on 5102 every time the original IEs are updated through the ie-doctors process, which just seems like a lot of extra bureaucracy to me. We have to distinguish three types of errata, depending on the content of the "requester" in the IPFIX IANA registry 1. it contains RFC5102. I agree with you. Let's wait for the [RFC5102bis} and [ie-doctors] 2. it doesn't contain any specific RFC: let's do the change directly in IANA 3. it contains a RFC but not RFC5102. In that case, we need an errata on the originating RFC, which in turn, will change the IANA registry The errata in question is about messageScope, which falls in the category 3. Regards, Benoit > > Regards, > > Brian > > On 25 Mar 2013, at 11:59, Benoit Claise wrote: > >> Hi, >> >> This errata looks fine to me, but I want to hear from authors first, as this is the first time we will have a range of "0-0" in the IPFIX IANA registry. >> >> Regards, Benoit >>> The following errata report has been submitted for RFC5655, >>> "Specification of the IP Flow Information Export (IPFIX) File Format". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata_search.php?rfc=5655&eid=3560 >>> >>> -------------------------------------- >>> Type: Technical >>> Reported by: Paul Aitken >>> >>> Section: 8.2.11 + .18 >>> >>> Original Text >>> ------------- >>> (none) >>> >>> Corrected Text >>> -------------- >>> Range: The valid range is 0-0. >>> >>> Notes >>> ----- >>> 8.2.11 messageScope requires a value of 0 ("The value of this Information Element MUST be written as 0") but no range is given. The range should say "0-0". (Compare with text in RFC 5102). >>> >>> >>> >>> Similarly for 8.2.18 sessionScope. >>> >>> Instructions: >>> ------------- >>> This errata is currently posted as "Reported". If necessary, please >>> use "Reply All" to discuss whether it should be verified or >>> rejected. When a decision is reached, the verifying party (IESG) >>> can log in to change the status and edit the report, if necessary. >>> >>> -------------------------------------- >>> RFC5655 (draft-ietf-ipfix-file-05) >>> -------------------------------------- >>> Title : Specification of the IP Flow Information Export (IPFIX) File Format >>> Publication Date : October 2009 >>> Author(s) : B. Trammell, E. Boschi, L. Mark, T. Zseby, A. Wagner >>> Category : PROPOSED STANDARD >>> Source : IP Flow Information Export >>> Area : Operations and Management >>> Stream : IETF >>> Verifying Party : IESG >>> >>> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix > > From andrewf@plixer.com Mon Mar 25 09:28:21 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B33AA21F8C9A for ; Mon, 25 Mar 2013 09:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fgaimirJ5dH for ; Mon, 25 Mar 2013 09:28:21 -0700 (PDT) Received: from smtp.plixer.com (smtp.plixer.com [64.140.243.151]) by ietfa.amsl.com (Postfix) with ESMTP id C600521F8C9E for ; Mon, 25 Mar 2013 09:28:20 -0700 (PDT) Received: from [10.11.1.15] ([10.11.1.15]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Mar 2013 12:28:12 -0400 Message-ID: <51507B22.4080102@plixer.com> Date: Mon, 25 Mar 2013 12:28:18 -0400 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: ipfix@ietf.org References: <000601ce2629$a6f0da00$f4d28e00$@theiet.org> <372611A3-F9A5-462F-888A-1742DDF66209@tik.ee.ethz.ch> In-Reply-To: <372611A3-F9A5-462F-888A-1742DDF66209@tik.ee.ethz.ch> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 25 Mar 2013 16:28:12.0721 (UTC) FILETIME=[BEAC7A10:01CE2975] Subject: Re: [IPFIX] UDP Sequence Numbers rfc 5101 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 16:28:21 -0000 Hi Brian, I'm OK with your text as an editor note. That is how I always interpreted that section anyway. However, if we are wordsmithing I have one other nit in this section. The sequence number may not be "the total number of IPFIX Data Records sent for the UDP Transport Session prior to the receipt of this IPFIX Message" unless we assume in order (and instant ;) delivery. Maybe transmission instead of receipt. -Andrew On 03/24/2013 08:32 PM, Brian Trammell wrote: > Hi, Steve, > > This is an error in RFC 5101; the intent of the Sequence Number is that it be Observation Domain (and in the case of SCTP, Stream) scoped (i.e., you are correct that transport independence, to the extent possible, is the intent). The language in the present revision of 5101bis still contains the same error. Thanks for the catch! > > I would suggest we fix this by replacing the paragraph in question as follows: > > OLD: > > The Collecting Process SHOULD deduce the loss and reordering of IPFIX > Data Records by looking at the discontinuities in the IPFIX Sequence > Number. In the case of UDP, the IPFIX Sequence Number contains the > total number of IPFIX Data Records sent for the UDP Transport Session > prior to the receipt of this IPFIX Message, modulo 2^32. A Collector > SHOULD detect out-of-sequence, dropped, or duplicate IPFIX Messages > by tracking the Sequence Number. > > NEW: > > The Collecting Process SHOULD deduce the loss and reordering of IPFIX > Data Records by looking at the discontinuities in the IPFIX Sequence > Number. In the case of UDP, the IPFIX Sequence Number contains the > total number of IPFIX Data Records sent for the Observation Domain in the > current UDP Transport Session prior to the receipt of this IPFIX Message, > modulo 2^32. A Collector SHOULD detect out-of-sequence, dropped, or > duplicate IPFIX Messages by tracking the Sequence Number. > > The document is presently in Publication Requested state, so I think this should be placed as an RFC editor note on the document. WG: any comments thereon? > > Best regards, > > Brian > > On 22 Mar 2013, at 0:45, Steve Nash wrote: > >> Please consider the wording of the paragraph on Sequence Numbers in Section 3.1. >> Incremental sequence counter modulo 2^32 of all IPFIX Data Records >> sent in the current stream from the current Observation Domain by >> the Exporting Process. Each SCTP Stream counts sequence numbers >> separately, while all messages in a TCP connection or UDP >> transport session are considered to be part of the same stream. >> The phrase I have put in italics is depended on Transport protocol. >> Section 10.3.2 Reliability says: >> >> In the case of UDP, the IPFIX Sequence Number contains the >> total number of IPFIX Data Records sent for the UDP Transport Session >> prior to the receipt of this IPFIX Message >> >> This is NOT dependent on the ObservationDomain. Nothing prohibits the Exporting Process from using the same Transport Session for multiple Observation Domains. But in UDP the Sequence number is for the Transport session, whereas in TCP and SCTP each Observation Domain has an independent sequence on the same (and on each) Transport Session. >> >> The term ‘Stream’ seems to take different meanings in IPFIX, depending on the transport protocol. >> This is not consistent with IPFIX being “Transport protocol independent “ (Section 10 first para). >> >> Regards >> Steve Nash >> steve.nash@theiet.org >> UK >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From trammell@tik.ee.ethz.ch Mon Mar 25 11:29:36 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DCDE21F9005 for ; Mon, 25 Mar 2013 11:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4b0+EzrTtVV for ; Mon, 25 Mar 2013 11:29:35 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF0C21F8C9A for ; Mon, 25 Mar 2013 11:29:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 1AF90D9309; Mon, 25 Mar 2013 19:29:32 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id JyvxaRFQdvJm; Mon, 25 Mar 2013 19:29:31 +0100 (MET) Received: from [192.168.0.5] (unknown [121.99.65.160]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 83776D9307; Mon, 25 Mar 2013 19:29:30 +0100 (MET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Brian Trammell In-Reply-To: <51507B22.4080102@plixer.com> Date: Tue, 26 Mar 2013 07:29:25 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <000601ce2629$a6f0da00$f4d28e00$@theiet.org> <372611A3-F9A5-462F-888A-1742DDF66209@tik.ee.ethz.ch> <51507B22.4080102@plixer.com> To: Andrew Feren X-Mailer: Apple Mail (2.1499) Cc: ipfix@ietf.org Subject: Re: [IPFIX] UDP Sequence Numbers rfc 5101 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 18:29:36 -0000 On 26 Mar 2013, at 5:28, Andrew Feren wrote: > Hi Brian, >=20 > I'm OK with your text as an editor note. That is how I always = interpreted that section anyway. However, if we are wordsmithing I have = one other nit in this section. >=20 > The sequence number may not be "the total number of IPFIX Data Records = sent for the UDP Transport Session prior to the receipt of this IPFIX = Message" unless we assume in order (and instant ;) delivery. Maybe = transmission instead of receipt. Hi, Andrew, Excellent point. So now we have: NEW: The Collecting Process SHOULD deduce the loss and reordering of IPFIX Data Records by looking at the discontinuities in the IPFIX Sequence Number. In the case of UDP, the IPFIX Sequence Number contains the total number of IPFIX Data Records sent for the Observation Domain in = the current UDP Transport Session prior to the transmission of this IPFIX = Message, modulo 2^32. A Collector SHOULD detect out-of-sequence, dropped, or duplicate IPFIX Messages by tracking the Sequence Number. Thanks, Brian > -Andrew >=20 > On 03/24/2013 08:32 PM, Brian Trammell wrote: >> Hi, Steve, >>=20 >> This is an error in RFC 5101; the intent of the Sequence Number is = that it be Observation Domain (and in the case of SCTP, Stream) scoped = (i.e., you are correct that transport independence, to the extent = possible, is the intent). The language in the present revision of = 5101bis still contains the same error. Thanks for the catch! >>=20 >> I would suggest we fix this by replacing the paragraph in question as = follows: >>=20 >> OLD: >>=20 >> The Collecting Process SHOULD deduce the loss and reordering of = IPFIX >> Data Records by looking at the discontinuities in the IPFIX = Sequence >> Number. In the case of UDP, the IPFIX Sequence Number contains = the >> total number of IPFIX Data Records sent for the UDP Transport = Session >> prior to the receipt of this IPFIX Message, modulo 2^32. A = Collector >> SHOULD detect out-of-sequence, dropped, or duplicate IPFIX = Messages >> by tracking the Sequence Number. >>=20 >> NEW: >>=20 >> The Collecting Process SHOULD deduce the loss and reordering of = IPFIX >> Data Records by looking at the discontinuities in the IPFIX = Sequence >> Number. In the case of UDP, the IPFIX Sequence Number contains = the >> total number of IPFIX Data Records sent for the Observation Domain = in the >> current UDP Transport Session prior to the receipt of this IPFIX = Message, >> modulo 2^32. A Collector SHOULD detect out-of-sequence, dropped, = or >> duplicate IPFIX Messages by tracking the Sequence Number. >>=20 >> The document is presently in Publication Requested state, so I think = this should be placed as an RFC editor note on the document. WG: any = comments thereon? >>=20 >> Best regards, >>=20 >> Brian >>=20 >> On 22 Mar 2013, at 0:45, Steve Nash wrote: >>=20 >>> Please consider the wording of the paragraph on Sequence Numbers in = Section 3.1. >>> Incremental sequence counter modulo 2^32 of all IPFIX Data = Records >>> sent in the current stream from the current Observation Domain = by >>> the Exporting Process. Each SCTP Stream counts sequence = numbers >>> separately, while all messages in a TCP connection or UDP >>> transport session are considered to be part of the same = stream. >>> The phrase I have put in italics is depended on Transport protocol. >>> Section 10.3.2 Reliability says: >>> In the case of UDP, the IPFIX Sequence Number contains the >>> total number of IPFIX Data Records sent for the UDP Transport = Session >>> prior to the receipt of this IPFIX Message >>> This is NOT dependent on the ObservationDomain. Nothing prohibits = the Exporting Process from using the same Transport Session for multiple = Observation Domains. But in UDP the Sequence number is for the = Transport session, whereas in TCP and SCTP each Observation Domain has = an independent sequence on the same (and on each) Transport Session. >>> The term =91Stream=92 seems to take different meanings in IPFIX, = depending on the transport protocol. >>> This is not consistent with IPFIX being =93Transport protocol = independent =93 (Section 10 first para). >>> Regards >>> Steve Nash >>> steve.nash@theiet.org >>> UK >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From trammell@tik.ee.ethz.ch Mon Mar 25 13:44:57 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F59121F9165 for ; Mon, 25 Mar 2013 13:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R+65Wo3PIyHn for ; Mon, 25 Mar 2013 13:44:55 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 6370A21F93D1 for ; Mon, 25 Mar 2013 13:44:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 1CF17D930A for ; Mon, 25 Mar 2013 21:44:49 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id R0lAo5ST6fii for ; Mon, 25 Mar 2013 21:44:48 +0100 (MET) Received: from [192.168.0.5] (unknown [121.99.65.160]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 34077D9307 for ; Mon, 25 Mar 2013 21:44:47 +0100 (MET) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <86232477-BD1D-4F4D-B290-0CE75FF6AB75@tik.ee.ethz.ch> Date: Tue, 26 Mar 2013 09:44:44 +1300 To: "ipfix@ietf.org Working Group" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [IPFIX] Editorial change to RFC5102bis X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 20:44:58 -0000 Greetings, all,=20 During discussions concerning requests for changes to existing = Information Elements from consistency on the ie-doctors list, Paul = Aitken noted that the definition of "octetArray" (3.1.13) refers to = "strings" of octets and the definition of string (3.1.14) refers to = "strings" of characters. This could be read as confusingly circular; the = correct terminology would would be "sequences". This seems like an editorial change to me, and as the document is still = in the RFC Editor queue, I'd like to send an RFC Editor note up with the = following change for clarity: OLD: 3.1.13. octetArray The type "octetArray" represents a finite-length string of octets. 3.1.14. string The type "string" represents a finite-length string of valid=20 characters from the Unicode coded character set [ISO.10646].=20 NEW: 3.1.13. octetArray The type "octetArray" represents a finite-length sequence of octets. 3.1.14. string The type "string" represents a finite-length sequence of valid=20 characters from the Unicode coded character set [ISO.10646].=20 Comments? What's the correct procedure for this? Thanks, best regards, Brian= From paitken@cisco.com Tue Mar 26 05:20:58 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF6B21F8ABA for ; Tue, 26 Mar 2013 05:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ub++A3MVKULi for ; Tue, 26 Mar 2013 05:20:57 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 426A321F8AA6 for ; Tue, 26 Mar 2013 05:20:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8983; q=dns/txt; s=iport; t=1364300452; x=1365510052; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=F2Y2YrVAt/e8FMzMud+69UUSWciju4tlIc4MpUPtlP4=; b=eD52R/soJufs4y1y5e6O1VHGm6JsxfMcSU86Vg5zzimVKxKdOmbAGLd+ /HgpxHTZZrIH9TymYlV6NpCutHO2yUb/uxAzuMpfoUhcTsUSQC3M9mmm6 bKbbzpkhCJgKizbgzjYZovzv+ULUe+ZFUyMV0xHKZKyS1TJ54URQKivMU Y=; X-IronPort-AV: E=Sophos;i="4.84,911,1355097600"; d="scan'208";a="12902635" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 26 Mar 2013 12:20:51 +0000 Received: from [144.254.153.46] (dhcp-144-254-153-46.cisco.com [144.254.153.46]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r2QCKm7V017315; Tue, 26 Mar 2013 12:20:48 GMT Message-ID: <515192A0.1040409@cisco.com> Date: Tue, 26 Mar 2013 12:20:48 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: Gerhard Muenz References: <510B8EA3.3050205@cisco.com> <511D8010.6030209@cisco.com> <511DFF13.6050001@net.in.tum.de> <51405471.6050406@cisco.com> <5140F2E1.10008@net.in.tum.de> In-Reply-To: <5140F2E1.10008@net.in.tum.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] IPFIX observationPointId uniqueness X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 12:20:58 -0000 Gerhard, My problem is mapping multiple discrete 32-bit number spaces into a single 32-bit Observation Point ID. Keeping track of the mapping could be impossibly expensive: in the worst case, 2^32 IDs x { (8-bit source type) + (32-bit source ID) + (32-bit OPID) } = 36G of memory :-( This suggests that the number space should be carved, so source 1 uses OP IDs 0 - 999, source 2 uses OP IDs 1,000 - 1,999 etc. However I can't do that because there are only 32-bits in the destination (OP ID) number space. Each of the source number spaces is also 32-bits; I can't know whether they'll be linearly allocated or sparsely populated (eg, by a hashing algorithm), so I can't impose that certain bits (eg the topmost bits) be used for the carving. A 64-bit OP ID would really help me. Thanks, P. On 13/03/13 21:42, Gerhard Muenz wrote: > > Paul, > > I always thought of OPID, ODID, MPID, EPID etc. as being abstract > identifiers. If an implementation can map them directly to > implementation-specific internal parameters, that's fine. If not, a > mapping needs to be provided by the device. That's the same for other > data models. > > For example, you would also need to assign ipfixObservationPointIndex > for each OP if you implement IPFIX-MIB. You could use the same value > for the OPID IE. > > If there is no other solution than map 32 bit directly into OPID, I > would prefer changing OPID to unsigned64. > > Regards, > Gerhard > > > On 13.03.2013 11:26, Paul Aitken wrote: >> Gerhard, >> >> We are monitoring traffic in multiple places - at the ingress and egress >> interfaces, at processes, in ACLs, in policies. >> >> Each of these has a unique 32-bit ID (ie, there may be up to N x 32-bit >> IDs). >> >> However, these IDs are in unique number spaces. eg, the interface ID >> could happen to be the same as the process ID or the same as the policy >> ID. So it's not possible to say what the ID represents without knowing >> the type. >> >> You would meet this issue if you monitor interfaces and also want to >> report PSAMP stats for each selection process. Somehow you need to >> report distinct IDs for the interfaces versus the processes. >> >> Several possibilities come to mind: >> >> 1. use multiple different IEs, one per observation point type, with >> multiple templates. This is not ideal, because we have to request new >> IEs for each new observation point type, and store / export multiple >> templates. ie, it adds a layer of unnecessary complexity rather than >> rather than simplifying the export. >> >> 2. implement a conversion function, mapping the N x 32-bit IDs into the >> 1 x 32-bit observationDomainID space. Obviously only a limited number of >> conversions (1/N) are possible, and there'll be a trade-off between the >> table size and lookup time. >> >> 3. associate an observationPointType with each observationPointID, and >> not require any conversion at all. Each internal ID is mapped 1:1 with >> an observationPointId, with uniqueness being determined by the >> associated observationPointType. This is the simplest and cleanest >> solution. >> >> >> So to answer your questions directly: >> >> - Do you really need OPID for your purpose? Have you thought about using >> IEs like ingressPhysicalInterface or ingressInterface? Or, if these IEs >> are not appropriate, about defining new IEs? >> >> - per (1) above, this makes for an unnecessarily complex solution. >> >> >> - If you need to use OPIDs and if you want to avoid any mapping, have >> you thought about assigning the different sources (interface cards, >> VLANs) to different ODs? >> >> - they are all within a single OD. >> - Example use case: report packet counts as traffic progresses >> through selection and filtering within the router. The report will be >> exported in a single message with a single OD in the header. >> It's not possible to export a single cohesive report using >> multiple ODs. >> >> P. >> >> >> >> On 15/02/13 09:25, Gerhard Muenz wrote: >>> >>> Benoit, Paul, >>> >>> Like Benoit, I do not have a good feeling about this proposal. On the >>> other hand, I have not found any RFC that really requires the use of >>> OPIDs. Even RFC5476 leaves it open whether the OP is identified by >>> OPID or any other IE. Therefore, I have been silent until now. >>> >>> IPFIX-CONFIG assumes that the OPID is assigned by the IPFIX device, >>> i.e. it is not a configuration parameter. I think that we agree here. >>> >>> Up to now, the IPFIX RFCs do not impose any restriction on the OPID >>> except for the uniqueness per OD. This means that various >>> implementations are possible right now: >>> 1) OPID is equal to an internal identifier (e.g. internal interface >>> number) or a non-IPFIX MIB index (e.g. ifIndex, entPhysicalIndex). >>> 2) OPID is equal to the IPFIX-MIB index ipfixObservationPointIndex >>> 3) OPID is unrelated to any other index, the IPFIX device provides the >>> internal mapping >>> >>> If IPFIX-MIB is supported by the device, the natural choice for me >>> would be 2). This would allow easy mapping of MIB entries and IPFIX >>> export. >>> >>> As Paul points out, 1) only works as long as the internal identifiers >>> are unique per OD. >>> >>> My questions to Paul are: >>> - Do you really need OPID for your purpose? Have you thought about >>> using IEs like ingressPhysicalInterface or ingressInterface? Or, if >>> these IEs are not appropriate, about defining new IEs? >>> - If you need to use OPIDs and if you want to avoid any mapping, have >>> you thought about assigning the different sources (interface cards, >>> VLANs) to different ODs? >>> >>> Regards, >>> Gerhard >>> >>> >>> On 15.02.2013 01:23, Benoit Claise wrote: >>>> Paul, >>>> >>>> At first glance, it looks reasonable. >>>> But what would be the consequence on the Selection Sequence Report >>>> Interpretation(see >>>> http://tools.ietf.org/html/rfc5476#section-6.5.1). If >>>> we use the observationPointId and it's not unique, then we need to >>>> include the observationPointType? >>>> Note that the sentence "It is RECOMMENDED that this identifier is also >>>> unique per IPFIX Device." was inserted specifically for this. >>>> >>>> Regards, Benot >>>>> Dear IPFIX experts, >>>>> >>>>> IPFIX observationPointId (#138) is defined as: >>>>> >>>>> An identifier of an Observation Point that is unique per >>>>> Observation Domain. It is RECOMMENDED that this >>>>> identifier is >>>>> also unique per IPFIX Device. Typically, this Information >>>>> Element is used for limiting the scope of other Information >>>>> Elements. >>>>> >>>>> We now also have observationPointType (#277), defined as: >>>>> >>>>> Type of observation point. Values assigned to date are: >>>>> >>>>> 1. Physical port >>>>> 2. Port channel >>>>> 3. Vlan. >>>>> >>>>> >>>>> Could we relax the uniqueness requirements of observationPointId when >>>>> an observationPointType is also exported, such that the { >>>>> observationPointType, observationPointId } pair must be unique, >>>>> though >>>>> not the observationPointId itself. >>>>> >>>>> The reason being that observation points of different types already >>>>> have IDs, though these are not unique. eg, we have interface 1, 2, 3, >>>>> ...; vlan 1, 2, 3, ...; port 1, 2, 3, ... >>>>> >>>>> So an extra mediation layer is required to convert values from >>>>> each of >>>>> these number spaces into unique IDs in the observationPointId number >>>>> space - which becomes harder as we add more places that observations >>>>> can be made, ie more observationPointTypes. >>>>> >>>>> Whereas prefixing with the observationPointType achieves the required >>>>> uniqueness in a faster, simpler, and more reliable way. >>>>> >>>>> To achieve this, I'd propose the following definition change: >>>>> >>>>> An identifier of an Observation Point that is unique per >>>>> Observation Domain and per observationPointType, if >>>>> specified. >>>>> It is RECOMMENDED that this identifier is >>>>> also unique per IPFIX Device. Typically, this Information >>>>> Element is used for limiting the scope of other Information >>>>> Elements. >>>>> >>>>> For backwards compatibility, we could define observationPointType = 0 >>>>> to be "unspecified". >>>>> >>>>> Thanks, >>>>> P. >>>>> >>>>> >>>>> _______________________________________________ >>>>> IPFIX mailing list >>>>> IPFIX@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ipfix >>>> >>>> >>>> >>>> _______________________________________________ >>>> IPFIX mailing list >>>> IPFIX@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipfix >>>> >> From ramk@Brocade.com Wed Mar 27 10:40:36 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 961A821F9259 for ; Wed, 27 Mar 2013 10:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.264 X-Spam-Level: X-Spam-Status: No, score=-3.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENw3kkBLue2V for ; Wed, 27 Mar 2013 10:40:36 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by ietfa.amsl.com (Postfix) with ESMTP id 1DBC921F9258 for ; Wed, 27 Mar 2013 10:40:35 -0700 (PDT) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id r2RHccXq007459; Wed, 27 Mar 2013 10:40:35 -0700 Received: from hq1wp-exchub02.corp.brocade.com ([144.49.131.13]) by mx0a-000f0801.pphosted.com with ESMTP id 1bbmd18g7n-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 27 Mar 2013 10:40:35 -0700 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by hq1wp-exchub02.corp.brocade.com (10.70.38.99) with Microsoft SMTP Server (TLS) id 14.2.309.2; Wed, 27 Mar 2013 10:40:35 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::8c73:93bf:41b4:1443]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Wed, 27 Mar 2013 10:40:29 -0700 From: ramki Krishnan To: IPFIX Working Group Date: Wed, 27 Mar 2013 10:40:19 -0700 Thread-Topic: clarification questions Thread-Index: Ac4rEiYqMvIZQbCfRe6WXAknmGcfKQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7634EB63EFD984A978DFB46EA5174F2BFD7ECDAFAHQ1EXCH01corp_" MIME-Version: 1.0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1211240000 definitions=main-1303270166 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-03-27_07:2013-03-26, 2013-03-27, 1970-01-01 signatures=0 Cc: Ning So Subject: [IPFIX] clarification questions X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 17:40:36 -0000 --_000_C7634EB63EFD984A978DFB46EA5174F2BFD7ECDAFAHQ1EXCH01corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear IPFIX experts, >From RFC 6728, 1. Section 4.3.2 o Is there a way to periodically export the flows if we are using a Timeo= utCache or NaturalCache ? 2. Suppose we want to populate the cache only with long-lived large f= lows (see Note1 below for data model definitions) o One way to achieve this would be to have a selection process, using a u= nique observation domain, which filters the long-lived large flows. Are any= other better ways ? 3. Continuing from 3) - suppose we want to sample the other flows (no= t the long-lived large flows) o Is there a way to not include the long-lived large flows in the selecti= on process ? Note 1: - observationInterval: The minimum time interval to observe a flow= for performing further processing of the flow. Unit is in seconds. - bandwidthThreshold: The minimum bandwidth of the flow during the= observation interval for declaring the flow a long-lived large flow. Unit = is in Mbps. For example, a flow which is at or above 10 Mbps (bandwidthThreshold )for a= time period of at least 30 seconds (observationInterval) could be declared= a long-lived large flow. -- Thanks, Ram (aka Ramki) --_000_C7634EB63EFD984A978DFB46EA5174F2BFD7ECDAFAHQ1EXCH01corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear IPFIX exper= ts,

 

From RFC 6728,

1. &= nbsp;     Section 4.3.2

o   Is there = a way to periodically export the flows if we are using a TimeoutCache or Na= turalCache ?

2.  &nbs= p;    Suppose we want to populate th= e cache only with long-lived large flows (see Note1  below for data mo= del definitions)

= o   One way to achieve this would be to have a selection process= , using a unique observation domain, which filters the long-lived large flo= ws. Are any other better ways ?

3.o   Is there a way to not include the long-lived large flows in the sele= ction process ?

 

Note 1:

=

-       &nb= sp;  observationInterval: The minimum time int= erval to observe a flow for performing further processing of the flow. Unit= is in seconds.

-  &nb= sp;       bandwidthTh= reshold: The minimum bandwidth of the flow during the observation interval = for declaring the flow a long-lived large flow. Unit is in Mbps.=

For example, a flow which is at or above 10 Mbps (= bandwidthThreshold )for a time period of at least 30 seconds (observationIn= terval) could be declared a long-lived large flow.

 

--

Thanks,

Ram (aka Ramki= )

 

= --_000_C7634EB63EFD984A978DFB46EA5174F2BFD7ECDAFAHQ1EXCH01corp_-- From andrewf@plixer.com Wed Mar 27 11:10:29 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA6121F9215 for ; Wed, 27 Mar 2013 11:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cK8avSd9pF0K for ; Wed, 27 Mar 2013 11:10:28 -0700 (PDT) Received: from smtp.plixer.com (smtp.plixer.com [64.140.243.151]) by ietfa.amsl.com (Postfix) with ESMTP id 526A721F9128 for ; Wed, 27 Mar 2013 11:10:28 -0700 (PDT) Received: from [10.11.1.15] ([10.11.1.15]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Mar 2013 14:10:26 -0400 Message-ID: <5153361B.2090101@plixer.com> Date: Wed, 27 Mar 2013 14:10:35 -0400 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: ramki Krishnan References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030306060203010302090106" X-OriginalArrivalTime: 27 Mar 2013 18:10:26.0607 (UTC) FILETIME=[5B94B3F0:01CE2B16] Cc: Ning So , IPFIX Working Group Subject: Re: [IPFIX] clarification questions X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 18:10:29 -0000 This is a multi-part message in MIME format. --------------030306060203010302090106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Ram, On 03/27/2013 01:40 PM, ramki Krishnan wrote: > > Dear IPFIX experts, > > From RFC 6728, > > 1.Section 4.3.2 > > oIs there a way to periodically export the flows if we are using a > TimeoutCache or NaturalCache ? > Maybe I'm not understanding your question, but periodic export of flows is exactly what I would expect with with a TimeoutCache or NaturalCache. After an activeTimeout, for example, flows are exported with the observed values for that inteverval (using IEs with deltaCounter semantics for any counters). > 2.Suppose we want to populate the cache only with long-lived large > flows (see Note1 below for data model definitions) > > oOne way to achieve this would be to have a selection process, using a > unique observation domain, which filters the long-lived large flows. > Are any other better ways ? > > 3.Continuing from 3) - suppose we want to sample the other flows (not > the long-lived large flows) > > oIs there a way to not include the long-lived large flows in the > selection process ? > What are you trying to accomplish? This feels like a catch-22 to me. Do you intend to sample all flows until they cross some threshold? Based on your description I'm not sure how you would know a flow was long lived until after observationInterval and/or bandwidthThreshold. -Andrew > Note 1: > > -observationInterval: The minimum time interval to observe a flow for > performing further processing of the flow. Unit is in seconds. > > -bandwidthThreshold: The minimum bandwidth of the flow during the > observation interval for declaring the flow a long-lived large flow. > Unit is in Mbps. > > For example, a flow which is at or above 10 Mbps (bandwidthThreshold > )for a time period of at least 30 seconds (observationInterval) could > be declared a long-lived large flow. > > -- > > Thanks, > > Ram (aka Ramki) > > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --------------030306060203010302090106 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Ram,

On 03/27/2013 01:40 PM, ramki Krishnan wrote:

Dear IPFIX experts,

 

From RFC 6728,

1.       Section 4.3.2

o   Is there a way to periodically export the flows if we are using a TimeoutCache or NaturalCache ?


Maybe I'm not understanding your question, but periodic export of flows is exactly what I would expect with with a TimeoutCache or NaturalCache.  After an activeTimeout, for example, flows are exported with the observed values for that inteverval (using IEs with deltaCounter semantics for any counters).

2.       Suppose we want to populate the cache only with long-lived large flows (see Note1  below for data model definitions)

o   One way to achieve this would be to have a selection process, using a unique observation domain, which filters the long-lived large flows. Are any other better ways ?

3.       Continuing from 3) - suppose we want to sample the other flows (not the long-lived large flows)

o   Is there a way to not include the long-lived large flows in the selection process ?


What are you trying to accomplish?  This feels like a catch-22 to me.  Do you intend to sample all flows until they cross some threshold?  Based on your description I'm not sure how you would know a flow was long lived until after observationInterval and/or bandwidthThreshold.

-Andrew

 

Note 1:

-          observationInterval: The minimum time interval to observe a flow for performing further processing of the flow. Unit is in seconds.

-          bandwidthThreshold: The minimum bandwidth of the flow during the observation interval for declaring the flow a long-lived large flow. Unit is in Mbps.

For example, a flow which is at or above 10 Mbps (bandwidthThreshold )for a time period of at least 30 seconds (observationInterval) could be declared a long-lived large flow.

 

--

Thanks,

Ram (aka Ramki)

 



_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

--------------030306060203010302090106-- From muenz@net.in.tum.de Wed Mar 27 13:54:01 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45C5B21F9292 for ; Wed, 27 Mar 2013 13:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvtQlrR46O1m for ; Wed, 27 Mar 2013 13:53:59 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mailsender1.informatik.tu-muenchen.de [131.159.0.97]) by ietfa.amsl.com (Postfix) with ESMTP id 9B83621F9290 for ; Wed, 27 Mar 2013 13:53:58 -0700 (PDT) Received: from [192.168.2.32] (g230149236.adsl.alicedsl.de [92.230.149.236]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 86F8F1950A94; Wed, 27 Mar 2013 21:53:55 +0100 (CET) Message-ID: <51535C6B.70501@net.in.tum.de> Date: Wed, 27 Mar 2013 21:54:03 +0100 From: Gerhard Muenz User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Paul Aitken References: <510B8EA3.3050205@cisco.com> <511D8010.6030209@cisco.com> <511DFF13.6050001@net.in.tum.de> <51405471.6050406@cisco.com> <5140F2E1.10008@net.in.tum.de> <515192A0.1040409@cisco.com> In-Reply-To: <515192A0.1040409@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] IPFIX observationPointId uniqueness X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 20:54:01 -0000 Paul, I do not see any problem with 64bit OP ID. I think, we had a similar motivation for having 64bit selector IDs/selection sequence IDs. Will it confuse existing collectors? (hopefully not) Regards, Gerhard On 26.03.2013 13:20, Paul Aitken wrote: > Gerhard, > > My problem is mapping multiple discrete 32-bit number spaces into a > single 32-bit Observation Point ID. > > Keeping track of the mapping could be impossibly expensive: in the worst > case, 2^32 IDs x { (8-bit source type) + (32-bit source ID) + (32-bit > OPID) } = 36G of memory :-( > > This suggests that the number space should be carved, so source 1 uses > OP IDs 0 - 999, source 2 uses OP IDs 1,000 - 1,999 etc. However I can't > do that because there are only 32-bits in the destination (OP ID) number > space. Each of the source number spaces is also 32-bits; I can't know > whether they'll be linearly allocated or sparsely populated (eg, by a > hashing algorithm), so I can't impose that certain bits (eg the topmost > bits) be used for the carving. > > A 64-bit OP ID would really help me. > > Thanks, > P. > > > On 13/03/13 21:42, Gerhard Muenz wrote: >> >> Paul, >> >> I always thought of OPID, ODID, MPID, EPID etc. as being abstract >> identifiers. If an implementation can map them directly to >> implementation-specific internal parameters, that's fine. If not, a >> mapping needs to be provided by the device. That's the same for other >> data models. >> >> For example, you would also need to assign ipfixObservationPointIndex >> for each OP if you implement IPFIX-MIB. You could use the same value >> for the OPID IE. >> >> If there is no other solution than map 32 bit directly into OPID, I >> would prefer changing OPID to unsigned64. >> >> Regards, >> Gerhard >> >> >> On 13.03.2013 11:26, Paul Aitken wrote: >>> Gerhard, >>> >>> We are monitoring traffic in multiple places - at the ingress and egress >>> interfaces, at processes, in ACLs, in policies. >>> >>> Each of these has a unique 32-bit ID (ie, there may be up to N x 32-bit >>> IDs). >>> >>> However, these IDs are in unique number spaces. eg, the interface ID >>> could happen to be the same as the process ID or the same as the policy >>> ID. So it's not possible to say what the ID represents without knowing >>> the type. >>> >>> You would meet this issue if you monitor interfaces and also want to >>> report PSAMP stats for each selection process. Somehow you need to >>> report distinct IDs for the interfaces versus the processes. >>> >>> Several possibilities come to mind: >>> >>> 1. use multiple different IEs, one per observation point type, with >>> multiple templates. This is not ideal, because we have to request new >>> IEs for each new observation point type, and store / export multiple >>> templates. ie, it adds a layer of unnecessary complexity rather than >>> rather than simplifying the export. >>> >>> 2. implement a conversion function, mapping the N x 32-bit IDs into the >>> 1 x 32-bit observationDomainID space. Obviously only a limited number of >>> conversions (1/N) are possible, and there'll be a trade-off between the >>> table size and lookup time. >>> >>> 3. associate an observationPointType with each observationPointID, and >>> not require any conversion at all. Each internal ID is mapped 1:1 with >>> an observationPointId, with uniqueness being determined by the >>> associated observationPointType. This is the simplest and cleanest >>> solution. >>> >>> >>> So to answer your questions directly: >>> >>> - Do you really need OPID for your purpose? Have you thought about using >>> IEs like ingressPhysicalInterface or ingressInterface? Or, if these IEs >>> are not appropriate, about defining new IEs? >>> >>> - per (1) above, this makes for an unnecessarily complex solution. >>> >>> >>> - If you need to use OPIDs and if you want to avoid any mapping, have >>> you thought about assigning the different sources (interface cards, >>> VLANs) to different ODs? >>> >>> - they are all within a single OD. >>> - Example use case: report packet counts as traffic progresses >>> through selection and filtering within the router. The report will be >>> exported in a single message with a single OD in the header. >>> It's not possible to export a single cohesive report using >>> multiple ODs. >>> >>> P. >>> >>> >>> >>> On 15/02/13 09:25, Gerhard Muenz wrote: >>>> >>>> Benoit, Paul, >>>> >>>> Like Benoit, I do not have a good feeling about this proposal. On the >>>> other hand, I have not found any RFC that really requires the use of >>>> OPIDs. Even RFC5476 leaves it open whether the OP is identified by >>>> OPID or any other IE. Therefore, I have been silent until now. >>>> >>>> IPFIX-CONFIG assumes that the OPID is assigned by the IPFIX device, >>>> i.e. it is not a configuration parameter. I think that we agree here. >>>> >>>> Up to now, the IPFIX RFCs do not impose any restriction on the OPID >>>> except for the uniqueness per OD. This means that various >>>> implementations are possible right now: >>>> 1) OPID is equal to an internal identifier (e.g. internal interface >>>> number) or a non-IPFIX MIB index (e.g. ifIndex, entPhysicalIndex). >>>> 2) OPID is equal to the IPFIX-MIB index ipfixObservationPointIndex >>>> 3) OPID is unrelated to any other index, the IPFIX device provides the >>>> internal mapping >>>> >>>> If IPFIX-MIB is supported by the device, the natural choice for me >>>> would be 2). This would allow easy mapping of MIB entries and IPFIX >>>> export. >>>> >>>> As Paul points out, 1) only works as long as the internal identifiers >>>> are unique per OD. >>>> >>>> My questions to Paul are: >>>> - Do you really need OPID for your purpose? Have you thought about >>>> using IEs like ingressPhysicalInterface or ingressInterface? Or, if >>>> these IEs are not appropriate, about defining new IEs? >>>> - If you need to use OPIDs and if you want to avoid any mapping, have >>>> you thought about assigning the different sources (interface cards, >>>> VLANs) to different ODs? >>>> >>>> Regards, >>>> Gerhard >>>> >>>> >>>> On 15.02.2013 01:23, Benoit Claise wrote: >>>>> Paul, >>>>> >>>>> At first glance, it looks reasonable. >>>>> But what would be the consequence on the Selection Sequence Report >>>>> Interpretation(see >>>>> http://tools.ietf.org/html/rfc5476#section-6.5.1). If >>>>> we use the observationPointId and it's not unique, then we need to >>>>> include the observationPointType? >>>>> Note that the sentence "It is RECOMMENDED that this identifier is also >>>>> unique per IPFIX Device." was inserted specifically for this. >>>>> >>>>> Regards, Benot >>>>>> Dear IPFIX experts, >>>>>> >>>>>> IPFIX observationPointId (#138) is defined as: >>>>>> >>>>>> An identifier of an Observation Point that is unique per >>>>>> Observation Domain. It is RECOMMENDED that this >>>>>> identifier is >>>>>> also unique per IPFIX Device. Typically, this Information >>>>>> Element is used for limiting the scope of other Information >>>>>> Elements. >>>>>> >>>>>> We now also have observationPointType (#277), defined as: >>>>>> >>>>>> Type of observation point. Values assigned to date are: >>>>>> >>>>>> 1. Physical port >>>>>> 2. Port channel >>>>>> 3. Vlan. >>>>>> >>>>>> >>>>>> Could we relax the uniqueness requirements of observationPointId when >>>>>> an observationPointType is also exported, such that the { >>>>>> observationPointType, observationPointId } pair must be unique, >>>>>> though >>>>>> not the observationPointId itself. >>>>>> >>>>>> The reason being that observation points of different types already >>>>>> have IDs, though these are not unique. eg, we have interface 1, 2, 3, >>>>>> ...; vlan 1, 2, 3, ...; port 1, 2, 3, ... >>>>>> >>>>>> So an extra mediation layer is required to convert values from >>>>>> each of >>>>>> these number spaces into unique IDs in the observationPointId number >>>>>> space - which becomes harder as we add more places that observations >>>>>> can be made, ie more observationPointTypes. >>>>>> >>>>>> Whereas prefixing with the observationPointType achieves the required >>>>>> uniqueness in a faster, simpler, and more reliable way. >>>>>> >>>>>> To achieve this, I'd propose the following definition change: >>>>>> >>>>>> An identifier of an Observation Point that is unique per >>>>>> Observation Domain and per observationPointType, if >>>>>> specified. >>>>>> It is RECOMMENDED that this identifier is >>>>>> also unique per IPFIX Device. Typically, this Information >>>>>> Element is used for limiting the scope of other Information >>>>>> Elements. >>>>>> >>>>>> For backwards compatibility, we could define observationPointType = 0 >>>>>> to be "unspecified". >>>>>> >>>>>> Thanks, >>>>>> P. >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> IPFIX mailing list >>>>>> IPFIX@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ipfix >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> IPFIX mailing list >>>>> IPFIX@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ipfix >>>>> >>> > From muenz@net.in.tum.de Wed Mar 27 14:21:39 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E213921F8EBB for ; Wed, 27 Mar 2013 14:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMrtldEKWfyF for ; Wed, 27 Mar 2013 14:21:38 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mailsender1.informatik.tu-muenchen.de [131.159.0.97]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3C721F8DFB for ; Wed, 27 Mar 2013 14:21:37 -0700 (PDT) Received: from [192.168.2.32] (g230149236.adsl.alicedsl.de [92.230.149.236]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 572061950AD8; Wed, 27 Mar 2013 22:21:34 +0100 (CET) Message-ID: <515362E7.9040306@net.in.tum.de> Date: Wed, 27 Mar 2013 22:21:43 +0100 From: Gerhard Muenz User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: ramki Krishnan References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------020300050403070400000205" Cc: Ning So , IPFIX Working Group Subject: Re: [IPFIX] clarification questions X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 21:21:39 -0000 This is a multi-part message in MIME format. --------------020300050403070400000205 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Ram, The configuration model of RFC 6728 does not cover flow selection. If you want to configure something like flow selection, you need to extend the model. It seems that your actual question is how flow selection fits into the IPFIX device architecture which has been taken as a basis for RFC 6728. Concretely, you seem to wonder whether your flow selection is a kind of Selection Process or a new kind of Cache (or maybe both?). I cannot answer this question because I do not know how it would be implemented. Regarding your question: - With TimeoutCache and NaturalCache, the Flow is only exported when it is expired. At expiration, the Flow is immediately removed from the Cache. A longlasting flow will result in a new Flow being created in the Cache. - It's different with PermanentCache. Here, the Flow remains in the Cache, and the status is periodically exported. Regards, Gerhard On 27.03.2013 18:40, ramki Krishnan wrote: > > Dear IPFIX experts, > > From RFC 6728, > > 1.Section 4.3.2 > > oIs there a way to periodically export the flows if we are using a > TimeoutCache or NaturalCache ? > > 2.Suppose we want to populate the cache only with long-lived large > flows (see Note1 below for data model definitions) > > oOne way to achieve this would be to have a selection process, using a > unique observation domain, which filters the long-lived large flows. > Are any other better ways ? > > 3.Continuing from 3) - suppose we want to sample the other flows (not > the long-lived large flows) > > oIs there a way to not include the long-lived large flows in the > selection process ? > > Note 1: > > -observationInterval: The minimum time interval to observe a flow for > performing further processing of the flow. Unit is in seconds. > > -bandwidthThreshold: The minimum bandwidth of the flow during the > observation interval for declaring the flow a long-lived large flow. > Unit is in Mbps. > > For example, a flow which is at or above 10 Mbps (bandwidthThreshold > )for a time period of at least 30 seconds (observationInterval) could > be declared a long-lived large flow. > > -- > > Thanks, > > Ram (aka Ramki) > > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --------------020300050403070400000205 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Ram,

The configuration model of RFC 6728 does not cover flow selection. If you want to configure something like flow selection, you need to extend the model.

It seems that your actual question is how flow selection fits into the IPFIX device architecture which has been taken as a basis for RFC 6728. Concretely, you seem to wonder  whether your flow selection is a kind of Selection Process or a new kind of Cache (or maybe both?).

I cannot answer this question because I do not know how it would be implemented.

Regarding your question:
- With TimeoutCache and NaturalCache, the Flow is only exported when it is expired. At expiration, the Flow is immediately removed from the Cache. A longlasting flow will result in a new Flow being created in the Cache.
- It's different with PermanentCache. Here, the Flow remains in the Cache, and the status is periodically exported.

Regards,
Gerhard


On 27.03.2013 18:40, ramki Krishnan wrote:

Dear IPFIX experts,

 

From RFC 6728,

1.       Section 4.3.2

o   Is there a way to periodically export the flows if we are using a TimeoutCache or NaturalCache ?

2.       Suppose we want to populate the cache only with long-lived large flows (see Note1  below for data model definitions)

o   One way to achieve this would be to have a selection process, using a unique observation domain, which filters the long-lived large flows. Are any other better ways ?

3.       Continuing from 3) - suppose we want to sample the other flows (not the long-lived large flows)

o   Is there a way to not include the long-lived large flows in the selection process ?

 

Note 1:

-          observationInterval: The minimum time interval to observe a flow for performing further processing of the flow. Unit is in seconds.

-          bandwidthThreshold: The minimum bandwidth of the flow during the observation interval for declaring the flow a long-lived large flow. Unit is in Mbps.

For example, a flow which is at or above 10 Mbps (bandwidthThreshold )for a time period of at least 30 seconds (observationInterval) could be declared a long-lived large flow.

 

--

Thanks,

Ram (aka Ramki)

 



_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

--------------020300050403070400000205-- From paitken@cisco.com Thu Mar 28 02:52:12 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FFBD21F91E6 for ; Thu, 28 Mar 2013 02:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.149 X-Spam-Level: X-Spam-Status: No, score=-10.149 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlcDn47OuQpA for ; Thu, 28 Mar 2013 02:52:11 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 6E57D21F90BC for ; Thu, 28 Mar 2013 02:52:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10057; q=dns/txt; s=iport; t=1364464330; x=1365673930; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=G0pza9vFJhYto5ib18kfoGdZEwbITdD8pNTwlVHvb7I=; b=jNWOJMkaHb7khoqQTcElnxKqBV606x4E/Er8osWsbm5c50qcgWTWaInG 5pASCHQ058rvsJGjqc4LXToImu8zKx0vySO7iqGYizbXv1OQYLmnSneOV K6NfaLAdeANRjI7Gl/OKrv33hEzx8yvMzon6qAOMEgqni0GAdPD5t6cA3 E=; X-IronPort-AV: E=Sophos;i="4.87,365,1363132800"; d="scan'208";a="12487048" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-3.cisco.com with ESMTP; 28 Mar 2013 09:52:09 +0000 Received: from [10.61.164.13] ([10.61.164.13]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2S9q62l020878; Thu, 28 Mar 2013 09:52:06 GMT Message-ID: <515412C7.1010103@cisco.com> Date: Thu, 28 Mar 2013 09:52:07 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Gerhard Muenz References: <510B8EA3.3050205@cisco.com> <511D8010.6030209@cisco.com> <511DFF13.6050001@net.in.tum.de> <51405471.6050406@cisco.com> <5140F2E1.10008@net.in.tum.de> <515192A0.1040409@cisco.com> <51535C6B.70501@net.in.tum.de> In-Reply-To: <51535C6B.70501@net.in.tum.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] IPFIX observationPointId uniqueness X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 09:52:12 -0000 Gerhard, This question needs input from collector experts on this list. P. On 27/03/13 20:54, Gerhard Muenz wrote: > Paul, > > I do not see any problem with 64bit OP ID. > > I think, we had a similar motivation for having 64bit selector > IDs/selection sequence IDs. > > Will it confuse existing collectors? (hopefully not) > > Regards, > Gerhard > > > On 26.03.2013 13:20, Paul Aitken wrote: >> Gerhard, >> >> My problem is mapping multiple discrete 32-bit number spaces into a >> single 32-bit Observation Point ID. >> >> Keeping track of the mapping could be impossibly expensive: in the worst >> case, 2^32 IDs x { (8-bit source type) + (32-bit source ID) + (32-bit >> OPID) } = 36G of memory :-( >> >> This suggests that the number space should be carved, so source 1 uses >> OP IDs 0 - 999, source 2 uses OP IDs 1,000 - 1,999 etc. However I can't >> do that because there are only 32-bits in the destination (OP ID) number >> space. Each of the source number spaces is also 32-bits; I can't know >> whether they'll be linearly allocated or sparsely populated (eg, by a >> hashing algorithm), so I can't impose that certain bits (eg the topmost >> bits) be used for the carving. >> >> A 64-bit OP ID would really help me. >> >> Thanks, >> P. >> >> >> On 13/03/13 21:42, Gerhard Muenz wrote: >>> >>> Paul, >>> >>> I always thought of OPID, ODID, MPID, EPID etc. as being abstract >>> identifiers. If an implementation can map them directly to >>> implementation-specific internal parameters, that's fine. If not, a >>> mapping needs to be provided by the device. That's the same for other >>> data models. >>> >>> For example, you would also need to assign ipfixObservationPointIndex >>> for each OP if you implement IPFIX-MIB. You could use the same value >>> for the OPID IE. >>> >>> If there is no other solution than map 32 bit directly into OPID, I >>> would prefer changing OPID to unsigned64. >>> >>> Regards, >>> Gerhard >>> >>> >>> On 13.03.2013 11:26, Paul Aitken wrote: >>>> Gerhard, >>>> >>>> We are monitoring traffic in multiple places - at the ingress and >>>> egress >>>> interfaces, at processes, in ACLs, in policies. >>>> >>>> Each of these has a unique 32-bit ID (ie, there may be up to N x >>>> 32-bit >>>> IDs). >>>> >>>> However, these IDs are in unique number spaces. eg, the interface ID >>>> could happen to be the same as the process ID or the same as the >>>> policy >>>> ID. So it's not possible to say what the ID represents without knowing >>>> the type. >>>> >>>> You would meet this issue if you monitor interfaces and also want to >>>> report PSAMP stats for each selection process. Somehow you need to >>>> report distinct IDs for the interfaces versus the processes. >>>> >>>> Several possibilities come to mind: >>>> >>>> 1. use multiple different IEs, one per observation point type, with >>>> multiple templates. This is not ideal, because we have to request new >>>> IEs for each new observation point type, and store / export multiple >>>> templates. ie, it adds a layer of unnecessary complexity rather than >>>> rather than simplifying the export. >>>> >>>> 2. implement a conversion function, mapping the N x 32-bit IDs into >>>> the >>>> 1 x 32-bit observationDomainID space. Obviously only a limited >>>> number of >>>> conversions (1/N) are possible, and there'll be a trade-off between >>>> the >>>> table size and lookup time. >>>> >>>> 3. associate an observationPointType with each observationPointID, and >>>> not require any conversion at all. Each internal ID is mapped 1:1 with >>>> an observationPointId, with uniqueness being determined by the >>>> associated observationPointType. This is the simplest and cleanest >>>> solution. >>>> >>>> >>>> So to answer your questions directly: >>>> >>>> - Do you really need OPID for your purpose? Have you thought about >>>> using >>>> IEs like ingressPhysicalInterface or ingressInterface? Or, if these >>>> IEs >>>> are not appropriate, about defining new IEs? >>>> >>>> - per (1) above, this makes for an unnecessarily complex >>>> solution. >>>> >>>> >>>> - If you need to use OPIDs and if you want to avoid any mapping, have >>>> you thought about assigning the different sources (interface cards, >>>> VLANs) to different ODs? >>>> >>>> - they are all within a single OD. >>>> - Example use case: report packet counts as traffic progresses >>>> through selection and filtering within the router. The report will be >>>> exported in a single message with a single OD in the header. >>>> It's not possible to export a single cohesive report using >>>> multiple ODs. >>>> >>>> P. >>>> >>>> >>>> >>>> On 15/02/13 09:25, Gerhard Muenz wrote: >>>>> >>>>> Benoit, Paul, >>>>> >>>>> Like Benoit, I do not have a good feeling about this proposal. On the >>>>> other hand, I have not found any RFC that really requires the use of >>>>> OPIDs. Even RFC5476 leaves it open whether the OP is identified by >>>>> OPID or any other IE. Therefore, I have been silent until now. >>>>> >>>>> IPFIX-CONFIG assumes that the OPID is assigned by the IPFIX device, >>>>> i.e. it is not a configuration parameter. I think that we agree here. >>>>> >>>>> Up to now, the IPFIX RFCs do not impose any restriction on the OPID >>>>> except for the uniqueness per OD. This means that various >>>>> implementations are possible right now: >>>>> 1) OPID is equal to an internal identifier (e.g. internal interface >>>>> number) or a non-IPFIX MIB index (e.g. ifIndex, entPhysicalIndex). >>>>> 2) OPID is equal to the IPFIX-MIB index ipfixObservationPointIndex >>>>> 3) OPID is unrelated to any other index, the IPFIX device provides >>>>> the >>>>> internal mapping >>>>> >>>>> If IPFIX-MIB is supported by the device, the natural choice for me >>>>> would be 2). This would allow easy mapping of MIB entries and IPFIX >>>>> export. >>>>> >>>>> As Paul points out, 1) only works as long as the internal identifiers >>>>> are unique per OD. >>>>> >>>>> My questions to Paul are: >>>>> - Do you really need OPID for your purpose? Have you thought about >>>>> using IEs like ingressPhysicalInterface or ingressInterface? Or, if >>>>> these IEs are not appropriate, about defining new IEs? >>>>> - If you need to use OPIDs and if you want to avoid any mapping, have >>>>> you thought about assigning the different sources (interface cards, >>>>> VLANs) to different ODs? >>>>> >>>>> Regards, >>>>> Gerhard >>>>> >>>>> >>>>> On 15.02.2013 01:23, Benoit Claise wrote: >>>>>> Paul, >>>>>> >>>>>> At first glance, it looks reasonable. >>>>>> But what would be the consequence on the Selection Sequence Report >>>>>> Interpretation(see >>>>>> http://tools.ietf.org/html/rfc5476#section-6.5.1). If >>>>>> we use the observationPointId and it's not unique, then we need to >>>>>> include the observationPointType? >>>>>> Note that the sentence "It is RECOMMENDED that this identifier is >>>>>> also >>>>>> unique per IPFIX Device." was inserted specifically for this. >>>>>> >>>>>> Regards, Benot >>>>>>> Dear IPFIX experts, >>>>>>> >>>>>>> IPFIX observationPointId (#138) is defined as: >>>>>>> >>>>>>> An identifier of an Observation Point that is unique per >>>>>>> Observation Domain. It is RECOMMENDED that this >>>>>>> identifier is >>>>>>> also unique per IPFIX Device. Typically, this >>>>>>> Information >>>>>>> Element is used for limiting the scope of other >>>>>>> Information >>>>>>> Elements. >>>>>>> >>>>>>> We now also have observationPointType (#277), defined as: >>>>>>> >>>>>>> Type of observation point. Values assigned to date are: >>>>>>> >>>>>>> 1. Physical port >>>>>>> 2. Port channel >>>>>>> 3. Vlan. >>>>>>> >>>>>>> >>>>>>> Could we relax the uniqueness requirements of observationPointId >>>>>>> when >>>>>>> an observationPointType is also exported, such that the { >>>>>>> observationPointType, observationPointId } pair must be unique, >>>>>>> though >>>>>>> not the observationPointId itself. >>>>>>> >>>>>>> The reason being that observation points of different types already >>>>>>> have IDs, though these are not unique. eg, we have interface 1, >>>>>>> 2, 3, >>>>>>> ...; vlan 1, 2, 3, ...; port 1, 2, 3, ... >>>>>>> >>>>>>> So an extra mediation layer is required to convert values from >>>>>>> each of >>>>>>> these number spaces into unique IDs in the observationPointId >>>>>>> number >>>>>>> space - which becomes harder as we add more places that >>>>>>> observations >>>>>>> can be made, ie more observationPointTypes. >>>>>>> >>>>>>> Whereas prefixing with the observationPointType achieves the >>>>>>> required >>>>>>> uniqueness in a faster, simpler, and more reliable way. >>>>>>> >>>>>>> To achieve this, I'd propose the following definition change: >>>>>>> >>>>>>> An identifier of an Observation Point that is unique per >>>>>>> Observation Domain and per observationPointType, if >>>>>>> specified. >>>>>>> It is RECOMMENDED that this identifier is >>>>>>> also unique per IPFIX Device. Typically, this >>>>>>> Information >>>>>>> Element is used for limiting the scope of other >>>>>>> Information >>>>>>> Elements. >>>>>>> >>>>>>> For backwards compatibility, we could define >>>>>>> observationPointType = 0 >>>>>>> to be "unspecified". >>>>>>> >>>>>>> Thanks, >>>>>>> P. >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> IPFIX mailing list >>>>>>> IPFIX@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ipfix >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> IPFIX mailing list >>>>>> IPFIX@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ipfix >>>>>> >>>> >> From andrewf@plixer.com Thu Mar 28 05:01:17 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E28D421F8E5E for ; Thu, 28 Mar 2013 05:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZceVTtTHHCp for ; Thu, 28 Mar 2013 05:01:16 -0700 (PDT) Received: from smtp.plixer.com (smtp.plixer.com [64.140.243.151]) by ietfa.amsl.com (Postfix) with ESMTP id 4A70E21F8D8F for ; Thu, 28 Mar 2013 05:01:15 -0700 (PDT) Received: from [192.168.1.37] ([24.34.46.175]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Mar 2013 08:01:09 -0400 User-Agent: Microsoft-MacOutlook/14.3.2.130206 Date: Thu, 28 Mar 2013 08:01:02 -0400 From: Andrew Feren To: Paul Aitken , Gerhard Muenz Message-ID: Thread-Topic: [IPFIX] IPFIX observationPointId uniqueness In-Reply-To: <515412C7.1010103@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 28 Mar 2013 12:01:09.0650 (UTC) FILETIME=[EF6B1F20:01CE2BAB] Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] IPFIX observationPointId uniqueness X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 12:01:18 -0000 Hi Paul, Gerhard, I can't speak for other collectors, but I don't see a problem with increasing the length of observationPointId. I never saw any upside to doing anything other than respecting the length in a template when that length in the template differs from the nominal type size of the IE. For reduced size encoding this is a specified behavior disallowing increased size encoding seemed like extra work with no return. Also I think Gerhard made a good case for increasing the size being a better option than the original proposal. I didn't have an problem with the original proposal, but after considering Gerhard's arguments I think increasing the length of observationPointId is less likely to have any negative consequences. -Andrew On 3/28/13 5:52 AM, "Paul Aitken" wrote: >Gerhard, > >This question needs input from collector experts on this list. > >P. > > >On 27/03/13 20:54, Gerhard Muenz wrote: >> Paul, >> >> I do not see any problem with 64bit OP ID. >> >> I think, we had a similar motivation for having 64bit selector >> IDs/selection sequence IDs. >> >> Will it confuse existing collectors? (hopefully not) >> >> Regards, >> Gerhard >> >> >> On 26.03.2013 13:20, Paul Aitken wrote: >>> Gerhard, >>> >>> My problem is mapping multiple discrete 32-bit number spaces into a >>> single 32-bit Observation Point ID. >>> >>> Keeping track of the mapping could be impossibly expensive: in the >>>worst >>> case, 2^32 IDs x { (8-bit source type) + (32-bit source ID) + (32-bit >>> OPID) } = 36G of memory :-( >>> >>> This suggests that the number space should be carved, so source 1 uses >>> OP IDs 0 - 999, source 2 uses OP IDs 1,000 - 1,999 etc. However I can't >>> do that because there are only 32-bits in the destination (OP ID) >>>number >>> space. Each of the source number spaces is also 32-bits; I can't know >>> whether they'll be linearly allocated or sparsely populated (eg, by a >>> hashing algorithm), so I can't impose that certain bits (eg the topmost >>> bits) be used for the carving. >>> >>> A 64-bit OP ID would really help me. >>> >>> Thanks, >>> P. >>> >>> >>> On 13/03/13 21:42, Gerhard Muenz wrote: >>>> >>>> Paul, >>>> >>>> I always thought of OPID, ODID, MPID, EPID etc. as being abstract >>>> identifiers. If an implementation can map them directly to >>>> implementation-specific internal parameters, that's fine. If not, a >>>> mapping needs to be provided by the device. That's the same for other >>>> data models. >>>> >>>> For example, you would also need to assign ipfixObservationPointIndex >>>> for each OP if you implement IPFIX-MIB. You could use the same value >>>> for the OPID IE. >>>> >>>> If there is no other solution than map 32 bit directly into OPID, I >>>> would prefer changing OPID to unsigned64. >>>> >>>> Regards, >>>> Gerhard >>>> >>>> >>>> On 13.03.2013 11:26, Paul Aitken wrote: >>>>> Gerhard, >>>>> >>>>> We are monitoring traffic in multiple places - at the ingress and >>>>> egress >>>>> interfaces, at processes, in ACLs, in policies. >>>>> >>>>> Each of these has a unique 32-bit ID (ie, there may be up to N x >>>>> 32-bit >>>>> IDs). >>>>> >>>>> However, these IDs are in unique number spaces. eg, the interface ID >>>>> could happen to be the same as the process ID or the same as the >>>>> policy >>>>> ID. So it's not possible to say what the ID represents without >>>>>knowing >>>>> the type. >>>>> >>>>> You would meet this issue if you monitor interfaces and also want to >>>>> report PSAMP stats for each selection process. Somehow you need to >>>>> report distinct IDs for the interfaces versus the processes. >>>>> >>>>> Several possibilities come to mind: >>>>> >>>>> 1. use multiple different IEs, one per observation point type, with >>>>> multiple templates. This is not ideal, because we have to request new >>>>> IEs for each new observation point type, and store / export multiple >>>>> templates. ie, it adds a layer of unnecessary complexity rather than >>>>> rather than simplifying the export. >>>>> >>>>> 2. implement a conversion function, mapping the N x 32-bit IDs into >>>>> the >>>>> 1 x 32-bit observationDomainID space. Obviously only a limited >>>>> number of >>>>> conversions (1/N) are possible, and there'll be a trade-off between >>>>> the >>>>> table size and lookup time. >>>>> >>>>> 3. associate an observationPointType with each observationPointID, >>>>>and >>>>> not require any conversion at all. Each internal ID is mapped 1:1 >>>>>with >>>>> an observationPointId, with uniqueness being determined by the >>>>> associated observationPointType. This is the simplest and cleanest >>>>> solution. >>>>> >>>>> >>>>> So to answer your questions directly: >>>>> >>>>> - Do you really need OPID for your purpose? Have you thought about >>>>> using >>>>> IEs like ingressPhysicalInterface or ingressInterface? Or, if these >>>>> IEs >>>>> are not appropriate, about defining new IEs? >>>>> >>>>> - per (1) above, this makes for an unnecessarily complex >>>>> solution. >>>>> >>>>> >>>>> - If you need to use OPIDs and if you want to avoid any mapping, have >>>>> you thought about assigning the different sources (interface cards, >>>>> VLANs) to different ODs? >>>>> >>>>> - they are all within a single OD. >>>>> - Example use case: report packet counts as traffic progresses >>>>> through selection and filtering within the router. The report will be >>>>> exported in a single message with a single OD in the header. >>>>> It's not possible to export a single cohesive report using >>>>> multiple ODs. >>>>> >>>>> P. >>>>> >>>>> >>>>> >>>>> On 15/02/13 09:25, Gerhard Muenz wrote: >>>>>> >>>>>> Benoit, Paul, >>>>>> >>>>>> Like Benoit, I do not have a good feeling about this proposal. On >>>>>>the >>>>>> other hand, I have not found any RFC that really requires the use of >>>>>> OPIDs. Even RFC5476 leaves it open whether the OP is identified by >>>>>> OPID or any other IE. Therefore, I have been silent until now. >>>>>> >>>>>> IPFIX-CONFIG assumes that the OPID is assigned by the IPFIX device, >>>>>> i.e. it is not a configuration parameter. I think that we agree >>>>>>here. >>>>>> >>>>>> Up to now, the IPFIX RFCs do not impose any restriction on the OPID >>>>>> except for the uniqueness per OD. This means that various >>>>>> implementations are possible right now: >>>>>> 1) OPID is equal to an internal identifier (e.g. internal interface >>>>>> number) or a non-IPFIX MIB index (e.g. ifIndex, entPhysicalIndex). >>>>>> 2) OPID is equal to the IPFIX-MIB index ipfixObservationPointIndex >>>>>> 3) OPID is unrelated to any other index, the IPFIX device provides >>>>>> the >>>>>> internal mapping >>>>>> >>>>>> If IPFIX-MIB is supported by the device, the natural choice for me >>>>>> would be 2). This would allow easy mapping of MIB entries and IPFIX >>>>>> export. >>>>>> >>>>>> As Paul points out, 1) only works as long as the internal >>>>>>identifiers >>>>>> are unique per OD. >>>>>> >>>>>> My questions to Paul are: >>>>>> - Do you really need OPID for your purpose? Have you thought about >>>>>> using IEs like ingressPhysicalInterface or ingressInterface? Or, if >>>>>> these IEs are not appropriate, about defining new IEs? >>>>>> - If you need to use OPIDs and if you want to avoid any mapping, >>>>>>have >>>>>> you thought about assigning the different sources (interface cards, >>>>>> VLANs) to different ODs? >>>>>> >>>>>> Regards, >>>>>> Gerhard >>>>>> >>>>>> >>>>>> On 15.02.2013 01:23, Benoit Claise wrote: >>>>>>> Paul, >>>>>>> >>>>>>> At first glance, it looks reasonable. >>>>>>> But what would be the consequence on the Selection Sequence Report >>>>>>> Interpretation(see >>>>>>> http://tools.ietf.org/html/rfc5476#section-6.5.1). If >>>>>>> we use the observationPointId and it's not unique, then we need to >>>>>>> include the observationPointType? >>>>>>> Note that the sentence "It is RECOMMENDED that this identifier is >>>>>>> also >>>>>>> unique per IPFIX Device." was inserted specifically for this. >>>>>>> >>>>>>> Regards, Benot >>>>>>>> Dear IPFIX experts, >>>>>>>> >>>>>>>> IPFIX observationPointId (#138) is defined as: >>>>>>>> >>>>>>>> An identifier of an Observation Point that is unique >>>>>>>>per >>>>>>>> Observation Domain. It is RECOMMENDED that this >>>>>>>> identifier is >>>>>>>> also unique per IPFIX Device. Typically, this >>>>>>>> Information >>>>>>>> Element is used for limiting the scope of other >>>>>>>> Information >>>>>>>> Elements. >>>>>>>> >>>>>>>> We now also have observationPointType (#277), defined as: >>>>>>>> >>>>>>>> Type of observation point. Values assigned to date >>>>>>>>are: >>>>>>>> >>>>>>>> 1. Physical port >>>>>>>> 2. Port channel >>>>>>>> 3. Vlan. >>>>>>>> >>>>>>>> >>>>>>>> Could we relax the uniqueness requirements of observationPointId >>>>>>>> when >>>>>>>> an observationPointType is also exported, such that the { >>>>>>>> observationPointType, observationPointId } pair must be unique, >>>>>>>> though >>>>>>>> not the observationPointId itself. >>>>>>>> >>>>>>>> The reason being that observation points of different types >>>>>>>>already >>>>>>>> have IDs, though these are not unique. eg, we have interface 1, >>>>>>>> 2, 3, >>>>>>>> ...; vlan 1, 2, 3, ...; port 1, 2, 3, ... >>>>>>>> >>>>>>>> So an extra mediation layer is required to convert values from >>>>>>>> each of >>>>>>>> these number spaces into unique IDs in the observationPointId >>>>>>>> number >>>>>>>> space - which becomes harder as we add more places that >>>>>>>> observations >>>>>>>> can be made, ie more observationPointTypes. >>>>>>>> >>>>>>>> Whereas prefixing with the observationPointType achieves the >>>>>>>> required >>>>>>>> uniqueness in a faster, simpler, and more reliable way. >>>>>>>> >>>>>>>> To achieve this, I'd propose the following definition change: >>>>>>>> >>>>>>>> An identifier of an Observation Point that is unique >>>>>>>>per >>>>>>>> Observation Domain and per observationPointType, if >>>>>>>> specified. >>>>>>>> It is RECOMMENDED that this identifier is >>>>>>>> also unique per IPFIX Device. Typically, this >>>>>>>> Information >>>>>>>> Element is used for limiting the scope of other >>>>>>>> Information >>>>>>>> Elements. >>>>>>>> >>>>>>>> For backwards compatibility, we could define >>>>>>>> observationPointType = 0 >>>>>>>> to be "unspecified". >>>>>>>> >>>>>>>> Thanks, >>>>>>>> P. >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> IPFIX mailing list >>>>>>>> IPFIX@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/ipfix >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> IPFIX mailing list >>>>>>> IPFIX@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ipfix >>>>>>> >>>>> >>> > >_______________________________________________ >IPFIX mailing list >IPFIX@ietf.org >https://www.ietf.org/mailman/listinfo/ipfix From paitken@cisco.com Thu Mar 28 05:17:04 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 612C721F8EC9 for ; Thu, 28 Mar 2013 05:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.239 X-Spam-Level: X-Spam-Status: No, score=-10.239 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYiEmLKJ04vY for ; Thu, 28 Mar 2013 05:17:02 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 1063321F8EC6 for ; Thu, 28 Mar 2013 05:17:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11823; q=dns/txt; s=iport; t=1364473022; x=1365682622; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=+0mo/VDVu3NVjceixK23bGJAORq/lVF6qRBy2/y+C9A=; b=IXT1pHjH43xRhP1qtzKa6bWhhBZu0w6935C87NhHUJBlONXZ4y45xPjp bV+LAuQniXQNLdC8qs2E336aLnfokawdlMIxk8w0Q9xIVoEpYyIm2gJLP rdoRTmvLbaxETmBDUI9u5rJVCpK2nQsKLpYiz7hUfMlAVAWBI4w5g5TaN Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAEgzVFGQ/khR/2dsb2JhbABDgzoBvmOBAxZ0gh8BAQEEAQEBNTMDCgEQCxgJFg8JAwIBAgEVMAYBDAEFAgEBF4d5DL5mgk6LEoE4B4NAA5ZngR+EYIsIgws8gS4 X-IronPort-AV: E=Sophos;i="4.84,925,1355097600"; d="scan'208";a="12953072" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-4.cisco.com with ESMTP; 28 Mar 2013 12:17:00 +0000 Received: from [10.61.164.13] ([10.61.164.13]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r2SCGvnw020076; Thu, 28 Mar 2013 12:16:58 GMT Message-ID: <515434BA.7080808@cisco.com> Date: Thu, 28 Mar 2013 12:16:58 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Andrew Feren , Gerhard Muenz References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] IPFIX observationPointId uniqueness X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 12:17:04 -0000 Thanks Andrew and Gerhard. I'll forward the request to IE-doctors and IANA. P. On 28/03/13 12:01, Andrew Feren wrote: > Hi Paul, Gerhard, > > I can't speak for other collectors, but I don't see a problem with > increasing the length of observationPointId. > > I never saw any upside to doing anything other than respecting the length > in a template when that length in the template differs from the nominal > type size of the IE. For reduced size encoding this is a specified > behavior disallowing increased size encoding seemed like extra work with > no return. > > Also I think Gerhard made a good case for increasing the size being a > better option than the original proposal. I didn't have an problem with > the original proposal, but after considering Gerhard's arguments I think > increasing the length of observationPointId is less likely to have any > negative consequences. > > -Andrew > > > On 3/28/13 5:52 AM, "Paul Aitken" wrote: > >> Gerhard, >> >> This question needs input from collector experts on this list. >> >> P. >> >> >> On 27/03/13 20:54, Gerhard Muenz wrote: >>> Paul, >>> >>> I do not see any problem with 64bit OP ID. >>> >>> I think, we had a similar motivation for having 64bit selector >>> IDs/selection sequence IDs. >>> >>> Will it confuse existing collectors? (hopefully not) >>> >>> Regards, >>> Gerhard >>> >>> >>> On 26.03.2013 13:20, Paul Aitken wrote: >>>> Gerhard, >>>> >>>> My problem is mapping multiple discrete 32-bit number spaces into a >>>> single 32-bit Observation Point ID. >>>> >>>> Keeping track of the mapping could be impossibly expensive: in the >>>> worst >>>> case, 2^32 IDs x { (8-bit source type) + (32-bit source ID) + (32-bit >>>> OPID) } = 36G of memory :-( >>>> >>>> This suggests that the number space should be carved, so source 1 uses >>>> OP IDs 0 - 999, source 2 uses OP IDs 1,000 - 1,999 etc. However I can't >>>> do that because there are only 32-bits in the destination (OP ID) >>>> number >>>> space. Each of the source number spaces is also 32-bits; I can't know >>>> whether they'll be linearly allocated or sparsely populated (eg, by a >>>> hashing algorithm), so I can't impose that certain bits (eg the topmost >>>> bits) be used for the carving. >>>> >>>> A 64-bit OP ID would really help me. >>>> >>>> Thanks, >>>> P. >>>> >>>> >>>> On 13/03/13 21:42, Gerhard Muenz wrote: >>>>> Paul, >>>>> >>>>> I always thought of OPID, ODID, MPID, EPID etc. as being abstract >>>>> identifiers. If an implementation can map them directly to >>>>> implementation-specific internal parameters, that's fine. If not, a >>>>> mapping needs to be provided by the device. That's the same for other >>>>> data models. >>>>> >>>>> For example, you would also need to assign ipfixObservationPointIndex >>>>> for each OP if you implement IPFIX-MIB. You could use the same value >>>>> for the OPID IE. >>>>> >>>>> If there is no other solution than map 32 bit directly into OPID, I >>>>> would prefer changing OPID to unsigned64. >>>>> >>>>> Regards, >>>>> Gerhard >>>>> >>>>> >>>>> On 13.03.2013 11:26, Paul Aitken wrote: >>>>>> Gerhard, >>>>>> >>>>>> We are monitoring traffic in multiple places - at the ingress and >>>>>> egress >>>>>> interfaces, at processes, in ACLs, in policies. >>>>>> >>>>>> Each of these has a unique 32-bit ID (ie, there may be up to N x >>>>>> 32-bit >>>>>> IDs). >>>>>> >>>>>> However, these IDs are in unique number spaces. eg, the interface ID >>>>>> could happen to be the same as the process ID or the same as the >>>>>> policy >>>>>> ID. So it's not possible to say what the ID represents without >>>>>> knowing >>>>>> the type. >>>>>> >>>>>> You would meet this issue if you monitor interfaces and also want to >>>>>> report PSAMP stats for each selection process. Somehow you need to >>>>>> report distinct IDs for the interfaces versus the processes. >>>>>> >>>>>> Several possibilities come to mind: >>>>>> >>>>>> 1. use multiple different IEs, one per observation point type, with >>>>>> multiple templates. This is not ideal, because we have to request new >>>>>> IEs for each new observation point type, and store / export multiple >>>>>> templates. ie, it adds a layer of unnecessary complexity rather than >>>>>> rather than simplifying the export. >>>>>> >>>>>> 2. implement a conversion function, mapping the N x 32-bit IDs into >>>>>> the >>>>>> 1 x 32-bit observationDomainID space. Obviously only a limited >>>>>> number of >>>>>> conversions (1/N) are possible, and there'll be a trade-off between >>>>>> the >>>>>> table size and lookup time. >>>>>> >>>>>> 3. associate an observationPointType with each observationPointID, >>>>>> and >>>>>> not require any conversion at all. Each internal ID is mapped 1:1 >>>>>> with >>>>>> an observationPointId, with uniqueness being determined by the >>>>>> associated observationPointType. This is the simplest and cleanest >>>>>> solution. >>>>>> >>>>>> >>>>>> So to answer your questions directly: >>>>>> >>>>>> - Do you really need OPID for your purpose? Have you thought about >>>>>> using >>>>>> IEs like ingressPhysicalInterface or ingressInterface? Or, if these >>>>>> IEs >>>>>> are not appropriate, about defining new IEs? >>>>>> >>>>>> - per (1) above, this makes for an unnecessarily complex >>>>>> solution. >>>>>> >>>>>> >>>>>> - If you need to use OPIDs and if you want to avoid any mapping, have >>>>>> you thought about assigning the different sources (interface cards, >>>>>> VLANs) to different ODs? >>>>>> >>>>>> - they are all within a single OD. >>>>>> - Example use case: report packet counts as traffic progresses >>>>>> through selection and filtering within the router. The report will be >>>>>> exported in a single message with a single OD in the header. >>>>>> It's not possible to export a single cohesive report using >>>>>> multiple ODs. >>>>>> >>>>>> P. >>>>>> >>>>>> >>>>>> >>>>>> On 15/02/13 09:25, Gerhard Muenz wrote: >>>>>>> Benoit, Paul, >>>>>>> >>>>>>> Like Benoit, I do not have a good feeling about this proposal. On >>>>>>> the >>>>>>> other hand, I have not found any RFC that really requires the use of >>>>>>> OPIDs. Even RFC5476 leaves it open whether the OP is identified by >>>>>>> OPID or any other IE. Therefore, I have been silent until now. >>>>>>> >>>>>>> IPFIX-CONFIG assumes that the OPID is assigned by the IPFIX device, >>>>>>> i.e. it is not a configuration parameter. I think that we agree >>>>>>> here. >>>>>>> >>>>>>> Up to now, the IPFIX RFCs do not impose any restriction on the OPID >>>>>>> except for the uniqueness per OD. This means that various >>>>>>> implementations are possible right now: >>>>>>> 1) OPID is equal to an internal identifier (e.g. internal interface >>>>>>> number) or a non-IPFIX MIB index (e.g. ifIndex, entPhysicalIndex). >>>>>>> 2) OPID is equal to the IPFIX-MIB index ipfixObservationPointIndex >>>>>>> 3) OPID is unrelated to any other index, the IPFIX device provides >>>>>>> the >>>>>>> internal mapping >>>>>>> >>>>>>> If IPFIX-MIB is supported by the device, the natural choice for me >>>>>>> would be 2). This would allow easy mapping of MIB entries and IPFIX >>>>>>> export. >>>>>>> >>>>>>> As Paul points out, 1) only works as long as the internal >>>>>>> identifiers >>>>>>> are unique per OD. >>>>>>> >>>>>>> My questions to Paul are: >>>>>>> - Do you really need OPID for your purpose? Have you thought about >>>>>>> using IEs like ingressPhysicalInterface or ingressInterface? Or, if >>>>>>> these IEs are not appropriate, about defining new IEs? >>>>>>> - If you need to use OPIDs and if you want to avoid any mapping, >>>>>>> have >>>>>>> you thought about assigning the different sources (interface cards, >>>>>>> VLANs) to different ODs? >>>>>>> >>>>>>> Regards, >>>>>>> Gerhard >>>>>>> >>>>>>> >>>>>>> On 15.02.2013 01:23, Benoit Claise wrote: >>>>>>>> Paul, >>>>>>>> >>>>>>>> At first glance, it looks reasonable. >>>>>>>> But what would be the consequence on the Selection Sequence Report >>>>>>>> Interpretation(see >>>>>>>> http://tools.ietf.org/html/rfc5476#section-6.5.1). If >>>>>>>> we use the observationPointId and it's not unique, then we need to >>>>>>>> include the observationPointType? >>>>>>>> Note that the sentence "It is RECOMMENDED that this identifier is >>>>>>>> also >>>>>>>> unique per IPFIX Device." was inserted specifically for this. >>>>>>>> >>>>>>>> Regards, Benot >>>>>>>>> Dear IPFIX experts, >>>>>>>>> >>>>>>>>> IPFIX observationPointId (#138) is defined as: >>>>>>>>> >>>>>>>>> An identifier of an Observation Point that is unique >>>>>>>>> per >>>>>>>>> Observation Domain. It is RECOMMENDED that this >>>>>>>>> identifier is >>>>>>>>> also unique per IPFIX Device. Typically, this >>>>>>>>> Information >>>>>>>>> Element is used for limiting the scope of other >>>>>>>>> Information >>>>>>>>> Elements. >>>>>>>>> >>>>>>>>> We now also have observationPointType (#277), defined as: >>>>>>>>> >>>>>>>>> Type of observation point. Values assigned to date >>>>>>>>> are: >>>>>>>>> >>>>>>>>> 1. Physical port >>>>>>>>> 2. Port channel >>>>>>>>> 3. Vlan. >>>>>>>>> >>>>>>>>> >>>>>>>>> Could we relax the uniqueness requirements of observationPointId >>>>>>>>> when >>>>>>>>> an observationPointType is also exported, such that the { >>>>>>>>> observationPointType, observationPointId } pair must be unique, >>>>>>>>> though >>>>>>>>> not the observationPointId itself. >>>>>>>>> >>>>>>>>> The reason being that observation points of different types >>>>>>>>> already >>>>>>>>> have IDs, though these are not unique. eg, we have interface 1, >>>>>>>>> 2, 3, >>>>>>>>> ...; vlan 1, 2, 3, ...; port 1, 2, 3, ... >>>>>>>>> >>>>>>>>> So an extra mediation layer is required to convert values from >>>>>>>>> each of >>>>>>>>> these number spaces into unique IDs in the observationPointId >>>>>>>>> number >>>>>>>>> space - which becomes harder as we add more places that >>>>>>>>> observations >>>>>>>>> can be made, ie more observationPointTypes. >>>>>>>>> >>>>>>>>> Whereas prefixing with the observationPointType achieves the >>>>>>>>> required >>>>>>>>> uniqueness in a faster, simpler, and more reliable way. >>>>>>>>> >>>>>>>>> To achieve this, I'd propose the following definition change: >>>>>>>>> >>>>>>>>> An identifier of an Observation Point that is unique >>>>>>>>> per >>>>>>>>> Observation Domain and per observationPointType, if >>>>>>>>> specified. >>>>>>>>> It is RECOMMENDED that this identifier is >>>>>>>>> also unique per IPFIX Device. Typically, this >>>>>>>>> Information >>>>>>>>> Element is used for limiting the scope of other >>>>>>>>> Information >>>>>>>>> Elements. >>>>>>>>> >>>>>>>>> For backwards compatibility, we could define >>>>>>>>> observationPointType = 0 >>>>>>>>> to be "unspecified". >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> P. >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> IPFIX mailing list >>>>>>>>> IPFIX@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/ipfix >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> IPFIX mailing list >>>>>>>> IPFIX@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/ipfix >>>>>>>> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix From ramk@Brocade.com Thu Mar 28 14:06:09 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E64821F8FF0 for ; Thu, 28 Mar 2013 14:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.264 X-Spam-Level: X-Spam-Status: No, score=-3.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UsyL2ytVY++0 for ; Thu, 28 Mar 2013 14:06:07 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by ietfa.amsl.com (Postfix) with ESMTP id 0622621F8BE2 for ; Thu, 28 Mar 2013 14:06:07 -0700 (PDT) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id r2SL36NP026339; Thu, 28 Mar 2013 14:06:06 -0700 Received: from hq1wp-exchub01.corp.brocade.com ([144.49.131.13]) by mx0a-000f0801.pphosted.com with ESMTP id 1bcqdc880h-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 28 Mar 2013 14:06:06 -0700 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by HQ1WP-EXCHUB01.corp.brocade.com (10.70.36.99) with Microsoft SMTP Server (TLS) id 14.2.309.2; Thu, 28 Mar 2013 14:06:05 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::8c73:93bf:41b4:1443]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Thu, 28 Mar 2013 14:06:05 -0700 From: ramki Krishnan To: Gerhard Muenz , IPFIX Working Group Date: Thu, 28 Mar 2013 14:06:04 -0700 Thread-Topic: [IPFIX] clarification questions Thread-Index: Ac4rMRTQYHDORG/mSAqhpClT0ppV7wAobknw Message-ID: References: <515362E7.9040306@net.in.tum.de> In-Reply-To: <515362E7.9040306@net.in.tum.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7634EB63EFD984A978DFB46EA5174F2BFD7ECDEC9HQ1EXCH01corp_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-03-28_07:2013-03-28, 2013-03-28, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1211240000 definitions=main-1303280219 Cc: Ning So Subject: Re: [IPFIX] clarification questions X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 21:06:09 -0000 --_000_C7634EB63EFD984A978DFB46EA5174F2BFD7ECDEC9HQ1EXCH01corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Gerhard, Thanks a lot. More below. >>- With TimeoutCache and NaturalCache, the Flow is only exported when it i= s expired. At expiration, the Flow is immediately removed from the Cache. A= longlasting flow will result in a new Flow being created in the Cache. For applications, especially security, it would be worthwhile to periodical= ly export the flow for monitoring purposes. We could add an optional "expor= tInterval" parameter similar to PermanentCache for this. Your comments/thou= ghts would be appreciated. Hi Gerhard/All, >>It seems that your actual question is how flow selection fits into the IP= FIX device architecture which has been taken as a basis for RFC 6728. Concr= etely, you seem to wonder whether your flow selection is a kind of Selecti= on Process or a new kind of Cache (or maybe both?). The new data models I am trying to specify are based on the following draft= and presentation at the IETF Orlando meeting. It seems to me that a good = starting point is specifying a new flow selection process. Your comments/th= oughts would be appreciated. http://www.ietf.org/proceedings/86/slides/slides-86-ipfix-1.pptx http://datatracker.ietf.org/doc/draft-krishnan-ipfix-flow-aware-packet-samp= ling/ Thanks, Ramki From: Gerhard Muenz [mailto:muenz@net.in.tum.de] Sent: Wednesday, March 27, 2013 2:22 PM To: ramki Krishnan Cc: IPFIX Working Group; Ning So Subject: Re: [IPFIX] clarification questions Hi Ram, The configuration model of RFC 6728 does not cover flow selection. If you w= ant to configure something like flow selection, you need to extend the mode= l. It seems that your actual question is how flow selection fits into the IPFI= X device architecture which has been taken as a basis for RFC 6728. Concret= ely, you seem to wonder whether your flow selection is a kind of Selection= Process or a new kind of Cache (or maybe both?). I cannot answer this question because I do not know how it would be impleme= nted. Regarding your question: - With TimeoutCache and NaturalCache, the Flow is only exported when it is = expired. At expiration, the Flow is immediately removed from the Cache. A l= onglasting flow will result in a new Flow being created in the Cache. - It's different with PermanentCache. Here, the Flow remains in the Cache, = and the status is periodically exported. Regards, Gerhard On 27.03.2013 18:40, ramki Krishnan wrote: Dear IPFIX experts, >From RFC 6728, 1. Section 4.3.2 o Is there a way to periodically export the flows if we are using a Timeo= utCache or NaturalCache ? 2. Suppose we want to populate the cache only with long-lived large fl= ows (see Note1 below for data model definitions) o One way to achieve this would be to have a selection process, using a u= nique observation domain, which filters the long-lived large flows. Are any= other better ways ? 3. Continuing from 3) - suppose we want to sample the other flows (not= the long-lived large flows) o Is there a way to not include the long-lived large flows in the selecti= on process ? Note 1: - observationInterval: The minimum time interval to observe a flow f= or performing further processing of the flow. Unit is in seconds. - bandwidthThreshold: The minimum bandwidth of the flow during the o= bservation interval for declaring the flow a long-lived large flow. Unit is= in Mbps. For example, a flow which is at or above 10 Mbps (bandwidthThreshold )for a= time period of at least 30 seconds (observationInterval) could be declared= a long-lived large flow. -- Thanks, Ram (aka Ramki) _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --_000_C7634EB63EFD984A978DFB46EA5174F2BFD7ECDEC9HQ1EXCH01corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Hi Gerhard,

 

Thanks a lot. More below.

&nbs= p;

>>- With TimeoutCache and Nat= uralCache, the Flow is only exported when it is expired. At expiration, the= Flow is immediately removed from the Cache. A longlasting flow will result= in a new Flow being created in the Cache.

For applications, especially security, it would be worthwhile to periodi= cally export the flow for monitoring purposes. We could add an optional = 220;exportInterval” parameter similar to PermanentCache for this. You= r comments/thoughts would be appreciated.

 

Hi Gerhard/All,

<= p class=3DMsoNormal> 

>>It se= ems that your actual question is how flow selection fits into the IPFIX dev= ice architecture which has been taken as a basis for RFC 6728. Concretely, = you seem to wonder  whether your flow selection is a kind of Selection= Process or a new kind of Cache (or maybe both?).

The new data models I am trying to specify are based on the follo= wing draft and presentation at the IETF Orlando meeting.  It seems to = me that a good starting point is specifying a new flow selection process. <= /span>Your comments/thoughts would be appreciated.

 

http://www.ietf.or= g/proceedings/86/slides/slides-86-ipfix-1.pptx

http://datatracker.ietf.org/doc/draft-krishn= an-ipfix-flow-aware-packet-sampling/

 

Th= anks,

Ramki

 

From: Gerhard Muenz [mailto:muenz@net.in.tum.de]
Sent: = Wednesday, March 27, 2013 2:22 PM
To: ramki Krishnan
Cc: IPFIX Working Group; Ning So
Subject: Re: [IPFIX] clarification= questions

 = ;


Hi Ram,<= br>
The configuration model of RFC 6728 does not cover flow selection. I= f you want to configure something like flow selection, you need to extend t= he model.

It seems that your actual question is how flow selection f= its into the IPFIX device architecture which has been taken as a basis for = RFC 6728. Concretely, you seem to wonder  whether your flow selection = is a kind of Selection Process or a new kind of Cache (or maybe both?).
=
I cannot answer this question because I do not know how it would be imp= lemented.

Regarding your question:
- With TimeoutCache and Natura= lCache, the Flow is only exported when it is expired. At expiration, the Fl= ow is immediately removed from the Cache. A longlasting flow will result in= a new Flow being created in the Cache.
- It's different with PermanentC= ache. Here, the Flow remains in the Cache, and the status is periodically e= xported.

Regards,
Gerhard

On 27.03.2013 18:40, ramki Krishnan wrote:

Dear IPFIX experts,

 <= /p>

From RFC 6728,

1.      Section 4.3= .2

o   Is there a way to periodically export the flows if we are using a Timeou= tCache or NaturalCache ?

2. &= nbsp;    Suppose we want to populate= the cache only with long-lived large flows (see Note1  below for data= model definitions)

o   One way to achieve this would be to have a selection proc= ess, using a unique observation domain, which filters the long-lived large = flows. Are any other better ways ?

3.      Continuing from= 3) - suppose we want to sample the other flows (not the long-lived large f= lows)

o   Is there a way to not include the long-lived large flows in the selecti= on process ?

 

Note 1:

-        observationInterval: The minimum time interval to observ= e a flow for performing further processing of the flow. Unit is in seconds.=

-=      =    bandwidthThreshold: The minimum bandwi= dth of the flow during the observation interval for declaring the flow a lo= ng-lived large flow. Unit is in Mbps.

Fo= r example, a flow which is at or above 10 Mbps (bandwidthThreshold )for a t= ime period of at least 30 seconds (observationInterval) could be declared a= long-lived large flow.

 

--

Thanks,

Ram (aka Ramki)

 




_______________________________________________
<= pre>IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

 

= --_000_C7634EB63EFD984A978DFB46EA5174F2BFD7ECDEC9HQ1EXCH01corp_--